Avant les agents IA, les fondations

Depuis quelques mois, toutes les discussions autour du réseau finissent au même endroit : les agents. Agents de troubleshooting, agents de configuration, copilotes d’exploitation. Les démos sont impressionnantes, les roadmaps se remplissent, les budgets suivent.

Et pourtant, en sortant d’AutoCon 5, ce n’est pas une démo d’agent qui m’a le plus marqué. C’est une session de Víctor Fernández qui posait une question beaucoup moins glamour : est-ce que vos données sont seulement en état de supporter tout ça ?

Je suis reparti convaincu d’une chose que je vois se confirmer sur le terrain : la première étape de l’adoption de l’IA en Network Operations, ce n’est pas l’IA. C’est un certain niveau de maturité en network automation : une source de vérité fonctionnelle et réellement adoptée, des workflows d’automatisation éprouvés, une observabilité qui produit de la donnée digne de confiance.

Le problème n’est pas le modèle

Quand un projet d’agent réseau échoue, on cherche presque toujours la cause du mauvais côté. On change de modèle, on retouche les prompts, on ajoute des outils, on rallonge la fenêtre de contexte.

Mais dans l’immense majorité des cas, le modèle n’est pas le maillon faible. Le maillon faible, c’est ce qu’on lui donne à voir.

Un agent ne « connaît » pas votre réseau. Il ne connaît que ce que vos systèmes acceptent de lui raconter : un inventaire, une topologie, des métriques, des alarmes, un historique de changements. Si cet inventaire est à moitié faux, si la topologie date de la dernière migration, si les alarmes ne sont corrélées à rien, l’agent ne va pas s’en apercevoir. Il va répondre quand même. Vite, avec assurance, et à côté.

C’est le vrai risque de l’IA appliquée à l’exploitation réseau, et il est plus insidieux qu’une panne : on ne se retrouve pas sans réponse, on se retrouve avec de mauvaises réponses produites plus vite. Et livrées avec un ton qui n’invite pas à les vérifier.

> pourquoi le site de Lyon est-il lent ?
La télémétrie montre le lien WAN principal de Lyon saturé à 92 %.
Je recommande de basculer le trafic vers le lien de secours via core-lyon-02.
Voulez-vous que je prépare le changement ?
réponse en 1,8 s · ton assuré
✗ core-lyon-02 : décommissionné il y a 8 mois
✗ inventaire : dernière mise à jour il y a 14 mois

Ce qu’on appelle vraiment « contexte réseau »

On emploie le mot « contexte » à tort et à travers. La session d’AutoCon lui donnait une définition que je trouve utile, parce qu’elle est opérationnelle, et je la complète d’une quatrième dimension. Le contexte réseau, c’est la combinaison de quatre choses :

• les relations entre services, équipements, ressources et clients : qui dépend de quoi, et qui est impacté si ça tombe ;
• l’état opérationnel et les événements temps réel : ce qui se passe maintenant, pas ce qui était vrai au dernier export ;
• l’historique des changements : ce qui a bougé, quand, et par qui ;
• l’intention : l’état attendu du réseau, celui que décrit la source of truth, par opposition à l’état observé.

L’intention est la dimension qui permet de répondre à la question que tout diagnostic finit par poser : est-ce que ce que j’observe est normal ? Et l’ensemble forme le minimum vital du raisonnement : un agent d’analyse d’incident privé de ces quatre dimensions ne peut pas raisonner correctement, pas plus qu’un ingénieur réseau qui ne connaîtrait rien de l’infrastructure sur laquelle il intervient.

Regardez cette liste et posez-vous la question honnêtement : dans votre environnement, ces quatre dimensions sont-elles accessibles, fiables, et reliées entre elles ?

Chez la plupart d’entre nous, la réponse est « en partie ». Les relations et l’intention vivent dans une source of truth, quand elle existe. L’état temps réel vit dans un outil de supervision qui ne parle pas à la source of truth. L’historique des changements vit dans un outil de ticketing. Ces silos sont exactement ce qui empêche un agent d’être utile, et aucun ne se résout avec de l’IA : ce sont des problèmes de données, pas des problèmes de modèle.

Encore faut-il que ce soit la bonne donnée, pas seulement de la donnée juste. Comme me le faisait remarquer Daren Fulwell dans les échanges qui ont suivi mes premières notes sur le sujet, de la télémétrie corrélée à de la configuration raconte ce qui se passe sur chaque équipement. Mais ce qui intéresse le métier, c’est la façon dont ces équipements coopèrent pour porter les applications. La télémétrie dit ce qui se passe ; c’est à la source of truth de dire qui dépend de qui, qui possède quoi, et où aller chercher la donnée d’observabilité pertinente. L’accès à la configuration, lui, referme la boucle Act → Observe → Reason : sans lui, l’agent observe mais n’agit jamais.

Reste la corrélation. Même quand toutes ces informations sont disponibles, elle n’est construite nulle part. La tentation est alors de laisser le LLM reconstruire ou deviner les relations en fouillant les données : c’est la mauvaise approche. Elle sature la fenêtre de contexte, et le résultat n’est ni déterministe, ni reproductible, ni testable, ni auditable. C’est justement un des rôles de l’automatisation : assembler ce contexte en amont, de manière déterministe, reproductible et auditable, et le fournir au LLM comme socle de son raisonnement.

L’IA est le chef d’orchestre, pas l’orchestre

J’utilisais déjà cette image il y a un an, pour parler d’automatisation. Elle vaut encore plus aujourd’hui, et elle vaut pour l’ensemble des fondations.

Un LLM, c’est une manière remarquablement intuitive de déclencher et d’orchestrer du travail. Mais en bout de chaîne, le travail est toujours exécuté par de l’automatisation, et il est toujours décidé à partir de données. L’IA dirige, elle ne joue pas : elle n’exécute qu’à travers des tools, locaux ou exposés via MCP, dont l’implémentation repose sur l’automatisation. Là aussi, on le voit : dans un contexte réseau, l’automatisation est le socle de l’Agentic AI.

Autrement dit :

• l’observabilité, c’est la capacité de percevoir : sans elle, l’agent agit à l’aveugle ;
• la source of truth, c’est la capacité de savoir : l’état voulu et les relations, la référence contre laquelle comparer ce qu’on perçoit et cadrer ce qu’on exécute ;
• l’automatisation, c’est la capacité d’agir : sans elle, l’agent peut recommander, mais rien ne se passe. Ce sont vos workflows existants qui exécutent : collecte de données, changements contrôlés, self-remediation.

Si l’orchestre ne sait pas jouer, un meilleur chef ne produira pas une meilleure musique. Il produira la même cacophonie.

C’est pour ça qu’il me semble important d’arrêter de traiter l’automatisation et l’observabilité comme des sujets techniques de second rang, des « enablers » qu’on financera plus tard. Dans un monde où l’IA arrive par-dessus, ce sont devenus des piliers stratégiques. Leur maturité plafonne mécaniquement la valeur de tout ce qu’on posera au-dessus.

La chaîne de valeur, dans l’ordre

Si je devais résumer ma conviction en une ligne, ce serait celle-ci :

Qualité de la donnée → Observabilité → Contexte → Agentic AI → Valeur

C’est une chaîne, pas un menu. On ne peut pas sauter un maillon, et chaque maillon plafonne les suivants. Concrètement, cela veut dire :

1. Fiabiliser la donnée. La source of truth doit être sous contrôle.
2. Construire l’observabilité. Télémétrie, topologie, inventaire, alarmes, historique de changements : collectés, datés, requêtables.
3. Corréler pour produire du contexte. C’est l’étape la plus souvent oubliée. Des données côte à côte ne font pas un contexte ; il faut les relations entre elles.
4. Exposer ce contexte par des API et des workflows. C’est ce qui rend le contexte consommable par autre chose qu’un humain devant un dashboard. C’est aussi, très concrètement, ainsi que se construit la fenêtre de contexte sur laquelle le raisonnement du LLM va s’appuyer.
5. Alors seulement, brancher des agents.

La forme cible de ce contexte, Víctor la résumait bien en réponse à l’un de mes posts : un graphe réseau en temps réel (services, équipements, ressources, clients et leurs relations), pour que l’agent puisse réellement naviguer les dépendances plutôt que de juxtaposer des exports.

La bonne nouvelle, c’est que les quatre premières étapes ont une valeur immédiate, indépendamment de l’IA.

Ce que j’en retiens

L’IA n’est pas un raccourci qui permettrait de sauter les années de travail d’automatisation et d’observabilité qu’on n’a pas faites. C’est l’inverse : elle rend ce travail plus rentable, et son absence plus coûteuse.

Les équipes qui tireront de la valeur des agents dans les deux ans ne seront pas celles qui auront choisi le meilleur modèle. Ce seront celles qui auront une Source de Vérité/Intent juste, une topologie à jour, une télémétrie exploitable et un historique de changements accessible par API.

Alors avant de vous demander quel agent déployer, posez-vous cette question : si je devais expliquer mon réseau à quelqu’un qui ne l’a jamais vu, en n’utilisant que mes systèmes, est-ce que j’y arriverais ?

Si la réponse est non, vous savez par où commencer. Et ce n’est pas par l’IA.

Merci à Víctor Fernández pour la session d’AutoCon 5 qui a déclenché cette réflexion.