Le million de tokens que je n'ouvre jamais en grand

Mon agent avale un million de tokens d'un coup. Environ 750 000 mots, 3 000 pages, sans ciller. Et pourtant, le tout premier fichier qu'il rencontre au réveil, à chaque session — l'index de sa mémoire — je le tiens sous la barre des 200 lignes. Pas par manque de place. Par choix.

Ce paradoxe est devenu, ces derniers mois, le cœur de ma façon de travailler avec lui. J'ai un contexte gigantesque, et je passe mon temps à le tenir presque vide.

C'est contre-intuitif, alors je vais expliquer pourquoi. Parce qu'en 2026, ce n'est plus la taille de la fenêtre qui fait la qualité d'un agent — c'est ce qu'on décide d'y mettre.

Le million qui ne sert à rien

Quand un modèle annonce un million de tokens de contexte, le réflexe est de tout y verser. Toute la doc, tout l'historique, tous les fichiers du projet — au cas où. Plus il en sait, mieux c'est, non ?

Non. Les chercheurs de Chroma ont mesuré et nommé le phénomène dans un rapport technique : le context rot, la pourriture du contexte. La performance d'un modèle se dégrade à mesure que son contexte grossit — même sur des tâches qu'il réussit parfaitement quand on les lui pose avec un contexte court et propre. Le constat tient sur toute la famille : Claude, GPT, Qwen, Gemini. Passé quelques dizaines de milliers de tokens réellement pertinents, la fenêtre se remplit, l'attention se dilue, et le modèle commence à confondre, à oublier le milieu, à répondre à côté.

Autrement dit : le million affiché sur la boîte est un maximum, pas un objectif. C'est un budget, pas un entrepôt. Et comme tout budget, la compétence n'est pas de le dépenser — c'est de le dépenser bien.

Ce basculement a un nom. On est passés du prompt engineering — soigner la question — au context engineering — soigner les conditions dans lesquelles la question est posée. C'est, de l'avis à peu près général cette année, la discipline qui a remplacé toutes les autres. Sauf que la plupart des gens en parlent en théorie. Moi, j'ai dû la construire, brique par brique, parce que mon agent tourne toute la journée sur mes vrais projets et que le context rot, chez moi, ça se paie en bugs et en tokens.

Le vrai métier : choisir ce qui entre

La discipline tient en 4 gestes : écrire la connaissance dehors, ne rappeler que ce qui sert, compresser ce qui traîne, et isoler ce qui peut l'être. Je les ai tous les 4 en production. Voici à quoi ça ressemble quand ce n'est pas un slide mais une maison qui tourne.

Écrire dehors

La première règle : la mémoire de l'agent ne vit pas dans la conversation. Elle vit sur le disque.

Je l'ai posée au printemps 2026, et je ne cesse de la refondre depuis — encore ces dernières semaines. La structure exacte n'est pas l'important : le nombre de fichiers, la forme de l'index, j'en ai déjà changé plusieurs fois. Ce qui est stable, c'est un principe que je tiens désormais pour acquis — chaque savoir a un seul foyer, choisi selon sa nature.

Concrètement, 3 natures de savoir, donc 3 foyers :

Les règles de comportement durables — ce qui ne doit jamais dériver. Elles tiennent dans un fichier que je maintiens à la main.
Les faits — décisions d'architecture, conventions, pièges appris, préférences. Ils partent dans une base indexée, découpée en fiches et interrogeable par le sens : une fiche par savoir, rangée là plutôt que traînée dans la conversation. C'est ce que j'ai raconté dans MCP-first.
L'état d'avancement d'un chantier — il ne vit pas dans la mémoire générale, il a son propre journal, qu'on rouvre en reprenant le sujet, pas avant.

Au-dessus, un index de tête tenu court, qui ne fait que pointer vers le bon foyer.

L'agent ne « retient » donc rien en gardant tout sous les yeux. Il écrit dehors, range chaque chose à sa place, et relit à la demande. La conversation reste un espace de travail — pas un grenier. Et quand cette organisation ne suffit plus, je la refais : c'est un savoir-faire qu'on affûte, pas un réglage qu'on pose une fois.

Ne rappeler que le pertinent

Deuxième règle, et c'est celle qui fait le plus gros du gain : quand l'agent a besoin de savoir quelque chose, il ne recharge pas tout. Il interroge sa base par le sens et n'en tire que les 5 passages qui répondent, pas les 500 qui parlent du sujet de loin.

C'est aussi pour ça que l'index de sa mémoire est volontairement maigre. Le plafond, c'est 200 lignes ; en pratique je le tiens autour de 110 — une ligne par savoir durable, pas une de plus. Tout le travail est là : ne jamais déborder, viser en permanence le contexte minimum. Cet index, il le lit à chaque réveil ; s'il gonfle, c'est autant de context rot que je lui inflige d'entrée. Un index gras, c'est un agent qui commence sa journée déjà encombré.

Le même principe vaut pour les outils. J'ai raconté dans 150 outils pour un agent le jour où l'un d'eux m'a rendu 124 815 caractères pour 3 champs que je voulais. La parade — filtrer dans du code avant que la donnée touche le modèle — a ramené ces 124 815 caractères à 2 272. 55 fois moins de contexte, pour exactement le même travail. Ce n'est pas une optimisation cosmétique : c'est le geste central du context engineering, appliqué aux outils.

Compresser, puis isoler

Les 2 derniers gestes s'occupent de ce qui déborde malgré tout.

Compresser : quand une conversation s'allonge, les vieux tours sont résumés au lieu d'être traînés mot pour mot. On garde le sens, on lâche le verbatim. Le fil reste vivant sans que la fenêtre se sature.

Isoler : c'est le geste que je préfère. Quand il faut fouiller un coin de code ou balayer 30 fichiers, l'agent ne le fait pas dans sa propre fenêtre — il délègue à un sous-agent qui reçoit un contexte neuf, part explorer, et ne remonte que sa conclusion. La fenêtre principale ne voit jamais les 30 fichiers ouverts ; elle reçoit 3 lignes de réponse. J'en parlais déjà dans Le jour où j'ai arrêté de regarder le code : déléguer, ce n'est pas seulement gagner du temps, c'est protéger le contexte du chef.

Ce que ça coûte

Rien de tout ça n'est gratuit, et l'honnêteté de ce site l'exige : le context engineering déplace le travail, il ne le supprime pas.

Il faut construire la mémoire — le format, la base vectorielle, l'indexeur qui la tient à jour, la discipline de ranger chaque savoir au bon endroit. Il faut entretenir l'index, l'élaguer, trancher les doublons. Et il faut accepter que le rappel puisse rater : une mauvaise requête ne ramène rien, et un agent qui ne trouve pas est un agent qui devine — le pire des cas. C'est un jardin, pas une machine qu'on installe une fois. Je passe une part réelle de mon temps à désherber cette mémoire pour qu'elle reste utile.

Mais c'est un coût qu'on paie une bonne fois et qui rapporte à chaque session, contre un context rot qu'on paierait, lui, à chaque tour, indéfiniment.

Le piège qu'on ne voit pas

Le plus vicieux, avec la pourriture du contexte, c'est qu'elle est silencieuse. Pas d'erreur, pas de plantage, pas d'alerte rouge. Juste une qualité qui dérive doucement — des réponses un peu moins justes, un détail oublié, une confusion qui n'aurait pas eu lieu sur un contexte propre. Le temps qu'on comprenne, on a déjà perdu une demi-journée à chercher un bug qui n'était pas dans le code, mais dans la fenêtre trop pleine.

Et la tentation joue toujours dans le mauvais sens : dans le doute, on ajoute. « Mets-lui aussi ça, au cas où. » C'est exactement le geste à ne pas faire. Une mémoire qui a grossi et vieilli trompe plus mal qu'une mémoire vide — parce qu'elle affirme avec aplomb des choses qui ne sont plus vraies. Alors l'index reste maigre, tenu à la main, et je préfère un agent qui dit « je ne sais pas » à un agent qu'on a bourré pour qu'il ait l'air sûr.

Le million reste un maximum

Le million de tokens n'est pas la prouesse. Remplir une fenêtre, n'importe qui sait le faire — il suffit de tout y jeter. La prouesse, c'est la discipline inverse : la tenir presque vide, et n'y laisser entrer que ce que la tâche réclame, rien de plus.

Mon agent a un million de tokens sous le capot. La plupart du temps, il en ouvre quelques milliers. C'est précisément pour ça qu'il reste bon.

— Damien

Voir aussi