Il condense l’historique pour préserver décisions et contexte ; exécutez /compact autour de 60 % d’utilisation pour limiter la dérive. Cet article identifie les signes de dégradation, explique le fonctionnement technique, détaille le bon timing et montre comment surveiller la fenêtre de contexte.
Pourquoi les sessions Claude Code dévient-elles ?
Les sessions dévient quand la mémoire active du modèle (la fenêtre de contexte) se remplit et compresse l’historique ancien, ce qui fait perdre des décisions et des patterns globaux. Les symptômes sont clairs : répétitions, contradictions et optimisations locales qui dégradent l’architecture conçue au départ.
Rôle des tokens et de la fenêtre de contexte. Un token est une unité de texte traitée par le modèle, souvent un sous-mot ou un groupe de caractères (par exemple, 1 token ≈ 4 caractères en anglais ; 1 000 tokens ≈ 750 mots selon la tokenisation d’OpenAI). La fenêtre de contexte est la mémoire à court terme du LLM où toutes les instructions, le code et les dialogues récents sont stockés et utilisés par le mécanisme d’attention (voir Vaswani et al., 2017 pour l’architecture Transformer).
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 l’accumulation consomme l’espace utile. Chaque nouvelle instruction, chaque log d’exécution et chaque exemple ajouté prend des tokens. La fenêtre finie oblige le modèle à remplacer ou à compresser l’historique ancien. La compression automatique perd souvent des détails structurels : décisions d’architecture, conventions de nommage, invariants de design.
Conséquences concrètes en session de codage. L’accumulation provoque :
- Reprises et répétitions : Le modèle redemande ou regénère du code déjà fourni.
- Contradictions : Instructions anciennes et nouvelles deviennent incohérentes entre elles.
- Régressions de design : Changements locaux (p. ex. micro-optimisation) qui cassent l’architecture globale.
- Optimisation locale : Le modèle favorise corrections immédiates au détriment d’une vision systémique.
Scénario séquentiel illustratif.
- Utilisateur : « Construis un module authentification modulaire, tests inclus. »
- Assistant : « Proposition : architecture en 3 couches, interfaces claires, tests unitaires. »
- Utilisateur : « Optimise la fonction de hachage pour la vitesse, privilégie allocations minimales. »
- Assistant : « Remplace la couche d’abstraction par une implémentation spécialisée pour la perf ; suppression des tests d’intégration pour alléger le code. »
La régression vient du fait que l’optimisation locale a effacé ou comprimé la contrainte architecturale initiale.
Pourquoi /compact est pertinent. La commande /compact force une condensation contrôlée et une purge des redondances dans la fenêtre de contexte, préservant les décisions structurantes tout en libérant des tokens. Cette opération réduit la dérive en maintenant visibles les patterns globaux nécessaires à une session de codage cohérente.
Sources : Vaswani et al., « Attention Is All You Need » (2017) ; OpenAI Tokenizer docs (https://platform.openai.com/tokenizer).
Comment se manifeste la context rot ?
La context rot commence par réponses incohérentes mineures et évolue vers la perte de décisions clés et la réintroduction de corrections annulées. Elle se manifeste d’abord par petits écarts, puis par ruptures de logique et régressions qui coûtent du temps et de la confiance.
- Signes précoces (références obsolètes, variations subtiles dans le style de code, questions répétées) : On voit des références à des fichiers ou des constantes qui ont été modifiées, des variations légères du style de variable ou d’indentation, et des prompts qui demandent deux fois la même précision. Ces signes indiquent que le modèle compresse l’historique et perd des détails contextuels récents.
- Signes avancés (désalignement sur les patterns établis, contradictions dans l’API ou la structure du projet, régressions fonctionnelles) : On observe des décisions opposées à des conventions précédentes, des appels d’API incohérents, ou des tests unitaires qui repassent d’un état vert à rouge après des itérations censées corriger un bug.
- Pourquoi chaque token compte (poids du texte, exemples, logs) : Les tokens sont les unités d’information que le modèle pondère via les mécanismes d’attention. Plus un token est ancien, plus sa contribution est comprimée ou évincée quand la fenêtre contextuelle est pleine. Les preuves empiriques de l’attention (Vaswani et al., 2017) expliquent pourquoi la récence et la fréquence pèsent fortement sur la décision finale.
- Indicateurs observables en pratique : Mesurez le taux d’échecs unitaires (augmentation soudaine de +10–30% signale un problème), le nombre de fois où l’on redemande la même précision, la fréquence des clarifications clients et le nombre d’itérations nécessaires pour atteindre une spécification (si ça double, la context rot est probable). Suivez également le temps moyen entre corrections et réintroductions de bugs.
Mini-checklist opérationnelle pour repérer la dégradation dès qu’elle commence :
- Surveiller les références de code modifiées : détecter les mentions d’anciens noms ou chemins.
- Suivre les tests automatisés : déclenchements répétés après corrections indiquent régression.
- Compter les relances du prompt : plus de 2 relances pour la même précision = alerte.
- Limiter la longueur du contexte utile : résumer périodiquement l’état clé en 3–5 phrases.
- Archiver logs et exemples critiques en début de prompt pour préserver les tokens essentiels.
Que fait /compact exactement ?
/compact lance une synthèse contrôlée de l’historique en remplaçant des messages détaillés par un résumé condensé qui préserve décisions, contraintes et points d’architecture.
La mécanique repose sur une summarisation ciblée qui identifie et conserve les éléments critiques (décisions architecturales, conventions de nommage, contraintes opérationnelles) puis agrège ou élimine les informations redondantes. On utilise des heuristiques d’importance pour scorer les passages (par exemple décisions, actions à faire, paramètres techniques) et on génère un condensé abductif — c’est-à-dire un résumé qui reformule plutôt que de copier mot à mot — afin de réduire fortement le nombre de tokens tout en gardant l’intention. Cette compression réduit le bruit (répétitions, débogage intermédiaire, logs) et préserve les « ancres » utiles pour les prompts futurs.
Voici les principaux bénéfices, expliqués succinctement :
- Conservation de l’intention : Le résumé garde les objectifs et contraintes clés, ce qui évite les dérives fonctionnelles lors des itérations suivantes.
- Meilleure qualité des prompts futurs : Un contexte épuré donne des prompts plus ciblés et réduit les ambiguïtés.
- Réduction du bruit et des coûts : Moins de tokens signifie des appels plus rapides et moins coûteux aux modèles.
Limiterations importantes à connaître :
- Dépendance à la qualité de la synthèse : Si le résumé est pauvre, on perd des informations critiques.
- Risque lié au timing : Lancer /compact trop tard peut synthétiser un contexte déjà dégradé ou partiel.
- Perte irréversible : Le détail original est remplacé, il est donc prudent d’archiver l’historique brut si nécessaire.
Exemple simple (historique avant → après /compact) :
Message 1: Client précise besoin API REST pour données utilisateurs, auth OAuth2.
Message 2: Choix DB discuté : PostgreSQL vs MongoDB, on penche PostgreSQL pour ACID.
Message 3: Contrainte : réponse <200ms pour endpoints critiques.
Message 4: Décision : schéma utilisateur minimal (id, email, role, created_at).
Message 5: Convention : nommage camelCase pour JSON, snake_case pour DB.
Message 6: ToDo : écrire tests d'intégration et CI/CD.
---
Résumé /compact :
Conserver API REST avec OAuth2; utiliser PostgreSQL pour garanties ACID; exigences de latence <200ms pour endpoints critiques; schéma utilisateur minimal et conventions de nommage (camelCase JSON, snake_case DB); prévoir tests d'intégration et pipeline CI/CD.La qualité du résumé dépend autant du moment où on le lance que de la clarté des messages d'entrée ; mieux vaut compacter régulièrement et protéger les sources originales si l'on craint une perte d'information.
Pourquoi exécuter /compact à 60% ?
Exécuter /compact autour de 60 % d'utilisation maximise la qualité de la synthèse parce que la session est encore complète et cohérente. Cette règle vise à préserver suffisamment de contexte pour que le modèle conserve la fenêtre de décision et la continuité sémantique avant que la mémoire ne soit trop fragmentée.
La règle des 60 % : Exécuter /compact quand la session atteint environ 55–65 % de la capacité utile. Cette règle repose sur l'idée que garder une marge de contexte permet au modèle de relier des éléments récents et anciens sans forcer une condensation trop agressive. Des travaux sur les architectures Transformer montrent que la qualité de raisonnement et la fidélité au contexte décroissent avec l'allongement non maîtrisé des séquences (Vaswani et al., 2017 ; Kaplan et al., 2020).
- Comparaison avec attendre 80–95 % : Attendre ces niveaux augmente le risque de condenser une vue déjà altérée, de perdre des décisions intermédiaires et d'introduire des incohérences ou des hallucinations. Condenser tardivement revient souvent à supprimer ou réécrire des fragments qui servaient de fondation pour des choix faits plus tôt.
- Heuristiques pratiques : Mettre en place des checkpoints réguliers, par exemple toutes les 10–20 requêtes lourdes ou à chaque milestone fonctionnel. Automatiser via un script ou une automation qui invoque /compact quand l'utilisation tombe dans la plage 55–65 %. Garder un journal des compactions pour auditabilité.
- Mini-plan d'implémentation : Fréquence — compacter à chaque milestone ou toutes les N requêtes lourdes. Conditions déclenchantes — taille de patch > X tokens, nombre de commits > Y, temps écoulé > Z heures. Critères d'échec à surveiller — augmentation des erreurs de cohérence, baisse des scores d'exactitude, latence accrue ou perte de références critiques après compact.
# Exemple simple (bash pseudocode)
SESSION_ID=abc123
USAGE_PERCENT=$(query_session_usage $SESSION_ID) # fonction qui retourne l'utilisation en %
if [ $USAGE_PERCENT -ge 55 -a $USAGE_PERCENT -le 65 ]; then
send_message $SESSION_ID "/compact"
fi
| Timing | Avantages et risques |
| À ~60 % | Avantage: Meilleure cohérence et conservation des décisions; Risque: Nécessite monitoring fin. |
| À 80–95 % | Avantage: Moins de compactions fréquentes; Risque: Condensation d'une vue altérée, perte d'informations. |
Comment suivre l'utilisation du contexte ?
Surveillez en priorité l'indicateur d'utilisation du contexte (barre visuelle ou pourcentage) et complétez ce repère par des métriques opérationnelles pour décider d'envoyer /compact.
- Où trouver l'indicateur dans Claude Code. L'interface affiche généralement une barre ou un pourcentage près du chat ou du fil de conversation. Dans certaines variantes UI, l'indicateur est dans le panneau de métadonnées de la session ou dans un onglet "Usage".
- Métriques complémentaires à surveiller. Taux de répétitions : pourcentage de tokens ou phrases réutilisés (mesure de redondance). Nombre de clarifications : comptes des relances utilisateur demandant précision (indicateur de perte d'information). Dérive des réponses : baisse de similarité sémantique entre réponses initiales et courantes (calculable par embedding). Latence : temps de réponse en millisecondes, indicateur d'impact côté perf.
- Méthodes d'automatisation. Scripts qui pollent l'API pour récupérer usage/context metrics et déclenchent /compact quand seuils passent. Automatisation via UI possible avec un petit bot Selenium pour extraire l'indicateur si l'API ne l'expose. Orchestration low-code : utiliser n8n ou Zapier pour recevoir métriques (webhook), évaluer le seuil et appeler /compact.
- Exemples concrets. Pseudo-code d'un webhook simple qui appelle /compact quand utilisation >= 60 % :
// Endpoint webhook qui reçoit metrics
const express = require('express');
const fetch = require('node-fetch');
const app = express();
app.use(express.json());
app.post('/metrics', async (req, res) => {
const usage = req.body.context_usage_percent; // valeur 0-100
if (usage >= 60) {
await fetch('https://api.anthropic/claude-code/compact', {
method: 'POST',
headers: { 'Authorization': 'Bearer YOUR_KEY', 'Content-Type': 'application/json' },
body: JSON.stringify({ session_id: req.body.session_id })
});
console.log(JSON.stringify({ level: 'info', action: 'compact_called', usage }));
}
res.status(200).end();
});
app.listen(3000);
// Exemple de log d'alerte
{"timestamp":"2026-05-04T12:00:00Z","level":"warn","session_id":"abc123","context_usage_percent":62,"action":"compact_called"}
- Bonnes pratiques de monitoring. Produire des journaux structurés JSON pour faciliter alerting et corrélations. Mesurer des baselines avant/après chaque compact pour vérifier gains (taille de contexte, latence, taux de répétitions). Intégrer tests d'acceptation automatisés qui valident que les décisions clefs du système persistent après compact (test de non-régression fonctionnelle). S'appuyer sur bonnes pratiques SRE (Google SRE Book) pour seuils et alerting.
| Métrique | Quand alerter / action |
| Indicateur d'utilisation (barre/% ) | Alertes à 60–80% → déclencher /compact |
| Taux de répétitions | >15% → activer compactation et revue des prompts |
| Nombre de clarifications | Augmentation soutenue → compact + vérif. des instructions |
| Dérive des réponses (embedding) | Baisse de similarité >10% → compact + ré-ancrage du contexte |
| Latence | Augmentation >20% → investiguer et compacter si corrélé |
Prêt à appliquer /compact pour stabiliser vos sessions Claude Code ?
En condensant l'historique au bon moment, /compact préserve les décisions architecturales et réduit la dérive des sessions longues. L'exécution autour de 60 % d'utilisation assure une synthèse de haute qualité ; attendre trop dégrade la source et produit des résumés erronés. En appliquant les indicateurs et automatisations décrits, vous maintenez la cohérence des développements et gagnez en productivité. Bénéfice concret : moins de reprises, moins d'erreurs réintroduites et des sessions d'IA plus fiables pour avancer plus vite.
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.