Ce qu'est vraiment une fenêtre de contexte (et ce qu'elle coûte)

Une fenêtre de contexte est l’ensemble fini de tokens qu’un modèle lit en une passe pour produire son token suivant. Vos instructions, les fichiers ouverts, la conversation en cours, chaque ligne de sortie d’outil : tout tient dans un même espace borné, à capacité fixe. Ce qui est hors de la fenêtre n’existe pas pour le modèle. Ce qui est dedans n’est jamais gratuit.

Le cadre, ce sont les agents : assistants de code et outils construits autour. L’essentiel de la mécanique vaut pour n’importe quel usage d’un grand modèle de langage, mais les tensions sont les plus vives quand c’est l’agent qui remplit la fenêtre tout seul. Trois faits font le gros du travail, et ils découlent tous d’une seule mécanique : le modèle lit toute la fenêtre, du début à la fin, à chaque étape.

TL;DR. Un token vaut environ 4 caractères d’anglais, donc 100 tokens font à peu près 75 mots, et le code est plus dense. Ce qui remplit la fenêtre : prompt système, définitions d’outils, fichiers chargés, conversation et sorties d’outils. Le coût de l’attention croît avec le carré de la longueur : doubler le contexte quadruple à peu près le travail par étape. Un préfixe stable est bon marché à réutiliser (les lectures en cache sont facturées de 50 à 90 % moins cher), mais modifiez-le tôt et vous repayez plein tarif. Et la capacité n’est pas la fiabilité : les modèles perdent en justesse, de façon mesurable, bien avant que la fenêtre soit pleine.

Anatomie d'une fenêtre de contexte : une barre bornée, remplie par une charge permanente en gris (prompt système, définitions d'outils, fichiers et compétences) et une crue en orange (conversation, sorties d'outils), l'espace libre se réduisant vers une capacité fixe.

Les tokens : l’unité que vous dépensez vraiment

Le modèle ne lit ni des caractères ni des mots. Il lit des tokens : de courts fragments de texte, chacun associé à un nombre. Pour de la prose anglaise, un token fait environ 4 caractères, et 100 tokens représentent à peu près 75 mots (OpenAI, What are tokens and how to count them). La « tokenisation » n’est rien d’autre que l’étape qui découpe votre texte en fragments avant que le modèle ne le voie.

Deux remarques pratiques. D’abord, le compte dépend du modèle : traitez les 4 caractères comme un ordre de grandeur, pas comme une loi. Ensuite, le code est plus dense que la prose. Indentation, ponctuation et identifiants en camelCase se fragmentent en quantité de petits tokens, si bien qu’un fichier source coûte nettement plus de tokens par caractère que la même longueur d’anglais. Un budget calibré sur de la prose s’épuisera plus tôt que prévu sur du code.

Ce qui entre dans la fenêtre

La fenêtre, ce n’est pas seulement votre prompt. C’est un budget, et cinq choses le dépensent.

La charge permanente, c’est ce qui est déjà là avant que le vrai travail commence : le prompt système, les définitions des outils que le modèle a le droit d’appeler, et les fichiers ou compétences chargés d’entrée. Vous la fixez une fois. Elle reste sur la table toute la session, que l’étape en cours en ait besoin ou non.

La crue, c’est ce qui s’accumule pendant que l’agent travaille : la conversation jusqu’ici, et surtout les sorties d’outils. Une seule exécution de tests ou un listing de répertoire peut déverser des centaines de lignes dans la fenêtre en une étape. La charge permanente, vous la choisissez délibérément. La crue, elle, arrive toute seule, et c’est en général là qu’une fenêtre passe de sobre à obèse.

La fenêtre est finie, et « pleine » n’est pas la panne à craindre

Toute fenêtre a un plafond dur, et ce plafond a beaucoup bougé. Les Transformers d’origine étaient entraînés sur 512 à 2 048 tokens (Liu et al., 2024). GPT-4 est sorti à 8K, avec une variante 32K. Claude a atteint 100K en 2023 et 200K en 2024. En 2026, la frontière se situe à 1M de tokens sur Claude, GPT-4.1 et Gemini 2.5 Pro, et 2M sur Gemini 1.5 Pro (documentation des fournisseurs, 2025 à 2026).

Frise en échelle logarithmique des fenêtres de contexte maximales : 512 à 2K tokens pour les Transformers d'origine en 2017, 8K à 32K pour GPT-4 en 2023, 100K puis 200K pour Claude, et 1M à 2M en 2025-2026. Chaque palier vaut environ un ordre de grandeur.

Manquer de place, c’est la panne ennuyeuse. Vous touchez le plafond, des tokens sont évincés ou l’appel échoue, et vous savez exactement ce qui s’est passé. La panne qui mérite d’être comprise arrive bien plus tôt, très en dessous de la limite, et elle est silencieuse. Gardez ça en tête : les deux dernières sections lui sont consacrées.

Prefill et decode : deux phases, deux factures

Produire une réponse se fait en deux phases, et elles ne coûtent pas la même chose.

Le prefill lit tout votre prompt en une seule passe parallèle. Chaque token d’entrée est traité en même temps que les autres, ce qui sature les unités de calcul du GPU. Le prefill est limité par le calcul.

Le decode génère ensuite la réponse un token à la fois. Chaque nouveau token exige sa propre passe, qui relit l’intégralité du contexte construit jusque-là, et cette passe consiste surtout à attendre la mémoire plutôt qu’à calculer. Le decode est limité par la bande passante mémoire et, comme il est séquentiel, c’est lui qui domine la latence que vous ressentez (SPAD, arXiv 2025 ; et la littérature classique sur prefill/decode).

Deux panneaux : le prefill lit tout le prompt en une passe parallèle et est limité par le calcul ; le decode émet un token par passe, chaque passe relisant un contexte qui grandit d'un token, et il est limité par la bande passante mémoire.

Ce qu’il faut en retenir pour un budget de fenêtre : les tokens que vous chargez ne se paient pas une fois. Le prompt est prefillé, puis chaque token écrit par le modèle est une passe de plus sur l’ensemble.

Pourquoi une fenêtre plus longue coûte plus cher à chaque étape

Voici la mécanique sous tout le reste. L’attention, l’opération qui permet à chaque token de regarder tous les autres, croît avec le carré de la longueur de séquence. L’auto-attention est en O(n²) sur le nombre de tokens (Vaswani et al., Attention Is All You Need, 2017). Liu et al. le disent sans détour : les Transformers « require memory and compute that increases quadratically in sequence length » (2024).

Quadratique, c’est le mot qui compte. Doublez les tokens de la fenêtre et vous ne doublez pas le travail d’attention : vous le quadruplez, à peu près. Dix fois plus de tokens, cent fois plus de travail.

Courbe convexe du travail d'attention par étape en fonction de la longueur de contexte : à la longueur n le coût vaut une unité, à la longueur 2n il en vaut quatre. Doubler le contexte quadruple à peu près le travail.

Et cela se paie à chaque étape. Une fenêtre deux fois plus pleine ne transporte pas seulement deux fois plus de matière : elle est plus chère à lire, sur chaque token que le modèle génère, et elle enchérit d’autant plus vite qu’elle se remplit. C’est pourquoi « autant utiliser la grande fenêtre, elle est là » n’est jamais gratuit, même quand ça rentre.

Le cache : pourquoi un préfixe stable coûte peu

Le contrepoids, c’est le cache, et il vaut la peine d’être compris parce qu’il change l’ordre dans lequel vous devriez composer un prompt.

Pendant qu’il traite un prompt, le modèle construit un KV cache : l’état intermédiaire de chaque token, conservé pour ne pas avoir à recalculer les tokens précédents à chaque nouvelle étape. Ce cache croît linéairement avec la longueur. Pour l’ordre de grandeur, un modèle de 70B peut consommer quelques mégaoctets de cache par token (à titre indicatif ; la grouped-query attention moderne divise ce chiffre par plusieurs). Linéaire, donc, pas quadratique, mais pas rien non plus.

Le levier, c’est le prefix caching. Si le début de votre prompt est identique octet pour octet à celui d’un appel récent, le fournisseur réutilise le travail mis en cache au lieu de le refaire. Anthropic facture ces lectures en cache à 10 % du prix d’entrée, soit 90 % de remise ; OpenAI applique automatiquement environ 50 % de réduction, les deux au-delà d’environ 1 024 tokens (documentation prompt caching d’Anthropic et d’OpenAI). Le piège : le cache s’apparie sur un préfixe. Changez un seul token en début de prompt et tout ce qui suit la modification est invalidé, puis recalculé au prix fort.

Deux lignes : un préfixe stable est réutilisé depuis le cache (un cache hit, facturé environ 90 % moins cher), tandis que modifier un token en début de prompt invalide le cache à partir de la modification, forçant un recalcul au prix fort.

Mettez donc le matériau stable en premier : prompt système, définitions d’outils, tout ce qui ne bouge pas. Et le matériau volatil en dernier. C’est toute la différence entre payer votre charge permanente une fois et la payer à chaque tour.

L’attention n’est pas uniforme : le milieu est négligé

Le modèle lit toute la fenêtre, mais il n’en pondère pas toutes les parties également. La position compte, et pas dans le sens qui vous arrangerait.

Liu et al. l’ont mesuré directement. Donnez 20 documents à un modèle, posez une question dont la réponse se trouve dans exactement un d’entre eux, et la justesse dépend fortement de l’endroit où ce document se situe. Elle est maximale quand la réponse est en tête ou en queue, et elle s’affaisse au milieu.

🔬 La position, mesurée. Pour GPT-3.5-Turbo, la courbe part d’environ 75 % quand la réponse est en première position, descend jusqu’à un creux proche de 53 % au milieu, et remonte à 63 % en dernière position (Liu et al., Lost in the Middle, 2024).

Courbe de justesse en U selon la position de la réponse parmi 20 documents : environ 75 % en première position, un creux proche de 53 % au milieu, 63 % en dernière position, le tout comparé à une référence à livre fermé de 56,1 %.

Regardez la ligne pointillée. Quand la réponse est au milieu, le modèle fait moins bien que sa référence à livre fermé de 56,1 %, le score qu’il obtient sans aucun document. Enterrée en plein milieu du contexte, la bonne réponse valait moins que pas de réponse du tout. Voilà pourquoi rogner une longue entrée pour n’en garder que la tête et la queue n’est pas un bricolage grossier : la tête et la queue sont précisément les parties que l’attention utilise.

La capacité n’est pas la fiabilité

Venons-en à la panne que je vous ai demandé de garder en tête. Une fenêtre qui n’est pas pleine peut très bien être une fenêtre qui a mal tourné.

🔬 Mesuré, pas supposé. En 2025, un benchmark nommé NoLiMa a mis la chose à l’épreuve sur 13 modèles de pointe. Le protocole était volontairement peu charitable : supprimer les correspondances littérales de mots qui rendent la recherche facile, pour forcer le modèle à raisonner sur le texte au lieu de repérer des mots-clés. Le résultat a été constant et déplaisant. À 32 000 tokens, 11 des 13 modèles obtenaient moins de la moitié de leur propre score en contexte court, et GPT-4o à lui seul tombait de 99,3 %, quasi parfait, à 69,7 % (Modarressi et al., NoLiMa: Long-Context Evaluation Beyond Literal Matching, ICML 2025).

Un second benchmark, RULER, a retrouvé le même écart par l’autre bout. Sur 17 modèles annonçant tous un contexte d’au moins 32 000 tokens, la moitié seulement tenait encore la route quand on les poussait effectivement à cette longueur (Hsieh et al., RULER, 2024). C’est exactement pour ça que la taille de la fenêtre et la santé de la fenêtre sont deux choses différentes. La capacité vous dit ce qui rentre. Elle ne dit rien de ce que le modèle sait encore exploiter de façon fiable. Une fenêtre plus grande a relevé le plafond ; elle n’a pas acheté d’immunité. La discipline qui consiste à garder la fenêtre sobre, délibérément, c’est un autre sujet, pour un autre jour.

Retenez la mécanique unique : le modèle lit toute la fenêtre, du début à la fin, à chaque étape. Le coût, la position et la pourriture du contexte découlent tous de cette seule ligne. La fenêtre n’a jamais été un stockage. C’est ce que le modèle relit pour penser, et vous payez la relecture à chaque fois.


Sources

Newsletter

Un email par mois — ce sur quoi je travaille, et les articles qui en sortent. Désinscription en un clic.Pour l'instant, les envois sont en anglais.

Malo Couaran
Une réaction, une correction, une meilleure idée ? Répondez par email.