À chaque message, le modèle relit tout ce qu'il a le droit de voir : les instructions, la conversation jusque-là, les documents joints. Ce budget de lecture, c'est la fenêtre de contexte. Elle se mesure en tokens, et elle a une limite stricte.
Pixel François montre une consigne donnée une seule fois qui disparaît quand la conversation est compactée, puis la même consigne qui survit dans un fichier d'instructions.
Ce qui tient, et ce qui sort
Une longue conversation ne grandit pas indéfiniment. Quand la fenêtre est pleine, il faut retirer quelque chose, et c'est en général le plus ancien : le brief donné au départ, la contrainte mentionnée une seule fois. Le modèle répond ensuite avec assurance, sans elle.
Concept clé
Un modèle ne connaît que ce qui se trouve dans sa fenêtre de contexte à cet instant. Il n'a aucune mémoire d'un appel à l'autre. Ce qui n'y tient pas, ou en a été poussé dehors, n'existe pas pour lui.
8 messages dans la fenêtre de contexte. 4 anciens messages en sont sortis.
Les assistants dotés d'une mémoire n'échappent pas à cette règle : c'est l'application qui garde des notes et les remet dans la fenêtre à chaque requête.
Plus de contexte n'est pas toujours mieux non plus. Quand le texte s'allonge et se charge d'éléments inutiles, le modèle retrouve moins bien l'information qui compte : Anthropic parle de dégradation du contexte (context rot). L'effet varie selon le modèle : mesurez-le sur vos propres textes longs. Chaque token en plus coûte aussi du temps et de l'argent à chaque requête.
6 éléments inutiles autour de l'information qui compte : elle se perd dans le bruit, et chacun se paie à chaque requête. Dégradation indicative : l'effet varie selon le modèle.
Toutes les fenêtres n'ont pas la même taille
La taille de la fenêtre dépend d'abord du modèle, de sa conception et de son entraînement. En octobre 2026, les modèles phares de trois grands fournisseurs acceptent environ un million de tokens : 1 000 000 pour les modèles Claude actuels d'Anthropic, 1 050 000 pour les modèles GPT de l'API d'OpenAI, 1 048 576 pour Gemini 3.1 Pro, en préversion chez Google. Les générations précédentes en acceptaient moins : 200 000 tokens pour plusieurs anciens modèles Claude.
Elle dépend aussi du produit. Servir un long contexte coûte cher au fournisseur, qui ne donne pas toujours toute la fenêtre du modèle. En octobre 2026, ChatGPT accorde à son modèle rapide, GPT Instant, 27 000 tokens dans l'offre gratuite et 54 000 dans les offres Go et Plus, loin du million de l'API. À la même date, Claude Haiku 5.5 dispose d'un million de tokens dans les conversations des offres payantes de Claude, mais de 500 000 dans Claude Cowork. Le même modèle n'a donc pas la même fenêtre d'un produit à l'autre : vérifiez celle de l'outil que vous utilisez, pas seulement celle du modèle.
Ce qu'une grande fenêtre coûte. Une fenêtre remplie se paie à chaque requête : au même prix par token, une requête de 500 000 tokens coûte cent fois plus en entrée qu'une requête de 5 000. Certains fournisseurs augmentent aussi le prix au-delà d'un seuil. En octobre 2026, le prix d'entrée double au-delà de 200 000 tokens pour Gemini 3.1 Pro chez Google, et au-delà de 272 000 tokens chez OpenAI. Anthropic facture Claude Haiku 5.5 0,50 dollar par million de tokens d'entrée au-delà de 100 000 tokens, au lieu de 0,10, mais garde le même prix pour ses autres modèles actuels. Un long contexte peut aussi retarder la réponse : Anthropic indique que la latence dépend de la longueur du prompt, mais OpenAI estime que la longueur de la réponse pèse bien plus.
Ce qu'elle ne règle pas. Une fenêtre plus grande ne lit pas mieux. La dégradation du contexte décrite plus haut s'aggrave à mesure que la fenêtre se remplit. Un million de tokens de documents mal triés peut donner une moins bonne réponse que quelques milliers de tokens bien choisis.
Quand chercher plutôt qu'agrandir. Si vos documents dépassent la fenêtre, changent souvent, ou si chaque question n'en concerne qu'une petite partie, le RAG (génération appuyée sur une recherche) convient mieux : il cherche les passages utiles et n'envoie qu'eux au modèle. La grande fenêtre sert quand la tâche demande vraiment de tout lire d'un coup : comparer deux contrats en entier, relire un long rapport.
Chercher d'abord : le RAG cherche les passages utiles et n'envoie qu'eux au modèle. Il convient mieux si vos documents dépassent la fenêtre, changent souvent, ou si chaque question n'en concerne qu'une petite partie.
Ce que ça change pour vous
Pour les fondateurs
Le contexte est une ligne de coût. Chaque token envoyé est payé à chaque requête, donc « tout envoyer au cas où » fait grimper la facture avec l'usage.
Pour les product managers
Quand les utilisateurs disent que l'assistant « a oublié », il n'a souvent rien oublié. L'information est sortie de la fenêtre. Concevez des parcours qui reformulent l'essentiel au lieu d'espérer que le modèle s'en souvienne.
Pour les tech leads
Traitez le contexte comme un budget à répartir entre le prompt système, les documents récupérés et l'historique de conversation. Mesurez chaque part, et décidez ce qui est coupé en premier quand le budget est épuisé. La page Le prompting : bien briefer un modèle détaille ce qui doit entrer dans la fenêtre, ce qui doit être cherché et ce qui doit en sortir.
Pour les dirigeants
Quand un fournisseur promet un assistant qui « se souvient de tout », demandez ce qu'il oublie quand l'historique d'un client devient long. La réponse fixe ce que vous pouvez promettre à vos propres clients.
Pour aller plus loinComment les tokens sont comptés
Un token est un fragment de texte, souvent un morceau de mot. En anglais, un token vaut entre la moitié et les trois quarts d'un mot, selon le découpage propre à chaque modèle. En octobre 2026, la documentation d'Anthropic indique qu'un million de tokens représente environ 555 000 mots sur ses modèles actuels, contre environ 750 000 sur les modèles plus anciens : le même texte compte donc plus de tokens qu'avant. Le français et le code en demandent en général plus que l'anglais pour le même sens.
La limite couvre à la fois ce que vous envoyez et ce que le modèle répond, donc une longue réponse laisse moins de place à vos messages et à vos documents. Quand une conversation dépasse la limite, c'est l'application qui décide quoi retirer, pas le modèle. La section « Compacter, à la main ou automatiquement », plus bas, explique comment.
L'erreur classique
fAIling RÈGLE I
Le piège : Collez l'intégralité de votre codebase dans le prompt
Coller toute une base de code ou tout un dossier de documents dans les instructions n'aide pas le modèle à mieux comprendre. Cela remplit la fenêtre de bruit, pousse dehors ce qui compte, et coûte plus cher à chaque requête.
Lire la règle I du manifesteÀ essayer
Choisissez une fonctionnalité ou un processus IA utilisé par votre équipe. Notez tout ce qu'il envoie au modèle sur une requête typique, et estimez la part qui change vraiment la réponse. Retirez une partie qui ne sert pas, et comparez les résultats pendant une semaine.
Autour du sujet
Pour aller plus loinCe qui remplit une fenêtre
Votre conversation n'est qu'un des occupants de la fenêtre. Elle la partage avec le prompt système, les définitions des outils, les fichiers d'instructions et de mémoire, les extensions chargées (skills, plugins), et une réserve laissée libre pour la réponse et pour la compaction (un résumé qui remplace le début de la conversation, voir plus bas). Une partie de la fenêtre est donc déjà prise avant que vous ayez tapé un mot.
Un exemple relevé en octobre 2026, dans une session Claude Code (l'agent de code d'Anthropic) avec une fenêtre d'un million de tokens : la conversation en occupait 7,4 %, la configuration chargée au démarrage presque autant (7,1 %). Chaque outil branché et chaque fichier d'instructions prend de la place à chaque requête, qu'il serve ou non.
Pour des questions sur des documents, la conversation occupe 57 % de la fenêtre dans cet exemple indicatif ; c'est la plus grande part.
Pour aller plus loinCompacter, à la main ou automatiquement
Compacter, c'est remplacer le début d'une conversation par un résumé pour libérer de la place. Ce n'est pas le modèle qui s'en charge, c'est l'application. La compaction manuelle se lance quand vous le décidez, au bon moment, par exemple entre deux tâches, et vous pouvez préciser ce qu'il faut garder. La compaction automatique se déclenche près de la limite, souvent en pleine tâche, et décide seule de ce qui survit.
Dans les deux cas, le résumé laisse de l'information de côté : la formulation exacte, une contrainte posée au début, un détail qui semblait mineur. Les instructions écrites dans un fichier rechargé à chaque requête survivent à la compaction. Celles données une seule fois dans la conversation peuvent disparaître. Si une règle compte, mettez-la dans un fichier d'instructions, pas dans un message.
Pour aller plus loinLe cache de prompt
À chaque requête, le modèle relit tout depuis le début, et le début change rarement : le prompt système, les outils, les documents de référence. Les fournisseurs peuvent garder ce début commun en cache (une copie prête à relire) pendant quelques minutes. Le relire depuis le cache coûte moins cher et la réponse arrive plus vite.
Une lecture en cache coûte une petite fraction du prix normal : la page Les tokens et le coût donne les prix relevés en octobre 2026. À la même date, chez Anthropic, le cache expire par défaut après cinq minutes sans utilisation. La règle pratique : mettez ce qui ne bouge pas au début, et ce qui change à la fin.
Quoi en faire
Une consigne donnée une seule fois peut sortir de la fenêtre : si elle compte, mettez-la dans un fichier d'instructions, pas dans un message.
Plus de contexte n'est pas toujours mieux : le superflu cache ce qui compte, et chaque token se paie à chaque requête.
Quand les documents dépassent la fenêtre ou changent souvent, allez chercher les passages utiles avec le RAG plutôt que d'agrandir la fenêtre.