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
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.
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 versionnée (v0). Chaque nœud porte une origine (structurelle, déterministe, extraite par LLM) et un statut (proposé → validé).
- Invariants (I1–I6). 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.
- Protocole d’évaluation. Au moins 30 tâches en langage naturel, notées automatiquement ou par un juge. Les seuils de passage ont été fixés en amont : 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 ; précision de l’extraction déterministe ≥ 0,95 par type ; κ inter-annotateurs ≥ 0,7.
- Phases P0–P6 avec jalons humains. L’implémentation est déléguée à une session d’agent qui doit s’arrêter à chaque jalon 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.
É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) acquis de manière idempotente ; 13 272 nœuds et 6 022 arêtes extraits en 2,1 s pour un coût LLM nul ; les six invariants au vert sur 57 969 vérifications.
- Mesure sur jeu de référence. 145 unités d’annotation et 100 paires de résolution d’entités. L’annotation humaine était partielle et le second annotateur était un LLM. Accord humain × LLM : κ = 0,72 (logiciel), 0,41 (écran), 0,31 (catégorie), 0,52 (limites de segments). Précision de l’extracteur par rapport à la référence humaine : 0,74, 0,43, 0,04, 0,63. Jalon G2 (≥ 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 filtre LLM local, avec 1 erreur de décision sur un échantillon de 50 éléments revu par l’agent superviseur. Un prototype MCP en lecture seule existe ; aucune règle n’a encore été prouvée dans le logiciel. Les travaux ont été suspendus après une surcharge de la VM hôte.
Mesure sur jeu de référence face aux seuils fixés à l’avance : les barres sont les valeurs mesurées par champ, la ligne orange est le seuil. Une seule barre le franchit.
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.
Les 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, puis construire les trois serveurs et mener l’évaluation préenregistrée. 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