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. Le modèle relit ce passé pour prédire le token suivant. Plus la session avance, plus le coût monte et plus la qualité peut chuter avant que tu aies l'impression d'avoir « fini ».

Les fenêtres sont grandes (centaines de milliers à un million de tokens selon modèle et offre). Grande ne veut pas dire illimitée en qualité. En pratique on voit deux zones: une zone « smart » où les réponses restent solides, puis une zone où la pertinence chute. On l'appelle souvent dump zone: après un certain pourcentage d'occupation de la fenêtre, le raisonnement n'est plus le même.

Ordre de grandeur utile pour piloter l'équipe: plusieurs retours terrain et études de 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. Ce n'est pas une loi physique figée. C'est un signal d'alarme pour compacter ou découper la session avant de « pousser encore un peu ».

Claude Code t'avertit souvent assez tôt: quand tu approches de la fin utile, l'outil pousse à faire un compact. La guerre du token, au quotidien, c'est moins de bruit, des sessions plus courtes, des résumés intentionnels, des tools bornés.

Compact vs clear: deux commandes, deux jobs

Compact: tu demandes (ou l'outil te pousse) à résumer l'historique utile. Le modèle compacte les allers-retours, les recherches de fichiers, les essais d'édition, la compréhension du flux. Tu continues 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; compact n'est pas « gratuit ».

Clear: tu changes de fil. Tu sors du contexte de discussion en cours. Compact = compresser pour continuer. Clear = reset du chat pour un autre objectif.

Ce qui se perd en sortant de Claude Code dépend de ce que tu as matérialisé ailleurs. Un résumé seulement dans la session peut disparaître à la fermeture. Une note dans un fichier du repo (CLAUDE.md, memory, skill, handoff) survit. Règle: ce qui doit rester d'un jour sur l'autre s'écrit dans le repo.

Compaction intentionnelle et fréquente: sur monorepo ou feature longue, on ne attend pas la dump zone. On compacte après une étape (recherche, plan, implémentation d'un sous-objectif). On documente un handoff court: objectif, décisions, fichiers touchés, 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. Le milieu s'érode. Avec trop de MCP, trop de fichiers, 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.

Signaux: l'agent relit des fichiers déjà vus sans raison, propose des diffs hors scope, ignore la definition of done, boucle sur les outils, ou te dit que tu as « complètement raison » en mode sycophante juste avant de dérailler. Ce dernier réflexe est un bon marqueur pour reset ou handoff.

Contre-mesures: un objectif par session; compact après chaque étape; clear quand le sujet change; limiter les MCP actifs; refuser les permissions destructrices (ex. rm -rf); découper le monorepo (sous-arbre, package, CLAUDE.md local); sous-agents pour isoler une recherche lourde.

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 (tests, build) et on refuse le destructif par défaut. Les settings d'équipe peuvent pré-autoriser une allowlist et bloquer le reste.

Yolo / skip permissions: tentant en sandbox jetable. Dangereux sur machine de dev avec secrets et accès prod. Règle: sandbox isolée ou pas de yolo.

Sans la troisième brique (contrôle: permissions, HITL, allowlist), tu as juste un POC / une démo, même avec le meilleur agent de code.

Init, CLAUDE.md, skills et plan mode

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

Skills: compétences réutilisables (create plan, migration, design tokens, scénario de test). Mieux qu'un prompt jetable. En équipe, un skill de plan unique évite que chaque dev produise un format de plan différent et une review impossible.

Create plan n'est pas one-shot: l'agent recherche, pose des questions d'arbitrage, rédige le plan, itère. Si tu switches 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. Des équipes matures accumulent des dizaines de skills et des milliers de lignes de contexte versionné: c'est du produit interne, pas du gadget chat.

Hooks: points d'extension pour imposer des étapes (lint, tests, checks) à certains moments du cycle. Utile pour du déterministe autour de l'agent.

Subagents, scripts et tokens « gratuits »

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

Un script déterministe (lint, format, transform) ne consomme pas de tokens 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 outillage (sorties de commandes monstrueuses, arbres de fichiers) est aussi du context engineering côté IDE. Des outils type « token killer » existent pour compresser ce qui rentre 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 un « USB-C » des agents). Claude Code peut orchestrer plusieurs serveurs: build et simulateur (ex. écosystème Xcode), design (Figma: tokens, hiérarchie, screenshot), tickets, docs.

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

Coût: plus de serveurs MCP + plus de skills = plus de tokens en entrée, même avant d'écrire une ligne. Jour 1: peu d'outils, lecture d'abord, écritures derrière confirmation. Désactive ce qui n'est pas nécessaire pour la session.

Détail d'architecture MCP (allowlist, sécu, computer use) dans l'article Model Context Protocol. Ici: l'impact sur la session Claude Code.

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

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

Pattern sain: 1) construire le plan avec l'humain (valeur ajoutée 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 (fait / reste), 4) conditions de sortie explicites par objectif.

Limite structurelle: saturation du contexte dans une longue boucle. L'agent déraille dans le même fil. Solutions: compacter, découper en sessions, ou rejouer le pattern « batch » hors plugin avec handoffs fichiers (même logique, plus de contrôle).

Yolo + plugin sans sandbox = incident. Spec d'abord, autonomie bornée ensuite.

Debug, ADE, cloud coding agents

Donner un debugger (ou une CLI de debug) à l'agent change la boucle: repro → hypothèse → patch → retest, au lieu de deviner dans le vide. Même discipline de contexte: logs bornés, pas de dump monstrueux non filtré.

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

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

Routine d'équipe (checklist)

1) Un objectif par session. 2) Spec ou plan fichier avant génération large. 3) Compact après chaque étape majeure (ou avant ~50-60% si l'outil le signale). 4) Clear quand le sujet change. 5) Handoff fichier si la session dépasse 30-40 minutes utiles. 6) MCP et permissions listés pour la session. 7) Scripts déterministes pour le mécanique. 8) Revue humaine sur auth, paiement, migrations, PII.

Enablement: atelier 1 jour, max 8 pers., repo réel. On force compact/clear et plan versionné, pas le feature tour.

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