Fenêtre de contexte : la mémoire de travail des modèles de langage
Ou : Pourquoi un modèle avec un million de tokens de contexte peut quand même oublier ce que vous lui avez dit il y a trois paragraphes
Imaginez que vous travaillez à un bureau. Sur ce bureau, vous pouvez étaler un certain nombre de documents. Tant que les documents sont devant vous, vous pouvez les consulter, les comparer, faire des connexions entre eux. Mais le bureau a une taille fixe. Si vous voulez ajouter un nouveau document et que le bureau est plein, il faut en retirer un. Et une fois retiré, vous ne pouvez plus le consulter — il n’existe plus pour vous.
La fenêtre de contexte (ou context window) d’un LLM, c’est ce bureau. C’est la quantité totale de texte — mesurée en tokens — que le modèle peut « voir » en même temps. Tout ce qui est dans la fenêtre existe pour le modèle. Tout ce qui est en dehors n’existe pas. Il n’y a pas de zone grise, pas de mémoire floue : c’est binaire.
Quand on dit qu’un modèle a une fenêtre de contexte de 128 000 tokens, ça signifie qu’il peut traiter environ 100 000 mots en une seule requête — le prompt que vous envoyez plus la réponse qu’il génère. C’est à peu près la longueur d’un roman. Ce qui semble énorme. Ce qui est énorme, comparé à ce qu’on avait il y a trois ans. Et ce qui est, paradoxalement, parfois insuffisant.
De 1 024 tokens à un million — l’évolution d’une contrainte devenue argument marketing
La course aux tokens
L’histoire de la fenêtre de contexte, c’est l’histoire d’une contrainte technique qu’on repousse un peu plus chaque année. Comme les mégapixels des appareils photo ou les gigahertz des processeurs — un chiffre qui augmente, que le marketing adore, et dont l’impact réel est plus nuancé qu’un communiqué de presse ne le suggère.
| Modèle | Année | Fenêtre de contexte | En mots (~) |
|---|---|---|---|
| GPT-2 | 2019 | 1 024 tokens | ~750 mots |
| GPT-3 | 2020 | 2 048 tokens | ~1 500 mots |
| GPT-3.5 Turbo | 2023 | 4 096 → 16 385 tokens | ~3 000 → 12 000 mots |
| GPT-4 | 2023 | 8 192 → 128 000 tokens | ~6 000 → 96 000 mots |
| Claude 3 | 2024 | 200 000 tokens | ~150 000 mots |
| Gemini 1.5 Pro | 2024 | 1 000 000 → 2 000 000 tokens | ~750 000 → 1 500 000 mots |
| Claude Opus 4.6 | 2025-2026 | 200 000 → 1 000 000 tokens | ~150 000 → 750 000 mots |
En six ans, on est passé d’un contexte qui tenait dans un email à un contexte qui peut contenir l’intégralité des Misérables. Et pourtant, la question n’a jamais été « est-ce qu’on peut mettre plus de texte ? ». La vraie question, c’est « est-ce que le modèle utilise correctement tout ce texte ? ».
Ce que « 200K tokens » signifie vraiment
Quand un fournisseur annonce une fenêtre de 200 000 tokens, il faut comprendre que ce chiffre inclut tout : votre prompt, les instructions système, les documents que vous injectez, l’historique de conversation, et la réponse du modèle. C’est un budget partagé entre l’entrée et la sortie.
Concrètement, si vous injectez 180 000 tokens de documentation dans le prompt (ce qui est courant en RAG), il vous reste 20 000 tokens pour la réponse. Et la réponse maximale est souvent plafonnée indépendamment — beaucoup de modèles limitent la génération à 4 096 ou 8 192 tokens, quelle que soit la taille de la fenêtre de contexte.
C’est comme avoir un bureau de 10 mètres carrés mais un stylo qui ne peut écrire que sur une feuille A4. Vous pouvez lire beaucoup plus que ce que vous pouvez écrire.
Pourquoi c’est si cher
L’attention — le mécanisme au cœur de l’architecture Transformer — a une complexité quadratique par rapport à la longueur de la séquence. En termes simples : doubler la fenêtre de contexte ne double pas le coût de calcul. Ça le quadruple1.
C’est pour ça que les API facturent les tokens d’entrée et de sortie séparément, et que les tokens de sortie coûtent généralement 3 à 5 fois plus cher que les tokens d’entrée. C’est aussi pour ça que « balancer tout le corpus dans le contexte » n’est pas une stratégie viable en production — le coût par requête explose.
Un calcul rapide : envoyer 100 000 tokens d’entrée à GPT-4 coûte environ 1 $ par requête. Si vous avez 1 000 utilisateurs qui font chacun 10 requêtes par jour, vous êtes à 10 000 $ par jour. Par mois, ça fait la moitié du salaire annuel d’un développeur. Et on n’a pas encore compté les tokens de sortie.
Le problème « lost in the middle »
Avoir un million de tokens de contexte ne sert à rien si le modèle ne les utilise pas tous de la même façon. Et c’est exactement ce qui se passe.
En 2023, Liu et al. ont publié une étude intitulée « Lost in the Middle: How Language Models Use Long Contexts » qui a démontré un phénomène contre-intuitif : les LLM ont tendance à bien utiliser l’information placée au début et à la fin du contexte, mais à ignorer ou sous-utiliser ce qui se trouve au milieu2.
Imaginez votre bureau à nouveau. Vous avez 50 documents étalés devant vous. Vous allez naturellement accorder plus d’attention aux documents sur le dessus de la pile (les plus récents) et à ceux que vous avez vus en premier (les plus mémorables). Ceux du milieu ? Ils sont là, techniquement visibles, mais votre attention les survole.
C’est exactement ce que font les LLM. Et ça a des implications pratiques énormes pour le RAG : si vous injectez 10 documents dans le contexte, l’information du document n°5 a statistiquement moins de chances d’être utilisée que celle du document n°1 ou n°10. L’ordre dans lequel vous présentez les documents au modèle compte.
Fenêtre de contexte vs mémoire
Il y a une confusion fréquente entre la fenêtre de contexte et la « mémoire » d’un modèle. Ce sont deux choses fondamentalement différentes :
La fenêtre de contexte est éphémère. Elle existe le temps d’une requête (ou d’une conversation, si le fournisseur gère l’historique). Quand la conversation se termine, tout disparaît. Le modèle ne se souvient pas de vous. Il ne se souvient pas de ce qu’il a dit. Chaque nouvelle conversation commence de zéro.
Les connaissances du modèle sont permanentes — elles sont encodées dans ses paramètres pendant l’entraînement. Mais elles sont statiques, figées à la date de coupure des données d’entraînement, et parfois inexactes (voir hallucination).
C’est la différence entre la mémoire de travail (ce que vous avez en tête en ce moment) et la mémoire à long terme (ce que vous avez appris au cours de votre vie). Un LLM avec une fenêtre de contexte de 1 million de tokens a une mémoire de travail spectaculaire. Mais il n’a aucune capacité à former de nouveaux souvenirs à long terme entre les conversations3.
Le dialogue de la fenêtre pleine
DevOps Dave : J’ai mis toute notre documentation Confluence dans le contexte du chatbot. 200 pages. Les réponses sont parfaites.
Security Sarah : 200 pages, ça fait combien de tokens ?
DevOps Dave : Environ 180 000. On a un modèle avec 200K de contexte, donc ça rentre.
Security Sarah : Et la réponse du modèle, elle rentre où ?
DevOps Dave : … Ah.
Security Sarah : Et si quelqu’un pose une question sur un document qui est au milieu de tes 200 pages ?
DevOps Dave : Le modèle a accès à tout le contexte, donc—
Security Sarah : « Lost in the middle. » Le modèle va probablement ignorer l’information qui est au milieu et répondre à partir de ce qu’il a vu au début ou à la fin. Ou pire, il va halluciner une réponse plausible.
DevOps Dave : Donc je devrais plutôt utiliser du RAG pour sélectionner les bons documents ?
Security Sarah : Maintenant tu comprends pourquoi le RAG existe, même avec des fenêtres de contexte géantes.
Tableau récapitulatif
| Concept | En une phrase |
|---|---|
| Fenêtre de contexte | Quantité maximale de tokens qu’un LLM peut traiter en une seule requête. |
| Tokens d’entrée | Le prompt, les instructions système, les documents injectés, l’historique. |
| Tokens de sortie | La réponse générée par le modèle (souvent plafonnée indépendamment). |
| Complexité quadratique | Doubler le contexte quadruple le coût de calcul (attention O(n²)). |
| Lost in the middle | Les LLM sous-utilisent l’information placée au milieu du contexte. |
| Contexte ≠ mémoire | Le contexte est éphémère (une requête), la mémoire est permanente (entraînement). |
Le mot de la fin
La fenêtre de contexte est devenue un argument marketing, un chiffre qu’on compare entre modèles comme on comparait les mégapixels entre smartphones. Et comme les mégapixels, le chiffre brut ne raconte qu’une partie de l’histoire. Un modèle avec 128K tokens de contexte qui utilise bien toute l’information est plus utile qu’un modèle avec 2M tokens qui oublie ce qui est au milieu.
La vraie avancée ne sera pas un modèle avec 10 millions de tokens de contexte. Ce sera un modèle qui utilise chaque token de son contexte avec la même attention — du premier au dernier. En attendant, la combinaison contexte long + RAG reste la solution pragmatique : le RAG sélectionne les bons documents, le contexte long donne au modèle assez de place pour les analyser en profondeur.
Le bureau est plus grand que jamais. Reste à apprendre à s’en servir.
C’est une simplification. L’attention standard (« full attention ») est bien O(n²), mais plusieurs techniques réduisent cette complexité en pratique : FlashAttention optimise l’utilisation de la mémoire GPU, les architectures à attention clairsemée (sparse attention) ne calculent l’attention que sur un sous-ensemble de la séquence, et certains modèles utilisent des mécanismes de « sliding window » qui limitent l’attention aux tokens voisins. Mais le principe fondamental reste : plus de contexte = plus de calcul, et la relation n’est pas linéaire. ↩︎
L’étude de Liu et al. (2023) a testé des modèles sur des tâches de recherche d’information dans des contextes de différentes longueurs. Le résultat clé : la performance forme une courbe en U — élevée quand l’information pertinente est au début, faible quand elle est au milieu, élevée à nouveau quand elle est à la fin. Ce phénomène est atténué dans les modèles plus récents, mais pas éliminé. C’est une des raisons pour lesquelles l’ordre des documents dans un prompt RAG n’est pas anodin. ↩︎
Certains fournisseurs ajoutent des mécanismes de « mémoire » au-dessus du modèle — ChatGPT se « souvient » de vos préférences entre conversations, par exemple. Mais ce n’est pas le modèle qui se souvient. C’est une couche logicielle qui stocke des informations et les réinjecte dans le contexte à chaque nouvelle conversation. Le modèle lui-même, à chaque requête, est une ardoise vierge avec un bureau vide. ↩︎