Gestion du contexte dans le code Claude

Claude Code dispose désormais d'une fenêtre de contexte d'un million de caractères. Ça change beaucoup de choses. Mais ça ne change pas la règle fondamentale : une fenêtre plus grande ne résout pas les problèmes de gestion des sessions.

Ce qui détermine réellement les résultats, c'est la décision que tu prends après chaque tour :

• continuer dans la même session
• /rewind vers une meilleure branche
• /clear et repartir à zéro
• /compact et conserver le résumé
• déplacer le bloc suivant vers un sous-agent

C'est la véritable couche de gestion du contexte dans Claude Code. La plupart des mauvaises sessions ne sont pas dues à la faiblesse du modèle. Elles sont causées par le fait de conserver trop longtemps un mauvais contexte.

Les directives officielles d'Anthropic du 15 avril 2026 ont mis l'accent sur ce point : chaque tour est un point de bifurcation. Cette page transforme cela en un système d'exploitation pratique.

Astuce rapide

Applique immédiatement ces deux règles :

1. Nouvelle tâche, nouvelle session. Si le travail a changé de manière significative, exécute « /clear » ou lance une nouvelle session d'claude.
2. Mauvaise voie, reviens en arrière au lieu de corriger. Si Claude s'est engagé sur la mauvaise branche, utilise /rewind au lieu d'empiler « ça n'a pas marché, essaie plutôt ça » par-dessus un contexte obsolète.

Si tu adoptes seulement ces deux habitudes, la qualité moyenne de tes sessions va rapidement s’améliorer.

Contexte, compactage et pourriture du contexte

La fenêtre de contexte, c'est tout ce que le modèle peut voir pour sa prochaine réponse :

• invite du système
• ton historique de conversation
• les appels d'outils et leurs résultats
• fichiers lus dans le contexte
• la mémoire chargée et les instructions

Claude Code peut désormais contenir bien plus qu'auparavant. Cela ne rend toutefois pas le contexte libre.

À mesure que le contexte s'épaissit, les performances peuvent se dégrader. Anthropic appelle ça **la « pourriture du contexte **» : l'attention se disperse sur plus de tokens, les données obsolètes s'accumulent, et les anciens détails non pertinents commencent à faire concurrence à la tâche qui t'intéresse vraiment en ce moment.

Quand la fenêtre est trop pleine, Claude Code compacte la session. Ça veut dire que la conversation en cours est résumée en une description plus courte et que le travail continue à partir de ce résumé. C'est utile, mais ça entraîne des pertes.

L'erreur principale est de traiter le contexte comme une archive. Ce n'est pas une archive. C'est une mémoire de travail active.

Chaque tour est un point de bifurcation

Une fois que Claude a terminé un tour, tu as plusieurs options valables. La bonne dépend du fait que le contexte actuel soit toujours porteur.

Si tu ne retiens qu'un seul tableau de cette page, utilise celui-là.

Cinq scénarios quotidiens

C'est là que les abstractions deviennent utilisables. La plupart des sessions réelles correspondent à l'un de ces modèles.

1. La mise en œuvre d'une fonctionnalité se transforme en documentation

Tu viens de terminer le middleware d'authentification et tu veux maintenant des notes de migration et de la documentation pour ce même changement.

Meilleure approche : continue dans la même session

Pourquoi : le code, les décisions et les cas limites sont toujours utiles. Recréer cet état ne ferait que te faire perdre du temps.

2. Claude a choisi la mauvaise voie d'implémentation

Il a lu les bons fichiers, mais s'est ensuite engagé dans une approche qui ne correspond pas à la base de code.

La meilleure chose à faire : /rewind

Pourquoi : garde l'exploration utile, abandonne la branche qui a échoué.

3. Une tâche, trop de résidus de débogage

Tu travailles toujours sur la même fonctionnalité, mais la session est remplie de faux départs et de logs sans issue.

Meilleure solution : /compact avec une petite astuce

Pourquoi : la tâche reste la même ; la session a juste besoin d'être allégée.

4. Tu passes du codage à la planification de la feuille de route

Domaine connexe, tâche différente.

Meilleure solution : /clear ou commence une nouvelle session

Pourquoi : les résidus de la mise en œuvre ne sont plus qu’un bruit de fond.

5. Tu as besoin d'un audit global, mais seule la conclusion compte

Tu veux une enquête parallèle sur un autre dépôt, une vérification des spécifications ou une recherche approfondie.

Meilleure solution : subagent

Pourquoi : pour éviter que le bruit intermédiaire n'envahisse le thread parent.

Quand rester dans la même session

Continue dans la même session lorsque :

• c'est toujours la même tâche
• les fichiers que Claude vient de lire sont toujours directement pertinents
• la chaîne de raisonnement actuelle est toujours utile
• relire tout serait plus lent et plus coûteux que de continuer

Exemple classique : tu viens d'implémenter une fonctionnalité et tu veux maintenant que Claude rédige la documentation pour cette fonctionnalité précise. Recommencer à zéro fonctionnerait, mais Claude devrait relire le code qu'il a déjà en contexte. Si la tâche est connexe et que la session actuelle est encore suffisamment claire, continuer est raisonnable.

La question n'est pas « est-ce que c'est lié ? » La question est « est-ce que le contexte actuel est toujours utile ? »

Quand commencer une nouvelle session

La règle empirique d'Anthropic est simple : quand tu commences une nouvelle tâche, tu devrais aussi commencer une nouvelle session.

Recommence à zéro lorsque :

• tu es passé d’une fonctionnalité à une autre
• la session contient beaucoup de bruit lié au débogage ou à l'exploration
• la branche de travail précédente est terminée
• la tâche suivante nécessite des fichiers, des objectifs ou des contraintes différents

C'est important même avec 1 Mo de contexte. Une fenêtre plus grande te laisse plus de marge avant la compaction. Ça ne rend pas le contexte non pertinent inoffensif.

Voici de bons exemples de passage à une nouvelle session :

• la refactorisation de l'authentification est terminée, on passe maintenant à la facturation
• l'implémentation est terminée, je passe maintenant à la planification de la feuille de route
• J'ai passé 40 minutes à déboguer une erreur, je passe maintenant à un autre problème

Si tu as besoin de continuité, écris un bref transfert dans la première invite de la nouvelle session :

We just finished the auth middleware refactor.
What matters for this new task:
- the session format stayed unchanged
- files that matter now are X and Y
- we ruled out approach Z

New task: write the migration notes and docs.

C'est souvent plus clair que de reporter toute l'ancienne session.

Revenir en arrière au lieu de corriger

/rewind C'est l'un des outils de gestion de session les plus efficaces de Claude Code, mais aussi l'un des moins bien utilisés.

Quand Claude lit un tas de fichiers, choisit la mauvaise approche et que tu réponds par :

That didn't work. Try B instead.

tu gardes la tentative ratée, son raisonnement et ta correction dans le même contexte. Parfois, ça va. Souvent, c'est juste de la contamination.

Meilleure approche :

1. reprends depuis le point juste après l'exploration utile
2. conserve les lectures de fichiers utiles
3. abandonne la branche qui a échoué
4. reprends à partir de là avec ce que tu as appris

Exemple :

Don't use approach A. The foo module does not expose that.
Go straight to approach B using the existing adapter in src/lib/foo.ts.

Ça donne à Claude le contexte utile sans que la mauvaise branche ne vienne s'y ajouter.

Le retour en arrière est idéal lorsque :

• l'exploration s'est avérée utile
• la tentative de mise en œuvre était erronée
• tu as appris quelque chose de précis
• tu veux conserver les preuves mais pas le chemin de l'échec

/compact vs /clear

Ces deux notions ne sont pas interchangeables.

Utilise « /compact » lorsque :

• c'est toujours la même tâche
• la session est trop chargée
• tu veux que Claude conserve les apprentissages importants
• le travail se poursuit dans la même direction

Tu peux contrôler la compaction :

/compact focus on the auth refactor, drop the test debugging

C'est particulièrement utile maintenant que le contexte 1M te donne plus de temps pour compacter de manière proactive, avant que le modèle n'atteigne son pire état de contexte.

Utilise /clear lorsque :

• il s'agit d'une nouvelle tâche
• tu ne fais plus confiance au contexte actuel
• tu veux avoir le contrôle total sur ce qui est conservé
• tu préfères rédiger le transfert toi-même plutôt que de te fier à un résumé avec perte

La différence est simple :

• /compact demande à Claude de décider ce qui est important
• /clear te laisse décider de ce qui compte

Qu'est-ce qui cause un mauvais compact ?

L'explication d'Anthropic est utile ici : les mauvais compacts surviennent souvent lorsque le modèle ne peut pas prédire la direction que prendra ton travail ensuite.

Exemple :

1. tu passes une longue session à déboguer un problème
2. l'autocompact se déclenche
3. le résumé se concentre sur ce chemin de débogage
4. ta prochaine invite passe à un problème différent mais lié
5. le détail que tu voulais a été supprimé parce que l'autocompact a estimé qu'il n'était pas pertinent

C'est pourquoi l'/compacte manuel l'emporte sur l'autocompact passif dans de nombreux cas concrets. Tu peux indiquer à Claude quelle est la prochaine direction à prendre avant qu'il ne résume.

Une règle utile :

• si tu connais la phase suivante, effectue le compact avant que Claude ne doive la deviner

Mauvais :

• débogue pendant 45 minutes
• laisser l'autocompact se déclencher
• puis change brusquement de direction

Mieux :

• terminer la phase de débogage
• lancer l'/compact focus on the fix plan and the files that matter next
• passer à la mise en œuvre

Les anti-modèles à éviter

Une mauvaise gestion du contexte n'est généralement pas dramatique. Il s'agit simplement d'une série de petites décisions prises à la va-vite.

Fais attention à ça :

• Utiliser une seule session marathon pour des tâches sans rapport
• Corriger une mauvaise branche au lieu de la revenir en arrière
• Attendre l'autocompact alors que tu connais déjà la phase suivante
• Laisser des recherches bruyantes se dérouler dans la session parente
• Considérer que le fait d'être « lié » est une raison suffisante pour continuer

Ce sont ces habitudes qui font qu'un modèle solide semble incohérent.

Utilise des sous-agents pour éliminer le bruit intermédiaire

Les sous-agents ne sont pas seulement un outil de délégation. Ce sont des outils de gestion du contexte.

Le test mental anthropique est solide :

Aurai-je besoin de ce résultat intermédiaire à nouveau, ou juste de la conclusion ?

Si la réponse est « juste la conclusion », un sous-agent est souvent la solution la plus propre.

De bons candidats pour devenir sous-agents :

• lire une autre base de code et résumer un modèle
• vérifier une implémentation par rapport à une spécification
• rédiger de la documentation à partir de ton git diff
• effectuer une recherche approfondie que tu ne veux pas encombrer le thread principal
• effectuent un audit ciblé et rendent compte

Pourquoi ça marche :

• le processus enfant dispose d'une nouvelle fenêtre de contexte
• il peut générer beaucoup de résultats intermédiaires
• seule la synthèse finale revient au processus parent

C'est l'un des moyens les plus simples de prolonger l'utilité d'une session principale.

Les règles pratiques de la session

Si tu veux un guide pratique, utilise ceci :

Règle n° 1 : nouvelle tâche, nouvelle session

« Lié » n'est pas synonyme de « identique ».

Règle n° 2 : mauvaise branche, retour en arrière

N'empile pas les corrections sur un chemin qui a échoué si ce chemin est désormais du bruit.

Règle n° 3 : même tâche, contexte trop chargé, compacte avec une indication

N'attends pas la compaction automatique si tu sais déjà ce qui doit être conservé.

Règle n° 4 : Si l'étape suivante est bruyante, utilise un sous-agent

Garde le contexte parent pour les décisions, ne l'épuise pas.

Règle n° 5 : un contexte plus large signifie moins de réinitialisations forcées, pas l'absence de réinitialisations

Le contexte 1M est une véritable amélioration. Ce n'est pas une immunité.

Ce qu'un contexte de 1 Mo a réellement changé

La fenêtre de 1M a modifié l'économie de la gestion des sessions de trois façons :

1. moins de compactages forcés
2. plus d'espace pour des tâches cohérentes plus longues
3. plus de temps pour compacter de manière proactive avant que les choses ne se dégradent

Ça n'a pas changé la nécessité de :

• repartir à zéro pour les nouvelles tâches
• revenir en arrière sur les mauvaises branches
• éviter de traîner un débogage obsolète dans du travail sans rapport
• passer les tâches bruyantes à des sous-agents

La plus grande idée fausse après la mise en place du contexte 1M était « Je peux tout garder dans une seule session maintenant. » Techniquement, des sessions plus longues sont possibles. Mais sur le plan opérationnel, tu as toujours intérêt à avoir des limites plus claires que ça.

/usage et ce qu’il faut surveiller

Anthropic explique que la nouvelle commande « /usage » a été inspirée par les discussions avec les clients concernant les sessions de longue durée et la nouvelle fenêtre de 1 million. Ça correspond au vrai problème : la plupart des utilisateurs n’ont pas seulement besoin de plus de contexte, ils ont besoin d’une meilleure visibilité sur la façon dont ils l’utilisent.

Pour les décisions quotidiennes, surveille trois choses :

• si la tâche en cours est toujours la même
• si le contexte actuel est toujours utile
• si la prochaine étape nécessite un résultat intermédiaire détaillé ou seulement la conclusion

C'est plus utile que de se focaliser uniquement sur le nombre brut de tokens.

Une meilleure boucle d'habitudes contextuelles

Utilise cette séquence au cours d'une vraie journée de travail :

1. commence une session avec une tâche claire
2. continue tant que le contexte actuel est encore utile
3. reprends depuis le début quand une branche ne va pas
4. regroupe les tâches lors des changements de phase naturels, avec un indice
5. efface tout lorsque la tâche change
6. lancer des sous-agents pour les tâches secondaires bruyantes

Voilà le modèle de fonctionnement.

Un test de décision en 30 secondes

Quand tu ne sais pas quoi faire ensuite, pose-toi trois questions :

1. Est-ce toujours la même tâche ?
2. Le contexte actuel est-il toujours plus utile que nuisible ?
3. Aurai-je besoin plus tard du résultat intermédiaire de l'étape suivante ?

Si les réponses sont :

• oui / oui / oui -> continue
• oui / non / oui -> condenser
• oui / oui / non -> sous-agent
• non / non / peut-être -> effacer et recommencer

C'est généralement suffisant pour prendre la bonne décision sans trop y réfléchir.

Sources

• Utilisation de Claude Code : gestion des sessions et contexte de 1 Mo
• Sous-agents - Claude Docs

Pages connexes

• Fenêtre de contexte 1M dans Claude Code
• Gestion du tampon de contexte
• Ingénierie du contexte
• Contexte de démarrage dynamique