Comment éviter le context rot dans Claude Code ?

Le context rot rend Claude Code moins précis quand l’historique devient bruyant; on l’évite en nettoyant la session, en compactant l’historique et en organisant les skills. Cet article propose signes à surveiller et procédures simples (/clear, /compact, nettoyage de skills) pour garder l’agent performant.

Pourquoi mon agent commence-t-il à faire des erreurs inattendues ?

Les erreurs apparaissent parce que l’historique encombré dégrade le signal utile dans la fenêtre de contexte, entraînant réponses vagues, contradictions et réapparition d’erreurs corrigées.

Premier point — comportement typique : Au démarrage d’une session, les réponses sont précises et ciblées parce que la fenêtre de contexte contient surtout l’objectif actuel et les instructions récentes. En fin de session, la fenêtre accumule des fragments de tests, d’expérimentations et de corrections, ce qui aboutit à des réponses plus vagues, des contradictions internes et le retour d’informations obsolètes.

Deuxième point — exemples concrets tirés de sessions de code :

• Variable renommée qui réapparaît : Après avoir renommé une variable globalement, l’agent réutilise l’ancien nom prélevé d’une ancienne instruction de test, provoquant des erreurs de compilation ou d’exécution.
• Fonction supprimée toujours mentionnée : Après suppression d’une fonction, l’agent continue de proposer son utilisation parce que l’appel était présent dans l’historique et n’a pas été nettoyé.
• Instructions contradictoires dans le README : Le README a été mis à jour mais des fragments anciens indiquent l’ancienne API, entraînant propositions contradictoires et mauvaise implémentation.

Troisième point — pourquoi les sessions de code sont particulièrement sensibles : Les sessions de développement multiplient les copies de fichiers, les essais locaux, et les commits temporaires. Ces pratiques génèrent beaucoup de « bruit » dans le contexte : extraits de logs, traces d’erreurs et tentatives multiples qui polluent le signal utile.

Quatrième point — taille de la fenêtre et implications : Les modèles modernes peuvent gérer des fenêtres de contexte très larges, jusqu’à 200000 tokens selon Anthropic. Cela permet d’archiver beaucoup d’information, mais n’élimine pas le problème du tri : plus il y a de tokens, plus il faut résumer et hiérarchiser pour préserver le signal.

Cinquième point — bonnes pratiques immédiates :

• Segmenter les tâches : Travailler par fonctionnalités indépendantes pour éviter l’entrelacement des historiques.
• Garder un changelog résumé : Maintenir un résumé synthétique des changements récents en haut du contexte.
• Utiliser /clear au bon moment : Nettoyer la session après milestones importants pour repartir d’un contexte propre.
• Pin des faits essentiels : Insérer en début de contexte les invariants du projet (API, conventions, noms clés).
• Faire des snapshots : Exporter un état stable du projet et référencer ce snapshot plutôt que tout l’historique brut.

Problème observable	Cause probable	Action corrective
Réapparition d’anciens noms	Historique de tests non nettoyé	Segmenter tâches et /clear après refactor
Réponses contradictoires	Instructions multiples et obsolètes	Maintenir un changelog résumé en tête de contexte
Informations obsolètes	Fichiers copiés et logs accumulés	Utiliser snapshots et pinner les invariants

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

Claude reconstruit l’état de la conversation à chaque requête en relisant tout l’historique ; quand ce flux contient beaucoup d’informations anciennes ou contradictoires, le modèle perd le signal utile.

La fenêtre de contexte est la quantité de texte que le modèle peut « voir » en une seule passe, mesurée en tokens (unités de texte, souvent ~4 caractères en anglais). Claude Code supporte jusqu’à 200000 tokens, ce qui paraît large mais s’use vite. Chaque échange, code, log ou diagnostic consomme ce budget.


Découvrez égalementComment utiliser OpenClaw avec Ollama en local ?

Le mécanisme général consiste en une relecture séquentielle de l’historique : le modèle parcourt les messages, pondère implicitement les éléments récents ou répétitifs et tente d’isoler le signal. Les éléments bruyants (données non pertinentes, contradictions) réduisent la clarté du signal en diluant l’information utile.

Le code, les logs d’erreur, les expérimentations et les messages de diagnostic consomment rapidement le budget parce qu’ils sont verbeux et riches en tokens. Un patch de code de 200 lignes peut facilement peser 3000–8000 tokens. Un log d’erreur volumineux ou un dump atteint aussi plusieurs milliers de tokens.

Exemple chiffré hypothétique (hypothèses : message moyen de dev = 500 tokens, patch complet = 5000 tokens, log volumineux = 3000 tokens, fenêtre = 200000 tokens). Dans ce cadre, on peut tenir ~400 messages courts, ~40 patches complets, ou ~66 logs volumineux avant de saturer la fenêtre. Une combinaison réaliste (50 messages courts + 10 patches + 20 logs) utilise déjà ~50×500 + 10×5000 + 20×3000 = 25 000 + 50 000 + 60 000 = 135 000 tokens, soit 68% du budget.

Les contradictions historiques entraînent des réponses incohérentes parce que le modèle doit résoudre des règles conflictuelles et finit par « moyenner » ou prioriser mal. Un résumé compact retire les redondances et explicite les faits stables, améliorant le ratio signal/bruit.


Découvrez égalementLe data scientist devient-il un manager IA ?

Recommandations techniques claires avant une session :

• Fragmenter par tâche : Séparer les sessions par sujet pour limiter l’historique inutile.
• Stocker l’état en externe : Garder l’état long-term dans une base ou un vecteur store et ne rappeler que l’essentiel.
• Résumé périodique : Générer des résumés compressés qui remplacent de longs historiques.
• Maintenir les fichiers de skills : Nettoyer et versionner les compétences/scripts pour éviter les duplications.

Source de token	Impact typique	Stratégie recommandée
Code/patchs	Élevé (kTokens par patch)	Stocker extern., référencer diff/link
Logs d’erreur	Moyen–élevé (dumps lourds)	Ingest filtré + résumés
Expérimentations/notes	Moyen (beaucoup de petits messages)	Regrouper + synthétiser périodiquement
Messages utilisateurs	Variable	Fragmenter sessions par contexte

Comment reconnaître le context rot avant qu’il vous fasse perdre du temps ?

On reconnaît le context rot par répétitions d’anciennes décisions, réponses évasives, contradictions, et la réapparition d’erreurs déjà corrigées.

Signaux d’alerte précis à surveiller :

• Même bug corrigé réapparaît deux fois ou plus dans la session.
• Réponses qui commencent fréquemment par « Je pense » ou « Peut‑être », signe d’incertitude de contexte.
• Tâches simples nécessitant trop d’allers‑retours (plus de 3 itérations pour une micro-tâche).
• Contradictions entre réponses successives sur la même donnée (ex : valeur A puis valeur B).
• Réapparition de variables obsolètes ou de directives annulées (ex : « ignore previous » présent plusieurs fois).
• Sections de l’historique tronquées ou répétées sans clarification.
• Régressions de tests unitaires ou d’exemples précédemment validés.
• Augmentation soudaine du nombre de corrections manuelles dans un court laps de temps.

Checklist opérationnelle (vérifier pendant la session) :

• Confirmer dernière décision validée et son horodatage.
• Scanner l’historique pour occurrences de la même correction.
• Compter réponses incertaines (« peut‑être », « je pense »).
• Vérifier variables déclarées vs utilisées.
• Exécuter tests rapides ou checksums sur outputs récents.
• Comparer état courant à un snapshot connu sain.
• Chercher balises « ignore previous » ou équivalentes.
• Exporter tout bloc de contexte dépassant 2 kB pour audit.

Découvrez égalementOKF va-t-il remplacer le RAG pour les agents IA ?

Heuristiques automatiques simples et pseudocode :

SET THRESHOLD_REPEATS = 2
SET THRESHOLD_UNCERTAINTY = 3
FOR EACH session_message IN history:
  IF count_occurrences(session_message.text, "ignore previous") > 0 THEN INCREMENT flag_ignore
  IF repeated_fragment_detected(session_message.text) > THRESHOLD_REPEATS THEN INCREMENT repeat_counter
  IF starts_with_uncertainty(session_message.text) THEN INCREMENT uncertainty_counter
IF repeat_counter > THRESHOLD_REPEATS OR uncertainty_counter >= THRESHOLD_UNCERTAINTY THEN ALERT("Context Rot Suspect")

Instrumentation no/low code :

• Utiliser n8n pour récupérer l’historique via API, appliquer filtres (regex pour « ignore previous », fragments répétés) et compter occurrences.
• Envoyer une alerte Slack via webhook quand seuil dépassé avec extrait du contexte problématique.
• Exemple d’alerte : « Alerte Context Rot: 3 répétitions du bug X détectées. Dernier message : … ».

Règles pratiques :

• Intervenir manuellement quand alertes > seuils ou contradictions multiples.
• Utiliser /clear quand le contexte est incohérent et que la perte est limitée.
• Exporter l’état pertinent (historique + variables) avant tout clear pour audit.

Signe	Gravité	Action immédiate
Même bug réapparu 2x	Élevée	Exporter + alerter équipe + bloquer workflow
Beaucoup de « peut‑être »	Moyenne	Forcer relance contexte ciblé
Variables obsolètes	Faible	Corriger et documenter, puis monitorer

Quand et comment utiliser /clear et /compact efficacement ?

/clear efface la session pour repartir proprement ; /compact réduit l’historique utile sans tout perdre.

La différence essentielle tient au scope et à l’intention. /clear supprime toute la session pour repartir d’une ardoise propre, ce qui est utile pour un changement de tâche radical ou pour éliminer des fuites de contexte. /compact conserve l’historique jugé utile tout en réduisant la taille effective du contexte en synthétisant ou en supprimant les éléments redondants, ce qui convient lors d’une transition exploration → exécution ou quand la session devient brouillonne mais contient des éléments encore pertinents.

Scénarios de priorité : Priorité 1, Changement de tâche (ex : passer de conception à génération de code) → utiliser /clear. Priorité 2, Session brouillonne mais réutilisable (ex : brainstorming avec éléments actionnables) → utiliser /compact. Priorité 3, Passage exploration → exécution (ex : on garde les décisions, on compresse les détails) → préférer /compact.

Procédure de décision pas à pas (flowchart en texte) : Commencer par vérifier si la session contient des informations nécessaires pour le travail suivant. Si non, lancer /clear. Si oui, évaluer si ces informations peuvent être résumées sans perte critique. Si résumable, lancer /compact ; sinon, exporter et /clear.

Exemples pratiques intégrables dans un workflow. Exemple d’utilisation de /clear : après une livraison, exécuter la commande /clear pour supprimer la session. Exemple d’appel /compact : /compact –keep=decisions –max-tokens=800. Exemple de format minimal pour un fichier de skills épuré en JSON sur une ligne : {« skill »: »summarize », »version »: »1″, »prompt »: »Résumer en 5 points », »usage »: »compaction »}.

Routine recommandée pour maintenir skills et historique. Après chaque sprint, compacter la session pour conserver les décisions clés. Une fois par semaine, exporter les résumés A4 (1 page) des sessions importantes et stocker dans un dépôt versionné. Une fois par mois, faire un /clear sélectif après archivage pour éviter l’accumulation de bruit.

Voici quelques outils complémentaires et pourquoi les utiliser.

• Export des logs — Permet d’archiver l’historique avant /clear pour relecture ou audit.
• Stockage des résumés (Git, Notion) — Permet de retrouver des décisions sans garder tout le contexte en mémoire.
• Automations (n8n, Zapier) — Permettent de déclencher /compact périodique ou après fin de tâche, et d’archiver automatiquement.

Action	Quand l’utiliser	Risque / Limite
/clear	Changement de tâche radical, session corrompue, fin de flux.	Perte totale du contexte et des prompts non sauvegardés si pas d’export.
/compact	Transition exploration→exécution, nettoyage sans tout perdre.	Risque de compacter trop agressivement et d’éliminer des détails utiles.
Exporter + clear	Archivage légal ou audit avant purge.	Surcharge de gestion des archives si pas de politique claire.

Prêt à garder Claude Code précis et fiable ?

Le context rot apparaît quand l’historique d’une session encombre la fenêtre de contexte et masque le signal utile ; reconnaître les signes (répétitions, contradictions, réponses évasives) permet d’intervenir tôt. Des actions simples — segmenter les tâches, utiliser /clear au changement de phase, lancer /compact régulièrement et alléger les fichiers de skills — réduisent nettement les régressions. En appliquant ces pratiques vous diminuerez le temps perdu en corrections et améliorerez la vitesse de livraison de vos développements avec Claude Code, soit un gain direct en productivité pour votre équipe.

FAQ

• Qu’est-ce que le context rot avec Claude Code ?
  Le context rot désigne la dégradation des réponses d’un agent quand l’historique de session devient trop volumineux, contradictoire ou bruyant, ce qui masque le signal utile dans la fenêtre de contexte.
• À quelle fréquence dois-je utiliser /clear ?
  Utilisez /clear lors d’un changement de tâche majeur, après une phase d’exploration intensive ou dès que vous observez signes d’incohérence. En pratique, pour des sessions de développement, le /clear après une phase de tests importants est souvent suffisant.
• Quelle est la différence entre /clear et /compact ?
  /clear supprime l’historique de la session pour repartir à zéro. /compact réduit et résume l’historique sans tout effacer, conservant l’état important tout en supprimant le bruit.
• Comment conserver l’état important sans provoquer de context rot ?
  Externalisez l’état clé (résumés, variables importantes, versions de fichiers) dans des fichiers de skills ou une base externe et ne chargez que des résumés compressés dans la session. Compactez régulièrement ces résumés.
• Peut-on automatiser la détection du context rot ?
  Oui : mettez en place des heuristiques (détection de répétitions, réapparition d’erreurs corrigées, hausse des réponses évasives) et des alertes via automations (n8n, scripts) pour proposer /compact ou /clear automatiquement.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et 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 de formation Formations Analytics, j’ai accompagné des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football et Texdecor. J’aide les équipes à stabiliser leurs agents IA et leurs pipelines analytics — disponible pour vous aider => contactez moi.