Mémoire catastrophique : pourquoi les fichiers CLAUDE.md grossissent de 226 % et ne rétrécissent jamais

Tout développeur ayant travaillé avec un agent de codage connaît ce sentiment. Le fichier d'instructions du projet, CLAUDE.md pour les configurations Claude Code, ou l'un de ses équivalents, commence comme une liste de règles bien ordonnée. Des mois plus tard, il ressemble à une accumulation de décisions que personne ne peut pleinement expliquer, et personne n'ose l'élaguer, car supprimer la mauvaise ligne pourrait silencieusement casser le comportement de l'agent.

Ce n'est pas un problème d'habitude humaine. C'est structurel, et un article publié sur arXiv le 11 août 2026 lui donne un nom. Écrit par Kushal Chakrabarti, « Why Does CLAUDE.md Keep Growing? » appelle le phénomène catastrophic remembering (la « mémoire catastrophique ») : le miroir de l'oubli catastrophique autour duquel la recherche sur l'apprentissage continu gravite depuis des années.

Les chiffres derrière le gonflement

L'article suit 247 694 vies d'instructions à travers 1 867 dépôts. Le schéma se vérifie partout : les prompts agentiques croissent sans limite, faisant plus que tripler au cours de leur vie, soit une augmentation de +226 %. Chaque commit représente un ajout net de 4,9 instructions. Et plus une instruction vieillit, moins elle a de chances de disparaître : le risque de suppression diminue de 0,032 par commit sur une échelle logarithmique. Le fichier ne cesse de croître que lorsque le dépôt est retiré ou que quelqu'un le réécrit entièrement.

La mécanique explique les données. Ajouter une instruction ne coûte rien : une ligne de plus, et c'est fait. En supprimer une est un tout autre jeu. Une fois la justification d'une instruction perdue, la supprimer sans risquer une régression de correction coûte O(2^|D|) dans un prompt de |D| instructions. Personne ne paie cette facture. Le fichier ne fait que grossir.

Pourquoi la suppression est le geste coûteux

La raison pour laquelle cette facture est si difficile à évaluer dépasse le prompt lui-même. Des travaux connexes de l'équipe de recherche de Qwen, « The Verification Horizon », soutiennent que le goulot d'étranglement des agents de codage actuels s'est inversé : générer des solutions candidates n'est plus la partie difficile ; c'est les vérifier de manière fiable qui l'est. Chaque vérificateur qu'une équipe peut construire n'est qu'un proxy de l'intention humaine, jamais l'intention elle-même. Si l'on ne peut pas prouver à moindre coût que la suppression d'une instruction ne change rien, la conserver paraît rationnel même quand elle n'est que du poids mort.

C'est là que le correctif de l'article entre en jeu. Les auteurs inversent IFEval, un benchmark standard de respect des instructions, pour construire des « mondes vérifiables » où le prompt optimal est connu à l'avance. Dans ces environnements contrôlés, les commentaires qui encodent le raisonnement latent derrière les instructions suppriment 99,3 % des instructions superflues, réduisant la croissance de +211,3 % à +1,4 %. En appliquant la même inversion à WildIFEval, un benchmark du monde réel plus bruité, les commentaires de prompt améliorent le respect des instructions jusqu'à 23,1 %.

Des commentaires, mais pour les prompts

L'article se termine par une question qui mérite de voyager : « Si l'anglais est le nouveau code, pourquoi n'avons-nous pas encore de commentaires ? »

Il ne s'agit pas de documentation pour les humains. Les commentaires qui notent pourquoi une instruction existe donnent au prochain éditeur, humain ou modèle, l'information nécessaire pour la supprimer en toute sécurité. C'est la justification qui rend la suppression de nouveau peu coûteuse, car le problème de coût n'apparaît qu'une fois cette justification perdue. Un prompt assorti de raisons est un prompt qui peut rétrécir. Sans elles, chaque instruction devient un engagement permanent que personne ne peut auditer. La lecture pratique est presque ennuyeuse : traiter le fichier d'instructions comme du code, examiner les ajouts comme on examinerait n'importe quel commit, et exiger que chaque règle porte son pourquoi.

L'article est une prépublication, et ses expériences contrôlées ne prouvent pas que les commentaires maîtriseront chaque CLAUDE.md de production. Mais le constat de fond est difficile à contester : un fichier qui ne fait que s'accumuler, où rien ne peut être supprimé en toute sécurité, est un fichier sur une route à sens unique vers le gonflement. Nommer l'échec est la première étape, et le nom restera, car quiconque a vu un fichier d'instructions tripler de taille sait exactement ce que la mémoire catastrophique fait ressentir.