Context rot : pourquoi l'IA oublie tes consignes

Au début de la session, l'assistant est brillant : il suit tes consignes, respecte ton style, comprend ton archi. Deux heures plus tard, il réintroduit un bug que vous aviez corrigé ensemble, ignore une règle posée d'entrée, et se met à tourner en rond. Tu n'as rien fait de mal — tu viens de rencontrer le context rot, et ça se gère très bien une fois qu'on a compris d'où ça vient.

Pourquoi ça déraille : le contexte est une mémoire vive, pas un disque dur

Un modèle de langage ne « se souvient » pas de ta session comme tu l'imagines. À chaque tour, il relit l'intégralité de ce qui tient dans sa fenêtre de contexte — tes messages, ses réponses, les fichiers qu'il a ouverts, la sortie de chaque commande. Cette fenêtre est grande, mais finie. Et tout se dispute la même place.

Deux choses se produisent quand la session s'allonge :

• La dilution. Tes consignes du départ se noient sous des centaines de lignes de diffs et de logs accumulés depuis. Les modèles prêtent une attention moins fiable à ce qui est enfoui au milieu d'un long contexte — un phénomène bien connu, parfois appelé lost in the middle.
• L'éviction. Quand la fenêtre se remplit, les tours les plus anciens sont résumés ou écartés pour faire de la place. Ta contrainte soignée du début peut littéralement sortir de la fenêtre, ou être compressée en un résumé qui en perd la moitié.

Autrement dit : l'IA ne t'ignore pas, elle n'a peut-être plus sous les yeux ce que tu lui as dit. Pense à de la RAM, pas à un disque dur.

Le doom loop : quand l'IA tourne en rond

Le cas le plus rageant, c'est la boucle de la désespérance : une erreur, une tentative de correction, une nouvelle erreur, encore une tentative… et ça repart. Pourquoi ça s'enlise ?

Parce que le contexte récent se remplit des propres échecs du modèle. À chaque tour, il se conditionne sur cette pile de tentatives ratées et finit par recopier sa propre confusion. Ajoute à ça des états contradictoires — il a lu une version d'un fichier, tu l'as modifié depuis, les deux cohabitent dans la fenêtre — et il ne sait plus laquelle est vraie.

Le signal à reconnaître : il répète une solution déjà rejetée, re-casse ce qui marchait, ou propose des variantes de plus en plus alambiquées du même correctif. Quand tu vois ça, inutile de lui réexpliquer une sixième fois. Le problème n'est plus dans ta formulation, il est dans la fenêtre.

Mets tes règles hors de la fenêtre

La parade la plus solide, c'est de ne pas dépendre de la mémoire du modèle pour tes contraintes durables. Les fichiers de règles servent exactement à ça : l'outil les fournit lui-même au modèle, à chaque session, sans que tu aies à les recoller.

Selon ton outil : CLAUDE.md pour Claude Code, .cursor/rules pour Cursor, et AGENTS.md, une convention partagée qui émerge entre plusieurs assistants. Tu y mets le stable, pas le ponctuel :

• la stack et les conventions du projet (« toujours TypeScript strict », « pas de CSS inline ») ;
• comment lancer les tests et le lint ;
• les frontières d'archi à respecter, le nommage, les pièges connus du repo.

Un piège, justement : un fichier de règles obèse mange le même budget de contexte et se dilue lui-même. Plus de règles n'égale pas meilleures règles — je taille dedans dès qu'il devient bavard. L'objectif, c'est un signal court et net que le modèle relit sans effort.

Repartir frais, sans repartir de zéro

Voici le réflexe le plus contre-intuitif, et le plus efficace : quand une session patine, n'insiste pas — ouvre-en une neuve. Le contexte accumulé n'est plus un atout, il est devenu le problème ; le vider, c'est rendre au modèle la lucidité qu'il avait au début.

« Mais je vais tout perdre ! » Non — à condition d'avoir externalisé l'état ailleurs que dans le chat :

• Commite souvent. Git est ta mémoire permanente ; le chat est jetable. Si le travail est dans des commits, tu peux réinitialiser sans crainte.
• Fais un résumé de relais. Avant de couper, demande un point d'avancement court : ce qu'on fait, ce qui est fait, ce qui reste, les décisions prises, le blocage actuel. Quelques lignes suffisent.

Tu démarres ensuite la nouvelle session avec, en amorce, ce résumé plus ton fichier de règles. Le modèle repart frais, mais orienté. C'est exactement comme passer le relais à un collègue : on ne lui relit pas tout l'historique, on lui donne l'état et le cap.

En résumé

Le context rot n'est pas une faille de ton prompting, c'est une propriété de l'outil : une mémoire vive finie qui se dilue et s'écrase quand on la remplit. Trois habitudes suffisent à garder le cap — ranger tes contraintes dans un fichier de règles, commiter pour rendre le chat jetable, et repartir frais avec un résumé quand ça patine. Travailler par sessions courtes et cadrées plutôt qu'en marathon confus : c'est ça, vibecoder comme un pro.