Pourquoi la mémoire d’un agent de codage ne doit contenir que le delta, et comment le stocker.
La mémoire de l’agent de codage ne doit conserver que ce que le modèle ne peut pas deviner. Quatre tests pour chaque entrée, trois besoins pour le stockage, et pourquoi le markdown dans Git convient bien.
Sources: Why Your Agent Needs Memory, and How to Organize It
Imaginez un stockage de mémoires personnelles destiné à un agent de codage sur une seule machine. Il contient 181 fichiers thématiques derrière un index de 134 lignes, et presque rien de tout cela ne constitue une connaissance au sens habituel. Cet agent comprend déjà le middleware Express, la structure d’un test Playwright et la fonction d’un Dockerfile, ayant lu bien plus à leur sujet que n’importe quel être humain. Chaque ligne de ce stockage existe pour une raison inverse : elle marque un endroit où un monde particulier diffère de la moyenne du domaine.
Deux exemples illustrent cette idée. Un vérificateur de déploiement bloque toute publication dès qu’une vérification ne peut pas être exécutée, et c’est intentionnel. Le mécanisme d’approbation automatique d’une série de publications lit .status plutôt que .conclusion ; ce détail a nécessité une après-midi entière avant de devenir une simple ligne dans un fichier.
C’est là la forme d’une bonne mémoire d’agent. Ce n’est pas une copie de ce que l’agent sait. C’est le delta, la partie restante. Tout le monde s’accorde sur le fait qu’un agent a besoin de mémoire, mais personne n’en a défini les caractéristiques précises ; par conséquent, la suite de cet exposé suit deux étapes : d’abord expliquer pourquoi un agent a besoin de mémoire, puis décrire comment l’organiser. La seconde partie est divisée en quatre parties : rester simple, les exigences envers chaque unité de mémoire et envers le stockage, les systèmes de stockage qui répondent à ces exigences, et la routine nécessaire pour faire fonctionner cette mémoire au quotidien.
La mémoire d’agent n’est pas la mémoire humaine
L’instinct naturel est de raisonner par analogie. Les gens se souviennent de choses, donc les agents devraient en faire autant. Cet argument tombe à l’eau dès le premier pas : une personne commence avec un esprit vierge, ce qui oblige la mémoire humaine à conserver à la fois les cas moyens et les exceptions. Un modèle, quant à lui, arrive déjà préchargé avec des valeurs moyennes, sur une échelle dépassant celle de toute personne individuelle. Lui indiquer ce qu’est un middleware ne fournit aucune information supplémentaire ; cela ne fait qu’ajouter des éléments inutiles.
Les tokens ont un coût, et c’est là que beaucoup de gens se trompent. Un contexte inutile n’est pas neutre : c’est une perte nette. Dans une étude, des chercheurs ont compté la fréquence à laquelle un modèle effectuait correctement des appels API. Lorsque le modèle recevait de la documentation pour des API qu’il connaissait déjà bien, mais que la récupération était imparfaite, son taux d’appels corrects chutait de 39 points de pourcentage. En revanche, obtenir ce type de documentation pour des API rares qu’il n’avait jamais vues améliorait les résultats, ajoutant neuf points d’exactitude. Même contenu et même processus, mais l’effet changeait de signe.
Vu de cette manière, un fichier de mémoire représente une différence par rapport aux hypothèses existantes du modèle. Chaque ligne qui réaffirme une convention familière lutte pour attirer l’attention avec la seule ligne qui compte vraiment, or l’attention est précisément ce qui manque.
Ne consigner que ce que le modèle n’aurait pas pu deviner.
En faisant passer des fichiers de contexte réels à travers ce filtre, la majeure partie de leur contenu disparaît. Les règles de nommage, le principe de « composition plutôt que d’héritage » ainsi que la structure des dossiers de stockage relèvent de connaissances de base gérées par un outil de vérification et déjà présentes dans le modèle. Ce qui reste, c’est généralement des éléments complexes : des solutions de contournement, des chemins abandonnés, ou des caractéristiques valables uniquement dans cette base de code et nulle part ailleurs.
Dans le magasin d’exemples, long de près de 3 700 lignes (3 831 si l’index est compté), aucune ligne ne précise quel est le middleware utilisé ni comment structurer un test. Les lignes qui expliquaient un outil célèbre sont supprimées, car le modèle en connaissait déjà les fonctionnalités, ce qui signifie que des tokens étaient gaspillés à chaque requête sans raison.
La mémoire la moins chère est celle dont on n’a pas besoin
Si ma mémoire est bonne, la différence dépend de l’écart entre un projet et le modèle commun. En suivant l’architecture habituelle, on ne doit presque rien à l’agent, car il connaît bien le domaine. En inventant un système de modules privé, chacune de ses règles devient une ligne à écrire, à respecter et à prendre en compte à chaque demande.
Aucun test de référence n’est nécessaire pour ressentir cet effet. Dans une stack courante, l’agent s’occupe simplement de sa tâche. Avec un langage de niche ou un framework interne personnalisé, il s’arrête, devine ou pose des questions. Pour combler cet écart, il faut gérer soi-même le contexte : l’écrire, le versionner et le maintenir à jour à jamais.
Il n’existe pas de test A/B fiable pour valider cette affirmation, et il serait malhonnête de prétendre le contraire. La recherche citée ici soutient le mécanisme en question, tandis que les fichiers d’une seule personne ne prouvent que la pratique, ce qui n’est pas une preuve du mécanisme lui-même. L’expérience reste cependant cohérente : le travail nouveau dans des structures ordinaires avance rapidement, tandis que le travail dans de grands systèmes anciens, où la plupart des contextes n’ont jamais été consignés, progresse plus lentement, parfois même plus lentement que s’il était effectué manuellement.
Ainsi, les choix architecturaux sont devenus des choix liés à la mémoire. En choisissant le modèle ennuyeux mais largement utilisé, il n’y a rien d’extra à maintenir indéfiniment. Chaque déviation par rapport au modèle courant représente une ligne que quelqu’un doit consigner et tenir à jour, et un chemin personnalisé entraîne des coûts supplémentaires à chaque requête ultérieure, et non seulement pour celle qui l’a créé.
La partie difficile, c’est de rester petit
C’est la raison. La manière de procéder commence par un fait dérangeant : ce qui détruit les systèmes de mémoire en production, ce n’est pas l’oubli, mais l’accumulation.
L’utilité reste en retrait par rapport à la taille. Deux fois plus de mémoire ne signifie pas deux fois plus de valeur, car le désordre s’accumule plus rapidement que le signal, et au-delà d’un certain point, une mémoire plus grande donne de pires résultats qu’une plus petite, même pour les questions pour lesquelles elle a été conçue.
Les conflits se développent plus vite que la taille. Tout nouveau fait peut contredire n’importe quel fait existant, de sorte que le nombre de conflits possibles augmente bien plus rapidement que le nombre de fichiers. Une contradiction coûte également bien plus cher qu’un manque d’information. Lorsqu’un fait fait défaut, l’agent est incertain, et cette incertitude est acceptable : il pose des questions ou échoue de manière visible par les autres. Lorsque deux faits se contredisent, l’agent est convaincu mais à tort, et comme rien dans le processus ne semble défaillant, personne ne s’en aperçoit.
Pire encore, la plupart des produits de mémoire ne perçoivent pas le problème. La similarité vectorielle identifie deux phrases sur le même sujet, mais pas le fait que l’une dise oui tandis que l’autre dit non. Ainsi, la valeur diminue, les conflits augmentent sans cesse, et au-delà d’une certaine taille, le système de mémoire rend l’agent moins performant.
La mémoire échoue rarement de manière évidente. Elle échoue en donnant des réponses fausses avec assurance, alors que chaque requête fonctionne encore correctement.
La difficulté réside donc non pas dans l’accumulation de données, car tous les produits le font volontiers, mais dans le fait de rester compact tout en restant suffisant. Cela nécessite des suppressions, et supprimer signifie évaluer ses propres écrits anciens.
Les gens ont tendance à chercher d’abord une structure. Face à un amas désordonné, ils imposent une taxonomie de hiérarchies, de catégories, de graphes ou de schémas de connaissance formels. Cela a systématiquement des effets négatifs. Lors d’une évaluation en 2026, on a testé l’ajout de profondeur à un index contextuel sur demande avec le même modèle, et la précision est passée de 0,91 à 0,64. La structure plate a toujours surpassé la structure hiérarchique partout où elle a été testée. Une structure complexe ne résout pas la complexité : c’est une seconde complexité ajoutée à la première, et désormais les deux nécessitent une maintenance.
Organiser la mémoire consiste donc moins à créer un diagramme plus performant qu’à fixer un critère que chaque élément doit atteindre, ainsi qu’un système permettant de le franchir facilement.
Quatre tests pour chaque unité de mémoire
Ces critères s’appliquent à l’unité, et non au système. Au sein d’une équipe, ce sont également les critères que vérifie un examinateur.
- Simple et dense. Seules les informations essentielles sont présentes. Aucune phrase n’existe simplement pour paraître complète. Une ligne qui ne change rien aux actions de l’agent n’est qu’une décoration, et la décoration a un coût.
- Sans conflits. Aucun fait ne peut être faux en même temps. Cela exige un effort actif, car les conflits s’accumulent progressivement et jamais intentionnellement.
- Utile de manière mesurable. La mémoire ne rend pas l’agent plus intelligent ; elle le rend plus rapide et moins coûteux tout en maintenant la même qualité, en fournissant les mêmes réponses sans avoir à tout redécouvrir. Un fichier qui ne réduit pas visiblement le temps ou les ressources nécessaires pour accomplir une tâche réelle ne justifie pas son entretien.
reference_, les règles établies dans 50 fichiers feedback_, et les états périssables dans 14 fichiers project_. Le lecteur sait ce que contient un fichier avant de l’ouvrir.Un résultat publié semble contredire le troisième test tout en le soutenant en réalité. Des chercheurs de l’ETH Zurich ont comparé des fichiers de contexte de dépôt avec aucun fichier du tout. Ils n’ont constaté aucun avantage général en termes de réussite des tâches, et même une augmentation de plus de vingt pour cent des coûts d’inférence ; de plus, les fichiers générés par machine ont obtenu des résultats légèrement inférieurs à ceux obtenus sans fichier. En examinant la règle de différence, on s’aperçoit qu’il ne s’agit pas d’un résultat contraire. Un fichier rempli de connaissances moyennes est précisément ce que la règle prédit comme entraînant des coûts sans aucun avantage. Cette étude ne dit pas que les fichiers de contexte échouent, mais seulement que ceux qui répètent des informations moyennes échouent, ce qui décrit la plupart d’entre eux.
La discipline signifie donc moins d’écriture et plus de suppression : chaque ligne doit rester dense, et aucun couple de lignes ne doit être en désaccord.
Addy Osmani a abordé le même problème du côté de la maintenance en août, affirmant que les fichiers des agents deviennent obsolètes à mesure que les modèles s’améliorent (son post est intitulé « Audit des fichiers des agents »), ce qui justifie leur suppression et leur récréation périodiques plutôt qu’une croissance infinie. Une mémoire qui ne cesse de s’agrandir est en réalité en déclin progressif.
Ensuite, divisez ce qui reste par tâche, comme vous le faites vous-même pour vous en souvenir. Ce qui est chargé pour rédiger du texte diffère de ce qui est chargé pour déboguer une compilation.
Nul n’a besoin d’une seule mémoire. Ce qui est nécessaire, c’est la plus petite portion adaptée à la tâche en cours.
Trois exigences pour le stockage
Ces quatre tests ne disent rien sur l’emplacement des fichiers, qui constitue l’autre moitié de l’organisation.
Une piste provient de ce que les outils existants ont déjà en commun. AGENTS.md est un fichier markdown ordinaire situé à un emplacement prévisible, et plus de vingt outils le lisent, même si leurs créateurs sont en concurrence sur presque tous les autres aspects. Les fournisseurs rivaux n’ont jamais mis en œuvre la même API de mémoire.
Une étude sur les agents de codage en service (publiée sur Substack) a révélé que sept d’entre eux convergeaient vers un même design sans coordination : un petit fichier markdown toujours présent dans le contexte, ainsi qu’un archive plus volumineux sur le disque qui s’ouvre lorsque une tâche l’exige. Aucun d’eux n’utilisait de recherche vectorielle. Bien qu’ils ne partagent pas de référentiel de performance, les sept répondent aux mêmes trois exigences.
Recherche possible sans rien installer. Le terme « recherche » évoque souvent une recherche sémantique, ce qui n’est même pas le cas le plus courant. L’outil de mémoire développé par Anthropic permet de visualiser, créer, remplacer, insérer, supprimer et renommer des éléments, mais ne dispose d’aucune opération de requête. L’agent liste un répertoire et lit son contenu. Une mémoire qui ne fonctionne que lorsque l’index est créé, que les embeddings sont à jour et que le fournisseur est opérationnel crée une faiblesse dans le contexte. Elle doit continuer de fonctionner même lorsque tout cela cesse de fonctionner.
Modifiable pendant que quelqu’un regarde. C’est la mémoire qui s’actualise elle-même qui subit les dommages majeurs. Un audit de 10 134 entrées extraites automatiquement en environnement de production a révélé que 97,8 % d’entre elles étaient inutiles. Une étude distincte a fait en sorte que des modèles enregistrent leurs exécutions réussies dans la mémoire, et les résultats obtenus étaient pires que s’il n’y avait pas de mémoire du tout, pour les quatre agents testés. La mémoire qui s’écrit elle-même évolue de manière imprévisible, et non de façon contrôlée ; par conséquent, tout changement doit être visible sous forme de différence, rejetable et annulable.
Facile à maintenir grâce à des outils déjà disponibles. La corruption ne met presque jamais fin à un système de mémoire. La négligence, en revanche, si : le fichier est écrit une fois, personne ne le consulte à nouveau, et il devient progressivement incorrect. Selon un rapport sur une étude menée en 2026, la moitié des fichiers contextuels n’a jamais fait l’objet d’aucune modification après le premier enregistrement, et les 6 % qui continuaient d’être modifiés appartenaient à des personnes qui rapportaient un réel bénéfice de l’agent. La maintenance doit se faire dans l’éditeur, c’est-à-dire dans les outils de recherche et de contrôle de version que les gens utilisent déjà au quotidien.
C’est là toute la spécification. Il ne reste plus qu’à déterminer quel type de stockage la satisfait.
Pourquoi les fichiers Markdown conviennent dans Git
Le cas des fichiers n’est pas nouveau. Des auteurs sur Medium ont affirmé à au moins six reprises au cours de l’année écoulée que « le markdown est supérieur aux bases de données vectorielles pour la mémoire des agents », et les discussions sur Hacker News à ce sujet continuent de produire des plaisanteries qui se résument à l’utilisation de texte brut. Ce qui est rarement fourni, c’est la justification.
Trois fournisseurs vendant des bases de données mémoire ont publié des arguments contre les fichiers en l’espace de trois mois, tandis que les deux fournisseurs proposant les agents les plus performants avaient déjà choisi les fichiers. L’argument avancé ici n’a rien à vendre, juste un dossier.
Ce que le domaine stocke
Ce qu’un système stocke détermine tout ce qui suit.
- Mem0 stocke une phrase extraite par un LLM ainsi que son embedding, soit une ligne dans un index vectoriel. Ce qui est retourné n’est pas le document original, mais une paraphrase de l’extracteur, et il est impossible de l’ouvrir.
- Zep conserve une arête graphique saisie pour chaque fait et suit deux chronologies par fait, de sorte que chacune possède une fenêtre de validité. Les corrections s’effectuent par remplacement : l’ancienne arête est marquée comme inutilisable au lieu d’être modifiée.
- Une startup spécialisée dans la mémoire vectorielle a géré des archives vectorielles pendant des années. Au début de 2026, elle a remplacé le stockage par défaut de ses agents de codage par un arbre de fichiers Markdown dans un répertoire git, en enregistrant les modifications une fois par modification.
- Anthropic propose un outil de mémoire qui ne consiste qu’en des opérations sur des fichiers situés dans le répertoire
/memories, exécutées par le client du client lui-même. Son API Memory Stores, encore en version bêta et hébergée, identifie les éléments par leur chemin dans le système de fichiers et résout les écritures simultanées à l’aide d’un hash de contenu, ce qui revient au modèle de données de git avec une couche HTTP. - Les assistants aux consommateurs présentent un résumé que les utilisateurs ne peuvent consulter qu’à l’état affiché. À ce jour, en septembre 2026, aucune version exportable, lisible par machine et documentée, n’existe pour aucun d’eux.
En réalité, la véritable distinction réside dans la possibilité de lire la mémoire, et la distinction entre fichiers et bases de données ne prend pas cela en compte. Toutes les options autres que les fichiers ont un point commun : il n’est pas possible de comparer la mémoire à deux moments différents. Les corrections s’effectuent via un interrupteur, et non via un commit.
Chaque camp propose sa solution, et chacun a partiellement raison
En mars 2026, MatrixOrigin a affirmé que le Markdown statique se dégrade et ne garantit rien. Cinq semaines plus tard, Mem0 a publié un article intitulé « La mémoire de votre agent IA n’est qu’un fichier ? Voilà le problème », soulignant que les fichiers plats reproduisent les erreurs antérieures aux bases de données des années 1970 : pas de recherche sémantique, pas de raisonnement temporel, pas d’écritures concurrentes sécurisées et pas de mécanisme d’oubli. En juin, Zep a ajouté « Le Markdown n’est pas une mémoire d’agent », insistant sur le fait qu’un fichier Markdown ne montre que ce qui a été écrit, jamais ce qu’il a remplacé ou pourquoi.
Pendant ce temps, l’agent de codage d’Anthropic conserve sa mémoire sous forme de Markdown simple sur disque, et la documentation de Windsurf conseille discrètement de transférer tout ce qui mérite d’être conservé hors de son stockage mémoire vers du Markdown géré par un système de contrôle de version. Il est intéressant de noter qui vend quoi.
Les fournisseurs de bases de données ont effectivement deux arguments valables. Les vecteurs l’emportent lorsque la question et la note ne partagent aucun vocabulaire, comme dans le cas d’une demande concernant « ce qu’on ressent quand on est épuisé » face à une note qui ne mentionne jamais l’épuisement. Seul un encodage permet de combler cette lacune, à une vitesse constante même pour des millions de lignes. Grep ne peut pas trouver ce que l’on ne sait pas nommer.
Les graphes ont l’avantage en termes de temps. Pour répondre à ce que quelqu’un croyait mardi dernier et ce qui l’a remplacé, il faut des faits accompagnés de dates de début et de fin, et un score de similarité ne permet pas de déterminer lequel des deux faits contradictoires est actuel. Selon certaines sources, une nouvelle analyse effectuée par un tiers sur les questions temporelles d’un benchmark de mémoire à long terme aurait donné 63,8 % au système graphique contre 49,0 % au système vectoriel. Les fichiers sont en défaut dans les deux cas.
Les preuves, avec leur réservation
Les résultats obtenus en 2026 ont surpris le domaine. Les agents qui ont examiné un simple tas de fichiers à l’aide de grep, find et de lectures de fichiers ont surpassé tous les systèmes basés sur des mots-clés, des embeddings ou un réclassement traditionnel. Une étude de référence sur les recherches automatisées a montré que l’élimination du système d’extraction par embeddings et la simple lecture des fichiers par l’agent ont permis d’augmenter la précision de 69 % à 80 %, tout en réduisant les coûts d’environ un tiers. Une autre étude portant sur des questions liées à la mémoire à long terme a révélé que la recherche par mots-clés classiques était supérieure à la recherche sémantique dans chaque configuration d’appel d’outils intégrés. Cependant, lorsque les résultats étaient fournis sous forme de fichiers, l’ordre était inversé pour la moitié des paires, car les questions valorisaient la localisation de données précises telles que des dates, des comptes, des identifiants ou des chaînes d’erreurs.
La publication sur la recherche agente mentionne également une mise en garde évidente : en augmentant le nombre de documents de 100 000 à 400 000, la même méthode voit sa précision passer de 80 % à moins de 40 %, tout en nécessitant trois fois plus d’appels à l’outil. Grep fonctionne dans des limites de taille précises et n’est pas une loi de la nature ; à l’intérieur de ces limites, il est supérieur en termes de qualité et de coût, mais en dehors, il perd en efficacité.
La question légitime est donc de savoir de quel côté de ces limites se trouve un système, et non quelle approche l’emporte en général. Un ensemble de 181 fichiers est des centaines de fois plus petit que l’échelle à partir de laquelle les problèmes apparaissent selon les rapports. Un système de mémoire de production dans une grande entreprise comme LinkedIn ne relève pas de cette catégorie, et personne ne prétend qu’il devrait utiliser Markdown.
Tableau de comparaison : fichiers contre les alternatives
Face à ces trois exigences, les fichiers Markdown les satisfont toutes à un coût presque nul. Grep fait office de solution de secours : toute modification se présente sous forme de diff (un commit réversible au sein d’un répertoire), et les outils de maintenance sont déjà disponibles sur le bureau.
Deux autres avantages se présentent gratuitement. Les contradictions apparaissent, car deux faits contradictoires se traduisent par deux lignes de texte plutôt que par deux tableaux flottants, et le format de stockage sert également de format d’exportation.
Ce compromis mérite d’être nommé plutôt que caché. Les fichiers sont moins efficaces que les embeddings lorsque l’on a besoin d’une récupération approximative sur de nombreux documents. La solution consiste à placer un index par-dessus les fichiers, pouvant être reconstruit à tout moment, plutôt que de le mettre à la place d’eux. Les solutions basées sur la mémoire classique s’appuient sur SQLite, memsearch s’appuie sur Milvus, tandis que l’idée de wiki composé de Karpathy se contente d’une page d’index, sans aucun embedding. Lorsque l’index constitue le stockage, l’inspection, les comparaisons, la gestion des droits d’auteur et la portabilité sont sacrifiés au profit d’une récupération qui était déjà possible.
Si vous ne pouvez pas le grep, le comparer et supprimer une ligne dedans, ce n’est pas votre mémoire. C’est le cache de quelqu’un à votre sujet.
À quoi ressemble un système en cours d’exécution
Les principes sont peu coûteux, voici donc une configuration fonctionnelle.
- Des couches de pointeurs, sans manifeste. Le premier fichier que l’agent ouvre compte 21 lignes. Il fonctionne comme une carte avec trois zones de niveau supérieur, une ligne par zone, indiquant des fichiers plus profonds. Un niveau en dessous, un fichier de projet contient ce qui est véritablement personnel : le répertoire actif par rapport à celui qui a été supprimé lors d’un renommage, les versions auxquelles tout est fixé, les règles de communication à respecter. Vingt-huit fichiers de ce type se trouvent dans l’arborescence des projets, tous rédigés à la main, et chacun n’est chargé que lorsque le travail s’y dirige.
- Un stockage écrit par l’agent, approuvé par un humain. À côté se trouve la mémoire automatique, avec 181 fichiers de sujet derrière un index de 134 lignes. Seul l’index est chargé au démarrage d’une session, et un fichier de sujet est ouvert dès que une tâche en a besoin.
Couches pour le chargement, pas pour le raisonnement
Comptez les niveaux indiqués ci-dessus : il y en a quatre, ce qui correspond à la profondeur contre laquelle met en garde le résultat précédent allant de 0,91 à 0,64. Cependant, la variable étudiée dans cette recherche était la profondeur, tandis qu’un index restait constant dans toutes les configurations. La meilleure configuration consistait en un index plat par tâche, l’agent le parcourant en une seule passe avant de décider ce qu’ouvrir, ce qui doublait presque la précision par rapport à une navigation brute tout en coûtant environ la moitié. Les résultats se détérioraient uniquement lorsque l’index développait des branches que le modèle devait parcourir, devinant à partir uniquement des étiquettes laquelle contenait la réponse.
Cet index repose sur un classement linéaire : un seul niveau, lu dans son intégralité au début d’une session. Il compte 134 lignes, environ une par sujet, chacune indiquant les fichiers auxquels elle fait référence avec une brève phrase résumative. Il n’y a pas de branches, donc rien à deviner. Il s’agit d’une petite table de routage gérée manuellement, et non d’une taxonomie permettant au modèle de raisonner ; elle peut être imparfaite : onze des 181 fichiers y manquent. Les fichiers correspondant aux sujets sont de petite taille, structurés de manière linéaire et lus en totalité. Un niveau s’ouvre lorsque des travaux entrent dans sa catégorie, et non parce qu’une requête cherche spécifiquement quelque chose. C’est ce qu’on appelle la divulgation progressive.
Le test est simple. Si le modèle doit deviner quelle branche contient la réponse en se basant uniquement sur les étiquettes, c’est qu’un arbre a été construit et le score obtenu sera de 0,64. S’il lit l’ensemble de l’index et ouvre un fichier par son nom, il s’agit alors d’un ordre de chargement.
La structure existe pour déterminer ce qui doit être chargé. Elle n’est pas là pour permettre au modèle de raisonner.
Une mesure de protection contre l’écart
L’agent propose des modifications, celles-ci apparaissent sous forme de diff, et une personne peut les accepter ou non. Les fichiers stockés dans des dépôts possèdent leur propre historique, ce qui permet de répondre à la question de savoir pourquoi l’agent croit en quelque chose en consultant ce historique, ce que aucun stockage vectoriel ou page de mémoire fournisseur ne peut offrir. Une mémoire que personne n’a examinée n’est qu’une rumeur dotée d’un nom de fichier.
Occasionnellement, une opération de nettoyage est effectuée : suppression des lignes qui étaient vraies en juin, des fichiers que le modèle a depuis intégrés, ainsi que des règles remplacées par des versions améliorées. Les stocks se réduisent plus fréquemment que ce que les gens prévoient.
Tout est du markdown pur sur le disque local et fonctionne sans l’assistant qui a aidé à le rédiger. Lorsqu’un outil plus puissant arrivera l’année prochaine, ciblez-le sur le même dossier et continuez.
Une vérification que vous pouvez effectuer aujourd’hui
L’organisation tient sur une carte : quatre tests pour chaque ligne conservée, trois exigences concernant l’endroit où elle est stockée, et un intervenant humain entre l’agent et le fichier.
Pour déterminer votre propre position, ouvrez le fichier de contexte du projet, qu’il s’agisse de CLAUDE.md, AGENTS.md ou de tout autre fichier lu par l’outil, et supprimez toutes les lignes que le modèle aurait devinées sans aide. Réduire le contenu de moitié est un résultat réaliste. Ensuite, assignez la tâche suivante au fichier ainsi simplifié et voyez si la situation s’aggrave. Par la suite, chaque fois que l’agent commet une erreur sur quelque chose qu’il n’avait aucun moyen de connaître, ajoutez une seule ligne et faites-la examiner comme du code. Telle est la discipline, et elle ne s’améliore pas en ajoutant simplement plus de choses.
L’agent connaît déjà la valeur moyenne. La seule tâche à effectuer est de calculer la différence.
Lectures complémentaires
- Pourquoi les benchmarks de mémoire d’agent induisent en erreur, et comment évaluer avec vos propres données — Les classements publics de mémoire présentent des grilles de correction et des correcteurs défectueux. Séparez la récupération des informations des réponses, ajoutez des vérifications de cohérence, de fraîcheur, d’abstention et d’oublie, et suivez les coûts.
- L’injection de prompts et la triade mortelle : sécuriser les agents IA — Pourquoi les agents ne peuvent pas distinguer vos instructions de celles d’un attaquant, comment les attaques EchoLeak et GitHub MCP ont fonctionné, et quelles défenses restent efficaces.