Une fenêtre de contexte n'est pas du stockage — c'est de la mémoire de travail. Chaque token dans la fenêtre (votre prompt système, l'historique de conversation, les documents que vous collez et la propre sortie du modèle jusqu'ici) se dispute le même budget de taille fixe. Quand on dit que Claude a une fenêtre de contexte de 200 000 tokens ou que Gemini prend en charge 1 million de tokens, ces chiffres incluent tout : entrée et sortie combinées. Une erreur courante est de traiter la fenêtre de contexte comme une base de données qu'on peut remplir de documents en s'attendant à ce que le modèle cherche parfaitement. En réalité, les modèles traitent le contexte à travers des mécanismes d'attention, et l'attention a des limites tant computationnelles que qualitatives.
Le problème du « perdu au milieu » est réel et bien documenté. Des recherches de Stanford et d'ailleurs ont montré que lorsqu'on place une information critique au milieu d'un très long contexte, les modèles sont mesurablementmoins bons pour l'utiliser par rapport à l'information au début ou à la fin. Ce n'est pas une préoccupation théorique — cela affecte directement la façon dont vous devriez structurer vos prompts. Si vous fournissez 50 pages de documentation à un modèle, placez les sections les plus importantes au début et à la fin, pas enfouies à la page 25. Certaines équipes contournent cela en découpant les documents et en utilisant le RAG pour ne récupérer que les passages pertinents plutôt que de tout déverser dans le contexte.
Les tailles de fenêtre de contexte ont augmenté considérablement. GPT-3 a été lancé en 2020 avec 4 000 tokens (environ 3 000 mots). En 2024, Claude offrait 200 000 tokens, et Gemini 1.5 Pro a poussé à 1 million de tokens. Les modèles Gemini 2.5 de Google maintiennent cette fenêtre d'un million de tokens. Mais les fenêtres plus grandes viennent avec de vrais compromis. La latence augmente parce que le modèle doit porter attention à plus de tokens. Le coût augmente parce que la plupart des fournisseurs d'API facturent par token traité. Et comme mentionné, la qualité sur les tâches de recherche n'évolue pas linéairement avec la taille du contexte — une fenêtre de 1 million de tokens n'est pas 5 fois meilleure pour trouver une aiguille qu'une fenêtre de 200 000 tokens.
Pour les développeurs travaillant avec des API, la gestion du contexte est un problème d'ingénierie central. Les longues conversations accumulent les tokens rapidement. Un échange de chat pourrait consommer 500 à 1 000 tokens par tour, ce qui signifie qu'un modèle à 4 000 tokens manque de place en quelques tours seulement. Les systèmes en production gèrent cela avec des fenêtres glissantes (abandonner les messages les plus anciens), la résumé (compresser la conversation précédente en un résumé plus court), ou des approches hybrides utilisant le RAG pour décharger le matériel de référence dans une base de données vectorielle et ne récupérer que les passages pertinents à la demande. Bien faire cela est souvent la différence entre une démo qui fonctionne et un produit qui tient la charge.
Une nuance qui piège les débutants : la limite de la fenêtre de contexte porte sur les tokens, pas sur les caractères ou les mots. La tokenisation varie selon le modèle et la langue. Le texte anglais fait en moyenne environ 1 token pour 4 caractères, mais le code peut être plus dense (les noms de variables et la syntaxe consomment des tokens rapidement), et les écritures non latines comme le chinois ou l'hindi utilisent souvent plus de tokens par mot. Le même document pourrait consommer 10 000 tokens en anglais et 15 000 en japonais. La plupart des fournisseurs offrent des outils de tokenisation ou des bibliothèques — Anthropic a un compteur de tokens dans les en-têtes de réponse API, et OpenAI publie tiktoken — pour que vous puissiez mesurer exactement plutôt que deviner.