Graphes de connaissances de mission : des preuves de conseil à une ontologie interrogée via MCP

Wed, 14 Oct 2026 00:00:00 +0000

Contexte

Le conseil en observation des processus produit des logigrammes, des notes d’entretien, des enregistrements d’écran et des recommandations. Une fois la mission livrée, ce matériau est de fait inerte : la mission suivante repart d’une page blanche, même lorsque la réponse avait déjà été trouvée ailleurs. La question de recherche est de savoir comment transformer les livrables, de documents en données typées, sourcées et interrogeables, afin qu’un assistant puisse répondre à « où avons-nous déjà vu cela, et qu’en avions-nous conclu ? » en citant des preuves vérifiables.

Deux exigences structurent le travail : la traçabilité (chaque assertion renvoie à sa preuve) et une stricte séparation entre preuve et connaissance (ce qui a été observé n’est pas ce qui a été généralisé). La génération augmentée par la recherche (RAG) est rapide à mettre en place, mais cite des passages, pas des assertions vérifiables ; une ontologie formelle est traçable, mais coûteuse. Ce projet explore une voie pragmatique entre les deux.

Approche

flowchart TB
 A["`Sources brutes de mission
immuables, hachées`"] --> B["`Journal d'événements en ajout seul
source de vérité`"]
 B --> C["`Base SQLite reconstructible
jetable`"]
 C --> D[Extraction déterministe]
 C --> E["`Extraction par LLM
simple force de proposition`"]
 D --> F["`Nœuds et arêtes proposés
avec provenance`"]
 E --> F
 F --> G{"`Revue humaine
hors MCP`"}
 G -->|validé| H[Graphe de connaissances]
 H --> I[MCP : preuves]
 H --> J[MCP : connaissances]
 H --> K[MCP : ontologie]
 I --> L[Assistant IA]
 J --> L
 K --> L

Le choix de conception central consiste à scinder l’interface en trois serveurs MCP selon le statut épistémique : preuves (observations attestées et sourcées), connaissances (généralisations) et ontologie (le méta-modèle lui-même). Cette séparation empêche un assistant de présenter une généralisation comme une observation.

flowchart TB
 subgraph SCHEMA["SCHÉMA · nommage"]
 ON["`serveur ontologie
Comment le nomme-t-on ?`"]
 end
 subgraph PROVEN["PROUVÉ · observé"]
 EV["`serveur preuves
Qu'a-t-on capté, et où ?`"]
 end
 subgraph GENERAL["GÉNÉRALISÉ · conclu"]
 KN["`serveur connaissances
Qu'en conclut-on ?
propose, ne valide jamais`"]
 end
 ON -. "type" .-> EV
 EV == "fonde chaque conclusion" ==> KN
 EV --> AI["`Assistant IA
réponses étiquetées par statut`"]
 KN --> AI
 ON --> AI

Le graphe est unique ; seules les façades sont séparées. La frontière qui compte passe entre preuves et connaissances : le serveur preuves ne renvoie que ce qui a été observé, et où ; le serveur connaissances renvoie des conclusions qui doivent remonter jusqu’à ces preuves, et aucun outil MCP ne peut marquer quoi que ce soit comme validé.

Méthodes

Méta-modèle. Un noyau fixe, complété de profils de mission et d’une ontologie spécifiée (v0). Chaque nœud porte une origine (structurelle, déterministe, extraite par LLM) et un statut (proposé → validé).
Invariants (I1–I6). Six invariants d’intégrité et de provenance. La provenance est obligatoire sur chaque nœud et chaque arête dérivés ; une recommandation doit pouvoir être rattachée, de proche en proche, à un constat sourcé ; les citations extraites par LLM doivent être des sous-chaînes littérales de leur fragment ; le statut « validé » exige une décision humaine enregistrée. Les sources brutes sont immuables ; la base de données est jetable et reconstruite à partir du journal.
Questions de compétence avant l’implémentation. Un jeu v0 de 33 questions, typées comme factuelles, agrégées, de traçabilité, de contradiction, temporelles, inter-missions et négatives (requêtes que le système doit refuser, par exemple une fuite entre clients), dans un format exécutable avec réponses attendues et références. Elles sont spécifiées, mais pas encore instanciées ni exécutées.
Protocole d’évaluation. Au moins 30 tâches en langage naturel, notées automatiquement ou par un juge. Le protocole d’évaluation a été versionné avant le premier commit d’implémentation (le même jour) ; plusieurs jalons ont ensuite été adaptés. Seuils : exactitude ≥ 0,8, citations valides ≥ 0,98, ancrage ≥ 0,95, fuite = 0, médiane ≤ 6 appels d’outils par tâche ; chaque question soluble en ≤ 3 appels ; G1 : κ inter-annotateurs ≥ 0,7 ; G2 : précision de l’extracteur ≥ 0,95 par type.
Phases P0–P6 avec points de contrôle humains. L’implémentation est déléguée à une session d’agent qui doit s’arrêter aux points de contrôle humains désignés et consigner les décisions en suspens.
Cartographie d’un logiciel en boîte noire. La même méthode a été appliquée à un logiciel commercial de gestion d’entreprise, sans lecture de son code source. La cible est un triplet de vérités — utilisateur, logiciel et base de données — reliées par des arêtes prouvées. Onze heuristiques (H1–H11) couvrent l’appariement de valeurs, la perturbation inverse et directe, les champs calculés, la visibilité conditionnelle, les différences entre scénarios, la fouille d’invariants, le fuzzing des saisies, les a priori sémantiques (jamais considérés comme preuve), le passage de la documentation au test et du symptôme à la règle. Entrées : l’arborescence des menus via AT-SPI, un relevé des écrans, le profilage des colonnes et une typologie d’événements issue du journal d’audit de l’application. Une hypothèse n’est acceptée qu’avec une contre-preuve indépendante ; les cartographies produites par l’éditeur sont tenues en quarantaine et servent d’oracle de notation.

Un extrait illustratif du graphe typé (libellés fictifs) : la préconisation n’est recevable que parce que la chaîne qui descend jusqu’à un fragment littéral d’une source est complète.

flowchart TB
 R["`Préconisation
point de saisie unique`"] -- répond à --> C["`Constat
double saisie à la réception`"]
 O["`Observation
« le stock est ressaisi à la main »`"] -- atteste --> C
 O -- extrait de --> F["`Fragment
notes d'entretien, lignes 40–52`"]
 F -- cite --> P["`Pièce source
hachée, immuable`"]
 C -- porte sur --> A["`Activité
réception des marchandises`"]
 A -- utilise --> S["`Écran
formulaire de réception`"]
 S -- module de --> Y["`Système
logiciel de gestion`"]

État d’avancement & résultats

Il s’agit principalement d’une conception partiellement implémentée, et non d’un système en service.

Pilote (corpus d’observation, passe déterministe). 6 195 fichiers (6,92 Go ; 61 copiés, 6 134 par référence hachée) acquis de manière idempotente ; 13 272 nœuds (dont un nœud par fichier source) et 6 022 arêtes issus de la base de l’outil de capture (extracteur v0.1), en 2,1 s, sans nouvel appel LLM (la passe relit les sorties VLM/ASR déjà stockées par l’outil de capture) ; 57 969 vérifications automatiques des invariants I1–I6, toutes passées (plusieurs sont vraies par vacuité sur ce corpus ; I6 n’est que partiellement appliqué).
Mesure sur jeu de référence. 145 unités d’annotation et 100 paires de résolution d’entités (245 au total). 97 unités sur 245 ont été annotées par l’auteur (67 frames, 30 segments ; aucun passage, aucune paire de résolution d’entités). Le second annotateur était l’agent LLM qui a implémenté l’extracteur : l’accord ci-dessous oppose donc l’auteur à l’agent LLM, ce n’est pas un κ entre humains, et le jalon G1 (adapté) n’a pas pu être évalué au sens strict. Accord : κ = 0,72 (logiciel, n = 69), 0,41 (écran, n = 67), 0,31 (catégorie, n = 69), 0,52 (limites de segments, n = 30) ; le rapport compte 69 frames pour deux champs alors que 67 ont été annotées, un écart non encore résolu. Précision de l’extracteur par rapport à la référence de l’auteur : 0,74, 0,43, 0,04, 0,63. Jalon G2 (précision de l’extracteur ≥ 0,95) non franchi ; le résultat sur la catégorie traduit un désaccord de définition, et non une erreur de calcul.
Cartographie du logiciel. Schéma de 427 tables sans aucune clé étrangère, aucun déclencheur ni aucune vue déclarés (toute la logique est applicative) ; 1 048 entrées de menu (899 feuilles) cartographiées ; 154 des 899 écrans relevés (17 %) ; 2 845 hypothèses de règles ramenées à 1 519 par un tri par LLM local et un dédoublonnage par plongements. Un audit aléatoire de 30 éléments par l’agent LLM superviseur a relevé 1 mauvaise décision de conservation ou de rejet (≈ 3 %, IC à 95 % : 0,6–17 %) ; aucun audit humain à ce stade. Un unique prototype MCP en lecture seule existe pour la cartographie du logiciel (ce n’est pas l’un des trois serveurs) ; aucune règle n’a encore été prouvée dans le logiciel. Le travail sur la VM s’est arrêté lorsque l’accès a été retiré, après que les traitements de cartographie ont surchargé l’hôte partagé ; il s’est poursuivi en local.

Mesure sur jeu de référence face aux jalons : les barres sont les valeurs mesurées par champ (n = 69, 67, 69 et 30 unités), la ligne orange est le seuil. Une seule barre de κ le franchit, aucune barre de précision.

---
config:
 xyChart:
 width: 540
 height: 320
 themeVariables:
 xyChart:
 backgroundColor: "transparent"
 plotColorPalette: "#3F86B8, #C46A2B"
---
xychart-beta
 title "Accord auteur × LLM, κ (G1 adapté, seuil 0,7)"
 x-axis ["logiciel", "écran", "catégorie", "segments"]
 y-axis "κ" 0 --> 1
 bar [0.72, 0.41, 0.31, 0.52]
 line [0.7, 0.7, 0.7, 0.7]

---
config:
 xyChart:
 width: 540
 height: 320
 themeVariables:
 xyChart:
 backgroundColor: "transparent"
 plotColorPalette: "#3F86B8, #C46A2B"
---
xychart-beta
 title "Précision vs référence de l'auteur (G2, seuil 0,95)"
 x-axis ["logiciel", "écran", "catégorie", "segments"]
 y-axis "Précision" 0 --> 1
 bar [0.74, 0.43, 0.04, 0.63]
 line [0.95, 0.95, 0.95, 0.95]

La cartographie du logiciel, en entonnoir : l’arborescence des menus est entièrement cartographiée, mais la couverture des écrans et la preuve restent loin derrière, et la chaîne d’hypothèses n’a encore produit aucune règle prouvée.

---
config:
 xyChart:
 width: 540
 height: 360
 themeVariables:
 xyChart:
 backgroundColor: "transparent"
 plotColorPalette: "#3F86B8"
---
xychart-beta
 title "Cartographie en boîte noire : de l'inventaire à la preuve"
 x-axis ["Entrées menu", "Feuilles", "Écrans", "Hypothèses", "Filtrées", "Prouvées"]
 y-axis "Nombre" 0 --> 3000
 bar [1048, 899, 154, 2845, 1519, 0]

Les trois serveurs MCP et l’évaluation de bout en bout (P4–P5) ne sont pas implémentés.

Limites & suite

Les résultats du pilote sont inférieurs aux seuils et reposent sur une annotation humaine partielle. Prochaines étapes : redéfinir l’étiquette de catégorie, constituer une référence entièrement humaine, mesurer à nouveau G1/G2, instancier les questions de compétence, puis construire les trois serveurs et dérouler le protocole d’évaluation. Pour la cartographie du logiciel, les heuristiques de perturbation en écriture attendent une autorisation écrite et une VM dédiée.

Stack technique

Python 3.11 · JSONL event log · SQLite · YAML ontology · MCP · AT-SPI · Ollama · pytest