Ontologies, GraphRAG & Agents d’Action

1.1. L'Hallucination Opérationnelle et le Biais Statistique

L'architecture Transformer repose sur l'apprentissage auto-supervisé de représentations vectorielles au sein d'espaces multidimensionnels. Lorsqu'un LLM génère une analyse, il applique une distribution de probabilités conditionnelles :

Ce paradigme excelle dans l'assimilation du langage naturel. En revanche, l'exécution opérationnelle exige un tout autre invariant : le déterminisme sémantique.

Dans une infrastructure d'entreprise, un champ de données ou un indicateur d'état ne peut souffrir d'aucune ambiguïté probabiliste. Lorsqu'un agent dialogue avec un système d'exploitation, un ERP ou un SIEM, attribuer une valeur plausible à une variable inconnue constitue une défaillance critique, souvent qualifiée d'hallucination opérationnelle.

1.2. La Dette Cognitive dans le Système d'Information

Pourquoi les projets de migration logicielle, d'automatisation des processus ou de cyber-défense rencontrent-ils des frictions constantes ? La cause racine réside dans la dette cognitive structurelle des organisations.

Au fil des années, les schémas de bases de données se fragmentent. Les définitions fonctionnelles s'éparpillent entre plusieurs départements :

• Les développeurs nomment une entité account_status en se basant sur une logique technique d'authentification.
• L'équipe commerciale définit un compte client actif selon la date de signature de la commande.
• Les analystes cybersécurité tracent des identités sur la base de jetons d'accès émis par un annuaire Active Directory.

Les collaborateurs humains passent une proportion critique de leur temps à décoder les choix de modélisation de leurs prédécesseurs plutôt qu'à créer de la valeur. Si un humain hésite et commet des erreurs d'interprétation, un agent IA — privé de formalisation — interprètera arbitrairement ces données divergentes et propagera des erreurs systémiques dans ses prises de décision.

1.3. Définir un Contrat Sémantique Partagé

L'introduction d'une couche sémantique explicite permet de créer un espace unifié où chaque correspondance de données est gouvernée et vérifiable.

Cette couche sémantique se comporte comme un document vivant de l'organisation :

1. Elle réconcilie le vocabulaire technique avec les réalités métiers (taxonomie).
2. Elle décrit formellement les entités, leurs frontières et les actions admissibles.
3. Elle assure l'interopérabilité technique et sémantique entre des applications hétérogènes.

Dès lors que la signification d'un champ métier est explicitée au niveau du métamodèle, l'agent logiciel est déchargé de la tâche de deviner l'intention des créateurs de la donnée. L'ambiguïté est éliminée en amont de la génération du raisonnement.

2.1. Définition Formelle d'une Ontologie de Production

Dans l'ingénierie des systèmes autonomes, l'ontologie est la transcription formelle de la logique métier sous la forme d'un ensemble structuré de définitions vérifiables par machine.

Elle se compose de quatre éléments fondamentaux :

• Les Concepts (𝒞) : L'ensemble des entités manipulables au sein du système (ex. : Machine, Utilisateur, Contrat, Vulnerabilité).
• Les Propriétés (𝒫) : Les états et grandeurs attribués à chaque concept (ex. : score_cvss ∈ [0, 10], statut_connexion ∈ {Actif, Revoqué}).
• Les Relations typées (ℛ) : Les liaisons orientées et qualifiées reliant les concepts :

• Les Axiomes (𝒜) : Les propositions logiques imposant des vérités universelles sur le domaine. Un axiome interdit les incohérences d'état et guide le raisonnement déductif de l'agent sans recourir à des approximations statistiques.

2.2. La Qualification Sémantique des Relations : L'Exemple de la Dépendance

Pour illustrer l'importance de l'ontologie, analysons la relation « dépendre de » appliquée à la supervision d'une infrastructure d'entreprise. Dans une base de données non formalisée, relier un service A à un service B par une simple clé étrangère masque la nature de cette dépendance.

L'ontologie exige de catégoriser la relation selon son comportement réel en cas de rupture de service :

En l'absence de cette distinction, un agent confronté à une alerte sur le composant B ne peut pas calculer s'il doit ordonner l'isolation préventive du service A, basculer vers un mode dégradé ou simplement consigner un rapport dans les journaux d'audit.

2.3. Cas Pratique : Modélisation Ontologique d'un Incident de Sécurité

Formalisons le métamodèle d'un scénario de gestion d'incident informatique au sein d'une organisation.

Définition des Concepts et des Relations

Ontologie: "CyberSec_Ops_v1"
Concepts:
  - Service:
      proprietes: [nom (string), criticite (P1|P2|P3), statut (actif|degrade|eteint)]
  - Client:
      proprietes: [nom (string), support_vip (boolean), sla_heures (integer)]
  - Incident:
      proprietes: [ticket_id (string), cvss (float), domaine_attaque (string)]
  - Procedure:
      proprietes: [nom (string), automatisee (boolean), validation_humaine (boolean)]

Relations:
  - Client --[utilise]--> Service
  - Service --[depend_techniquement_de]--> Service
  - Incident --[affecte_directement]--> Service
  - Equipe --[est_responsable_de]--> Service
  - Procedure --[remedie_a]--> Incident

Déclaration des Axiomes Métier

Grâce à ces axiomes, l'agent ne formule pas d'hypothèse probabiliste sur ses prérogatives : son périmètre décisionnel est encadré de manière formelle par les règles de l'organisation.

3.1. Limites du Modèle Relationnel SQL face à la Topologie

Le modèle relationnel classique (SQL) organise l'information dans des tables interconnectées par des clés étrangères. Lorsque les requêtes portent sur la découverte de chemins indirects, de hiérarchies imbriquées ou de dépendances transversales, le modèle relationnel fait face à un mur de complexité algorithmique.

Considérons une question élémentaire pour un auditeur en sécurité :

Dans une base relationnelle, cette vérification nécessite une série de jointures multiples (JOIN) entre les tables organisations, filiales, contrats, clauses et droits. Si la filiale est rattachée au groupe par trois niveaux de sous-holdings, la requête implique une récursion dynamique lourde.

À l'inverse, le graphe de connaissances modélise les relations comme des entités de premier ordre (First-Class Citizens). Les entités constituent des nœuds, et leurs relations typées forment des arêtes directionnelles.

Sur cette structure, l'exploration de voisinage ne dépend pas du nombre total de lignes de la table, mais du degré de connectivité locale des nœuds.

Cependant, la simple traversée de relations explicites ne résout qu'une partie du problème : elle lit ce qui est déjà écrit. La véritable rupture technologique réside dans les mécanismes d'inférence.

3.2. L'Inférence Déductive : Du Fait Brut au Fait Calculé

L'inférence déductive est le processus logique par lequel le système dérive des faits nouveaux, mathématiquement certains, par application de règles axiomatiques strictes sur des faits établis.

Prenons la séquence formelle de notre cas d'usage :

# Faits observés dans le graphe :
1. Entreprise_A    ──[est_filiale_de]──>     Groupe_B
2. Groupe_B        ──[detient_contrat]──>    Contrat_Cadre_X
3. Contrat_Cadre_X ──[inclut_prestation]──>  Support_Premium
4. Contrat_Cadre_X ──[possede_clause]──>     Extension_Toutes_Filiales

# Règle déductive déclarée :
∀ x, y, c, p :
  (est_filiale_de(x, y) ∧ detient_contrat(y, c) ∧ possede_clause(c, Extension_Toutes_Filiales) ∧ inclut_prestation(c, p))
  ⇒ beneficie_directement(x, p)

À aucun endroit de la base de données relationnelle il n'a été saisi que l'Entreprise A dispose du Support Premium. L'inférence déductive génère dynamiquement cette nouvelle arête :

Pour un agent IA, cette capacité transforme son périmètre opérationnel : il n'interroge plus passivement un index de données enregistrées, il raisonne sur les règles de gestion de l'entreprise pour en déduire les droits réels en temps réel.

3.3. L'Inférence Inductive : Découverte de Motifs et Régularités Topologiques

À l'opposé de la déduction (qui va de la règle générale vers le cas particulier certain), l'inférence inductive observe les régularités statistiques pour identifier des relations probables.

Dans un graphe d'entreprise interconnectant les systèmes, les typologies d'utilisateurs, les incidents passés et les configurations matérielles, l'analyse topologique permet de déceler des structures récurrentes :

Appliquée à l'action d'un agent autonome :

1. Sur le volet commercial : L'agent identifie les opportunités de cross-selling en découvrant que des entités aux typologies de graphe identiques adoptent des modules logiciels complémentaires sans qu'aucune règle métier ne l'ait explicité au préalable.
2. Sur le volet cyberdéfense : L'agent constate qu'une machine présentant certaines dépendances de bibliothèques logicielles et certains profils de privilèges d'accès a une probabilité élevée d'être compromise lors d'une attaque en mouvement latéral, incitant à son isolation préventive.

4.1. L'Angle Mort du RAG Vectoriel Standard

Le système de Retrieval-Augmented Generation (RAG) vectoriel classique fonctionne selon un pipeline séquentiel linéaire :

Cette mécanique excelle dans la recherche de conformité textuelle ou la récupération de réponses documentaires directes (ex. : « Quelle est la politique de remboursement des frais de déplacement ? »).

En revanche, le RAG vectoriel est structurellement incapable de résoudre les requêtes de causalité multi-sauts (multi-hop reasoning).

Prenons un incident d'approvisionnement industriel ou une crise logistique :

Si ces chunks sont isolés dans une base vectorielle, le moteur de recherche par similarité cosinus va récupérer le document mentionnant NOVA et R24. En revanche, le chunk mentionnant que P200 entre dans E8 peut avoir un score de similarité trop faible par rapport à la question initiale pour entrer dans le top-k injecté dans le contexte du LLM.

Le modèle de langage n'ayant pas reçu l'ensemble de la chaîne dans sa fenêtre d'attention, il est aveugle : il affirme qu'aucun système majeur n'est menacé, ou invente un lien direct fictif.

4.2. Mécanique de la Traversée Multi-Sauts

Le GraphRAG résout cette impasse en combinant la recherche sémantique vectorielle avec la traversée topologique explicite d'un graphe de connaissances.

Le flux de traitement s'articule ainsi :

1. Extraction des entités nommées contenues dans la requête initiale.
2. Alignement des entités sur les nœuds pivots du Knowledge Graph.
3. Exécution d'une traversée de graphe sur N sauts (k-hop neighborhood expansion) pour collecter l'arbre complet des interconnexions.
4. Construction d'un contexte hybride associant les chunks textuels validés et le sous-graphe sérialisé (au format JSON-LD ou Cypher/nGQL).
5. Soumission du contexte enrichi au modèle pour analyse et décision opérationnelle.

4.3. Implémentation : Requête nGQL sous NebulaGraph

Dans les architectures de production, on privilégie les moteurs capables d'exécuter des traversées récursives à très faible latence sur des millions d'arêtes.

Voici une illustration d'extraction topologique sur NebulaGraph en langage nGQL permettant d'identifier récursivement l'ensemble des dépendances industrielles à partir du fournisseur défaillant :

/* Traversée en 3 sauts successifs depuis le nœud Fournisseur */
GO 1 TO 3 STEPS FROM "FOURNISSEUR_NOVA" OVER fournit, equipe, integre_dans
YIELD 
    $$.composant.code AS Composant,
    $$.sous_ensemble.reference AS SousSysteme,
    $$.equipement.nom AS ProduitImpacte;

Le résultat de cette requête fournit un graphe déterministe. Injecté dans le contexte du LLM, il garantit que l'agent dispose de l'arborescence exacte de la panne sans risquer la moindre omission.

4.4. Benchmark Industriel des Moteurs de Bases Graphes

Le dimensionnement d'une architecture GraphRAG impose un choix d'outillage adapté aux volumétries cibles :

Dans des contextes industriels manipulant des dizaines de millions de dépendances d'infrastructure, NebulaGraph représente souvent le meilleur compromis entre scalabilité horizontale, isolation sécurisée des espaces de calcul et temps d'exécution des traversées.

5.1. Les Trois Impératifs de l'Agent Autonome

Pour qu'un agent logiciel agisse avec pertinence sur un système d'information critique, son architecture ne peut pas s'appuyer sur une base de données unique. Elle doit résoudre simultanément trois impératifs opérationnels :

1. Retrouver l'information pertinente : Localiser des signaux faibles, des rapports d'incidents non structurés ou des documentations floues dans un référentiel documentaire.
2. Comprendre ses implications : Calculer l'impact systémique, parcourir l'arborescence des interconnexions et évaluer les effets de bord d'un dysfonctionnement.
3. Être autorisé à agir : Vérifier l'état de référence en temps réel, garantir l'intégrité transactionnelle de la modification et s'assurer des habilitations de sécurité associées.

5.2. Répartition Spécialisée des Responsabilités

Pour répondre à ces trois impératifs, on déploie une architecture de stockage tripartite :

5.3. Cas Pratique Intégré : Gestion d'une Panne d'Authentification Majeure

Analysons comment ces trois moteurs collaborent lors d'une défaillance d'un composant central d'un système d'information : l'interruption du service de SSO / Authentification centralisée.

1. Phase Topologique (Graphe) : L'agent interroge NebulaGraph. En 8 millisecondes, il identifie que la panne du SSO bloque immédiatement 12 microservices internes, affecte indirectement l'accès au portail de 45 clients finaux, et compromet un contrat industriel soumis à des pénalités financières après 15 minutes d'arrêt.
2. Phase Sémantique (Vectorielle) : L'agent soumet une requête à la base vectorielle pour retrouver les comptes-rendus de pannes similaires survenues au cours des 18 derniers mois. Il identifie un chunk documentant un incident lié à l'expiration d'un certificat TLS intermédiaire sur le proxy inverse.
3. Phase Transactionnelle (ACID) : L'agent interroge la base SQL pour vérifier la validité du certificat de secours, confirme que le statut de l'astreinte opérationnelle permet une modification automatisée sous mandat N2, applique la mise à jour et consigne l'opération dans le registre d'audit.

Aucune technologie de stockage prise isolément ne permet de résoudre cette équation opérationnelle. C'est leur assemblage orchestré qui confère à l'agent une efficacité mesurable et sécurisée.

6.1. La Cartographie des 7 Couches Technologiques

Déployer une infrastructure agentique au sein d'une organisation impose de maîtriser la chaîne de valeur d'exécution de bout en bout. S'en remettre à des API propriétaires distantes pose des défis structurels : fuite de données d'entreprise hautement stratégiques, coûts d'inférence non maîtrisés lors de boucles agentiques répétitives, et absence de garanties sur l'isolation des environnements d'exécution.

Une architecture agentique industrielle et maîtrisée se structure autour de 7 couches fondamentales :

7.1. L'Explosion Combinatoire des Intégrations Point-à-Point

Dans les premières générations d'architectures agentiques, l'intégration entre le modèle et les services tiers était réalisée au moyen d'appels d'outils (Tool Calling) codés sur mesure :

Si ce modèle fonctionne pour un prototype comportant un agent et deux outils, il s'effondre lors du passage à l'échelle industrielle.

Considérons une organisation déployant 20 agents spécialisés (sécurité, finance, logistique, RH) appelés à interagir avec 30 services ou bases de données de l'entreprise. Dans une logique d'intégration point-à-point, l'équipe d'ingénierie doit développer, maintenir et sécuriser :

Chaque intégration impose de gérer spécifiquement ses formats de sérialisation, sa méthode de découverte d'outils, ses politiques d'authentification et ses conventions de gestion d'erreur. Cette approche génère une dette technique ingérable et multiplie les surfaces d'attaque.

7.2. L'Architecture Model Context Protocol (MCP)

Le Model Context Protocol (MCP) standardise la communication entre les modèles décisionnels et les environnements d'outils. Il s'agit d'un standard ouvert qui introduit une séparation claire entre l'application consommatrice et les fournisseurs de capacités :

La complexité passe ainsi d'une relation multiplicative (N × M) à une relation additive linéaire :

• Le Client MCP : Embarqué au sein du harnais de l'agent, il gère la négociation de contexte, transmet les requêtes d'outils et reçoit les résultats structurés.
• Le Serveur MCP : Service léger agissant comme une passerelle d'accès vers les composants du système d'information (bases de données, API, terminaux de commande). Il expose de manière déclarative un catalogue de ressources, d'outils et de modèles de prompts vérifiables.

7.3. Coexistence API et MCP : Articulation Technique

Il est essentiel de dissiper une confusion fréquente : le MCP ne remplace pas les API d'entreprise ; il les encapsule.

L'API constitue le contrat technique d'exposition d'un logiciel métier. Le serveur MCP traduit ce contrat dans un format d'action standardisé et documenté que le modèle peut inspecter dynamiquement :

1. L'Agent interroge le Serveur MCP : "Quels outils sont disponibles ?"
2. Le Serveur MCP retourne le schéma JSON-Schema de l'action `bloquer_ip`.
3. L'Agent génère l'appel : bloquer_ip(ip="192.0.2.45", raison="Attaque brute-force").
4. Le Serveur MCP reçoit la commande, valide le typage et l'autorisation.
5. Le Serveur MCP appelle l'API REST interne du Firewall : POST /api/v2/firewall/rules.
6. Le Serveur MCP convertit la réponse HTTP 201 en un contexte exploitable par l'agent.

Grâce à cette abstraction, toute modification ou montée de version de l'API sous-jacente est traitée au niveau du serveur MCP sans impacter la logique de décision des agents.