Deux systèmes agentiques peuvent exploiter des données identiques et délivrer des résultats opérationnels radicalement différents

Deux systèmes peuvent reposer sur le même patrimoine de données et afficher des comportements à l’opposé. L’un se contente d’extraire l’information et de résumer ce qu’il trouve. L’autre comprend la portée opérationnelle de cette information, raisonne à partir d’elle et agit dans un cadre de gouvernance strict.

La différence clé réside rarement dans le modèle, l'infrastructure d'inférence ou le volume de données. Ce sont des composants nécessaires, mais ils ne constituent pas la couche architecturale décisive.

Ce qui compte, c’est l’architecture entre vos données d’entreprise et votre agent : le socle sémantique, la couche de contexte opérationnel en temps réel, le contexte agent spécifique aux tâches et le cadre de gouvernance qui transforme le raisonnement en actions maîtrisées.

C’est la partie que de nombreux projets d’IA d’entreprise sous-dimensionnent, et c’est pourquoi tant de démonstrations prometteuses ne survivent pas au passage en production.

1. Ontologie : la base sémantique

L'ontologie n'est pas seulement un schéma ou une taxonomie. Il s'agit d'une représentation formelle d'un domaine : les entités qui existent, les propriétés qui les caractérisent, les relations entre elles, les contraintes qui définissent des états valides et les règles qui permettent d'inférer de nouvelles connaissances à partir de faits existants.

Dans des implémentations plus formelles, c’est ici que des standards comme OWL 2 et la logique de description prennent tout leur sens. Sans vous enfermer dans ce formalisme, l’intérêt pratique est simple : une ontologie permet aux machines de comprendre comment les concepts s’articulent entre eux.

C'est ce qui permet à un agent d'inférer qu'un appareil présentant le symptôme X, sous la politique Y, dans l'environnement Z, se trouve dans un état qui nécessite l'action A, sans qu'on lui fournisse explicitement cette règle exacte à chaque fois. Il peut déduire la réponse car le sens du domaine a été modélisé.

Appliquée aux réseaux d’entreprise, une ontologie définit ce qu’est un point d’accès, ses liens avec les contrôleurs, les politiques, les utilisateurs, les applications, les localisations et la topologie physique. Elle identifie les modes de défaillance propres à chaque génération de matériel, ainsi que les liens de causalité entre les modifications de configuration et le comportement observé.

C'est la couche sémantique. Sans elle, les données restent déconnectées de leur signification opérationnelle. Grâce à elle, le système peut raisonner sur les connaissances en contexte.

C’est précisément pourquoi les entreprises qui ont investi massivement dans des plateformes pilotées par l’ontologie ont créé une telle valeur stratégique. Le défi ne réside pas seulement dans l’intégration des données. Il s’agit d’encoder suffisamment la sémantique métier pour que le logiciel puisse raisonner sur ces données avec une précision absolue.

2. Graphe de connaissances : ontologie instanciée

L'ontologie définit la structure du sens. Le graphe de connaissances instancie ce modèle avec des données d'entreprise réelles.

Les entités sont des nœuds typés. Les relations sont des arcs orientés et étiquetés. Les propriétés deviennent des attributs fondés sur des définitions ontologiques. Le résultat est une structure de graphe dans laquelle chaque élément porte une signification formelle plutôt qu'une simple étiquette.

C’est essentiel, car le graphe de connaissances permet un raisonnement multi-étapes que la recherche simple ne peut pas offrir.

Une recherche vectorielle permet de faire remonter des documents, à l’image d’une requête classique. Un parcours de graphe de connaissances permet de répondre à un tout autre type de question : quels segments du réseau sont à risque si cette vulnérabilité spécifique du firmware est exploitée, compte tenu des configurations de politiques actuelles et des populations d’utilisateurs actives sur ces segments ?

Voilà toute la différence entre la simple extraction d’information et le raisonnement sur un savoir relationnel structuré.

D’un point de vue opérationnel, le graphe de connaissances est aussi le garant de la traçabilité. Chaque fait doit être associé à une source, à un horodatage, à un niveau de confiance et à une relation clairement définie avec le reste du modèle de domaine. Lorsqu’un agent passe à l’action, l’entreprise doit pouvoir vérifier avec précision les connaissances qui ont justifié sa décision.

3. Graphe de contexte : la dynamique du savoir

C’est là que l’architecture devient beaucoup plus complexe. De nombreuses organisations parviennent à obtenir une ontologie et un graphe de connaissances. Moins nombreuses sont celles qui parviennent à maintenir ces connaissances connectées à ce qui se passe actuellement.

Les connaissances statiques ne suffisent pas aux agents autonomes évoluant dans des environnements dynamiques. Un graphe de connaissances fondé sur l’exécution ETL de la veille peut suffire à de l’analyse a posteriori, mais il est inutilisable pour un agent devant trancher en plein incident à 3 h du matin.

Le graphe de contexte résout ce problème en superposant l’état opérationnel en temps réel à la fondation sémantique du graphe de connaissances. Il ingère les flux de télémétrie en temps réel, les données de sessions actives, les séquences d’événements, les journaux de modifications des politiques et, point fondamental, les traces causales : le pourquoi de ce qui se passe, et pas seulement le quoi.

C’est aussi à ce stade que la modélisation causale prend tout son sens sur le plan opérationnel. Un graphe de contexte capable de capturer les dépendances causales – et pas de simples corrélations – permet à un agent de distinguer immédiatement un symptôme d’une cause profonde probable. Il peut anticiper les impacts en cascade d’une action avant même sa mise en œuvre. Il génère des traces décisionnelles parfaitement interprétables a posteriori par des opérateurs humains.

C’est la couche manquante dans de nombreuses implémentations. L’extraction d’information se limite à fournir des documents ou des outils à appeler. Un graphe de contexte causal offre une représentation en temps réel de ce qui se produit et des raisons qui l’expliquent.

Le graphe de contexte n'est pas un instantané. Il s'agit d'une représentation maintenue en continu et indexée temporellement de la réalité opérationnelle en direct, ancrée dans la précision sémantique de l'ontologie sous-jacente.

Reste à observer ce que les modèles du monde apporteront dans cet espace.

4. Contexte de l’agent : la distillation pour l’inférence

Le graphe de contexte est riche, mais la fenêtre de contexte d’un LLM est limitée. Surcharger un agent avec l’ensemble du graphe n’est ni efficace ni pertinent.

La couche de contexte de l’agent est ce qui permet de résoudre ce problème de distillation.

Pour chaque tâche, un sous-graphe spécifique est extrait : les entités, les relations, les chaînes causales et l’état en temps réel directement pertinents pour le raisonnement de l’agent. Ce sous-graphe est ensuite enrichi par trois composants supplémentaires.

Premièrement, le savoir procédural : les compétences, les flux de travail, les procédures opérationnelles standard (SOP) et les circuits d’escalade que l’agent peut exécuter. C’est le « comment » qui vient compléter le « quoi » et le « pourquoi » fournis par le graphe de contexte.

Deuxièmement, les contraintes de gouvernance : une représentation formelle de ce que l’agent est autorisé à réaliser en toute autonomie, de ce qui exige la vérification d’un seuil de confiance, de ce qui doit être transmis à un opérateur humain et de ce qui demeure strictement interdit, quel que soit le résultat du raisonnement. Il ne s’agit pas d’une simple consigne intégrée au prompt système. C’est un objet de politique structuré qui fait partie intégrante du contexte de l’agent et dont l’application est strictement garantie par le système environnant.

Troisièmement, l’armature des pistes d’audit décisionnel : la structure qui garantit que chaque action de l’agent génère une chaîne de raisonnement vérifiable, depuis les faits consignés dans le graphe de contexte jusqu’à l’action exécutée et au résultat observé, en passant par les étapes d’inférence. La boucle est ainsi bouclée, de l’action jusqu’à la mise à jour des connaissances.

C’est ce qui rend les décisions de l’agent explicables, auditables et véritablement exploitables sur le plan opérationnel. La vitesse n’est aucunement un facteur de différenciation si l’action exécutée n’inspire pas une confiance absolue.

5. Couche d’orchestration du système agentique : gouvernance et orchestration à l’échelle

La couche d’orchestration est celle que de nombreux fournisseurs évitent d’aborder, car c’est aussi la plus facile à survoler lors d’une démonstration.

Elle constitue l’ensemble de l’infrastructure d’orchestration : décomposition et coordination des tâches entre plusieurs agents, sélection et invocation des outils, gestion de la mémoire entre les interactions, intégration des boucles de feedback, et application de la gouvernance à mesure que les agents opèrent de manière autonome.

La couche d’orchestration est indispensable pour maintenir le système sur la bonne trajectoire, en particulier lorsqu’on évolue vers des systèmes orientés objectifs et non plus uniquement orientés tâches. Mais une couche d’orchestration sans socle sémantique revient à un système autonome dépourvu d’une compréhension ancrée du domaine dans lequel il opère.

Il peut être rapide et fluide, mais il montrera ses limites précisément là où les entreprises ont le plus besoin de confiance : les cas complexes en périphérie, les modes de défaillance inédits et les décisions qui nécessitent un raisonnement métier plutôt qu’une simple reconnaissance de schémas.

Pourquoi l’enjeu est désormais capital

Le marché de l'IA commence à se diviser en deux catégories distinctes.

D’un côté, on trouve des systèmes impressionnants lors de démonstrations rapides, conçus sur la simple recherche d’informations non structurées et capables de répondre avec fluidité à des questions courantes sur un périmètre restreint et à partir d’un jeu de données limité. Ces systèmes peuvent rendre service, mais ils se heurtent à une limite structurelle dès leur passage en production. Ils rencontrent des difficultés face aux cas spécifiques au domaine, généralisent mal dans des environnements opérationnels complexes et restent difficiles à fiabiliser pour une exécution autonome.

À l’opposé, on trouve des systèmes construits sur une pile sémantique bien architecturée : ontologie, graphe de connaissances, graphe de contexte, contexte agent et couche d’orchestration gouvernée.

Ces systèmes exigent plus de temps de développement. La couche sémantique n’a rien de spectaculaire et se prête rarement à une démonstration éclair. Elle requiert une expertise métier approfondie, une modélisation rigoureuse des données et un véritable engagement de l’organisation. En environnement de production, en revanche, la différence est radicale : le système raisonne sur le sens, explique ses décisions et opère au sein de limites parfaitement gouvernées.

Les piles d’IA qui définiront les infrastructures d’entreprise de la prochaine décennie – dans les réseaux, l’industrie, la santé, les services financiers et bien au-delà – sont conçues aujourd’hui par des équipes qui mesurent toute la portée de cette distinction et acceptent de fournir l’effort d’ingénierie nécessaire.

Nous bâtissons cette architecture depuis plus longtemps que la majorité des acteurs du marché. Ce que nous déployons aujourd’hui en production ne découle pas simplement du choix d’un meilleur modèle : c’est le fruit d’une démarche qui a consisté à ériger d’abord le socle sémantique, pour ensuite le connecter au contexte opérationnel en temps réel et à une exécution gouvernée.

L’ontologie n’a rien d’un détail technique : elle constitue l’un des fondements mêmes de la confiance. Tout ce qui est construit au-dessus — le graphe de connaissances, le graphe de contexte, le contexte agent et la couche d’orchestration — détermine si l’IA autonome reste une démonstration convaincante ou devient une véritable infrastructure sur laquelle les entreprises peuvent s’appuyer.

Je serais curieux de découvrir comment d’autres abordent ce cap, en particulier la transition d’un graphe de connaissances statique vers une couche de contexte dynamique et structurée sur le plan causal. À mes yeux, c’est précisément là que se concentre l’essentiel du travail d’ingénierie et d’organisation.