Add French blog post on AIOps and network observability

content/blog/aiops-observabilite-reseau-ia/index.fr.md

@@ -0,0 +1,111 @@
+---
+title: "AIOps et Observabilité Réseau : Préparer le Terrain pour l'IA"
+date: 2026-07-13
+authors:
+  - name: Damien
+    link: https://gitea.arnodo.fr/Damien
+tags:
+  - AIOps
+  - Observability
+  - Network Automation
+  - AI Agents
+---
+
+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 que je ne faisais pas juste du monitoring — 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.
+
+<!--more-->
+
+## 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 ?](https://www.ibm.com/think/topics/aiops) — définition et origine du terme (Gartner)
+- [Model Context Protocol — documentation officielle](https://modelcontextprotocol.io/docs/getting-started/intro)
+- [Introducing the Model Context Protocol](https://www.anthropic.com/news/model-context-protocol) — l'annonce d'origine, qui pose bien le problème que MCP résout
+- [Effective context engineering for AI agents](https://www.anthropic.com/engineering/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](https://gitea.arnodo.fr/Damien/arista-evpn-vxlan-clab)

content/blog/mlops-observabilite-reseau-ia/index.fr.md

@@ -1,111 +0,0 @@
----
-title: "MLOps et Observabilité Réseau : Préparer le Terrain pour l'IA (1/5)"
-date: 2026-07-10
-authors:
-  - name: Damien
-    link: https://gitea.arnodo.fr/Damien
-tags:
-  - MLOps
-  - Observability
-  - AIOps
-  - Network Automation
-  - AI Agents
----
-
-Je viens de terminer une stack de télémétrie complète sur mon lab EVPN/VXLAN : topologie, métriques et visualisation en temps quasi réel. En la construisant, je me suis rendu compte que je refaisais, sans le savoir au départ, une bonne partie des réflexes du MLOps. Ce premier article pose le cadre d'une série sur l'observabilité réseau — pourquoi elle compte, et pourquoi elle est le préalable obligé avant de brancher un agent IA sur son infrastructure.
-
-<!--more-->
-
-## Pourquoi parler de MLOps sur un blog réseau ?
-
-Ces derniers mois, j'ai construit 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, j'ai voulu que ce lab soit **observable** : je voulais 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 :
-
-- **IPFabric** comme source de vérité topologique (qui est connecté à qui, quels VLANs, quels VRFs)
-- **gnmic** pour la collecte de télémétrie via gNMI directement depuis les EOS
-- **Prometheus** pour le stockage des séries temporelles
-- **Grafana**, avec le panel weathermap, pour la visualisation — un script Python génère automatiquement le JSON du weathermap en croisant la topologie IPFabric et les métriques Prometheus, provisionné ensuite via l'API Grafana
-
-Ce projet est documenté au fil des issues sur mon repo `arista-evpn-vxlan-clab` (branche `feat/telemetry`), et il est fonctionnel aujourd'hui. Mais ce n'est pas la stack en elle-même qui m'a fait écrire cet article — c'est une prise de conscience en la construisant : je ne faisais pas seulement du "monitoring". Je posais les fondations d'un pipeline de données qui, un jour, pourrait nourrir un agent IA capable de raisonner sur mon réseau. Et ça, ça s'appelle du MLOps.
-
-## MLOps 101 : au-delà de la data science
-
-Le MLOps (Machine Learning Operations) est un ensemble de pratiques nées dans le monde de la data science pour répondre à un problème très concret : la majorité des projets de machine learning qui fonctionnent en notebook ne survivent jamais au passage en production. Les chiffres varient selon les études, mais l'ordre de grandeur qui revient souvent est que **la majorité des modèles entraînés ne sont jamais déployés**, et qu'une bonne partie de ceux qui le sont finissent par se dégrader silencieusement (data drift, model drift) faute de supervision.
-
-La leçon que la communauté MLOps en a tirée est simple, mais elle mérite d'être répétée : **l'observabilité n'est pas une option qu'on ajoute après coup, c'est la fondation sur laquelle tout le reste repose.** Un modèle sans monitoring n'est pas un modèle en production, c'est une boîte noire qu'on espère fiable.
-
-Cette leçon ne concerne pas que les data scientists. Elle s'applique à tout système qu'on prétend automatiser ou déléguer à une machine — y compris un réseau qu'on voudrait un jour rendre pilotable, en partie, par un agent IA.
-
-## Une grille de lecture en couches : infra, modèles, agents
-
-Ce qui m'a aidé à structurer ma réflexion, c'est de voir MLOps, AIOps et LLMOps non pas comme trois disciplines concurrentes, mais comme trois couches empilées :
-
-1. **La couche infrastructure** : est-ce que les données de base sont fiables, complètes, à jour ? (métriques, logs, topologie)
-2. **La couche modèle** : est-ce que ce qui est construit au-dessus (un modèle ML, une règle de corrélation, un LLM) reçoit des entrées de qualité, et est-ce qu'on peut mesurer sa performance dans le temps ?
-3. **La couche comportement/agent** : est-ce qu'on peut faire confiance aux décisions ou actions prises par ce système, et est-ce qu'on peut les auditer ?
-
-On ne saute pas d'étape. Un agent IA construit sur des modèles entraînés avec des métriques bruitées, elles-mêmes issues d'une infra mal instrumentée, hérite de toutes les faiblesses en cascade — avec en plus l'illusion de fiabilité que donne une réponse générée en langage naturel, assertive par construction.
-
-Transposé au réseau, ça donne un ordre de priorités très concret : avant de penser "IA", il faut d'abord avoir une télémétrie fiable, une source de vérité topologique à jour, et des logs exploitables. C'est exactement la couche 1 — et c'est celle sur laquelle je travaille depuis plusieurs mois avec IPFabric, gnmic et Prometheus.
-
-## Le parallèle réseau : une boîte noire, pour un humain comme pour une IA
-
-Un réseau sans observabilité structurée est une boîte noire. Ce n'est pas un scoop pour qui a déjà dû diagnostiquer une flap BGP à 2h du matin avec pour seul outil un `show` lancé équipement par équipement. Mais ce constat prend une dimension nouvelle quand on envisage qu'un agent IA puisse un jour interagir avec ce réseau.
-
-Un humain expérimenté compense le manque d'observabilité par de l'intuition, de la mémoire tribale, de la connaissance du contexte historique ("ce lien a toujours été instable, ne pas s'inquiéter"). Un agent IA n'a rien de tout ça. Il ne "voit" que ce qu'on lui donne à voir. Si les données qu'on lui expose sont partielles, obsolètes, ou incohérentes entre la topologie déclarée et l'état réel, il produira des réponses ou des actions fondées sur cette incohérence — avec la même assurance que s'il avait raison.
-
-Dans mon lab, le principe directeur que je me suis fixé est **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 il a un bénéfice direct pour la suite : des données propres et prévisibles, ce qui est exactement le prérequis pour qu'un système automatisé — IA ou pas — puisse s'appuyer dessus sans introduire de biais silencieux.
-
-## Vers l'agent IA : le rôle de MCP
-
-C'est là qu'intervient le Model Context Protocol (MCP), un protocole ouvert qui standardise la façon dont un LLM peut accéder à des outils et des sources de données externes. Dans le contexte réseau, MCP est en train de devenir le pont entre les données d'observabilité qu'on collecte (topologie, métriques, logs) et un agent IA qui doit s'en servir pour raisonner ou agir.
-
-Concrètement, un serveur MCP réseau expose des capacités — "donne-moi la topologie de ce site", "quelle est l'utilisation de cette interface sur les dernières 24h", "y a-t-il des logs d'erreur récents sur ce device" — que l'agent peut appeler à la demande, plutôt que de tout lui donner en vrac dans un prompt. C'est ce qui transforme des données brutes d'observabilité en **contexte exploitable**.
-
-L'écosystème des serveurs MCP orientés réseau est en pleine expansion en ce moment : autour d'IPFabric, autour de gNMI/Prometheus, et du côté de plusieurs constructeurs qui commencent à proposer leurs propres intégrations. C'est prometteur, mais ça reste jeune, et ça appelle à de la prudence :
-
-- **Lecture seule par défaut** : un agent qui interroge le réseau ne devrait pas, par défaut, avoir la capacité de le modifier
-- **Traçabilité** : chaque appel d'un agent à un outil MCP doit être journalisé et auditable, exactement comme on le ferait pour un accès humain privilégié
-- **Gouvernance explicite** : les capacités d'écriture, si elles existent, doivent être délibérément accordées et scopées, pas activées par défaut
-
-Je n'ai pas encore branché d'agent sur mon lab — ce sera l'objet du dernier article de cette série. Mais la raison pour laquelle je peux envisager cette étape sereinement, c'est que je ne pars pas d'une boîte noire : je pars d'une stack de télémétrie déjà en place.
-
-## Ce qui a été construit, et ce qui vient
-
-À ce stade, voici ce qui existe déjà sur le lab :
-
-- Une topologie EVPN/VXLAN à 28 devices Arista, répartie sur trois sites, gérée avec Containerlab
-- IPFabric comme source de vérité topologique
-- Une collecte de télémétrie gNMI via gnmic, alimentant Prometheus
-- Un weathermap Grafana généré automatiquement, combinant topologie et métriques temps réel
-
-Cette série va suivre l'ordre dans lequel j'ai construit — et je construis encore — cette stack :
-
-1. **(cet article)** MLOps et l'importance de l'observabilité — le cadre général
-2. **IPFabric** : comment utiliser la topologie comme source de vérité pour piloter le reste de la stack
-3. **Grafana / Prometheus / gNMI** : la mécanique de la télémétrie temps réel, du device au dashboard
-4. **Gestion des logs** : le chantier qui manque encore à ma stack aujourd'hui, et que je dois construire avant d'aller plus loin
-5. **Rendre le réseau "visible" par un agent IA** : MCP, agents, 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 dans lequel je la pense désormais. Le MLOps m'a donné une grille de lecture utile — infra d'abord, modèles ensuite, comportement des agents en dernier — et elle s'applique très bien à un réseau qu'on veut un jour rendre exploitable par une IA.
-
-La suite de cette série creusera chaque brique technique : IPFabric, la stack Prometheus/Grafana/gNMI, puis les logs, avant d'aborder la question de l'agent IA lui-même. Si vous construisez quelque chose de similaire, je serais curieux d'échanger sur vos choix d'architecture.
-
-## Ressources
-
-### Concepts
-- Documentation générale sur les pratiques MLOps (Google Cloud, AWS, Microsoft Learn proposent chacun des guides d'introduction)
-- Documentation du Model Context Protocol (spécification ouverte, disponible sur le site du projet)
-
-### Outils cités
-- [IPFabric](https://ipfabric.io/)
-- [gnmic](https://gnmic.openconfig.net/)
-- [Prometheus](https://prometheus.io/)
-- [Grafana](https://grafana.com/)
-- [Containerlab](https://containerlab.dev/)
-
-### Mon repo
-- [arista-evpn-vxlan-clab](https://gitea.arnodo.fr/Damien/arista-evpn-vxlan-clab) (branche `feat/telemetry`)