Comment limiter le context rot dans Claude Code ?

Le context rot dégrade les réponses au fil d’une session Claude Code. J’explique pourquoi ça arrive, comment le repérer et quatre stratégies concrètes (/clear, /compact, fichiers skills, workflows) pour restaurer une session claire et productive.

Qu’est-ce que le context rot

Réponse, puis :

Le context rot décrit la dégradation progressive de la qualité des réponses quand l’historique d’une session accumule du bruit et des instructions obsolètes. Claude reconstruit l’état à partir de tout l’historique envoyé à chaque requête, donc l’accumulation de code expérimental, d’erreurs, de commentaires et d’instructions contradictoires diminue le signal utile et rend les sorties moins fiables.

La donnée technique clé est la fenêtre de contexte, ici d’environ 200 000 tokens. Un token est une unité de texte (en pratique un token vaut souvent ~4 caractères ou ~0,75 mot), donc 200 000 tokens représentent plusieurs dizaines de milliers de mots. En pratique cela correspond à environ 50–100 fichiers de code moyens, ou à plusieurs milliers de lignes de logs ; atteindre la limite signifie que les éléments les plus anciens seront encore consultés lors des inférences et peuvent polluer la décision.

Les types de contenu qui génèrent le plus de bruit sont les suivants :

• Patchs expérimentaux et tentatives partielles qui restent dans l’historique et contredisent les versions stables.
• Traces d’erreur et dumps volumineux qui noient les informations utiles.
• Instructions redondantes ou contradictoires, notamment des règles changées sans nettoyage des anciennes.
• Fragments de code commentés ou alternatifs qui créent des ambiguités sur l’intention.

La comparaison avec la « dérive d’état » est utile : comme un cache qui se pollue ou une session longue qui accumule paramètres obsolètes, le context rot résulte d’un état historique chargé de données inappropriées, ce qui augmente latence cognitive et erreurs de choix.

Cause	Effet sur les réponses	Gravité
Patchs expérimentaux	Réponses contradictoires ; suggestions instables	Élevée
Traces d’erreur volumineuses	Perte du contexte utile ; priorisation d’erreurs passées	Moyenne
Instructions redondantes/obsolètes	Comportement incohérent ; règles mal appliquées	Élevée
Fragments/commentaires ambigus	Interprétations erronées du but du code	Moyenne

Comment fonctionne la fenêtre de contexte

La fenêtre de contexte fonctionne en incluant l’historique complet de la session dans chaque requête.

À chaque appel API ou interaction, le serveur envoie l’ensemble des messages précédents (system, user, assistant). Le modèle réencode ces messages — c’est‑à‑dire qu’il transforme le texte en tokens numériques — puis réinterprète l’ensemble pour reconstruire l’état conversationnel et produire la réponse suivante. Ce flux implique que l’intégralité de l’historique est relue et réévaluée à chaque requête, pas seulement les nouvelles instructions.

Pour visualiser techniquement le flux :

• Le client envoie la nouvelle requête et l’historique stocké.
• Le serveur agrége l’historique en séquences de tokens (system, user, assistant).
• Le modèle encode l’ensemble, calcule l’attention et génère la sortie en tenant compte de tous les tokens fournis.

Une fenêtre très large (par exemple 200 000 tokens) permet de garder un contexte long : notes de conception, fichiers de référence, logs, etc. Avantage : possibilité d’interroger une base documentaire volumineuse sans recharger à chaque fois. Inconvénient : plus de risques de contradictions, de bruit et d’informations obsolètes qui perturbent la génération. Exemple chiffré : si 1 fichier représente 2 000 tokens, alors 100 fichiers occuperont 200 000 tokens. Des commits successifs de code et des essais de prompts peuvent donc remplir la fenêtre en quelques itérations, rendant les messages très anciens présents mais moins « actifs ».

La « dépriorisation » signifie que, quand la fenêtre est chargée, les tokens les plus récents ont tendance à dominer l’attention du modèle tandis que les anciens sont moins influents. Cela crée des conflits quand une instruction récente contredit une ancienne directive toujours présente dans l’historique.

Coûts

Traiter 200k tokens augmente linéairement le temps de calcul et la latence. Les coûts cloud par token et le temps de tokenisation font croître la facture et la latence de réponse.

Ce fonctionnement rend nécessaire des stratégies de nettoyage pour maintenir précision, cohérence et coûts maîtrisés.

Quels sont les signes du context rot

Le signe principal du context rot est que le modèle réintroduit des approches abandonnées et devient vagues ou contradictoires.

Les sessions longues accumulent des instructions et des états qui finissent par « polluer » les réponses. Voici les signes observables et comment les repérer en pratique.

• Réapparition d’anciennes erreurs corrigées : Le modèle revient à une implémentation qu’on avait déjà patchée. Exemple : Vous avez corrigé une fonction pour utiliser async/await, puis le modèle propose à nouveau la version callback qui plantait les tests.
• Recommandations contradictoires entre messages successifs : Le modèle donne deux solutions opposées en quelques messages. Exemple : Un message préconise pipenv, le suivant recommande Poetry sans lien entre les deux et sans justification.
• Réponses trop prudentes ou vagues : Le modèle évite de trancher ou fournit des réponses génériques sans détails actionnables. Exemple : Au lieu d’un patch de 8 lignes, on obtient une prose sur « améliorer la robustesse » sans code.
• Augmentation des allers-retours pour tâches simples : Tâches de routine qui demandent plus d’itérations qu’avant. Exemple : Une refactorisation mineure nécessite désormais 4 itérations au lieu d’une seule.
• Perte d’état (variables, versions de fichiers) : Le modèle oublie l’état courant du workspace. Exemple : Il propose de modifier file_v1.py alors que la branche courante contient file_v2.py déjà validé.

Check-list opérationnelle (6 actions concrètes à exécuter) :

• Comparer l’état attendu : Exécuter git status / git log pour vérifier la divergence entre le code et les suggestions.
• Rechercher messages d’erreur anciens : Scinder l’historique et grep les traces d’erreurs précédentes.
• Vérifier instructions system obsolètes : Relire les messages système ou directives initiales qui pourraient être contradictoires.
• Mesurer taille de l’historique : Estimer le nombre de tokens (1 token ≈ 0,75 mot); un historique de dizaines de milliers de tokens peut dégrader le contexte. Exemple pour estimer :

# Estimation simple avec GPT-2 tokenizer (approximation)
from transformers import GPT2TokenizerFast
tok = GPT2TokenizerFast.from_pretrained("gpt2")
text = open("conversation.txt").read()
print(len(tok.encode(text)), "tokens (approx.)")

• Surveiller latence : Noter si les réponses ralentissent, signe d’augmentation du coût du contexte.
• Noter fréquence des retours en arrière : Compter les régressions sur une fenêtre de 10-20 messages.

Il faut intervenir dès l’apparition répétée d’un ou deux signes plutôt qu’attendre une panne grave.
Intervenir tôt coûte peu (nettoyage d’historique, résumer l’état, réinitialiser instructions système) et évite des heures perdues à corriger des régressions répétées.

Quelles stratégies pour restaurer une session claire

Commencez par cette phrase réponse.

Restaurer une session claire consiste à supprimer le bruit, conserver l’état essentiel et réinjecter un contexte léger et structuré pour poursuivre le travail sans ressusciter les erreurs passées.

• /clear : Utiliser quand la session est trop bruitée, lors d’une migration de tâche ou après plusieurs échecs répétitifs. Conséquence : perte totale de l’historique de la session. Exemple pas-à-pas : 1) Sauvegarder les snippets et prompts utiles dans un fichier local, 2) Exécuter /clear, 3) Réinjecter un résumé minimal de l’état (3–5 lignes) et les snippets essentiels. Cette méthode est la plus radicale mais la plus fiable pour repartir à zéro.
• /compact : Rôle : réduire la taille du contexte en synthétisant échanges et résultats tout en conservant l’état utile. Préférer quand on veut garder l’historique logique mais couper les essais/erreurs. Exemple de formulation : «Résume de façon structurée les 20 derniers échanges en 300 tokens, en listant les décisions, les actions accomplies et les points ouverts.» Résultat attendu : un bloc comprimé contenant les faits essentiels et supprimant les tentatives inutiles.
• Fichiers de skills légers : Préparer un fichier JSON ou YAML minimal (10–50 lignes) avec uniquement fonctions exposées, variables nécessaires et règles de sécurité. Exemple JSON :

{
  "name": "build-skill",
  "version": "1.0",
  "functions": [
    {"name":"run_tests","description":"Lance la suite de tests unitaires"},
    {"name":"deploy","description":"Déploie sur staging, nécessite CONFIRM=true"}
  ],
  "env": {"REPO":"git@...","CONFIRM":"false"},
  "policy": {"allow_network":false,"max_runtime_sec":60}
}

• Workflows et checkpoints : Organiser la session en phases (exploration, validation, exécution). Créer des checkpoints exportables sous forme de résumé, hash de fichiers ou snapshot de variables pour revenir rapidement à un état sain.

Méthode	Impact sur qualité	Coût/Risque	Usage recommandé
/clear	Réinitialisation complète, qualité restaurée	Perte totale d’historique	Sessions très bruitées, migrations
/compact	Conserve l’essentiel, réduit le bruit	Risque d’omission d’un détail	Sessions longues avec beaucoup d’essais
Skills légers	Confort et consistance	Maintenance des fichiers	Tâches répétitives ou automatisées

• Procédure opérationnelle (5 étapes) :
• 1) Sauvegarder les prompts et snippets utiles en local.
• 2) Exécuter /compact ou /clear selon l’analyse.
• 3) Réinjecter un résumé structuré de l’état (3–6 points).
• 4) Charger un fichier de skill léger avec fonctions essentielles.
• 5) Valider le checkpoint en générant un résumé exportable et un hash de fichiers.

Fréquence recommandée : Effectuer une compaction toutes les 5–10 merges ou après 3–5 essais non concluants. Utiliser /clear après plusieurs cycles de correction infructueux ou lors d’une migration majeure.

Prêt à garder vos sessions Claude Code nettes et efficaces ?

Le context rot survient parce que Claude reconstruit l’état de la session à partir de tout l’historique et la fenêtre de 200 000 tokens se remplit vite lors de vraies sessions de code. En repérant les signes (contradictions, régressions, vagues) et en appliquant des actions simples — /clear pour repartir propre, /compact pour préserver l’essentiel, fichiers skills légers et checkpoints — on réduit fortement les allers-retours et on retrouve de la précision. En appliquant ces méthodes, vous gagnez du temps et obtenez des réponses plus fiables et exploitables pour vos tâches de dev et d’IA.

FAQ

• Qu’est-ce que le context rot dans Claude Code ?
  Le context rot désigne la perte de clarté des réponses quand l’historique de la session accumule du bruit, des essais et des instructions contradictoires, ce qui baisse le rapport signal/bruit dans la fenêtre de contexte.
• Quels sont les signes qui montrent qu’une session est affectée ?
  Signes courants : le modèle réintroduit d’anciennes erreurs, produit des réponses vagues ou contradictoires, nécessite plus d’allers-retours pour des tâches simples ou oublie l’état de fichiers/codes déjà modifiés.
• Quand faut-il utiliser la commande /clear ?
  Utilisez /clear lorsque vous changez de tâche, que la session est embrouillée par trop d’échecs ou que l’agent reste bloqué sur un état obsolète : c’est la façon la plus rapide de repartir sur une ardoise propre.
• Quelle différence entre /clear et /compact ?
  /clear supprime tout l’historique ; /compact demande au modèle de résumer et d’éliminer le bruit tout en conservant l’essentiel. /compact est moins radicale et utile si vous voulez garder un état résumé.
• Comment organiser mes skills et workflows pour limiter le risque ?
  Créez des fichiers skills légers (10–50 lignes), segmentez la session en phases (exploration, validation, exécution), exportez des checkpoints sous forme de résumés et réinjectez seulement l’état nécessaire après un /clear ou une compaction.

 

 

A propos de l’auteur

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