/compact remplace l’historique d’une session Claude Code par un résumé structuré qui conserve les décisions, les contraintes et l’état du travail, puis libère la fenêtre de contexte. Lancée vers 60 % de remplissage et guidée par des consignes précises, la commande coupe court à la dérive des longues sessions. Voici pourquoi une session se dégrade, ce que /compact conserve réellement, à quel moment le déclencher et comment piloter tout cela sans surveiller l’écran en permanence.
Pourquoi une longue session Claude Code finit-elle par dériver ?
Une session dérive parce que tout ce qui s’y passe s’accumule dans la fenêtre de contexte : chaque prompt, chaque fichier lu, chaque sortie de commande. Plus elle se remplit, moins les consignes du début pèsent face au bruit récent, et plus le modèle prend des décisions locales qui contredisent celles d’il y a une heure.
Tokens et fenêtre de contexte. Le modèle ne lit pas des mots mais des tokens, des fragments de texte de trois à quatre caractères en moyenne. La fenêtre de contexte est le volume total de tokens traité à chaque requête : prompt système, fichiers CLAUDE.md, définitions d’outils, puis toute la conversation. Selon le modèle, Claude Code travaille avec une fenêtre de 200 000 tokens ou d’un million. Point essentiel : la conversation entière est renvoyée au modèle à chaque tour. Rien n’est oublié tant que la fenêtre n’est pas pleine, mais tout se dilue.
Entre nous, on le sait bien, faire appel à un consultant en automatisation intelligente et en agent IA, c’est souvent le raccourci le plus malin. On en parle ?
Comment réduire les tokens d’un prompt sans perdre en qualité ?
Ce qui remplit vraiment la fenêtre. Vos messages pèsent peu. Ce qui coûte cher, ce sont les résultats d’outils : un fichier de 800 lignes lu en entier, une suite de tests bavarde, une trace d’erreur, un diff complet. Lancez /context en cours de session : la commande ventile l’occupation entre prompt système, outils, fichiers mémoire et messages. Vous verrez vite que la conversation, gonflée de sorties d’outils, finit par tout dominer.
Ce que cela donne en session de code. L’accumulation produit des symptômes reconnaissables :
- Répétitions : Claude relit un fichier déjà analysé ou repose une question déjà tranchée.
- Contradictions : une convention fixée au départ (gestion des erreurs, nommage, arborescence) est abandonnée sans raison.
- Régressions : un correctif appliqué plus tôt est défait par une modification ultérieure.
- Optimisation locale : le modèle règle le problème du moment au détriment de l’architecture convenue.
Un scénario typique.
- Vous : « Crée un module d’authentification en trois couches, avec tests unitaires et tests d’intégration. »
- Claude : « Voici l’architecture : contrôleur, service, dépôt, interfaces séparées, tests à chaque niveau. »
- Quarante échanges plus tard, vous : « La vérification du mot de passe est lente, optimise-la. »
- Claude : « J’ai fusionné le service et le dépôt pour économiser un appel, et supprimé les tests d’intégration devenus redondants. »
Quels dépôts GitHub pour les AI agent skills ?
La consigne d’architecture n’a pas disparu du contexte : elle est enfouie sous quarante échanges de code, de logs et de corrections. Le modèle répond à la demande la plus récente, celle qui occupe le devant de la scène.
Ce que /compact change. /compact remplace cet historique par un résumé structuré. Les décisions d’architecture redeviennent des éléments courts et visibles, au lieu de quelques lignes perdues au milieu de 150 000 tokens de sorties d’outils. Vous repartez avec une fenêtre presque vide et un état du projet lisible.
Sources : Liu et al., « Lost in the Middle: How Language Models Use Long Contexts » (2023) ; Chroma Research, « Context Rot: How Increasing Input Tokens Impacts LLM Performance » (2025) ; documentation officielle de Claude Code (code.claude.com/docs).
Comment reconnaître le context rot ?
Comment réussir le harness engineering d’un agent ?
Le context rot désigne la baisse de qualité des réponses à mesure que l’entrée s’allonge, bien avant que la fenêtre ne soit pleine. L’étude de Chroma (2025) l’a mesuré sur 18 modèles récents : les performances reculent avec la longueur de l’entrée, y compris sur des tâches simples. En session de code, il s’installe par petites touches, puis par ruptures franches.
- Signes précoces : Claude cite une fonction ou un chemin renommé depuis, le style de code varie légèrement (indentation, nommage, gestion des erreurs), ou il vous redemande une précision déjà donnée. Le contexte est toujours là, mais il ne pèse plus assez.
- Signes avancés : décisions contraires aux conventions établies, appels d’API incohérents avec le reste du projet, tests qui repassent au rouge après une correction censée les réparer. À ce stade, chaque nouveau tour risque d’aggraver la situation.
- Pourquoi chaque token compte : un modèle exploite moins bien l’information placée au milieu d’un long contexte que celle du début ou de la fin (effet « lost in the middle »). Une décision prise au 20e message d’une session qui en compte 200 se trouve exactement dans cette zone grise, et chaque log superflu l’y enfonce un peu plus.
- Indicateurs mesurables : nombre de relances pour obtenir le même résultat, nombre d’itérations avant qu’un test passe, corrections réintroduites. Si vous devez reformuler deux fois une consigne que Claude appliquait sans effort une heure plus tôt, c’est le contexte qui est en cause, pas le modèle.
Mini-checklist pour repérer la dégradation dès ses débuts :
- Noms obsolètes : Claude mentionne-t-il des fichiers, fonctions ou variables déjà renommés ?
- Tests instables : un test corrigé repasse-t-il au rouge sans raison fonctionnelle ?
- Relances : avez-vous dû répéter la même consigne plus de deux fois ?
- Remplissage : /context ou la barre d’état indiquent-ils plus de 60 % d’occupation ?
- Bruit : les derniers échanges sont-ils surtout des logs, des diffs et des sorties de tests ?
Que fait réellement /compact ?
/compact demande au modèle de résumer toute la conversation, puis remplace l’historique par ce résumé structuré. Le message « Conversation compacted » s’affiche et la session reprend avec un contexte allégé.
Comment classer des textes en few-shot avec Scikit-LLM ?
Il faut savoir précisément ce qui est conservé et ce qui est reconstruit. Le prompt système, vos fichiers CLAUDE.md, la mémoire automatique et les outils MCP sont rechargés tels quels : ils ne passent pas par le résumé. Claude Code relit aussi jusqu’à cinq des fichiers modifiés le plus récemment et réinjecte le contenu des skills que vous avez invoquées, dans la limite de 5 000 tokens par skill. Tout le reste (vos échanges, les sorties d’outils, le raisonnement intermédiaire) n’existe plus que sous forme de résumé. Conséquence directe : une règle qui doit survivre à toutes les compactions a sa place dans CLAUDE.md, pas dans un message de la conversation.
Ce que vous y gagnez :
- Un contexte recentré : objectifs, contraintes et décisions redeviennent l’essentiel de ce que lit le modèle, au lieu d’être noyés dans les logs.
- Des réponses plus fiables : moins de bruit, moins d’ambiguïtés, moins de contradictions avec les choix passés.
- Des requêtes plus légères : chaque tour suivant renvoie un historique bien plus court, donc consomme moins de tokens.
Les limites à connaître :
- Un résumé reste un résumé : un message d’erreur exact, un numéro de ligne ou un chemin peuvent être paraphrasés, voire perdus. Si un détail est critique, consignez-le dans un fichier.
- Le moment compte : compacter un contexte déjà dégradé, c’est résumer une session qui a perdu le fil. Le résumé fige alors les erreurs.
- La compaction a un coût : /compact relit toute la conversation pour la résumer, c’est donc une requête volumineuse. Si vous changez de sujet, /clear repart de zéro sans rien coûter.
Le levier le plus sous-utilisé consiste à guider le résumé. /compact accepte des consignes, et CLAUDE.md peut contenir des instructions de compaction permanentes :
# Consigne ponctuelle, tapée dans la session
/compact Conserve les décisions d'architecture, les conventions de nommage, la liste des fichiers modifiés et les tests encore en échec. Ignore les logs de débogage.
# Consigne permanente, dans le CLAUDE.md à la racine du projet
# Compact instructions
Lors d'une compaction, conserve toujours :
- les choix d'architecture et leur justification ;
- les conventions (camelCase en JSON, snake_case en base) ;
- les contraintes de performance (réponse < 200 ms sur les endpoints critiques) ;
- les tâches restantes et les tests en échec.Avec ces consignes, le résumé ne dépend plus du seul jugement du modèle : c’est vous qui décidez de ce qui doit survivre. Toute la différence entre une compaction subie et une compaction pilotée.
Pourquoi lancer /compact vers 60 % plutôt qu’attendre l’auto-compact ?
À 60 %, la session est encore cohérente : le résumé part d’un historique sain et dispose de toute la marge nécessaire. Attendre l’auto-compact, c’est résumer une session déjà entrée dans la zone de dégradation.
La règle des 60 % : lancez /compact quand la fenêtre est remplie à 55–65 %, de préférence à la fin d’une étape logique (fonctionnalité terminée, tests au vert). Par défaut, Claude Code ne compacte automatiquement qu’à l’approche de la limite du modèle, vers 967 000 tokens sur une fenêtre d’un million. C’est tard : le context rot apparaît bien avant que la fenêtre soit pleine. Sur une fenêtre d’un million de tokens, 60 % représentent d’ailleurs 600 000 tokens, ce qui est déjà beaucoup trop. Raisonnez alors en volume absolu et visez une compaction entre 120 000 et 200 000 tokens de conversation.
- Face à l’auto-compact : laisser la compaction se déclencher seule, c’est la subir au pire moment, souvent en pleine tâche, sur un contexte saturé de sorties d’outils et sans vos consignes ponctuelles. Les décisions intermédiaires risquent d’être mal résumées, voire oubliées.
- Repères pratiques : compactez à chaque jalon (fonctionnalité livrée, refactoring terminé), avant une tâche gourmande en lecture de fichiers, et dès l’apparition d’un signe précoce de context rot. Vous passez à un sujet sans rapport ? /clear vaut mieux que /compact.
- Automatiser le seuil : plutôt que de guetter le pourcentage, réglez la fenêtre d’auto-compact sur votre seuil. La commande /autocompact accepte une valeur de 100 000 à 1 000 000 de tokens : 120 000 sur un modèle à 200 000 revient à appliquer la règle des 60 %.
# Dans la session : compacter automatiquement à 120 000 tokens
/autocompact 120k
# De façon permanente, dans ~/.claude/settings.json
{
"autoCompactWindow": 120000
}
# Dans un script ou un environnement distant (prioritaire sur les réglages ci-dessus)
export CLAUDE_CODE_AUTO_COMPACT_WINDOW=120000| Moment | Avantages et risques |
| Vers 60 % (ou fenêtre d’auto-compact réglée sur ce seuil) | Avantage : résumé fidèle d’une session encore cohérente, consignes de compaction appliquées. Risque : une compaction de plus, à déclencher au bon moment. |
| Auto-compact à la limite du modèle | Avantage : aucune intervention. Risque : résumé d’un contexte déjà dégradé, déclenché en pleine tâche, perte de décisions intermédiaires. |
Comment surveiller le remplissage du contexte ?
Affichez le taux de remplissage en permanence dans la barre d’état, puis complétez-le par /context et quelques signaux qualitatifs pour choisir le bon moment.
- Les indicateurs natifs. /context détaille la répartition de la fenêtre : prompt système, outils, fichiers mémoire, messages, espace libre. /usage donne la consommation de tokens de la session. Claude Code affiche en outre un avertissement quand la conversation approche de la fenêtre d’auto-compact.
- Une barre d’état sur mesure. La status line exécute le script de votre choix et lui transmet en JSON les données de la session, dont context_window.used_percentage. Quelques lignes suffisent pour afficher le remplissage en couleur et voir le seuil approcher sans taper la moindre commande.
- Les hooks de compaction. L’événement PreCompact se déclenche avant chaque compaction, manuelle ou automatique (matchers manual et auto) : c’est le bon endroit pour archiver la transcription brute avant qu’elle soit résumée. L’événement SessionStart avec le matcher compact s’exécute juste après : sa sortie est ajoutée au nouveau contexte, ce qui permet de réinjecter un fichier d’état du projet.
- Deux exemples prêts à l’emploi. D’abord un script de barre d’état (à déclarer dans settings.json avec « statusLine »: {« type »: « command », « command »: « ~/.claude/statusline.sh »}) qui passe à l’orange à 55 % et au rouge à 65 %. Ensuite une configuration de hooks qui archive la transcription avant chaque compaction et réinjecte un fichier d’état juste après :
#!/bin/bash
# ~/.claude/statusline.sh (nécessite jq)
input=$(cat)
MODEL=$(echo "$input" | jq -r '.model.display_name')
PCT=$(echo "$input" | jq -r '.context_window.used_percentage // 0' | cut -d. -f1)
if [ "$PCT" -ge 65 ]; then COLOR='\033[31m' # rouge : compacter maintenant
elif [ "$PCT" -ge 55 ]; then COLOR='\033[33m' # orange : préparer /compact
else COLOR='\033[32m'; fi # vert
echo -e "[$MODEL] ${COLOR}contexte : ${PCT} %\033[0m"{
"hooks": {
"PreCompact": [
{
"hooks": [
{
"type": "command",
"command": "mkdir -p \"$CLAUDE_PROJECT_DIR/.claude/archives\" && cp \"$(jq -r .transcript_path)\" \"$CLAUDE_PROJECT_DIR/.claude/archives/$(date +%Y%m%d-%H%M%S).jsonl\""
}
]
}
],
"SessionStart": [
{
"matcher": "compact",
"hooks": [
{ "type": "command", "command": "cat \"$CLAUDE_PROJECT_DIR/docs/ETAT_PROJET.md\"" }
]
}
]
}
}- Bonnes pratiques. Placez dans CLAUDE.md les règles qui doivent survivre à tout, et dans un fichier d’état (ETAT_PROJET.md par exemple) l’avancement et les décisions récentes, que Claude met à jour avant chaque compaction. Après un /compact, vérifiez en une question que l’essentiel est passé : « Rappelle-moi les conventions du projet et les tâches restantes. » Si la réponse est incomplète, corrigez tout de suite, avant que l’oubli ne se propage.
| Signal | Seuil et action |
| Remplissage (barre d’état ou /context) | 55–65 % → /compact avec consignes |
| Consignes répétées ou oubliées | Dès la deuxième relance → /compact, puis rappel des règles clés |
| Tests corrigés qui repassent au rouge | Dès la première réapparition → /compact et vérification du résumé |
| Changement de sujet | Systématiquement → /clear plutôt que /compact |
| Avertissement d’auto-compact | Immédiatement → /compact manuel avec consignes, sans attendre le déclenchement automatique |
En résumé : compacter tôt, compacter guidé
/compact n’est pas une commande de dernier recours mais un geste d’hygiène. Lancée vers 60 % de remplissage, à la fin d’une étape et avec des consignes qui précisent quoi conserver, elle remet les décisions d’architecture au premier plan et stoppe la dérive. Réglez la fenêtre d’auto-compact sur ce seuil, affichez le remplissage dans la barre d’état, sortez les règles durables dans CLAUDE.md : vos longues sessions resteront aussi fiables à la troisième heure qu’à la première minute.
FAQ
-
Que fait exactement la commande /compact ?
/compact synthétise l’historique de la session en remplaçant les messages détaillés par un résumé condensé qui conserve les décisions, contraintes et points d’architecture essentiels. -
Quand dois‑je lancer /compact pendant une session de code ?
Lancer /compact autour de 60 % d’utilisation de la fenêtre de contexte est recommandé : la session est encore complète et la synthèse sera de meilleure qualité que si l’on attend 80–95 %. -
Quels signes indiquent que le contexte se dégrade ?
Signes précoces : répétitions, références obsolètes, variations subtiles du style. Signes avancés : contradictions architecturales, réintroduction de corrections annulées, optimisation locale contre l’objectif global. -
Puis‑je automatiser l’appel à /compact ?
Oui. On peut créer un webhook ou un flow n8n qui surveille l’indicateur d’utilisation et appelle /compact à un seuil (ex. 60 %), avec logs et validations avant/après. -
La synthèse peut‑elle perdre de l’information critique ?
Un mauvais timing ou des résumés mal formulés peuvent perdre des détails. D’où l’importance du timing (60 %) et de vérifier les décisions clés après /compact via tests ou checkpoints.
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. Références : Logis Hôtel, Yelloh Village, BazarChic, Fédération Française de Football, Texdecor. Dispo pour aider les entreprises => contactez moi.
⭐ Data Analyst, Analytics Engineer et expert dans l’automatisation IA ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.