Mise en place d’une conscience numérique pour un projet à l’ère de l’IA

Le besoin : empêcher la perte de contexte

Un agent ne garde aucun souvenir d’une session à l’autre. Il doit donc retrouver à chaque fois ce qui définit le projet, c’est-à-dire ses décisions, ses règles et son état actuel.

Or, sur AceMyExam, ces connaissances étaient dispersées entre des comptes rendus de réunion, des fichiers de consignes et un wiki obsolète, dont certaines pages décrivaient encore des outils supprimés. Faute de source unique faisant foi, ni l’équipe ni les agents ne savaient à quelle information se fier.

Nous avons donc créé un référentiel unique qui regroupe la version à jour de tout ce qui définit AceMyExam. Nous l’appelons le cerveau, car il joue le rôle d’une mémoire partagée entre tous les agents du projet.

Un graphe de connaissances plutôt que des documents

Chaque connaissance constitue un nœud du graphe, caractérisé par sa nature (décision, règle ou fait). Outre son contenu intégral, chaque nœud comporte un résumé concis qui en facilite la consultation rapide.

Il mentionne également sa date, sa source et son auteur, afin que l’on puisse en vérifier l’origine. Enfin, des liens qualifiés unissent les nœuds entre eux pour indiquer qu’une décision porte sur un sujet, qu’elle en remplace une autre ou qu’elle la contredit.

Ainsi, chaque information n’est stockée qu’à un seul endroit, et les pages de synthèse sont générées à partir de ces nœuds.

Chaque nœud porte aussi un statut, afin qu’un agent sache s’il peut s’y fier.

Son évolution : remplacer sans effacer

Le projet évoluant en permanence, le graphe doit suivre ses transformations. Lorsqu’un agent enregistre une information qui en remplace une plus ancienne, il doit le déclarer explicitement. L’ancien nœud passe alors au statut remplace : il demeure consultable dans l’historique, mais ne fait plus foi.

Ce changement se répercute aussitôt sur les pages de synthèse qui citaient l’ancien nœud, lesquelles passent au statut a_revoir. Enfin, si une nouvelle entrée contredit un nœud en vigueur sans le remplacer, le conflit est signalé afin qu’un humain puisse trancher.

Sa lecture par les agents

Un agent qui charge trop d’informations sature rapidement sa fenêtre de contexte. Par défaut, les outils de consultation ne renvoient donc que le résumé d’un nœud et ses liens, tandis que le texte intégral n’est fourni qu’à la demande.

Pour s’orienter, un agent peut d’abord interroger tout ce qui est en vigueur sur un sujet, avec les motifs de chaque décision. Il peut également effectuer une recherche en texte intégral, puis explorer les nœuds voisins de proche en proche. Enfin, l’historique d’un nœud lui permet de retracer les décisions antérieures qu’il a remplacées.

Par ailleurs, la recherche fonctionne sans embeddings dans cette première version, de sorte qu’aucun texte n’est envoyé à un fournisseur extérieur.

Le schéma ci-dessous représente le graphe autour d’un sujet ainsi que le chemin qu’y suit un agent pour se repérer.

Son écriture par les agents

Les agents écrivent directement dans le graphe sans validation préalable, puisque nous préférons corriger après coup plutôt que de ralentir l’écriture. En contrepartie, les outils imposent une structure. Une information écrite avec sa source entre en vigueur, tandis qu’une information sans source reste non vérifiée et n’apparaît pas dans la lecture par défaut.

Avant d’écrire, un agent doit également effectuer une recherche afin d’éviter les doublons. Enfin, un garde-fou refuse tout ce qui ressemble à un secret, et le graphe ne contient aucune donnée d’élève.

Une conscience dynamique et universelle

Cette conscience est dynamique, car ce sont les agents eux-mêmes qui la mettent à jour au fil de leur travail. Elle évolue donc en même temps que le projet, contrairement à une documentation que personne ne maintient.

Elle est aussi universelle, puisqu’elle est servie par le MCP, que Claude Code comme Codex savent utiliser. De plus, les consignes d’utilisation sont transmises par le serveur au moment de la connexion, si bien qu’un agent sait s’y repérer quel que soit son fournisseur.

Un export lisible du dernier état est par ailleurs régénéré chaque nuit, afin qu’un agent sans accès au MCP puisse tout de même le consulter. Ce même serveur porte enfin les canaux par lesquels nos agents s’écrivent, que je décris dans une autre étude.

C’est pourquoi ce système me semble important pour un projet à l’ère de l’IA. Comme le contexte n’est plus lié à une session ni à un fournisseur, il devient une propriété du projet lui-même.

Les difficultés rencontrées

• L’ancien wiki continuait d’exister. Afin d’éviter deux sources concurrentes, nous avons marqué ses pages comme anciennes plutôt que de les recopier.
• Le graphe ne pouvait pas être rempli par une simple recopie. Une information reprise de l’existant doit être vérifiée dans le code ou en production avant d’entrer en vigueur, sans quoi elle reste non vérifiée.
• Les pages de synthèse ne se mettent pas à jour seules. Une page signalée à revoir le reste jusqu’à ce qu’un agent la régénère, puisqu’aucune tâche de fond ne le fait dans cette version.

Les limites du système

Dans cette première version, chacun de nous peut remplacer n’importe quel nœud par l’intermédiaire de son agent. L’historique conserve toutefois la trace de chaque remplacement, et aucune donnée n’est effacée.

Par ailleurs, le nom de l’agent qui écrit est une simple déclaration et non une garantie, c’est pourquoi aucune règle ne s’appuie dessus. Enfin, il n’existe pas encore d’ingestion automatique, si bien que ce sont les agents qui synthétisent et écrivent lorsque nous le leur demandons.

La complémentarité entre l’IA et l’humain

Dans ce système, les agents entretiennent la mémoire du projet tandis que nous gardons la main sur sa direction.