Comment prévenir le context rot dans Claude Code ?

En limitant l’historique inutile et en compactant l’état, on réduit nettement le context rot dans Claude Code. Cet article explique ce qu’est le phénomène, comment le repérer et quatre remèdes pratiques (/clear, /compact, skills légers, récupération par vecteurs). Lecture : 5–7 minutes.

Pourquoi le context rot arrive‑t‑il dans Claude Code ?

Le context rot survient quand la fenêtre de contexte se remplit et que le signal utile est noyé par le bruit. Claude Code garde en mémoire les messages, fichiers et itérations de la session dans une « fenêtre de contexte » qui peut atteindre, selon Anthropic, jusqu’à 200 000 tokens. Un token représente environ 0,75 mot ou ~4 caractères en anglais, ce qui donne une idée concrète de la capacité : 200 000 tokens ≈ 150 000 mots.

La mécanique est simple et opérationnelle : chaque message ou fichier consommé alimente cet espace limité. Plus on ajoute de contenu, moins l’attention du modèle peut se concentrer sur les éléments anciens ou pertinents. L’attention distribuée signifie que les poids d’importance se répartissent entre tous les tokens, ce qui dilue l’influence des informations clés. La saturation de l’espace de représentation rend aussi plus difficile la création de vecteurs distincts pour chaque concept, donc le modèle confond ou oublie des détails.

Par exemple, un dépôt complet uploadé de 10 000 tokens (≈7 500 mots) occupe déjà 5 % d’une fenêtre à 200 000 tokens. Un autre exemple courant est une longue itération de debug composée de 40 échanges détaillés et de traces de logs totalisant 30 000 tokens : cela représente 15 % de la fenêtre et augmente fortement le risque que les premières spécifications du cahier des charges soient « enfouies ». Ces accumulations rendent les requêtes suivantes moins précises et plus sujettes aux erreurs contextuelles.

• Bonne pratique résumée : Préserver le signal en évitant d’envoyer des blobs non filtrés.
• Conséquence directe : Les anciens messages pèsent moins dans les décisions du modèle.

Taille de session	Risque de context rot
Petite (<5 000 tokens)	Faible (≤5 %)
Large (10 000–50 000 tokens)	Modéré à élevé (5–25 %)

Passons maintenant à la détection : comment repérer quand le context rot commence à impacter les résultats.

Comment reconnaître les signes du context rot ?

Context rot se repère par quatre signes principaux : répétition d’idées abandonnées, réponses évasives, contradictions et réapparition d’erreurs déjà corrigées.

• Répétition d’idées abandonnées : Observer que le modèle réintroduit des objectifs ou contraintes qu’on a explicitement annulés. Exemple de prompt : « Ignore la proposition A, concentre‑toi sur B. » Exemple de réponse problématique : « On pourrait revenir à A, car… » Montrer ce comportement prouve que le contexte historique pollue la génération.
• Réponses évasives : Repérer des phrases vagues ou floues quand des précisions ont déjà été fournies. Exemple de prompt : « Donne le code exact pour X. » Réponse typique en cas de context rot : « Cela dépend de plusieurs facteurs, mais voici une piste… » Ce manque de précision signale une perte de focus dans le contexte.
• Contradictions : Identifier des affirmations qui se contredisent au fil de la session. Exemple de prompt : « Valide que la fonction F renvoie True. » Réponses successives problématiques : « Oui, F renvoie True. » puis « Non, F peut renvoyer False dans ce cas. » Les contradictions sont un symptôme clair de mémoire contextuelle corrompue.
• Réapparition d’erreurs déjà corrigées : Vérifier si un bug précédemment corrigé réapparaît dans une nouvelle réponse. Exemple de prompt : « Ne pas utiliser global state. » Réponse fautive : « J’utilise global state ici… » Cela montre que les corrections ne sont pas stables.

Trois métriques simples à suivre pour détecter la dégradation :

• Nombre de tokens cumulés : Les tokens sont des unités de texte utilisées par le modèle (mots ou morceaux de mots). Seuil d’alerte recommandé : >20 000 tokens.
• Taux d’allers‑retours pour une même tâche : Ratio messages échangés / tâches complétées. Valeur élevée indique friction contextuelle.
• Fréquence de reprise d’un ancien thread : Pourcentage de messages qui référencent une ancienne décision. Au‑delà de 10% il faut investiguer.

Exemple chiffré : Une session monte de 5 000 à 50 000 tokens en 3 heures, le nombre d’incohérences passe de 1 à 8 par heure et le temps de résolution d’un bug passe de 10 à 45 minutes.

Conseils rapides pour un monitoring léger : exporter la conversation en JSON et lancer un script qui compte les tokens, détecte références à anciens topics (mots‑clés) et calcule le ratio allers‑retours.

# Script Python simple (extrait)
import json
def count_tokens(convo): 
    return sum(len(m['content'].split()) for m in convo)  # approximation
data = json.load(open('convo.json'))
tokens = count_tokens(data['messages'])
if tokens>20000:
    print("Alerte tokens:", tokens)

Suivre ces indicateurs permet d’anticiper la dégradation ; la suite traite des remèdes opérationnels pour corriger le context rot.

Quand utiliser /clear et quelles alternatives ?

Quand la session devient incohérente ou que l’on change de tâche sans aucun lien, /clear est souvent la solution la plus simple et la plus sûre.

/clear réinitialise complètement la session et efface tout l’historique conversationnel : l’effet attendu est un état vierge où le modèle ne conserve plus de biais ou d’instructions antérieures pouvant polluer le code ou les réponses.

Inconvénients : perte d’historique utile (exemples, décisions, contexte de debugging) et nécessité de réinjecter les informations essentielles manuellement.

Alternatives moins radicales et comment les utiliser :

• /compact : Résume l’état conversationnel pour garder l’essentiel sans conserver le bruit. Procédure recommandée : compacter, vérifier 2–3 prompts clés, puis continuer le développement.
• Fichiers de skills allégés : Créer des fichiers contenant only les règles, conventions de nommage, snippets et patterns réutilisés. Contenu typique : objectifs, API surfaces, exemples de tests, conventions d’architecture.
• Pinning de faits essentiels : Marquer les faits immuables (par ex. version de runtime, secrets non sensibles, conventions) pour qu’ils restent accessibles sans tout l’historique.
• Externalisation vers une base de vecteurs : Stocker l’historique en embeddings et récupérer à la demande les fragments pertinents (RAG : Retrieval-Augmented Generation, récupération augmentée par recherche).

Tableaux comparatifs succincts :

/clear — Efficacité	Maximale pour supprimer tout bruit
/clear — Coût	Faible technique, fort coût humain (réinjection)

/compact — Efficacité	Bonne pour réduire le bruit sans tout perdre
/compact — Coût	Faible
/compact — Complexité	Moyenne

Fichiers de skills — Quand	Projets longs, multi-équipes
Vecteurs/RAG — Quand	Historique volumineux et recherche contextuelle

Exemples de commandes / workflow :

/compact
Vérifier prompt1: "Quel est l'état actuel du module auth ?"
Vérifier prompt2: "Liste des tâches ouvertes"
Continuer le développement

Règle pratique : Préférer /clear quand la session est contradictoire ou si l’on change de tâche sans aucun lien ; préférer le compactage ou l’externalisation quand l’historique contient des informations réutilisables.

Quelles bonnes pratiques pour garder Claude Code performant ?

Prévenir vaut mieux que réparer : compactage régulier, skills allégés, récupération par vecteurs et gestion stricte des uploads réduisent le « context rot » et maintiennent Claude Code performant. J’applique ces principes tous les jours en dev pour éviter que l’historique ne dégrade les réponses.

• Limiter la taille des uploads.
  Limiter les fichiers entrants à des seuils clairs (par exemple 2–5 Mo par document) pour éviter d’empoisonner le contexte avec du contenu rarement utile.
  Bénéfice : Réduction directe du coût en tokens et du temps de parsing.
  Priorité : Haut.
• Résumer périodiquement l’état.
  Générer des résumés condensés (1–3 paragraphes) de threads actifs pour remplacer l’historique verbeux.
  Bénéfice : Conserve l’essentiel tout en libérant plusieurs milliers de tokens.
  Priorité : Haut.
• Archiver les threads terminés.
  Déplacer les conversations closes vers une archive consultable via recherche vectorielle plutôt que dans le contexte actif.
  Bénéfice : Empêche l’historique mort de s’accumuler.
  Priorité : Haut.
• Maintenir des skills minimalistes.
  Garder chaque « skill » (module ou routine réutilisable) concentré sur une tâche précise et léger en prompts.
  Bénéfice : Moins de prompt bloat et comportements inattendus.
  Priorité : Haut.
• Utiliser une base de vecteurs pour docs volumineux.
  Stocker documents long format en embeddings et récupérer seulement les passages pertinents (explication : embeddings = représentations numériques pour recherche sémantique).
  Bénéfice : Accès rapide aux infos utiles sans charger tout le texte.
  Priorité : Haut.
• Nettoyer les logs de debug.
  Supprimer ou compacter les traces de debug volumineuses après résolution des bugs.
  Bénéfice : Empêche les sessions de debug de saturer le contexte.
  Priorité : Moyen.
• Réduire le verbiage des system prompts.
  Raccourcir les instructions système aux éléments essentiels et externaliser les règles longues dans une doc référencée.
  Bénéfice : Gain de tokens pour le contexte utile.
  Priorité : Moyen.
• Définir des points de contrôle (checkpoints).
  Sauvegarder l’état clé à intervalles réguliers et prévoir une routine de rollback.
  Bénéfice : Permet de revenir à un état performant sans reconstruire tout le contexte.
  Priorité : Haut.
• Surveiller le compteur de tokens et automatiser le compactage.
  Déclencher un compactage quand l’historique dépasse 20–50k tokens (heuristique).
  Bénéfice : Intervention avant dégradation perceptible des réponses.
  Priorité : Haut.

Voici un workflow pragmatique en 5 étapes pour une session de dev :

Start	Initialiser l’environnement, charger skills essentiels, vérifier token budget.
Iterate	Coder et tester en courtes boucles, limiter uploads et logs.
Compact	Générer résumé du thread actif et remplacer l’historique détaillé.
Checkpoint	Sauvegarder état, versionner le résumé et les skills.
Clear if necessary	Archiver ou purger l’historique quand les seuils token sont atteints ou après sessions de debug intenses.

Prêt à garder Claude Code net et efficace ?

Le context rot survient quand la fenêtre de contexte se remplit et que le bruit (fichiers volumineux, logs, essais) surpasse le signal utile. Repérez-le via répétitions, contradictions et hausse des allers‑retours. Les réponses rapides sont : /clear pour repartir proprement, /compact pour condenser l’état, skills allégés et externalisation (vecteurs) pour les gros docs. En appliquant ces bonnes pratiques, vous retrouvez des réponses plus précises et gagnez du temps de développement — bénéfice immédiat pour la qualité et la vitesse de vos itérations.

FAQ

• Qu’est‑ce que le context rot dans une session Claude Code ?
  Le context rot désigne la dégradation progressive de la qualité des réponses quand la fenêtre de contexte se remplit et que le signal utile est noyé par du bruit (fichiers volumineux, essais, logs).
• Comment savoir quand intervenir (clear/compact) ?
  Surveillez les signes : répétitions d’anciennes idées, contradictions, réponses évasives ou besoin de plus d’allers‑retours. Intervenez si ces symptômes apparaissent ou si l’historique devient très volumineux.
• Quelle différence entre /clear et /compact ?
  /clear efface tout l’historique (radical). /compact condense et résume l’état pour garder l’essentiel sans tout perdre — moins destructeur mais parfois moins précis qu’un reset total.
• Que faire des gros fichiers ou des docs de référence ?
  Ne les laissez pas dans l’historique brut : stockez‑les dans une base de vecteurs et récupérez‑les à la demande, ou résumez‑les avant de les envoyer pour garder la fenêtre de contexte légère.
• Existe‑t‑il des seuils pratiques pour agir ?
  Plutôt que seuils absolus, utilisez des heuristiques : intervenir après une session de debug intensif, ou quand vous dépassez 20–50k tokens cumulés. Ajustez selon votre flux de travail.

 

 

A propos de l’auteur

Franck Scandolera — expert & formateur en Tracking avancé server-side, Analytics Engineering, automatisation No/Low Code (n8n) et intégration de l’IA en entreprise. Responsable de l’agence webAnalyste et du centre de formation Formations Analytics. Références clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Française de Football, Texdecor. Dispo pour aider les entreprises => contactez moi.