1 million de tokens ne suffit pas : comment vraiment gérer le contexte dans Claude Code

Le 1 million de tokens fait beaucoup parler. Et c'est normal : passer d'une fenêtre de 200K à 1M change l'échelle de ce qu'on peut raisonnablement mettre dans la tête d'un agent. Un gros repo, plusieurs fichiers de spec, un historique de conversation dense, des sorties de tests, quelques logs — tout ça tient désormais sans qu'il faille bricoler.

Mais quand on bosse vraiment avec Claude Code au quotidien, on se rend vite compte que la question n'est pas "est-ce que ça rentre ?". La question est : est-ce que ce qui est dans le contexte aide encore le modèle à bien travailler ?

Et c'est précisément là que tout se joue. Une énorme fenêtre mal pilotée ne donne pas automatiquement de meilleurs résultats. Elle donne surtout plus de place pour accumuler du bruit, des erreurs, des branches mortes et des raisonnements devenus inutiles. Le vrai sujet, en 2026, ce n'est plus la taille brute du contexte. C'est sa gestion active.

Pourquoi le 1M de contexte impressionne autant

Un million de tokens, c'est beaucoup. De l'ordre de plusieurs centaines de pages de texte, ou d'un repo de taille raisonnable chargé en mémoire avec marge. Pour Claude Code, c'est un changement de posture.

Concrètement, la fenêtre de contexte de Claude Code contient tout ce que le modèle doit pouvoir consulter à un instant T :

le system prompt et les instructions projet (le CLAUDE.md, les règles d'outillage, etc.),
l'historique complet de la conversation,
les tool calls que l'agent a effectués,
les outputs de ces tool calls (commandes shell, recherches, edits),
et les fichiers lus au fil de la session.

Dès qu'on travaille sérieusement sur une feature, cette liste grossit très vite. Lire 10 fichiers, lancer quelques tests, fouiller un log, refactorer deux modules, et on approche déjà des centaines de milliers de tokens utilisés — sans avoir fait quoi que ce soit d'inhabituel.

Avec 1M de tokens, on gagne de la marge. On peut rester dans la même session plus longtemps sans que ça coince. On peut charger un gros contexte sans choisir à la main quoi garder. Pour des tâches longues, c'est un vrai confort.

Mais ce confort a un piège.

Le vrai problème, c'est le context rot

Le context rot est un phénomène simple à expliquer : quand le contexte grossit, la performance du modèle finit par baisser. Pas parce qu'il "oublie" la fenêtre — elle est bien là. Mais parce que son attention se répartit sur de plus en plus de tokens, et parce que des éléments anciens, non pertinents ou carrément contradictoires se mettent à le distraire.

En pratique, ça ressemble à ça :

le modèle relit une piste abandonnée 40 messages plus tôt et la reprend alors qu'elle n'est plus valide,
il suggère une solution qu'il a lui-même rejetée il y a une heure,
il s'appuie sur une version obsolète d'un fichier qui a été modifié depuis,
il mélange deux raisonnements menés en parallèle sur deux sous-problèmes différents,
il recommence à poser des questions auxquelles tu as déjà répondu.

Ce n'est pas un bug. C'est la conséquence mécanique d'avoir empilé beaucoup d'informations, dont beaucoup ne servent plus à la tâche en cours.

Et ce point est fondamental : augmenter la taille de la fenêtre n'élimine pas le context rot, ça déplace juste son seuil d'apparition. Une fenêtre de 1M ne garantit pas qualité = constante. Elle garantit juste que tu atteindras le moment où la qualité commence à fléchir plus tard.

D'où la règle implicite derrière toute cette discussion : la qualité du contexte compte plus que sa taille. Et c'est précisément ce que Claude Code donne les moyens de contrôler, à condition de savoir piloter la session.

Les 5 vraies options de pilotage d'une session Claude Code

Dans Claude Code, chaque tour de conversation est en réalité un point de décision. Après chaque réponse de l'agent, tu as cinq options raisonnables. Elles ne sont pas équivalentes, et la bonne discipline consiste à choisir consciemment laquelle utiliser plutôt que de toujours enchaîner par défaut.

Les cinq options sont :

Continue : continuer la session telle quelle.
/rewind : revenir à un message antérieur et repartir de là.
/clear : vider le contexte et repartir d'une page blanche.
Compact : résumer automatiquement la session pour libérer de la place.
Subagents : déléguer une sous-tâche à un agent séparé avec son propre contexte.

Chacune a un cas d'usage précis. Les confondre, c'est se condamner à traîner du contexte inutile ou à perdre du contexte utile. Creusons-les une par une.

Cas pratiques, commande par commande

Continue : quand la session est encore saine

L'option par défaut. Tu enchaînes avec une question, une instruction ou une correction. C'est le bon choix tant que le modèle travaille bien et que le contexte est encore cohérent.

Bon signal : Claude Code lit les bons fichiers, comprend du premier coup, ne revient pas sur des pistes fermées, et ses tool calls sont ciblés.

Mauvais signal : il commence à relire des zones non pertinentes, à proposer des solutions déjà écartées, ou à refaire des choses qu'il vient de faire. Là, continuer est souvent une mauvaise idée. Mieux vaut choisir une des options suivantes plutôt que d'essayer de "le remettre sur les rails" par instructions successives — c'est souvent comme ça qu'on dégrade encore le contexte.

/rewind : la commande sous-estimée

/rewind permet de revenir à un message antérieur dans la conversation, en supprimant du contexte tous les messages postérieurs. C'est probablement l'outil le plus mal utilisé de Claude Code, parce qu'il est culturellement contre-intuitif : on a tendance à vouloir "corriger en avançant" plutôt que "reculer pour mieux relancer".

Pourtant, dans beaucoup de cas, /rewind donne un bien meilleur résultat que la correction.

Scénario typique : l'agent lit trois fichiers, comprend mal une partie du code, et part dans une direction architecturale fausse. Tu t'en rends compte après cinq ou dix messages. Deux options :

Option 1 : corriger en ligne. Tu expliques ce qui ne va pas, tu donnes de nouveaux éléments, tu demandes de repartir. Le modèle va essayer, mais il garde dans son contexte toute la mauvaise piste. Il risque d'être influencé par son propre raisonnement précédent, et tu t'exposes à du context rot parfait : une session qui mélange la bonne et la mauvaise direction.
Option 2 : /rewind juste après la phase de lecture des fichiers. Tu reviens au moment où il avait toutes les bonnes informations en tête, mais avant la mauvaise décision. Et tu relances avec un brief plus précis : "fais X en gardant Y en tête, ne cherche pas à faire Z".

L'option 2 est presque toujours meilleure. Elle supprime le bruit. Elle évite à l'agent d'avoir à "désapprendre" une mauvaise piste. Elle te coûte quelques messages, mais elle te fait gagner des heures d'aller-retour.

Règle simple : quand tu te surprends à écrire "non, pas comme ça, essaie autre chose", demande-toi d'abord si /rewind ne serait pas plus propre.

/clear : reprendre le contrôle à la main

/clear est beaucoup plus radical. Il vide le contexte et te remet face à une session quasi vierge. Plus rien de l'historique n'est préservé dans la fenêtre.

C'est plus coûteux en effort humain. Tu dois re-préparer un brief complet, re-pointer les bons fichiers, re-résumer les contraintes. Mais en échange, tu as 100 % de contrôle sur ce qui entre dans le nouveau contexte.

C'est le bon choix dans plusieurs situations :

tu passes à une nouvelle tâche sans rapport avec la précédente (règle générale : nouvelle tâche = nouvelle session),
la session précédente est devenue confuse au point qu'il est plus rapide de tout réécrire qu'essayer de la récupérer,
tu veux repartir d'un brief totalement propre parce que tu as toi-même changé d'avis sur l'approche,
tu as fait du debugging qui a généré beaucoup de logs, de stack traces et de tool calls qui ne servent plus une fois le bug compris.

/clear est aussi un bon réflexe en début de journée quand tu reprends un sujet après une pause. Plutôt que de reprendre la session d'hier soir avec son contexte chargé, un /clear suivi d'un brief propre est souvent plus rapide.

Par contre, pense à sauvegarder ce qu'il faut avant. Une fois /clear passé, ce qui n'a pas été écrit dans du code, une note ou un document est perdu.

Compact : rapide mais lossy

/compact demande à Claude Code de résumer la session pour libérer de la place dans la fenêtre. Le résumé remplace une grande partie de l'historique, ce qui libère énormément de tokens pour continuer à travailler.

Claude Code peut déclencher une compaction automatiquement quand on approche de la limite de la fenêtre. On peut aussi la déclencher manuellement, et c'est souvent plus intelligent de le faire quand on sait où on veut aller, plutôt que de laisser l'auto-compact se déclencher au pire moment.

/compact est rapide. C'est un vrai avantage : en deux secondes, la session redevient légère. Mais /compact est aussi lossy : des détails se perdent. Parfois ce sont des détails sans importance, parfois non. Le modèle peut oublier un petit bout de spec, une contrainte que tu avais mentionnée en passant, ou une décision prise à mi-parcours.

Bon usage de /compact :

tu restes sur la même phase du travail, tu veux juste libérer de la place pour avancer,
tu peux fournir un hint au moment de compacter, en indiquant ce qui doit absolument être conservé : "compacte, mais garde les contraintes API et le plan d'intégration en cours",
la direction de la suite est claire dans ta tête et dans celle du modèle.

Mauvais usage de /compact :

tu changes de sujet ou de phase. Compacter sur un sujet pour en démarrer un autre est souvent pire qu'un /clear propre : tu gardes du bruit, tu perds des détails, et tu commences la nouvelle phase avec un résumé tiède.
le modèle ne sait pas où on va ensuite. Dans ce cas, le résumé sera flou, générique, et le mauvais compact est presque garanti. Les pires auto-compacts arrivent précisément dans ces moments-là, quand le modèle ne peut pas prédire la direction de travail suivante.

Règle : /compact est un outil de continuité, pas un outil de transition.

Subagents : envoyer le bruit ailleurs

Les subagents sont probablement la fonctionnalité la plus transformative pour qui veut vraiment gérer son contexte.

L'idée est simple : au lieu de faire faire une tâche bruyante dans la session principale, tu la délègues à un agent séparé, avec son propre contexte frais. Il fait le travail, il produit un résultat, et tu ne récupères dans ta session principale que ce résultat final — pas tous les tool calls intermédiaires, pas les fichiers lus, pas les tâtonnements.

Cas d'usage typiques :

vérifier une spec : "lis ce document de 40 pages et dis-moi juste quels endpoints sont concernés par la nouvelle règle d'authentification",
lire un autre codebase : "va dans le repo voisin, trouve comment ils implémentent X, et reviens-moi avec un résumé structuré",
consulter de la doc externe : "va chercher la doc de cette lib, reviens avec les trois points qui contredisent notre usage actuel",
lancer une recherche exploratoire : "cherche toutes les mentions de cette fonction dans le repo, classe-les par type d'appel, ignore les tests",
toute tâche qui va générer beaucoup de bruit intermédiaire qu'on ne veut surtout pas rapatrier dans la session principale.

L'effet sur la qualité est massif. Ta session principale reste propre, concentrée sur la tâche en cours. Le subagent fait le travail sale dans un coin, et ne te ramène que la conclusion utile.

En fait, une fois qu'on a pris l'habitude de déléguer aux subagents, on voit les sessions principales rester exploitables beaucoup plus longtemps, parce qu'elles ne grossissent plus à chaque fois qu'une vérification secondaire est nécessaire.

Comment choisir entre ces options, en pratique

Une heuristique simple, utilisable après chaque réponse de l'agent :

Le modèle a bien travaillé et la suite est claire → Continue.
Le modèle est parti dans la mauvaise direction et tu peux identifier le moment où ça a dérapé → /rewind jusqu'à ce point.
Tu changes de tâche ou la session est trop confuse pour être sauvée → /clear.
Tu restes sur la même phase mais la fenêtre se remplit → /compact, idéalement avec un hint.
Une sous-tâche va générer du bruit que tu ne veux pas rapatrier → subagent.

Dit autrement : plus le contexte devient grand, plus il faut savoir décider quoi garder, quoi résumer, quoi jeter, et quand repartir proprement.

Ce que ça change pour les développeurs qui bossent vraiment avec des agents

Travailler avec un agent long contexte n'est pas la même activité que prompter un chatbot. Ce n'est pas non plus "coder avec un peu d'assistance". C'est une discipline de session, et elle se rapproche paradoxalement beaucoup de certaines bonnes pratiques humaines :

découper correctement les tâches,
éviter de mélanger deux sujets dans la même fenêtre,
prendre des notes au bon endroit (dans le code, dans un doc, pas dans un chat),
savoir refermer un chantier avant d'en ouvrir un autre,
déléguer les recherches annexes au lieu de les faire en cours de route.

Une fenêtre d'1M ne rend pas ces réflexes optionnels. Elle les rend plus importants. Parce que le coût d'avoir un contexte pollué pendant 800K tokens est bien plus élevé que de l'avoir pendant 50K.

Et c'est probablement là l'insight intéressant de cette génération d'agents : la différence entre deux utilisateurs de Claude Code ne se jouera plus seulement sur la qualité du modèle sous-jacent. Elle se jouera sur la manière dont chacun structure sa session autour du modèle.

Deux développeurs avec exactement la même version de Claude Code n'obtiendront pas les mêmes résultats si l'un utilise /rewind, /clear, /compact et les subagents au bon moment, et si l'autre laisse simplement la fenêtre grossir jusqu'à ce que ça coince.

Conclusion

Le 1M de tokens est une vraie avancée. Plus de marge, plus de confort, moins de bricolage. Mais il ne résout pas le problème de fond : un modèle ne raisonne bien que si ce qu'il a sous les yeux est pertinent, cohérent et à jour.

La bonne nouvelle, c'est que Claude Code donne exactement les outils pour ça : cinq vraies options de pilotage de session, chacune avec un rôle précis. Le métier de l'utilisateur, c'est de choisir consciemment laquelle activer à chaque point de décision, plutôt que de cliquer "continue" par défaut.

La question qui reste ouverte, et qui mérite d'être posée : est-ce que les très grandes fenêtres de contexte vont vraiment simplifier le travail au quotidien… ou est-ce qu'elles vont surtout récompenser ceux qui savent déjà bien piloter leurs sessions ? Tout laisse penser que c'est la deuxième réponse qui est la bonne. Et ce n'est pas une mauvaise nouvelle : ça veut juste dire que la discipline de contexte est en train de devenir une compétence centrale pour travailler avec des agents, au même titre que savoir lire un diff ou structurer une spec.