Claude Code 1M Context : Ma méthode pour éviter le context rot

Claude Code 1M Context : Ma méthode pour éviter le context rot

Le compteur de session affichait 612 000 tokens. Opus 4.7 tournait depuis presque quatre heures. Il avait lu 38 fichiers, refactorisé une couche de service Laravel, écrit des tests, et me demandait maintenant d’actualiser une méthode dans une classe que j’avais supprimée… quatre-vingt-dix minutes plus tôt.

Pas une hallucination. Supprimée. Par Claude lui-même. Avec un appel d’outil dont je pouvais retrouver la trace, dans la même session.

Je suis resté là, les yeux rivés sur le terminal — mon café froid, le curseur clignotant sous un correctif qui aurait provoqué une régression —, et j’ai ressenti la même angoisse que tous les power users de Claude Code connaissent. Ce n’est pas que le modèle devenait moins performant. Le modèle coulait. Quelque part entre le 300 000ᵉ et le 600 000ᵉ token, le contexte était passé discrètement d’un atout à un handicap.

C’est la partie que personne n’intègre dans le marketing de la fenêtre de contexte Claude Code 1M. La fenêtre existe. Elle fonctionne. J’ai les preuves. Mais « 1 million de tokens », ce n’est pas « 1 million de tokens de raisonnement clair, ciblé, fiable ». Et c’est exactement dans cet écart que se situe la majorité de mes récents débogages.

Depuis 30 jours, j’ai épuisé assez de sessions Opus 4.7 sur Max 20x pour cartographier précisément où la dégradation du contexte commence, ce qui la déclenche, et les cinq actions spécifiques qui permettent de garder les longues sessions Claude Code pointues, et non détrempées. Rien de tout cela n’est théorique. Tout vient d’échecs réels sur des builds.

Si vous avez déjà vu Claude oublier une contrainte posée au message trois, cet article est fait pour vous.

Ce que « 1M Context » signifie réellement dans Claude Code à l’heure actuelle

Petit rappel, car les numéros de version sont importants et la plupart des articles s’y trompent.

La fenêtre de 1 million de tokens dans Claude Code n’est pas arrivée avec Opus 4.5. Opus 4.5 (novembre 2025) plafonnait à environ 250k. La fenêtre 1M a été déployée avec Claude Opus 4.6 le 5 février 2026, puis a été rendue généralement disponible dans Claude Code le 13 mars 2026 pour Opus 4.6 et Sonnet 4.6. Le modèle actuel, au moment où j’écris ces lignes, est Opus 4.7, sorti le 16 avril 2026, qui reprend le même plafond de 1M.

L’accès dépend toujours de votre formule :

• Max, Team, Enterprise — 1M est activé automatiquement avec Opus 4.6/4.7, sans frais supplémentaires, aucune option à activer
• Pro (20 $/mois) — vous devez activer manuellement en tapant /extra-usage dans Claude Code, et les tokens dépassant la fenêtre standard sont débités de vos crédits extra-usage
• API — le tarif pour un contexte supérieur à 200k utilise la grille long-context ; consultez la page de tarification Anthropic la plus récente avant de concevoir un workflow basé sur le tarif standard

La fenêtre de contexte elle-même inclut tout ce que le modèle peut voir à l’instant T : l’invite système, votre CLAUDE.md, l’historique de conversation, chaque fichier lu par Claude à l’aide de l’outil Read, chaque sortie générée par un outil, chaque résultat Glob/Grep, ainsi que le message que vous venez de taper. Tout compte. Tout se dispute l’attention du modèle.

Ce dernier point, c’est tout le sujet. Gardez-le en tête.

Le chiffre que personne ne cite : le context rot commence à 300 k, pas à 1 M

La promesse marketing de tout modèle à large contexte suggère une performance constante : que le jeton 999 000 soit aussi utile que le jeton 9 000. Ce n'est pas le cas. Il existe un terme documenté pour décrire ce qui se passe réellement, et il mérite de figurer dans le vocabulaire de tout utilisateur de Claude Code.

Le context rot est la dégradation mesurable des performances du modèle à mesure que le contexte d'entrée augmente. Ce n'est pas un bug propre à Anthropic. L'étude 2025 de Chroma a testé 18 modèles de pointe — GPT-4.1, Claude Opus 4, Gemini 2.5, entre autres — et a constaté le context rot à chaque incrément de longueur d'entrée mesurée. L'équipe d'ingénierie d'Anthropic en a également parlé ouvertement, décrivant le contexte comme un « budget d'attention limité » qui s'épuise à chaque nouveau jeton, exactement comme la mémoire de travail humaine.

Voici le chiffre clé à retenir pour Claude Code : la dégradation commence à se faire sentir aux alentours de 300 000 à 400 000 jetons. Cela équivaut à environ 30–40 % de la capacité maximale d’1 M — soit bien avant le chiffre mis en avant par le marketing. Sur le benchmark de récupération multi-aiguille MRCR, Opus 4.6 atteint encore 76 % de précision au plein 1 M, ce qui reste excellent pour un modèle de pointe. Mais « 76 % de récupération précise » est une propriété cauchemardesque si vous laissez un agent éditer du code de production sans supervision. Les 24 % restants vous retomberont dessus.

Dans la pratique, le rot n’apparaît que rarement sous la forme d'une hallucination spectaculaire. C’est plus discret. Plus subtil. Ce sont les quatre modes d’échec ci-dessous — et une fois que vous savez les nommer, vous pouvez les traquer.

Les quatre modes de défaillance que je nomme désormais explicitement

Avant d’avoir un vocabulaire pour cela, chaque moment où « Claude agit bizarrement » me semblait être le même problème vague. Maintenant, je les diagnostique en quelques secondes. Chacun nécessite une correction différente.

1. Pollution de contexte

La pollution, c’est l’information non pertinente qui noie le signal. Vous avez lancé un Grep qui a renvoyé 800 correspondances. Vous avez laissé Claude lire un fichier de logs de 4 000 lignes « au cas où ». Vous avez joint l'intégralité du répertoire node_modules des types parce que vous ne saviez pas quel fichier contenait le type recherché. Aucun de ces actes n’est problématique pris isolément. Pris tous ensemble, ils transforment l’attention de Claude en une véritable soupe.

Le modèle ne sait pas ce que vous jugez pertinent. Il traite chaque token comme s’il était potentiellement crucial. Plus vous insérez de bruit, plus la cognition de Claude est accaparée à réévaluer ce bruit.

Symptôme révélateur : Claude commence à référencer des fichiers dont vous aviez oublié l’importation.

2. Dérive des objectifs

La dérive des objectifs, c’est l’érosion progressive de l’intention initiale. Vous avez commencé la session par « réécrire le middleware d'auth pour supporter OAuth 2.1, tout en maintenant les flux JWT existants, sans toucher au modèle utilisateur ». Trois heures plus tard, après que Claude a lu 22 fichiers, corrigé huit erreurs lint sans rapport, et refactorisé un helper de logging, vous lui demandez d’ajouter une nouvelle revendication au payload JWT, et il modifie le modèle utilisateur.

Il n’a pas ignoré votre contrainte. Elle s’est simplement dégradée. Avec 400 000 tokens entre l’instruction initiale et l’action actuelle, le ratio signal/bruit du prompt système s’est effondré.

Symptôme révélateur : Claude répond correctement à la demande immédiate mais enfreint une règle de la consigne initiale.

3. Corruption de la mémoire

C’est celle qui m’a poussé à écrire cet article. La corruption de la mémoire survient lorsque le modèle interne de l’agent sur le monde s’éloigne de la réalité. Le fichier que Claude croit exister à app/Services/UserService.php a été supprimé au tour 47. Claude continue pourtant d'utiliser la version qu'il a mise en cache en mémoire de travail. Vous lisez son plan, il paraît cohérent, vous l’approuvez — et la modif est apportée à un fichier qui n’existe plus, ou pire, sur une version obsolète de celui-ci.

J’ai détecté le pire cas sur un refactoring Multica : Opus avait patché un service trois fois pendant la session, et lors du quatrième patch, il a généré un diff basé sur la première version du fichier. Les patches intermédiaires existaient bien dans l’historique de la conversation. Ils n'étaient tout simplement plus pondérés.

Symptôme révélateur : Les appels d’outils font référence à un état qui ne correspond pas au système de fichiers actuel.

4. Inexactitude des décisions

L’inexactitude des décisions correspond à l’impôt sur la cohérence. Au début de la session, vous aviez décidé que « toutes les erreurs de ce service lancent une DomainException et sont remontées ; le gestionnaire les logue sur Sentry. » Plus tard, en plein contexte, Claude écrit une nouvelle méthode qui capture tout en tant que \Exception, écrit dans Log::error puis retourne un 500.

Le code n’est pas incorrect. Il n’est juste pas le vôtre. Décisions incohérentes, modèles contradictoires, langage de conception instable.

Symptôme révélateur : Le style du code et les choix architecturaux ne correspondent plus au reste de la base, alors même que Claude a lu le reste du code.

Chacun de ces problèmes a sa solution. Aucun ne se règle par « utiliser un modèle plus petit ». Tout repose sur la gestion de la fenêtre de contexte.

Les cinq stratégies que j’utilise chaque jour

Quand une session Claude Code dépasse les 300k tokens — ou quand je constate l’un des quatre modes d’échec ci-dessus — cinq options s’offrent à moi. Le tout est de savoir laquelle choisir, car elles ne sont pas interchangeables.

Option 1 : Continuer (et pourquoi je le fais presque jamais)

Le réflexe par défaut : continuer sans s’arrêter. La tentation est forte, car on « est dans le flux » et les coûts de changement paraissent élevés.

Je choisis rarement cette option désormais, sauf si je suis sous les 300k tokens ET que la tâche est superficielle (fichier unique, préoccupation unique). Au-delà de cette limite, continuer revient à jouer : chaque nouveau tour aggrave le context rot. Le coût d’un mauvais patch poussé en prod écrase celui d’une pause pour réinitialiser le contexte.

Option 2 : Compacter, mais à la main

/compact résume la conversation actuelle en une version plus courte et poursuit le travail. En théorie, c’est la gomme magique contre l’encombrement contextuel. En pratique, l’autocompact — la version qui se déclenche automatiquement dès que la fenêtre est pleine — n’est pas fiable. La logique de compaction de Claude priorise les tours récents et peut discrètement jeter des éléments de contexte plus anciens mais critiques : le brief initial, les décisions architecturales, les contraintes évoquées dans le message trois.

Je laisse donc jamais autocompact agir seul. Je déclenche /compact manuellement, de façon proactive, dès qu’on approche des 300k, et je précise explicitement ce qu’il faut conserver :

/compact Préserver : (1) le brief initial en haut de session,
(2) toutes les décisions architecturales prises aux tours 1 à 15,
(3) la liste des fichiers déjà modifiés et pourquoi,
(4) toute contrainte commençant par « DO NOT » ou « MUST ».
Écarter : les résultats bruts des outils, les résultats Grep intermédiaires, les lectures de fichiers qu’on ne reconsultera pas.

Cette consigne unique change radicalement la qualité de la compaction. On passe de « résume le chat » à « produis un document structuré de transmission ». Ce n’est pas la même chose.

Option 3 : Clear et redémarrage

/clear efface totalement le contexte. C’est l’option nucléaire, et elle est souvent la bonne, bien plus souvent que je ne le pensais.

J’utilise /clear dès que je bascule sur un travail vraiment sans rapport — terminer la refonte auth et passer sur une correction de webhook de facturation, par exemple. Aucun intérêt à traîner le contexte de l’auth dans la session billing, et le risque est immense (pollution, dérive, tous les problèmes cités plus haut).

L’erreur courante ici, c’est de voir /clear comme un échec. C’en n’est pas un. Une session fraîche de 12k tokens, hyper ciblée, produira toujours un meilleur résultat qu’une session de 600k tokens embourbée par un raisonnement brumeux.

Option 4 : Clear + sauvegarde JSON (mon choix de référence pour les sujets complexes)

C’est la démarche sur laquelle je m’appuie le plus. Avant de faire un clear, je demande à Claude de générer un fichier JSON structuré qui capture l’état de l’avancement de façon à pouvoir relancer la session depuis ce point. Par exemple :

{
  "objective": "Migrer le middleware d’auth vers OAuth 2.1 en préservant les flux JWT",
  "constraints": [
    "Ne pas modifier app/Models/User.php",
    "Tous les nouveaux endpoints doivent conserver le préfixe /api/v1",
    "Les consommateurs JWT existants doivent continuer à fonctionner"
  ],
  "files_modified": [
    {"path": "app/Http/Middleware/Authenticate.php", "status": "complete"},
    {"path": "app/Services/Auth/OAuthHandler.php", "status": "in-progress"}
  ],
  "open_decisions": [
    "La stratégie de rotation du refresh token reste à définir",
    "Vérifier si l’ancien format JWT doit recevoir un header de dépréciation"
  ],
  "next_step": "Implémenter la rotation du refresh token dans OAuthHandler::refresh()"
}

Ensuite je fais /clear, j’ouvre une session fraîche, et mon tout premier message est : « Lis .claude/state.json, confirme que tu as bien compris l’objectif et les contraintes actuelles, puis poursuis à partir de next_step. »

Cette transmission est nettement plus fiable qu’aucun /compact que j’aie pu tester. La nouvelle session démarre avec 15k tokens à peine, un signal parfait, pas de dérive, ni de mémoire corrompue, ni de contrainte à moitié oubliée.

Option 5 : Sous-agents pour tout ce qui risque de saturer le contexte

Les sous-agents sont le joker de Claude Code pour éviter de déverser d’énormes sorties d’outils dans le contexte principal. L’agent tourne dans sa propre fenêtre isolée, effectue le travail, et ne renvoie que le résultat final à la session principale.

Le test mental que j’utilise — et que l’équipe d’Anthropic recommande aussi — est : « Aurais-je besoin du détail de cet output, ou juste de la conclusion ? »

Besoin de la conclusion seulement ? Sous-agent. Exemples :

• « Parcours toute la base de code, trouve chaque appel à l’ancienne passerelle de paiement et rapporte seulement la liste des fichiers et numéros de ligne » : tâche parfaite pour un sous-agent. Les résultats Grep mangeraient 40k tokens dans le contexte principal ; la liste finale pèse 200 tokens.
• « Lis ces 12 pages de documentation et dis-moi laquelle indique les infos de rate limit » : sous-agent. Les 12 pages pollueraient. La réponse tient en une phrase.
• « Lance la suite de tests et rapporte uniquement les échecs avec stacktrace » : sous-agent. Inutile de trimbaler 8 000 lignes de tests réussis.

Je configure ces tâches comme de vrais sous-agents Claude Code dans .claude/agents/, pour que l’orchestration soit reproductible. La toute première fois que j’ai rétro-adapté une session de 90 minutes pour utiliser les sous-agents lors des étapes gourmandes en recherches, mon contexte principal est passé de 400k à 90k et Opus est resté performant jusqu’au bout.

Les trois pratiques qui comptent plus que n'importe quelle commande

Au-delà des cinq options, trois habitudes font la plus grande différence au quotidien. Aucune n’est spectaculaire.

Remonter plutôt que relancer

Lorsque Claude prend une mauvaise décision et que vous la corrigez, cette mauvaise décision reste à jamais dans le contexte. Trois échanges plus tard, vous corrigez une autre erreur liée. Au dixième tour, la conversation devient à moitié du vrai travail, à moitié du « non, pas ça, fais plutôt ceci ». La pourriture progresse.

La solution la plus propre consiste à remonter — ramener la conversation avant le mauvais échange et relancer avec une meilleure instruction initiale, enrichie de ce que vous avez appris. Claude Code permet d’éditer les messages antérieurs. Servez-vous-en. La session ainsi remontée reste bien plus nette, se compacte mieux, et propage moins d’erreurs en aval.

Désormais, dès le troisième « non, ce n’est toujours pas ça », je considère comme réflexe de remonter, plutôt que de continuer à corriger.

Les résumés périodiques sont indispensables

Tous les 50 à 75k tokens de travail substantiel, je demande : « Résume l’objectif actuel, les contraintes convenues et le travail déjà accompli. » Deux paragraphes maximum.

Cela peut sembler du gaspillage. C’est tout le contraire. Le résumé oblige Claude à se recentrer sur la mission, ce qui réduit considérablement la dérive des objectifs dans les échanges suivants. Cela me permet aussi de détecter rapidement un éventuel déraillement de la compréhension de Claude — si le résumé est faux, je sais que la pourriture a commencé et qu’il est temps d’utiliser /compact ou /clear.

Considérez les résumés comme la version économique de la compaction. La compaction restructure la mémoire, les résumés la renforcent.

Des instructions de compaction explicites surpassent toujours le comportement par défaut

J’ai déjà abordé ce point dans l’option 2, mais il mérite d’être isolé comme une règle à part entière. Si vous laissez /compact s’exécuter sans instructions, vous faites confiance aux réglages par défaut de Claude pour deviner ce qui est structurant dans votre travail. Ce n’est souvent pas le cas. La contrainte que vous avez formulée au troisième message n’est qu’un texte pour le résumé automatique.

Indiquez toujours à /compact ce qu’il faut préserver, supprimer et comment structurer la sortie. Traitez cela comme la rédaction d’un document de passation pour un collègue, et non comme l’invocation d’une commande magique.

À quoi cela ressemble-t-il de bout en bout : une session réelle

Voici une version épurée du déroulement d’une longue session Claude Code telle que je la pratique désormais, après un mois à resserrer cette boucle :

1. Début de session — CLAUDE.md est concis, le brief figure dans le premier message, les contraintes sont explicites. Nombre de tokens : ~5 000.
2. Premiers 200k tokens — travail direct. Je n’optimise rien. Lecture de fichiers, écriture de code, exécution de tests. Le contexte est sain.
3. Palier des 300k — premier checkpoint. Je demande un récapitulatif. Confirme la direction. Pas de /compact tant que le travail reste focalisé.
4. Palier des 400k — deuxième checkpoint. Si je suis encore en plein travail, je lance manuellement un /compact avec des instructions explicites de ce qu’il faut conserver/éliminer. Le nombre de tokens retombe à environ 80k. Je poursuis.
5. Tout ce qui générerait plus de 20k de sortie d’outil — sous-agent. Toujours.
6. Fin d’un fragment de travail distinct — j’écris un fichier d’état JSON, /clear, session fraîche, reciblage à partir du JSON. La transition me coûte 3 minutes et m’épargne une accumulation de rot.
7. Première boucle “non, ce n’est toujours pas ça” — pause. Je diagnostique lequel des quatre modes d’échec intervient. Je choisis la bonne correction. Pas de re-prompting à l’aveugle.

C’est tout. Pas de magie. Pas de nouvel outil. Juste l’utilisation rigoureuse de ce que Claude Code propose déjà en standard.

Le résultat : je mène désormais des sessions Claude Code productives qui couvrent toute une journée de travail sur un même projet, sans que le modèle ne parte en vrille. Il y a un mois, je ne passais pas un mardi après-midi sans une cascade d’hallucinations.

Ce que j’ai mal fait pendant les trois premières semaines

Je vous dois la version honnête de la façon dont j’ai résolu ce problème, car j’ai gaspillé beaucoup d’argent avant d’y arriver.

J’ai supposé qu’un contexte plus grand était toujours mieux. Je bourrais délibérément davantage de fichiers dans le contexte « pour que Claude ait une visibilité complète ». Faux. Chaque fichier hors sujet prélevait une petite taxe à chaque échange ultérieur. Moins, c’est mieux. Lisez ce dont vous avez besoin, pas ce qui pourrait être utile.

J’ai fait confiance à l’autocompact. Pendant trois semaines, je l’ai laissé s’exécuter à volonté. La dérive était si progressive que j’ai blâmé moi-même, mes prompts, la structure de mon projet — tout sauf la véritable source du problème. La première fois que j’ai désactivé l’autocompact et que j’ai géré manuellement les compactages avec des instructions explicites, la différence était flagrante.

J’ai évité les sous-agents car l’orchestration me semblait être une perte de temps. Je m’étais trompé là-dessus aussi. Configurer un sous-agent de recherche ou un sous-agent de test ne prend que dix minutes. Ensuite, cela vous évite des dumps d’outils de 50k tokens à chaque session.

Et je considérais l’utilisation de /clear comme un échec. Ce n’est pas le cas. Une session propre n’est pas une session manquée. Une session propre est un outil. Servez-vous-en.

Foire aux questions

Quand le context rot commence-t-il dans Claude Code ?

Le context rot dans Claude Code devient mesurable autour de 300 000 à 400 000 tokens — soit approximativement 30 à 40 % de la fenêtre 1M. Les performances ne s’effondrent pas à ce stade, mais les risques de dérive des objectifs, de corruption de la mémoire et d’incohérence dans les décisions augmentent visiblement. Considérez 300k comme votre premier point de contrôle, et non 1M comme une limite supérieure.

Faut-il utiliser /compact ou /clear dans Claude Code ?

Utilisez /compact lorsque la tâche en cours est toujours active et que le contexte récent est vraiment nécessaire ; utilisez /clear lors d’un changement de travail sans rapport ou lorsque le contexte est tellement pollué que même sa synthèse ne ferait que maintenir du bruit. Pour les travaux complexes en cours, le schéma le plus efficace consiste à écrire un fichier d’état JSON, exécuter /clear et redémarrer une session fraîche à partir du JSON.

La fenêtre de contexte 1M engendre-t-elle un surcoût dans Claude Code ?

Sur les forfaits Max, Team et Enterprise, la fenêtre de contexte 1M est incluse sans frais supplémentaire pour Opus 4.6 et Opus 4.7. Sur le forfait Pro (20 $/mois), vous devez activer l’option via /extra-usage et les tokens excédant la fenêtre standard sont alors déduits des crédits d’utilisation supplémentaire. La tarification API applique le tarif long-contexte au-delà de 200k — vérifiez les tarifs en vigueur avant de bâtir un workflow sur cette hypothèse.

Quelle est la différence entre /compact et les sous-agents ?

/compact résume la conversation existante dans votre session actuelle, libérant ainsi des tokens ; les sous-agents, eux, empêchent toute croissance excessive dès le départ en réalisant des tâches secondaires dans leur propre fenêtre de contexte isolée et en ne renvoyant que le résultat final. Utilisez des sous-agents pour toute tâche dont vous n’avez pas besoin de conserver le résultat intermédiaire — recherche, analyse de logs, lancements de tests.

Pourquoi Claude Code se met-il à halluciner dans les longues sessions ?

Les longues sessions Claude Code hallucinent à cause du context rot : plus l’entrée grossit, plus le « budget d’attention » du modèle s’amenuise et les contraintes, fichiers et décisions antérieurs sont sous-pondérés. La solution ne réside pas dans une fenêtre plus grande, mais dans une gestion active : /compact manuel avec instructions explicites, récapitulatifs périodiques, sous-agents pour les tâches à fort volume, et transitions /clear+JSON entre les gros blocs de travail.

Donc : votre terminal est ouvert. La session atteint 280k tokens. Opus 4.7 vient de suggérer d’éditer un fichier dont vous êtes à 80 % certain qu’il a été supprimé il y a une heure.

Que faites-vous dans les 60 secondes à venir ?

Si votre réponse est « demander à Claude de revérifier », vous gérez encore le contexte à l’ancienne. Si c’est « revenir au dernier tour propre, écrire un fichier d’état JSON, /clear et réinitialiser la session », bienvenue dans la version de Claude Code qui passe réellement à l’échelle d’une journée complète de travail. La fenêtre 1M est bien réelle. La fiabilité qu’elle offre est quelque chose à concevoir activement.

Je préfère l’ingénierie à la critique du modèle.

Travaillons ensemble

Vous cherchez à créer des systèmes d’IA, automatiser des flux de travail ou faire évoluer votre infrastructure technologique ? J’aimerais vous accompagner.

• Fiverr (développements et intégrations sur mesure) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions d’entreprise) : ramlit.com
• ColorPark (design & branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io