Ajoute le premier article de la série observabilité réseau/MLOps

Introduit la série avec le contexte MLOps, la grille de lecture infra/modèles/agents, et le lab EVPN/VXLAN comme fil rouge.

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

@@ -0,0 +1,111 @@
+---
+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`)