Claude Code: gérer le contexte, compact, clear et les sessions

Claude Code: le goulot, c'est le contexte

Avant de parler de modèle ou de plugin, regarde la fenêtre de contexte. Avec Claude Code, chaque message, chaque fichier lu, chaque log d'outil et chaque réponse s'accumulent dans la session. Le modèle relit tout ce passé pour prédire le token suivant. Plus la session avance, plus le coût monte, et plus la qualité peut chuter avant même que tu aies l'impression d'avoir « fini ».

Les fenêtres actuelles sont grandes, de quelques centaines de milliers de tokens jusqu'à un million selon le modèle et l'offre. Une grande fenêtre ne garantit pas une qualité illimitée pour autant. En pratique, on observe deux zones: une zone « smart » où les réponses restent solides, puis une zone où la pertinence chute. On l'appelle souvent la dump zone: passé un certain pourcentage d'occupation de la fenêtre, le raisonnement n'est plus le même.

Pour piloter l'équipe, retiens un ordre de grandeur utile. Plusieurs retours terrain évoquent une dégradation nette quand on s'approche de la moitié à 60% de la fenêtre utile, surtout avec des boucles d'outils longues. Prends-le comme un signal d'alarme plutôt que comme une loi physique: c'est le moment de compacter ou de découper la session, pas de « pousser encore un peu ».

Claude Code t'avertit d'ailleurs assez tôt: quand tu approches de la fin utile, l'outil te pousse à faire un compact. Au quotidien, la guerre du token se gagne avec moins de bruit, des sessions plus courtes, des résumés intentionnels et des tools bornés.

Compact vs clear: deux commandes, deux jobs

La commande compact demande au modèle de résumer l'historique utile (l'outil te le propose aussi de lui-même). Elle compacte les allers-retours, les recherches de fichiers, les essais d'édition et la compréhension du flux. Tu continues ensuite le même fil avec un résumé plus petit, sans tout recharger à la main. Attention: le résumé lui-même coûte des tokens, un compact n'est jamais « gratuit ».

La commande clear, elle, change de fil. Tu sors du contexte de discussion en cours pour repartir de zéro. Retiens la différence ainsi: compact compresse pour continuer le même objectif, clear remet le chat à zéro pour un objectif différent.

Ce qui survit quand tu fermes Claude Code dépend de ce que tu as matérialisé ailleurs. Un résumé qui ne vit que dans la session peut disparaître à la fermeture. Une note écrite dans un fichier du repo (CLAUDE.md, memory, skill, handoff) survit, elle. La règle est simple: ce qui doit rester d'un jour sur l'autre s'écrit dans le repo.

Sur un monorepo ou une feature longue, compacte de façon intentionnelle et fréquente, sans attendre la dump zone. On compacte après chaque étape (la recherche, le plan, l'implémentation d'un sous-objectif) et on documente un handoff court: l'objectif, les décisions, les fichiers touchés, la suite. Moins de magie, plus de contrôle.

Dump zone: signaux et contre-mesures

Les LLM s'appuient surtout sur le début et la fin du contexte, et le milieu s'érode. Avec trop de MCP, trop de fichiers et trop de logs, tu entres vite dans la zone où les réponses deviennent génériques, se contredisent, ou « oublient » une contrainte posée 40 messages plus tôt.

Certains signaux ne trompent pas:

• L'agent relit des fichiers déjà vus sans raison
• Il propose des diffs hors scope ou ignore la definition of done
• Il boucle sur les outils
• Il te dit que tu as « complètement raison » en mode sycophante juste avant de dérailler

Ce dernier réflexe est un bon marqueur: quand l'agent devient trop d'accord avec toi, il est temps de faire un reset ou un handoff.

Les contre-mesures tiennent en une liste courte:

• Un objectif par session
• Un compact après chaque étape, un clear quand le sujet change
• Moins de MCP actifs et des permissions destructrices refusées (rm -rf par exemple)
• Un monorepo découpé (sous-arbre, package, CLAUDE.md local)
• Des sous-agents pour isoler une recherche lourde

Garde aussi en tête que plus de commits dans une session saturée ne veut pas dire plus de valeur. On regarde les incidents et le temps de revue après merge.

Permissions, sandbox, yolo

Chaque commande shell ou outil MCP peut demander une permission. On alloue ce qui est nécessaire (les tests, le build) et on refuse le destructif par défaut. Les settings d'équipe peuvent pré-autoriser une allowlist et bloquer tout le reste.

Le mode yolo, qui saute toutes les permissions, est tentant dans une sandbox jetable. Il devient dangereux sur une machine de dev avec des secrets et des accès prod. La règle est simple: une sandbox isolée, ou pas de yolo.

Sans la troisième brique, celle du contrôle (les permissions, la validation humaine, l'allowlist), tu as juste un POC ou une démo, même avec le meilleur agent de code.

Init, CLAUDE.md, skills et plan mode

La commande init et les fichiers d'instructions du repo donnent un contexte permanent: la stack, les commandes de test, les zones interdites, les conventions. Versionne-les. Un CLAUDE.md racine plus un CLAUDE.md par package chaud bat un monologue de 40 messages.

Les skills sont des compétences réutilisables: créer un plan, mener une migration, appliquer des design tokens, dérouler un scénario de test. Un skill vaut mieux qu'un prompt jetable. En équipe, un skill de plan unique évite que chaque dev produise son propre format de plan et rende la review impossible.

Le mode create plan n'a rien d'un one-shot: l'agent recherche, pose des questions d'arbitrage, rédige le plan, puis itère. Si tu changes de mode ou d'outil au milieu sans matérialiser le plan dans un fichier, tu perds le fil. Garde le plan dans le repo.

Quand tu fais deux fois la même chose, extrais un skill ou une commande. Les équipes matures accumulent des dizaines de skills et des milliers de lignes de contexte versionné: c'est un produit interne, pas un gadget de chat.

Les hooks complètent le dispositif: ce sont des points d'extension pour imposer des étapes (le lint, les tests, les checks) à des moments précis du cycle. C'est utile pour garder du déterminisme autour de l'agent.

Subagents, scripts et tokens « gratuits »

Un sous-agent a sa propre fenêtre de contexte. L'orchestrateur n'avale donc pas tout l'historique de la recherche. Tu gardes un contexte focalisé et tu vas souvent plus vite sur les tâches isolables: l'exploration, la doc, un audit local.

Un script déterministe (le lint, le format, une transformation) ne consomme aucun token LLM. Quand une étape est purement mécanique, un skill qui appelle un script bat un agent qui réinvente la roue en prose.

Optimiser le bruit de l'outillage (les sorties de commandes monstrueuses, les arbres de fichiers) est aussi du context engineering côté IDE. Des outils type « token killer » existent pour compresser ce qui entre dans le modèle. L'idée clé est l'efficience des tokens, pas seulement le prix unitaire du modèle.

MCP: build, design, monde extérieur

MCP est un standard commun pour brancher des outils sur l'agent, souvent décrit comme l'« USB-C » des agents. Claude Code peut orchestrer plusieurs serveurs: le build et le simulateur (l'écosystème Xcode par exemple), le design (Figma avec les tokens, la hiérarchie, les screenshots), les tickets, la doc.

Les MCP apportent le contexte du monde extérieur, et Claude orchestre. Un prompt sans ce contexte produit du code générique qu'on jette. Un skill de design system couplé à un MCP design réduit l'écart entre la maquette et le code.

Ce contexte a un coût: plus de serveurs MCP et plus de skills, c'est plus de tokens en entrée, avant même d'écrire une ligne. Pour le jour 1, garde peu d'outils, privilégie la lecture, et mets les écritures derrière confirmation. Désactive ce qui n'est pas nécessaire à la session.

Le détail de l'architecture MCP (l'allowlist, la sécurité, le computer use) vit dans l'article Model Context Protocol. Ici, on se concentre sur l'impact dans la session Claude Code.

Plugins d'autonomie: plan d'abord, sortie ensuite

Les plugins de boucle autonome (du style « persévère jusqu'au done ») promettent un agent qui itère seul. Sans paramètres, tu grilles surtout des tokens: pas de nombre de tours maximum, pas de condition de sortie, pas de plan.

Le pattern sain tient en quatre étapes:

1. Construire le plan avec l'humain, c'est là que la valeur ajoutée est réelle
2. Générer un fichier de plan d'implémentation versionné
3. Boucler sur les tâches en mettant à jour le plan (le fait, le reste)
4. Poser des conditions de sortie explicites par objectif

La limite structurelle reste la saturation du contexte dans une longue boucle: l'agent déraille dans le même fil. Les solutions sont connues: compacter, découper en sessions, ou rejouer le pattern « batch » hors plugin avec des handoffs fichiers. La logique est la même, avec plus de contrôle.

Un mode yolo plus un plugin sans sandbox, ça finit en incident. La spec d'abord, l'autonomie bornée ensuite.

Debug, ADE, cloud coding agents

Donner un debugger (ou une CLI de debug) à l'agent change la boucle: il reproduit le bug, pose une hypothèse, patche, puis reteste, au lieu de deviner dans le vide. La discipline de contexte reste la même: des logs bornés, pas de dump monstrueux non filtré.

On bascule progressivement d'un IDE « sidebar chat » vers des environnements agentiques (ADE) et des agents cloud ou CI, utiles pour les jobs headless. La policy d'équipe (les permissions, les secrets, la revue) reste la même, quel que soit le client.

Côté craft, garde tes garde-fous: l'IA est facile à adopter, les protections (les tests, la revue, la segmentation des fichiers, les prompts courts et précis) le sont moins. Un bon prompt précis en vaut trois flous et économise des tokens.

Routine d'équipe (checklist)

La routine d'équipe tient en huit points:

1. Un objectif par session
2. Une spec ou un plan fichier avant toute génération large
3. Un compact après chaque étape majeure, ou avant 50-60% de la fenêtre si l'outil le signale
4. Un clear quand le sujet change
5. Un handoff fichier si la session dépasse 30-40 minutes utiles
6. Des MCP et des permissions listés pour la session
7. Des scripts déterministes pour le mécanique
8. Une revue humaine sur l'auth, le paiement, les migrations et les PII

Pour l'enablement, on privilégie un atelier d'un jour, à 8 personnes maximum, sur un repo réel. On y force le compact, le clear et le plan versionné, pas le tour des features.

Si vous voulez cadrer Claude Code et les conventions d'équipe sur un process réel, on peut le faire en 20-40 minutes.