Comment prévenir le context rot dans Claude Code ?

Le context rot dégrade les réponses de Claude au fil d’une session. J’explique comment le repérer, pourquoi il survient et quatre stratégies pratiques — /clear, /compact, skill files légers et résumés automatisés — pour maintenir un agent précis et productif.

Pourquoi mon agent commet-il des erreurs inattendues ?

Le context rot provoque des réponses vagues, des contradictions et des oublis parce que l’historique accumulé finit par noyer le signal utile.

Ce n’est pas un bug ponctuel, mais une conséquence du fonctionnement des modèles: chaque requête reconstruit l’état à partir du contenu envoyé, sans mémoire persistante, et la fenêtre de contexte est limitée (par exemple, sur de nombreux modèles, elle tient quelques milliers de tokens).

En développement, cela se traduit par des comportements concrets et reproductibles.

Exemples observables: l’agent réintroduit une option précédemment abandonnée, oublie une règle système définie en début de session, ou renvoie une version antérieure d’un fichier corrigé parce que le correctif est hors de la fenêtre pertinente.

Les essais échoués, les commentaires temporaires et les fragments de debug s’accumulent comme du bruit: chaque élément prend des tokens et diminue la priorité des informations réellement utiles.

• Contradictions: L’agent affirme deux choses incompatibles dans la même session.
• Réponses conditionnelles: L’agent répond par «Peut-être», «Si» ou «Ça dépend», alors que la question était fermée.
• Répétition d’erreurs corrigées: L’agent refait une faute déjà corrigée précédemment.
• Hausse du nombre d’allers-retours: Tâches simples nécessitent plus d’échanges pour arriver à la solution.

User: Implémente la validation X et supprime l'option Y.
Agent: Fait, j'ai supprimé l'option Y.
User: Le test échoue encore, garde Y désactivé et applique le patch Z.
Agent: Réintègre l'option Y et renvoie l'ancienne version du code.

Symptôme	Cause probable	Action immédiate recommandée
Contradictions	Informations conflictuelles dans l’historique	Épurer l’historique et réaffirmer la règle clé dans le prompt
Réponses vagues/conditionnelles	Bruit élevé, signal utile dilué	Fournir un contexte minimal et explicite, supprimer les essais non pertinents
Répétition d’erreurs corrigées	Correction hors fenêtre de contexte	Réintroduire le correctif dans le prompt ou snapshot du code

Comment fonctionne la fenêtre de contexte de Claude Code ?

Claude réassemble l’état de la conversation à chaque requête en incluant l’historique dans la fenêtre de contexte, qui, même si elle est large (≈200 000 tokens mentionnés publiquement), peut se remplir rapidement lors de sessions techniques intensives.

Chaque message est sérialisé avec son rôle, son horodatage et son contenu, puis tokenisé pour être injecté dans la fenêtre de contexte. Les fichiers de code sont coûteux en tokens : un extrait de 50 lignes peut faire quelques centaines de tokens, alors qu’un fichier de 1 000 lignes peut représenter plusieurs milliers à dizaines de milliers de tokens selon la densité de code et des commentaires. Les dumps de logs sont encore plus gourmands parce qu’ils duplicent souvent des motifs et du bruit. Les allers-retours de debugging multiplient les tokens en accumulant états intermédiaires, patchs et commentaires.

Quand la fenêtre approche de sa limite, le modèle priorise les messages récents, entraînant la perte d’anciennes directives, l’accumulation de bruit et l’apparition de contradictions quand plusieurs versions successives du même code coexistent. Ces phénomènes dégradent la précision et la cohérence des réponses, et provoquent parfois des recommandations obsolètes.

Exemple de packaging pseudo-API montrant comment l’historique est joint :

// Préparer l'historique
history = [
  {role: "system", content: "Directives globales (résumé)"},
  {role: "user", content: "Question initiale"},
  {role: "assistant", content: "Réponse 1"},
  {role: "user", content: "Patch: diff du fichier X (seulement le diff)"}
]

// Envoi
request = {
  model: "claude-code",
  context: history, // tout l'historique tokenisé
  tools: ["link-to-large-file-storage"]
}

Le coût et la latence augmentent linéairement avec le nombre de tokens envoyés : plus l’historique est lourd, plus le temps de préparation et d’inférence augmente, et plus la facture liée au processing token-based grimpe.

Recommandations techniques :

• Limiter la quantité de code inline en ne fournissant que les extraits pertinents.
• Envoyer des diffs plutôt que des fichiers entiers pour réduire les tokens.
• Externaliser les gros fichiers dans un stockage et n’inclure qu’un résumé + lien.
• Résumé automatique de l’historique ancien pour conserver directives sans tokeniser tout le texte.

État	Précision	Cohérence	Coût / Latence
Petite fenêtre	Élevée sur le contexte actuel	Bonne, directives claires	Faible
Fenêtre saturée	Diminuée à cause du bruit	Risques de contradictions	Élevé

Comment détecter le context rot tôt ?

Pour prévenir le phénomène de context rot dans Claude Code, il faut surveiller des signaux simples et automatisables afin d’intervenir avant que la session ne devienne inefficace.

Métriques quantitatives (mesurables et automatisables) :

• Surveiller l’utilisation des tokens : Token signifie unité de texte (morceau de mot ou mot entier selon le modèle). Alerte recommandée entre 50 % et 75 % de la fenêtre contextuelle restante.
• Compter le nombre d’échanges : Plus de 50 allers-retours peut signaler une inflation de la conversation et une perte de signal.
• Tracer la fréquence des demandes de clarification : Si plus de 10 % des réponses nécessitent une reformulation ou un « précise » cela indique une dérive.

Métriques qualitatives (détectables par règles ou tests automatisés) :

• Réapparition d’idées abandonnées : Détection de retours fréquents sur des points déjà rejetés.
• Réponses conditionnelles excessives : Multiplication des « si » et « peut-être » qui traduisent une perte de confiance dans le contexte.
• Contradictions internes : Détecter énoncés incompatibles via règles simples de cohérence pour entités/clés.

Procédures d’observation pratiques :

• Checkpoint périodique : Sauvegarder un résumé stable toutes les N minutes ou tous les M échanges (ex. tous les 10 échanges).
• Tests unitaires automatisés : Exécuter sur snippets critiques des prompts-tests pour détecter régressions de réponse après évolutions de session.
• Compactage automatique : Lancer une routine de résumé/filtrage avant d’atteindre le seuil d’alerte tokens.

Seuil indicatif	Action
50 % tokens	Activer résumé automatique
75 % tokens	Forcer compactage / checkpoint
>50 échanges	Revue manuelle + tests unitaires

Exemple de script pseudo-Python :

# Pseudo-code, non lié à une API commerciale
def monitor_session(session):
    tokens = count_tokens(session)  # Compte approximatif des tokens
    exchanges = len(session.messages)
    clarif_rate = count_clarifications(session) / max(1, exchanges)
    if tokens > SESSION_TOKEN_LIMIT * 0.75:
        trigger_compactage(session)
    elif tokens > SESSION_TOKEN_LIMIT * 0.5:
        trigger_resume_summary(session)
    if exchanges > 50 or clarif_rate > 0.10:
        run_unit_tests(session)

Recommandation finale : Les chiffres dépendent du projet et de la fenêtre du modèle, mais démarrer avec 50 %/75 % pour les tokens et 50 échanges comme seuil d’alerte donne un bon compromis entre réactivité et coût opérationnel.

Quand et comment utiliser /clear et autres remèdes ?

Quand la session devient confuse ou hors-sujet, /clear est le remède radical à utiliser immédiatement pour repartir d’une page blanche sans héritage d’instructions contradictoires.

/clear : Utiliser lors d’un changement de tâche majeur, après une phase expérimentale saturée d’essais, ou quand des contradictions persistent malgré corrections.

/compact : Commandes ou routines qui compressent l’historique en un résumé systémique conservant l’intention et les règles essentielles.

Voici les scénarios d’usage :

• Lors d’un changement de projet : Effacer la session si l’objectif change complètement.
• Après des tests intensifs : Lancer /clear quand les essais successifs ont créé du bruit et des réponses incohérentes.
• Quand les corrections échouent : Préférer /clear si les contradictions persistent malgré plusieurs instructions correctives.

Créer des skill files minimalistes accélère la reprise après /clear.

• Structure recommandée : Contenir 5–10 règles claires, 2–3 exemples d’entrée/sortie, et les contraintes de style (ton, longueur, mots interdits).
• Bonnes pratiques : Versionner, garder chaque fichier ≤ 1 page, réviser toutes les 2–4 semaines et éviter les redondances.

Solutions complémentaires : Sauvegarder états critiques en résumé et externaliser l’historique dans un vector store (recherche par embeddings) pour effectuer retrieval plutôt que surcharger la fenêtre de contexte.

# Pseudo-shell : Sauvegarder puis /clear
echo "Résumé pré-clearing" > session-summary.txt
cli-chat --send-message "/save-summary file=session-summary.txt"
cli-chat --send-command "/clear"
# Re-injecter si besoin : cli-chat --send-file session-summary.txt

# Pseudo-Python : Résumer l'historique et remplacer par un message summary
def summarize(history):
    # Retourner 3-5 phrases synthétiques conservant intentions et règles
    return "Résumé : Objectif X, contraintes Y, règles principales A, B, C."

history = load_history()
summary = summarize(history)
# Remplacer l'historique dans la session par un message unique contenant le résumé
session.replace_history_with([{"role":"system","content":summary}])

/clear	Avantage : Remède radical et instantané.	Inconvénient : Perte d’historique non sauvegardé.	Moment : Changement de tâche majeur, netoyage après tests.
/compact	Avantage : Conserve l’essentiel sans surcharge.	Inconvénient : Risque d’omission de détails utiles.	Moment : Maintien périodique, avant saturation.
Skill files	Avantage : Référence stable et légère.	Inconvénient : Nécessite maintenance active.	Moment : Utilisation quotidienne, onboarding.
Mémoire externe	Avantage : Scalable via retrieval, conserve contexte riche.	Inconvénient : Coût et latence; nécessite embeddings.	Moment : Projets longs ou multi-sessions.

Prêt à garder votre agent Claude précis et efficace ?

Le context rot est inévitable quand une session technique accumule code, essais et discussions. En reconnaissant tôt les signes (contradictions, répétitions, réponses hésitantes) et en appliquant des remèdes simples — /clear quand il faut repartir, /compact et résumés périodiques pour alléger l’historique, skill files minimalistes et mémoire externe via retrieval — on maintient la précision et la vitesse. Vous gagnez du temps, réduisez les allers-retours inutiles et protégez la qualité des livrables.

FAQ

• Qu’est‑ce que le context rot ?
  Le context rot est la dégradation progressive de la qualité des réponses d’un assistant au fur et à mesure que l’historique d’une session remplit la fenêtre de contexte, noyant les informations utiles sous du bruit (essais, erreurs, versions anciennes).
• Quels sont les signes avant‑coureurs du context rot ?
  Contradictions dans les réponses, réapparition d’idées abandonnées, réponses trop conditionnelles (peut‑être/si), multiplication des allers‑retours pour tâches simples et réapparition d’erreurs déjà corrigées.
• Quand utiliser la commande /clear ?
  Utilisez /clear lors d’un changement de tâche majeur, après une phase exploratoire saturée d’essais, ou quand la conversation est confondante malgré tentatives de clarification. Sauvegardez d’abord les éléments utiles (résumé, fichiers) avant d’effacer.
• Que fait /compact et pourquoi l’utiliser ?
  /compact génère un résumé compressé de l’historique pour conserver l’intention et les règles clés tout en libérant de la place dans la fenêtre de contexte. C’est un compromis entre tout conserver et tout effacer.
• Comment prévenir durablement le context rot ?
  Adopter des skill files minimalistes, résumés périodiques, externaliser l’historique pertinent dans un vector store (retrieval) et automatiser des checkpoints permet de garder l’agent pertinent sans perdre d’information critique.

 

 

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. J’accompagne des clients comme Logis Hôtel, Yelloh Village, BazarChic ou la Fédération Française de Football sur leurs problématiques de data, trace et automatisation. Responsable de l’agence webAnalyste et de l’organisme Formations Analytics, je peux vous aider à implémenter des workflows robustes pour éviter le context rot — contactez-moi.