Context window
Définition
Quantité maximale de tokens (texte) qu'un LLM peut traiter en une seule fois. Claude propose 200 000 tokens en standard (1 million en mode étendu), assez pour ingérer un livre entier.
La mémoire de travail du modèle
La context window est la quantité maximale de tokens que le LLM peut traiter en une seule fois, en entrée comme en sortie cumulées. Elle représente sa mémoire de travail pour un échange : tout ce qui doit influencer la réponse (instructions système, historique de conversation, documents joints, données métier, exemples few-shot) doit tenir dedans. Au-delà de cette limite, le modèle ne peut tout simplement pas voir le contenu, et selon l'implémentation, soit l'API renvoie une erreur, soit le contenu en début de prompt est silencieusement tronqué. C'est l'une des contraintes architecturales les plus visibles d'un LLM.
Les tailles disponibles
Les modèles modernes proposent des fenêtres de 128 000 à plusieurs millions de tokens. Claude 4.5 et 4.7 supportent 200 000 tokens en standard, jusqu'à 1 million en mode étendu via une option. GPT-5 et la série o d'OpenAI offrent 128 000 à 200 000 tokens. Gemini 2.5 Pro propose jusqu'à 2 millions de tokens, ce qui en fait le champion sur les contextes très longs. Pour donner un ordre de grandeur : 200 000 tokens représentent environ 150 000 mots, soit un livre entier ou plusieurs heures de transcription. Les modèles plus petits ou plus anciens restent à 32 000 ou 64 000 tokens.
La qualité dégrade avec la longueur
En pratique, on ne remplit pas la fenêtre à 100%. La qualité de raisonnement baisse quand le contexte devient très long : le modèle a tendance à privilégier le début et la fin du prompt (effet U), à oublier les détails du milieu, et à se perdre dans les contradictions internes. Le phénomène est appelé lost in the middle dans la littérature. Les benchmarks comme RULER et Needle in a Haystack mesurent cette dégradation : tous les modèles voient leurs performances chuter au-delà de 50 à 70% de leur fenêtre. La règle pratique : utiliser le contexte large pour ingérer beaucoup, mais cibler avec un RAG ou un résumé pour la question précise.
Le coût des fenêtres larges
Tout ce qu'on injecte dans la context window est facturé en input à chaque appel. Un prompt de 100 000 tokens coûte plusieurs centimes à chaque message, même si seuls 200 tokens varient entre deux appels successifs. Pour un produit qui scale, c'est rapidement la facture qui explose. On combine plusieurs leviers : prompt caching pour ne payer qu'une fois les blocs stables, RAG pour ne charger que les passages utiles, résumé progressif de l'historique pour les longues conversations. Une fenêtre généreuse n'évite donc pas une stratégie de récupération ciblée, elle la rend tolérable quand le RAG rate son top-k.
Quand l'utiliser pleinement
On exploite vraiment une fenêtre large dans quelques cas. Analyser un long document d'un coup (contrat, rapport, code source complet) où le découpage perdrait du sens. Maintenir une conversation longue sans perdre le contexte initial. Charger plusieurs documents reliés pour un raisonnement croisé. Faire passer un examen ou un benchmark sur un corpus entier. Pour ces cas, le coût supplémentaire se justifie. Pour des usages plus standard (chat support, FAQ, génération courte), on garde le contexte minimal et on optimise via RAG et caching.
Les limites techniques
Plus la fenêtre est large, plus la latence augmente : un prompt de 100 000 tokens met plusieurs secondes à être traité avant que le premier token de réponse n'arrive. C'est un facteur critique pour les interfaces conversationnelles. Le streaming SSE atténue l'effet une fois la génération démarrée, mais le time-to-first-token reste élevé sur les très longs prompts. Côté implémentation, on monitore aussi le ratio input/output : si on envoie 100 000 tokens pour récupérer 500 tokens en sortie, c'est souvent le signe qu'on aurait dû RAGuer plus finement. La fenêtre n'est pas une excuse pour ne pas réfléchir au prompt.