Comment prévenir le context rot dans Claude Code ?

Prévenir le context rot exige de contrôler l’historique, compacter les informations clés et réinitialiser la session au bon moment. Cet article explique l’origine du problème, comment le détecter et quatre remèdes pratiques pour garder Claude utile sur des sessions longues.

Pourquoi mon agent devient-il imprécis ?

L’agent devient imprécis parce que l’historique de la session s’accumule, crée du bruit et enferme des threads contradictoires qui finissent par diluer le signal utile.

Le phénomène s’appelle context rot. Il survient parce que chaque requête au modèle reconstruit la conversation complète dans la fenêtre de contexte — c’est‑à‑dire l’ensemble des tokens (unités de texte) que le modèle peut voir en une passe. Claude Code supporte une fenêtre très large (environ 200 000 tokens), mais cette limite reste finie. Le modèle donne de la priorité aux contenus récents (biais de récence), utilise des embeddings et des poids d’attention pour pondérer l’information, et finit par intégrer erreurs et essais infructueux comme du signal. Tokens signifie ici des sous‑mots ou morceaux de mots utilisés par le tokenizer, pas forcément des mots humains.

Je rencontre fréquemment ces patterns en sessions de debug ou d’itération de code :

• Réapparition d’une approche rejetée. Exemple : Après avoir indiqué « Ne pas utiliser la librairie X », le modèle réintroduit X dans une solution ultérieure. Mécanisme : Priorisation du contenu récent mélangé au bruit ancien provoque une réactivation d’anciens tokens pertinents mais non désirés.
• Instruction oubliée sur l’état du fichier. Exemple : On précise « fichier déjà formaté », puis le modèle propose de reformatter ou de recréer le fichier. Mécanisme : Dilution du signal utile dans une longue trace d’essais où l’information d’état perd de la poids relatif.
• Correction réintroduite et contradictoire. Exemple : Une correction manuelle est appliquée, mais une réponse suivante réintroduit l’erreur corrigée. Mécanisme : Accumulation de messages d’erreur et d’essais infructueux qui forment des threads contradictoires concurrents.

Transition : Nous verrons ensuite des stratégies techniques pour limiter le context rot et préserver le signal utile.

Cause	Effet	Indicateur observable
Historique trop long	Dilution du signal principal	Réponses vagues, perte d’instructions
Threads contradictoires	Réintroduction d’approches rejetées	Solutions oscillantes entre options
Accumulation d’erreurs/tests	Bruit priorisé sur corrections	Corrections réapparues, incohérences

Que se passe-t-il dans la fenêtre de contexte ?

Claude reconstruit la conversation complète à chaque requête et la fenêtre de contexte se remplit rapidement, dépriorisant l’ancien contenu et laissant persister du bruit et des threads contradictoires.

Je détaille comment les tokens s’accumulent et pourquoi ce comportement crée du bruit, des contradictions et une fragmentation de l’état.

Les tokens sont des unités de texte (mots, fragments de mots) utilisées par le modèle pour représenter tout ce qui est envoyé en entrée : code source, logs, extraits de fichiers copiés, résultats de tests, messages de chat et tentatives partielles. Chaque fichier source long peut représenter plusieurs centaines à plusieurs milliers de tokens. Chaque copie de log ou stack trace ajoute souvent des milliers de tokens en quelques lignes.

La fenêtre de contexte fonctionne comme une mémoire limitée qui favorise le contenu récent : les informations nouvelles ont plus de poids que les plus anciennes, même si ces dernières contenaient des décisions architecturales ou des spécifications. Cette priorisation fait que des corrections récentes, des essais partiels ou des messages d’erreur persistent et peuvent contredire ou « effacer » implicitement des choix antérieurs tout en restant présents comme bruit.

Le bruit correspond à tout texte non pertinent pour la décision actuelle : erreurs temporaires, diffs incomplets, tentatives de debug, lignes de logs répétées. Les contradictions persistantes surviennent lorsque plusieurs versions d’une même décision coexistent dans la fenêtre et que le modèle ne sait plus laquelle appliquer. La fragmentation se produit lorsque l’état utile est dispersé en fragments dans différents messages et n’est plus reconstituable en une vue cohérente.

Estimation simplifiée	Nombre de tokens
Dix fichiers source (moyenne 1200 tokens chacun)	Douze mille
Cinquante échanges de debug (moyenne 120 tokens chacun)	Six mille
Logs et stack traces collés	Quinze mille
Total pour un cycle	Environ quarante et un mille

Répéter cinq cycles de ce type suffit à dépasser 200 000 tokens, surtout si l’on copie aussi des docs, des diff complets ou des dumps de base.

En pratique, trois conséquences directes pour votre workflow :

• Perte de cohérence : Les décisions antérieures sont noyées et difficiles à réappliquer, ce qui augmente les rework et le temps de validation.
• Augmentation des faux positifs/erreurs : Le modèle peut se baser sur essais partiels ou logs anciens et proposer des corrections inadaptées.
• Ralentissement des itérations : La nécessité de nettoyer ou résumer le contexte allonge les cycles de debug et la charge cognitive.

Pouvez-vous fournir un tableau synthétique cause / mécanisme / conséquence ?

Quels signes montrent que le context rot s’installe ?

Réponse : Les signes sont la réapparition d’approches rejetées, des réponses de plus en plus hésitantes, des contradictions internes et le besoin d’itérations excessives pour des tâches simples.

Le context rot correspond à la dégradation progressive de la qualité des réponses d’un agent conversationnel quand l’historique accumulé pollue ses décisions. Voici une checklist pratique pour détecter ces symptômes tôt et agir immédiatement.

• Réemploi d’anciennes suggestions. Pourquoi c’est un symptôme : Parce que l’agent réutilise des options déjà évaluées et rejetées, montrant que le contexte ancien influence encore la génération. Comment vérifier rapidement : Demander à l’agent «Quels critères ont conduit au rejet de la dernière proposition?» et inspecter l’historique des messages pour trouver la répétition. Action immédiate : Isoler la conversation problématique ou nettoyer l’historique (clear) des échanges non pertinents.
• Changement inattendu d’implémentation. Pourquoi c’est un symptôme : Parce que des décisions antérieures contradictoires s’accumulent et poussent à des choix incohérents. Comment vérifier rapidement : Poser «Montre le dernier prompt système et la version actuelle des instructions» et comparer. Action immédiate : Compacter les instructions essentielles dans un prompt système unique et créer une nouvelle session pour tests.
• Augmentation des aller-retour pour une tâche basique. Pourquoi c’est un symptôme : Parce que l’agent perd le fil et nécessite plus de clarifications, signe de sur-contexte. Comment vérifier rapidement : Mesurer le nombre de messages nécessaires pour produire la sortie attendue sur trois tâches identiques. Action immédiate : Réinitialiser la conversation et fournir un prompt minimal et reproductible.
• Retour de bugs déjà corrigés. Pourquoi c’est un symptôme : Parce que l’ancien état du modèle refait surface, indiquant contamination de l’historique. Comment vérifier rapidement : Demander «Quelle correction a été appliquée pour le bug X?» et vérifier les réponses précédentes. Action immédiate : Isoler la séquence contenant la correction et rejouer seulement les messages essentiels.
• Réponses «Ça dépend» sans proposition concrète. Pourquoi c’est un symptôme : Parce que l’agent évite la décision en s’appuyant sur un contexte ambigu. Comment vérifier rapidement : Poser une question fermée exigeant un choix ou un plan étape par étape. Action immédiate : Reformuler en contraintes claires et compacter le prompt pour forcer une réponse opérationnelle.

Synthèse symptôme	Vérification rapide	Action recommandée
Réemploi d’anciennes suggestions	Vérifier l’historique et interroger le critère de rejet	Clear ou isoler la conversation
Changement d’implémentation	Afficher le prompt système et comparer	Compacter instructions / nouvelle session
Aller-retour excessifs	Mesurer messages par tâche	Réinitialiser et fournir prompt minimal
Retour de bugs corrigés	Demander historique de la correction	Isoler et rejouer séquence essentielle
«Ça dépend» sans plan	Poser question fermée	Contraintes claires et compaction

Quand et comment utiliser la commande /clear ?

Réponse : utilisez /clear pour réinitialiser complètement la session quand la conversation devient chaotique, quand on change de tâche non liée ou avant une phase d’exécution propre.

La commande /clear supprime l’historique de la session côté modèle, effaçant le contexte, les messages précédents et l’état temporaire non sauvegardé. Cette action n’efface pas vos fichiers locaux ni les données stockées hors-session, mais entraîne la perte immédiate de tout état non sauvegardé (variables, décisions intermédiaires, essais en cours).

La commande a des limites importantes : elle est irréversible pendant la session, ne restaure pas les prompts précédents et ne protège pas contre l’oubli d’informations critiques si elles n’ont pas été exportées.

Moments précis pour utiliser /clear :

• Après une phase d’exploration qui a produit beaucoup d’essais et de contradictions, afin d’éviter le « context rot » où le modèle se perd.
• Après de nombreux essais techniques successifs qui ont pollué le contexte par des erreurs et du bruit.
• Avant une livraison ou une phase d’exécution propre, pour partir d’un état connu et reproductible.

Alternatives moins radicales :

• Compacter le contexte via un résumé synthétique des décisions clés et des contraintes à conserver.
• Extraire l’état essentiel dans un fichier de skills allégé (voir le modèle ci-dessous) pour réinjecter uniquement l’indispensable.
• Externaliser la mémoire hors-session (base de données, notes structurées) et référencer cet état dans le prompt.

Création d’un fichier de skills léger (instructions pratiques) :

• Conserver uniquement : variables d’état critiques, résumés des décisions, étapes prioritaires et exemples de prompts testés.
• Exclure toujours : clés API, secrets, données personnelles identifiables.

{
  "state": {"version":"v1","mode":"release"},
  "decisions":["Valider API X","Utiliser lib Y"],
  "checkpoints":["Résumé 2026-05-14"],
  "secrets": "DO_NOT_STORE"
}

Workflow recommandé pour sessions longues : segmenter par tâche, versionner les prompts importants, sauvegarder des checkpoints et résumés réguliers, puis utiliser /clear entre segments quand le risque de pollution contextuelle devient réel.

Action	Quand	Bénéfice	Risque
/clear	Après exploration ou avant livraison	État propre, moins d’erreurs contextuelles	Perte d’état non sauvegardé
Résumé	En continu ou avant /clear	Conserve l’essentiel sans bruit	Risque d’omission si mal résumé
Fichier de skills	Au début et après chaque segment	Réinjection contrôlée d’état	Mauvaise gestion des secrets

Prêt à garder Claude performant sur vos sessions longues ?

Le context rot arrive quand l’historique s’accumule, crée du bruit et dégrade progressivement la qualité des réponses. En surveillant les signes (réapparition d’approches rejetées, hésitations, contradictions), en segmentant les sessions, en compactant l’état utile et en utilisant /clear au bon moment, on limite fortement la détérioration. Vous gagnez du temps, réduisez les allers-retours inutiles et conservez un agent fiable pour l’exécution. Le bénéfice immédiat : moins d’erreurs réintroduites et des sessions de travail plus productives.

FAQ

• Qu’est-ce que le context rot ?
  Le context rot désigne la dégradation progressive des réponses d’un modèle sur une session longue due à l’accumulation d’historique, de bruit et de threads contradictoires dans la fenêtre de contexte.
• Pourquoi 200 000 tokens ne suffisent-ils pas toujours ?
  Même avec une grande fenêtre, le contenu utile se mélange au bruit (logs, essais, erreurs). Le modèle priorise le récent, ce qui peut effacer ou contredire des décisions précédentes et provoquer du context rot.
• Quels sont les premiers signes à surveiller ?
  Surveillez la réapparition d’idées déjà rejetées, des réponses vagues ou contradictoires, l’augmentation des aller-retour nécessaires et le retour de bugs corrigés.
• Faut-il utiliser systématiquement /clear ?
  Non. /clear est utile quand la session devient chaotique ou quand on change de tâche. Entre deux extrêmes, privilégiez la compaction du contexte ou des fichiers de skills allégés.
• Comment compacter efficacement le contexte ?
  Conservez uniquement l’état essentiel : résumés de décisions, variables clés, et extraits de code pertinents. Externalisez le reste (fichiers, logs) et réinjectez une version allégée quand nécessaire.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert & formateur en tracking server-side, Analytics Engineering, automatisation No/Low Code (n8n) et intégration de l’IA en entreprise. Je pilote l’agence webAnalyste et l’organisme de formation Formations Analytics. J’accompagne des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Dispo pour aider les entreprises => contactez moi.