Les agents ont besoin d’une mémoire vérifiée, pas de tout l’historique : comment construire leur contexte

Lorsque Claude Code a soudainement été bloqué, l’auteur d’une analyse publiée sur Habr est passé à Codex et a fait une découverte désagréable : le code était toujours sur le disque, mais des mois de discussions sur l’architecture, les bugs et les expériences abandonnées restaient prisonniers de l’ancien outil. Sur 25 projets et 53 conversations, l’import intégré a transféré environ 50 sessions, avec, en plus, des rattachements incorrects aux projets. Un débat s’est ensuite engagé dans les commentaires, et c’est lui qui présente davantage d’intérêt que la migration elle-même.

Le débat portait sur des tâches différentes

Les uns disaient : conservez les décisions et les plans dans Git, l’historique des conversations ne vaut rien. D’autres proposaient des skills, des bases de connaissances et des spécifications. D’autres encore rappelaient que l’état interne du raisonnement d’un modèle ne se transfère pas d’un fournisseur à l’autre. Tous avaient raison : ils cherchaient simplement à résoudre des problèmes différents.

Première tâche : donner à l’agent une compréhension à jour du projet. Pour cela, AGENTS.md ou CLAUDE.md, une documentation récente, des ADR, des plans de travail et des tests suffisent. Pour les grandes bases de code, on ajoute des outils de navigation : Aider Repo Map, par exemple, construit une carte compacte du projet en tenant compte du budget de tokens. Deuxième tâche : retrouver l’expérience passée — ce qui a été essayé, ce qui a été écarté et pourquoi. Troisième tâche : reprendre un travail interrompu lorsque la limite a été atteinte à mi-parcours et que personne n’a rédigé de HANDOFF.md.

Git, en soi, n’est toutefois pas une mémoire. C’est un système de gestion de versions, dont la valeur dépend de ce que vous y déposez et de la fraîcheur de ces informations.

Exemple : une erreur TUN sous Windows

L’auteur développe NetRuleRouter, un logiciel de routage du trafic. En enquêtant sur l’erreur 5010 de Windows TUN, l’agent a retrouvé, grâce à Hansard, que le portable de test TUF était une machine Windows distincte disposant d’une copie locale du dépôt. Ce type d’information n’a pas sa place dans la documentation d’architecture, mais fait gagner du temps lors du diagnostic. L’auteur apporte toutefois une précision honnête : il n’a pas encore mesuré si Hansard avait accéléré la correction.

Parmi les outils similaires, deja-vu indexe les journaux des agents de programmation et peut reconstituer un travail inachevé, rechercher des sessions à partir d’un fichier et signaler les solutions rejetées. Quant à baton, il transfère les sessions entre agents en ligne de commande lorsque l’ancien agent ne peut plus répondre.

La mémoire a un coût et peut se tromper

Dans une expérience menée avec MemShelf, au 38e jour, l’index et les synthèses de 157 épisodes occupaient environ 36 600 tokens, soit 18,3 % d’une fenêtre de 200 000. Sur une période distincte de 30 jours, l’auteur n’a trouvé aucun appel aux outils de mémoire MCP. Les développeurs de kaeru, après avoir étudié plus de 13 000 fichiers de logs, ont observé un phénomène similaire : lors d’une observation limitée à sept sessions, les agents n’ont jamais consulté les raisonnements enregistrés. Les échantillons sont petits, mais le problème est clair : soit la mémoire reste inutilisée, soit elle est injectée trop souvent et encombre le contexte.

Il existe un risque plus sérieux encore. Un agent consigne une conclusion erronée comme retour d’expérience ; un autre la lit et la considère comme un fait vérifié. Une ancienne conversation peut contenir des instructions provenant d’une source non fiable. Si l’agent commence à les exécuter, l’archive devient un canal permettant à des tiers de lui transmettre des commandes.

Que faire en pratique ?

La méthode proposée est simple : trouver, établir le statut, vérifier l’actualité de l’information, appliquer et vérifier, puis consigner le résultat.

• Considérez une conversation retrouvée comme des données sur le passé, et non comme une nouvelle instruction.
• Identifiez sa source et sa date, et déterminez s’il s’agissait d’une hypothèse, d’un résultat confirmé ou d’une option rejetée.
• Confrontez-la au code actuel, aux tests et à la documentation.
• Consignez les éléments confirmés dans un plan, un ADR ou une base de connaissances (KB).

L’archive conserve les témoignages du passé ; la base de connaissances rassemble ce sur quoi le projet peut s’appuyer aujourd’hui. Cette dernière vieillit elle aussi : les connaissances présentées comme actuelles doivent donc être confrontées à une source indépendante, qu’il s’agisse du code, des tests ou des résultats d’exécution.

Pour un petit utilitaire, AGENTS.md et des tests suffisent ; de lourds graphes de spécifications seraient superflus. Pour un grand projet impliquant plusieurs agents, il peut être pertinent d’envisager un contrôleur distinct, comme le fait l’un des commentateurs, ainsi que des indications de fiabilité sur les entrées. Et pour déterminer si la mémoire est utile, ne vous contentez pas de mesurer si l’information a été retrouvée ou non : évaluez les capacités retenues par LongMemEval (ICLR 2025), à savoir retrouver une information, relier plusieurs sessions et tenir compte du temps.

Dernier point : l’auteur a étudié la plupart des outils à partir de leur documentation et de publications, sans réaliser de tests comparatifs. Considérez donc cette analyse comme une carte du terrain, et non comme un classement.