AIOps et Observabilité Réseau : Préparer le Terrain pour l'IA

Je viens de terminer une stack d’observabilité complète sur mon lab EVPN/VXLAN : topologie, télémétrie et visualisation en temps quasi réel. En la construisant, j’ai compris ce que je faisais réellement : je préparais un réseau à être un jour « vu » par une IA. Ce premier article pose le cadre d’une série de cinq : pourquoi l’observabilité est le préalable obligé avant de brancher un agent sur son infrastructure.

Ce que je viens vraiment de construire

Ces derniers mois, j’ai monté un lab Containerlab EVPN/VXLAN de 28 équipements Arista EOS, répartis sur trois sites (campus, core, datacenter). Au-delà du BGP EVPN lui-même, je voulais que ce lab soit observable : pouvoir dire, à tout instant, quel est l’état réel du réseau. Pas seulement « est-ce que ça ping », mais quelle est la topologie effective, quelles interfaces sont up, quels compteurs dérivent.

Le résultat est une stack qui combine quatre briques :

• un outil de discovery et d’assurance réseau qui sert de source de vérité topologique (qui est connecté à qui, quels VLANs, quels VRFs) ;
• une collecte de télémétrie via gNMI directement depuis les EOS ;
• une base de séries temporelles pour le stockage des métriques ;
• une couche de visualisation régénérée automatiquement en croisant la topologie et les métriques.

C’est fonctionnel aujourd’hui. Mais ce n’est pas la stack elle-même qui m’a fait écrire cet article : c’est une prise de conscience en la construisant. Je ne posais pas seulement de la supervision, je posais les fondations d’un pipeline qui, un jour, pourrait permettre à un agent IA de raisonner sur mon réseau. Et ça, ça a un nom.

AIOps, pas MLOps

Il faut lever une ambiguïté tout de suite, parce que les deux termes se confondent souvent.

Le MLOps (Machine Learning Operations) est la discipline qui consiste à opérationnaliser le cycle de vie de modèles de machine learning : entraînement, versioning des jeux de données, déploiement, surveillance de la dérive. Ce n’est pas ce que je fais ici. Je n’entraîne aucun modèle, je n’en déploie aucun.

Ce que je fais relève de l’AIOps : rendre une infrastructure observable et exploitable par des systèmes automatisés, et, à terme, par une IA. Le centre de gravité n’est pas le modèle, c’est la donnée d’infrastructure : sa fraîcheur, sa cohérence, sa structure. C’est exactement le périmètre de cette série.

Je cite tout de même le MLOps une fois, comme discipline sœur, parce que c’est elle qui a normalisé une idée dont l’AIOps hérite directement : l’observabilité n’est pas une option qu’on ajoute après coup, c’est la fondation sur laquelle tout le reste repose. La communauté ML l’a appris à ses dépens : une large part des projets qui fonctionnent en notebook ne survivent jamais au passage en production, faute d’être supervisés. La leçon vaut pour tout système qu’on prétend déléguer à une machine. Y compris un réseau.

L’agent aveugle

Voici la thèse centrale de cet article, et le fil rouge de toute la série.

Un agent IA sans observabilité est un agent aveugle. Il ne « voit » que ce qu’on lui expose. Et un aveugle à qui l’on ne donne rien à voir ne s’arrête pas pour autant : il avance quand même, avec la même assurance que s’il y voyait clair.

Prenons un cas concret. J’ai fait migrer un serveur d’un VLAN vers un autre, le week-end dernier. La source de vérité topologique n’a pas encore reçu son cycle de discovery : elle décrit toujours l’ancien rattachement. J’ouvre une conversation avec un agent censé m’aider : « ce serveur ne répond plus depuis ce matin, où est le problème ? »

L’agent interroge ce qu’on lui a exposé, lit l’ancienne topologie, et répond avec aplomb : « Le serveur est rattaché au leaf-3 sur le VLAN 20, l’uplink est nominal, vérifie plutôt sa configuration IP. » La réponse est cohérente, bien formulée, argumentée. Elle est aussi entièrement fausse : le serveur est sur le leaf-7 depuis samedi. L’agent n’a pas menti, il n’a pas halluciné au sens strict : il a raisonné correctement sur une donnée périmée. Et à aucun moment il n’a signalé qu’il pouvait se tromper, parce qu’à aucun moment il n’a eu conscience de ne pas voir.

C’est ça le vrai danger. Un humain expérimenté compense le manque d’observabilité par de l’intuition, de la mémoire tribale, du contexte historique (« ce lien a toujours été instable, ne t’inquiète pas »). Un agent n’a rien de tout ça. Une donnée partielle, obsolète ou incohérente entre la topologie déclarée et l’état réel ne le rend pas prudent : elle le rend confiant à tort. L’assurance de la réponse générée en langage naturel masque la pauvreté de ce qu’il a réellement perçu.

Je précise qu’aucun agent ne tourne aujourd’hui sur ce lab : ce sera précisément l’objet du dernier article de cette série.

L’observabilité n’est donc pas une fin en soi. C’est la condition de possibilité pour qu’un agent puisse un jour voir le réseau avant d’agir dessus. Sans elle, on ne construit pas un assistant : on construit un aveugle sûr de lui.

Une grille de lecture en couches

Ce qui m’a aidé à structurer tout ça, c’est de raisonner en couches empilées, et d’accepter qu’on ne saute pas d’étape :

1. L’infrastructure d’abord. Les données de base sont-elles fiables, complètes, à jour ? Topologie, métriques, logs.
2. Le modèle ensuite. Ce qui est construit au-dessus : une règle de corrélation, un modèle, un LLM reçoit-il des entrées de qualité, et peut-on mesurer sa pertinence dans le temps ?
3. Le comportement de l’agent en dernier. Peut-on faire confiance à ses réponses et ses actions, et peut-on les auditer ?

L’ordre n’est pas négociable. Un agent construit au-dessus d’une couche 1 bancale hérite de toutes ses faiblesses en cascade, avec en prime l’illusion de fiabilité d’une réponse assertive par construction. On ne rattrape pas une infra mal instrumentée par un meilleur prompt.

Transposé au réseau, ça donne un ordre de priorités très concret : avant de penser « IA », il faut une télémétrie fiable, une source de vérité topologique à jour, et des logs exploitables. C’est la couche 1. C’est celle sur laquelle je travaille depuis des mois, et c’est celle que cette série va détailler.

Ce que « voir » veut dire pour un réseau

Concrètement, donner la vue à un agent réseau, c’est réunir trois choses :

• Une source de vérité topologique à jour. Qui est connecté à quoi, quels VLANs, quels VRFs, quel site. Sans elle, l’agent ne sait même pas de quoi il parle : c’est le cœur du prochain article.
• Une télémétrie temps réel. L’état vivant du réseau : interfaces up/down, compteurs, utilisation, dérives. La topologie dit la structure ; la télémétrie dit le comportement.
• Des logs exploitables. Le récit des événements : qui a changé quoi, quand, et quelles erreurs sont remontées.

Sur ces trois piliers, deux sont en place sur mon lab. Le troisième, les logs, reste un chantier que je n’ai pas encore mené. Je le dis honnêtement, parce que c’est le genre de trou qu’on est tenté de balayer sous le tapis : « j’ai la topo et les métriques, c’est déjà bien ». Sauf qu’un agent privé de logs voit l’état présent sans comprendre comment on y est arrivé. C’est un prérequis, pas un bonus.

Il y a un principe qui traverse toute cette couche 1, et que je me suis fixé comme règle : la standardisation plutôt que l’adaptabilité. Quand les conventions de nommage sont respectées partout : interfaces, hostnames, labels, aucun code ne vient compenser les écarts. C’est un humain qui corrige la configuration en amont, pas un script qui devine. Ce choix a un coût, de la rigueur en continu, mais un bénéfice direct : des données propres et prévisibles. Et des données propres, c’est précisément ce qui permet à un agent de ne pas construire des raisonnements justes sur des faits faux.

Voir ne suffit pas : il faut donner à voir

Réunir les données : topologie, télémétrie, logs, ne suffit pas : encore faut-il les structurer et les exposer intelligemment à l’agent, plutôt que de les lui déverser en vrac, au risque de saturer sa fenêtre de contexte et d’obtenir des réponses tout aussi assurées mais tout aussi peu fiables. C’est là qu’interviennent deux notions à retenir, le context engineering et le Model Context Protocol (MCP), que je développerai en détail dans le cinquième et dernier article de cette série.

La série

Cette série va suivre l’ordre dans lequel j’ai construit (et je construis encore) cette stack :

1. (cet article) AIOps et l’importance de l’observabilité réseau : le cadre général.
2. La topologie comme source de vérité : utiliser le discovery et l’assurance réseau pour piloter le reste de la stack.
3. La télémétrie temps réel : la mécanique des métriques et des séries temporelles, du device au dashboard.
4. La gestion des logs : le chantier qui manque encore à ma stack, et que je dois mener avant d’aller plus loin.
5. Rendre le réseau « visible » par un agent IA : context engineering, MCP, et les débuts de l’AIOps appliqué à mon lab.

Conclusion

Rien de tout ça n’est révolutionnaire pris isolément : de la télémétrie réseau, on en fait depuis longtemps. Ce qui change, c’est le cadre. Tant qu’on instrumente un réseau pour des humains, une donnée manquante se traduit par un point d’interrogation, quelqu’un remarque le trou et va chercher l’info ailleurs. Le jour où l’on branche un agent, ce même trou ne produit plus un doute : il produit une réponse fausse, énoncée avec assurance.

C’est pour ça que l’observabilité passe en premier, et l’agent en dernier : non pas parce que l’IA serait accessoire, mais parce qu’elle est aveugle par défaut, et qu’on ne confie pas les yeux d’un système avant d’avoir construit ce qu’il doit voir. Si vous construisez quelque chose de similaire, je serais curieux d’échanger sur vos choix d’architecture.

Ressources

Concepts

• Qu’est-ce que l’AIOps ? — définition et origine du terme (Gartner)
• Model Context Protocol — documentation officielle
• Introducing the Model Context Protocol — l’annonce d’origine, qui pose bien le problème que MCP résout
• Effective context engineering for AI agents — l’article de référence sur le context engineering, y compris le phénomène de saturation de la fenêtre de contexte
• Observability Engineering (O’Reilly, 2e édition), Charity Majors, Liz Fong-Jones, George Miranda : la référence du domaine, avec un chapitre dédié à l’essor des agents et des LLM

Mon repo

• arista-evpn-vxlan-clab