Fenêtre de contexte : à quoi servent vraiment le million de tokens

En février 2024, une annonce a fait bondir les compteurs de l'industrie : un modèle capable d'ingérer un million de tokens en une seule requête. Sur le papier, c'est vertigineux — l'équivalent d'une heure de vidéo, de onze heures d'audio, d'une base de code de plus de 30 000 lignes, ou encore de quelque 700 000 mots avalés d'un trait. Depuis, la fenêtre de contexte est devenue l'un des chiffres les plus mis en avant dans les fiches techniques des grands modèles de langage. Mais derrière le chiffre spectaculaire se cache une question bien plus utile : à quoi sert vraiment tout cet espace, et que peut-on réellement en attendre ?

Cet article propose un décryptage posé de la fenêtre de contexte. Nous allons d'abord définir ce qu'est un token et ce que recouvre exactement cette « fenêtre ». Nous verrons ensuite ce que le contexte long permet concrètement, pourquoi il coûte cher à mesure qu'il s'allonge, et surtout ce que les recherches nous apprennent sur ses limites d'attention — le fameux phénomène du « perdu au milieu ». Enfin, nous poserons la question qui intéresse tout praticien : quand faut-il vraiment un contexte d'un million de tokens, et quand une approche par récupération de documents reste-t-elle préférable ? L'objectif est simple : vous permettre de lire les fiches techniques en connaissance de cause, et de faire des choix éclairés plutôt que de courir après le plus gros chiffre.

Un mot de méthode d'abord. Les discussions publiques opposent souvent deux camps — les partisans du « tout dans le contexte » et ceux du « RAG partout ». La réalité, comme souvent, est plus nuancée : les deux approches ont leur domaine de pertinence, et comprendre les mécanismes sous-jacents est le meilleur moyen de trancher au cas par cas. C'est précisément l'ambition de cette chronique.

Qu'est-ce qu'un token, au juste ?

Avant de parler de « million de tokens », il faut clarifier une unité de base souvent mal comprise. Un modèle de langage ne lit pas le texte lettre par lettre, ni tout à fait mot par mot. Il le découpe en tokens : des fragments qui peuvent être un mot entier, un morceau de mot, un signe de ponctuation, ou même un simple caractère. Cette découpe est réalisée par un composant appelé tokeniseur, livré avec chaque modèle.

La tokenisation, expliquée simplement

La plupart des grands modèles utilisent une technique nommée Byte-Pair Encoding (BPE), ou codage par paires d'octets. L'idée est astucieuse : on part des caractères individuels, puis on fusionne progressivement les paires les plus fréquentes en entrées uniques du vocabulaire. Un mot courant comme « bonjour » sera représenté par un seul token, tandis qu'un terme rare ou technique sera découpé en plusieurs morceaux. Le vocabulaire résultant compte typiquement entre 32 000 et 100 000 entrées, parfois davantage.

Ce mécanisme explique une règle empirique utile à mémoriser : en anglais, un token représente environ quatre caractères, soit à peu près trois quarts de mot. Autrement dit, mille mots correspondent grosso modo à 1 300 ou 1 400 tokens. Le ratio n'est pas fixe : le texte conversationnel consomme moins de tokens, tandis que l'écriture technique et le code en consomment davantage. En français, la découpe diffère légèrement, mais l'ordre de grandeur reste comparable.

• Un token ≈ 4 caractères ≈ 0,75 mot en anglais ;
• 1 000 mots ≈ 1 300 à 1 400 tokens ;
• Le code source et le texte technique gonflent le compte de tokens ;
• Chaque modèle a son propre tokeniseur, donc son propre découpage.

Pourquoi ce détail compte-t-il ? Parce que toutes les limites d'un modèle — la taille de sa fenêtre de contexte, le coût d'une requête, la vitesse de génération — se comptent en tokens, pas en mots. Quand on lit qu'un modèle accepte « un million de tokens », il faut donc traduire : cela représente environ 750 000 mots, soit l'équivalent d'un long roman-fleuve, ou d'une pile respectable de documents professionnels. Ce n'est qu'en gardant cette conversion en tête qu'on prend la juste mesure des chiffres avancés.

La fenêtre de contexte : la mémoire de travail du modèle

Une fois la notion de token posée, celle de fenêtre de contexte devient limpide. La fenêtre de contexte est la quantité maximale de tokens qu'un modèle peut prendre en compte en une seule fois — tout ce qu'on lui fournit en entrée, plus ce qu'il génère en sortie. On peut la comparer à la mémoire de travail d'un être humain : c'est l'espace dans lequel le modèle « garde à l'esprit » les informations pendant qu'il raisonne.

Cette mémoire est volatile. Un modèle de langage, en lui-même, n'a pas de mémoire persistante entre deux requêtes : il ne se souvient pas de votre conversation d'hier. Tout ce qu'il « sait » d'une conversation en cours doit tenir dans la fenêtre de contexte de la requête courante. C'est pourquoi les interfaces conversationnelles renvoient généralement l'historique complet de l'échange à chaque nouveau message : sans cela, le modèle repartirait de zéro à chaque tour.

Une croissance rapide en quelques années

L'évolution de la taille des fenêtres de contexte illustre bien la vitesse des progrès. Les premiers grands modèles grand public se contentaient de quelques milliers de tokens. Puis les paliers ont chuté rapidement :

• Les modèles GPT de première génération plafonnaient autour de 2 000 à 4 000 tokens ;
• La famille Claude d'Anthropic a popularisé la fenêtre de 200 000 tokens, soit environ 500 pages de texte ;
• En février 2024, Google a annoncé Gemini 1.5 Pro avec une fenêtre standard de 128 000 tokens, extensible jusqu'à un million de tokens en preview.

Ce dernier saut a marqué les esprits, car il a fait basculer le contexte long d'une curiosité de laboratoire à une capacité concrète. Selon l'annonce de Google, Gemini 1.5 Pro peut traiter, dans sa fenêtre d'un million de tokens, l'équivalent d'une heure de vidéo, de onze heures d'audio, d'une base de code de plus de 30 000 lignes ou de plus de 700 000 mots. Les équipes de recherche ont même rapporté des tests réussis jusqu'à dix millions de tokens. Ces chiffres donnent le tournis, mais ils décrivent une capacité brute d'ingestion — la vraie question, on le verra, est de savoir ce que le modèle en fait ensuite.

La fenêtre de contexte n'est pas une base de connaissances permanente : c'est une mémoire de travail que l'on remplit à chaque requête, et qui s'efface à la suivante.

Ce que le contexte long permet concrètement

Passons du chiffre à l'usage. Que peut-on réellement faire avec une fenêtre de plusieurs centaines de milliers, voire d'un million de tokens ? Les bénéfices sont bien réels, et ils touchent plusieurs familles de tâches.

Analyser de longs documents d'un seul tenant

Le cas d'usage le plus évident est l'analyse documentaire. Avec une fenêtre de 200 000 tokens, un modèle peut ingérer un rapport annuel complet, un contrat de plusieurs dizaines de pages, ou la documentation technique d'un produit — puis répondre à des questions précises, produire une synthèse, ou repérer des incohérences. Là où il fallait auparavant découper le document en morceaux et jongler avec les extraits, on peut désormais soumettre l'ensemble et laisser le modèle faire le lien entre des passages éloignés. Pour un juriste qui analyse un contrat, ou un analyste financier qui décortique un rapport, ce gain de fluidité est appréciable.

Raisonner sur une base de code entière

La programmation assistée bénéficie tout particulièrement du contexte long. Comprendre un bug, proposer une modification cohérente, ou expliquer l'architecture d'un projet suppose souvent de croiser de nombreux fichiers. Un modèle capable d'ingérer plusieurs dizaines de milliers de lignes de code peut saisir les dépendances entre modules, respecter les conventions du projet et éviter de casser une fonctionnalité en en corrigeant une autre. Le contexte long transforme ici l'assistant de code, qui passe d'un aide ponctuel à un partenaire capable d'une vue d'ensemble.

Tenir de longues conversations cohérentes

Enfin, une fenêtre généreuse permet des échanges prolongés sans perdre le fil. Dans un dialogue de plusieurs heures — assistance technique, session de rédaction, tutorat — le modèle peut se référer à ce qui a été dit bien plus tôt, éviter les répétitions et maintenir une cohérence globale. C'est cette continuité qui donne l'impression d'un interlocuteur attentif plutôt que d'un système qui oublie tout au bout de quelques messages.

À ces usages s'ajoutent des applications multimodales rendues possibles par les fenêtres géantes : analyser une longue vidéo, transcrire et résumer un enregistrement audio de plusieurs heures, ou explorer un ensemble d'images accompagnées de leur description. La capacité d'ingestion brute ouvre, indéniablement, un champ d'applications qui restait fermé quelques années plus tôt.

Pourquoi le contexte long coûte cher

Cette puissance a un prix, au sens le plus littéral. Comprendre d'où vient ce coût est essentiel pour dimensionner un usage sans mauvaise surprise. Et tout remonte à une propriété fondamentale de l'architecture qui sous-tend ces modèles : le mécanisme d'attention.

La complexité quadratique de l'attention

Dans un transformer — l'architecture qui équipe la quasi-totalité des grands modèles actuels — chaque token doit « regarder » tous les autres tokens du contexte pour évaluer leur pertinence relative. C'est le principe du mécanisme d'attention : il calcule des interactions par paires entre tous les tokens de la séquence. Or, si l'on double la longueur du contexte, le nombre de paires à évaluer ne double pas — il quadruple.

Les informaticiens résument cette propriété par une formule : le coût de l'attention croît en O(n²), c'est-à-dire de manière quadratique avec la longueur de la séquence. En termes concrets, cela signifie que doubler la fenêtre de contexte multiplie par quatre à la fois le temps de calcul et la mémoire nécessaire. À mesure que l'on grimpe vers des dizaines ou des centaines de milliers de tokens, la latence d'inférence s'envole et la consommation mémoire explose. Certaines analyses estiment qu'à 64 000 tokens, une attention complète mobilise des ordres de grandeur plus d'opérations qu'à quelques milliers de tokens.

• Doubler le contexte quadruple le calcul et la mémoire ;
• La latence augmente fortement avec la longueur des requêtes ;
• La facturation à l'usage se fait au token : plus le contexte est long, plus la requête coûte cher.

Cette réalité économique a une conséquence pratique directe. Remplir systématiquement une fenêtre d'un million de tokens pour chaque requête, alors que la réponse ne dépend que de quelques paragraphes pertinents, revient à payer un carrosse pour traverser la rue. Le contexte long est un outil puissant, mais son coût invite à ne le déployer que lorsque la tâche l'exige réellement.

Les pistes pour dépasser le mur quadratique

La recherche ne reste évidemment pas les bras croisés face à cette contrainte. Plusieurs familles de techniques visent à casser la barrière quadratique. Les attentions creuses (sparse attention) ne calculent l'attention complète que sur une sélection de tokens jugés pertinents, plutôt que sur la totalité de la séquence. D'autres approches réduisent l'empreinte du cache mémoire en compressant les représentations intermédiaires. L'objectif commun est de rendre les contextes très longs praticables sans que le coût ne devienne prohibitif. Ces travaux sont actifs et prometteurs, et ils expliquent pourquoi les fenêtres géantes, jadis théoriques, deviennent progressivement exploitables en production.

La limite d'attention : le phénomène du « perdu au milieu »

Nous arrivons au cœur du sujet, et à la nuance la plus importante de cet article. Disposer d'une grande fenêtre de contexte ne garantit pas que le modèle exploite uniformément tout ce qu'on y met. C'est même l'un des enseignements les plus solides de la recherche récente.

Une courbe en U révélatrice

En 2023, une équipe de chercheurs a publié une étude devenue une référence, intitulée « Lost in the Middle: How Language Models Use Long Contexts ». Ses conclusions sont éclairantes. En testant des modèles sur des tâches de questions-réponses multi-documents et de récupération d'information, les auteurs ont constaté que la performance est la plus élevée quand l'information pertinente se trouve au début ou à la fin du contexte, et se dégrade nettement quand elle est enfouie au milieu.

Le résultat prend la forme d'une courbe en U caractéristique : excellente aux extrémités, plus faible au centre. Les chercheurs parlent de biais de primauté (le modèle retient bien le début) et de récence (il retient bien la fin), au détriment du milieu. Fait notable, cette limite touche même des modèles explicitement conçus pour les contextes longs — les auteurs l'ont observée sur des modèles de premier plan de l'époque. Autrement dit, un modèle qui accepte 200 000 tokens n'exploite pas forcément le 100 000e token aussi bien que le premier ou le dernier.

Les modèles retiennent bien le début et la fin d'un long contexte, mais peinent à mobiliser l'information enfouie en son milieu : disposer d'une grande fenêtre ne signifie pas l'utiliser uniformément.

Distinguer contexte annoncé et contexte « effectif »

Cette découverte a fait émerger une distinction précieuse pour tout praticien : celle entre le contexte annoncé et le contexte effectif. Le premier est le chiffre marketing — le nombre maximal de tokens que le modèle accepte techniquement. Le second est la portion de ce contexte sur laquelle le modèle raisonne réellement de façon fiable. Les deux ne coïncident pas nécessairement, et l'écart entre eux est précisément ce que mesurent les protocoles d'évaluation sérieux.

Il faut toutefois se garder de tout excès de pessimisme : les progrès sont réels. Google a rapporté que Gemini 1.5 Pro retrouvait un texte inséré dans un bloc de données 99 % du temps, jusqu'à un million de tokens, dans le cadre du test dit de « l'aiguille dans une botte de foin ». Ce type de résultat montre que la récupération d'un fait isolé sur un très long contexte est devenue remarquablement fiable. La nuance importe : récupérer une information précise et bien identifiée est une chose, raisonner globalement sur l'ensemble du contexte en est une autre, souvent plus exigeante.

Comment on mesure vraiment le contexte long

Puisque le chiffre affiché ne dit pas tout, comment évalue-t-on sérieusement la capacité d'un modèle à exploiter son contexte ? Plusieurs protocoles se sont imposés, et il est utile d'en connaître les principes pour lire les annonces avec discernement.

Le test de l'aiguille dans la botte de foin

Le plus connu est le test dit « needle in a haystack », proposé par le praticien Greg Kamradt. Le principe est simple et parlant : on insère une information incongrue et précise — l'« aiguille » — à une profondeur variable dans un long texte servant de « botte de foin », puis on demande au modèle de la retrouver. En faisant varier à la fois la longueur du contexte et la position de l'aiguille, on obtient une carte de la fiabilité de récupération. Dans la version originale, l'aiguille était une phrase décalée glissée dans des essais, à des profondeurs allant du haut au bas du document, sur des longueurs allant de mille tokens jusqu'à la limite de chaque modèle.

Ce test a le mérite de la clarté, mais il a aussi ses limites. Retrouver une aiguille unique et distinctive est une tâche de récupération pure. Elle ne dit rien de la capacité du modèle à synthétiser plusieurs informations dispersées, à raisonner sur des passages contradictoires, ou à comprendre globalement un document. C'est pourquoi des variantes plus exigeantes ont vu le jour : aiguilles multiples, aiguilles nécessitant un raisonnement, ou évaluations multimodales.

Vers des évaluations plus réalistes

La communauté a donc développé des batteries de tests plus proches des usages réels. Certaines mesurent la capacité à résumer fidèlement un long document, d'autres à répondre à des questions dont la réponse suppose de croiser plusieurs passages éloignés. Ces protocoles font apparaître ce que le simple chiffre de la fenêtre masque : deux modèles annonçant la même taille de contexte peuvent avoir des « contextes effectifs » très différents. La leçon, pour l'évaluateur, est la même que pour tous les benchmarks : se méfier du chiffre isolé et tester sur ses propres cas d'usage.

Contexte long ou RAG : le vrai débat

Nous voici à la question qui divise le plus les équipes techniques. Face à un besoin — interroger une grande base documentaire, par exemple — vaut-il mieux tout charger dans une fenêtre géante, ou recourir à une architecture de génération augmentée par récupération (RAG), qui va chercher au préalable les passages pertinents pour ne fournir au modèle que l'essentiel ?

Rappel : ce qu'est le RAG

Le RAG fonctionne en deux temps. D'abord, une étape de récupération sélectionne, dans une base de documents, les extraits les plus pertinents pour la question posée — le plus souvent via une recherche sémantique sur des représentations vectorielles. Ensuite, seuls ces extraits sont insérés dans le contexte du modèle, qui rédige sa réponse à partir de cette matière ciblée. Au lieu de soumettre une bibliothèque entière, on ne présente que les quelques rayons pertinents.

Ce que disent les études comparatives

Plusieurs travaux de 2024 ont comparé rigoureusement les deux approches, et leurs conclusions convergent vers une réponse nuancée. Une étude complète présentée à la conférence EMNLP a établi que, lorsque les ressources sont suffisantes, les modèles à long contexte l'emportent en moyenne sur le RAG en qualité de réponse, en particulier sur les tâches de raisonnement multi-étapes et les questions qui exigent une compréhension globale du contexte — des cas où le RAG peine, faute de récupérer en une fois tous les passages nécessaires. Mais les mêmes travaux soulignent un contrepoint décisif : le RAG conserve un avantage de coût très net. Ne fournir au modèle que quelques extraits pertinents, plutôt qu'un contexte gigantesque, réduit drastiquement le nombre de tokens facturés et le temps de calcul.

• Long contexte : brille sur les documents longs, statiques et bien structurés, où le lien entre passages éloignés importe ;
• RAG : plus économique, et souvent préférable quand la base est vaste, dynamique ou diverse ;
• La qualité du RAG dépend fortement de la qualité de la récupération : une mauvaise sélection d'extraits plombe la réponse.

Les chercheurs insistent : il n'existe pas de solution universelle. Le bon choix dépend de la taille du modèle, du type de tâche, de la fraîcheur des données et du budget. Certains travaux proposent d'ailleurs des approches hybrides, qui basculent de l'une à l'autre selon la nature de la requête — signe que la question n'est pas « lequel gagne ? » mais « lequel pour quel usage ? ».

Une grille de décision pratique

De ces enseignements, on peut tirer quelques repères simples. Le contexte long est indiqué quand on travaille sur un corpus fermé et cohérent — un seul long document, une base de code délimitée, une conversation prolongée — où l'on veut que le modèle saisisse l'ensemble d'un bloc. Le RAG s'impose plutôt quand la source de connaissances est vaste, change souvent, ou dépasse largement ce qu'une fenêtre peut contenir : une base documentaire d'entreprise de plusieurs gigaoctets ne tiendra jamais dans un million de tokens, et il serait ruineux d'essayer.

Un point mérite d'être souligné, car il tempère l'enthousiasme pour le « tout contexte » : même avec une fenêtre d'un million de tokens, injecter systématiquement une masse d'informations non pertinentes n'est pas neutre. Cela coûte plus cher, ralentit la réponse, et — au vu du phénomène du « perdu au milieu » — peut même diluer l'information utile au milieu du bruit. La discipline du RAG, qui consiste à ne présenter que le pertinent, garde donc toute sa valeur, y compris à l'ère des fenêtres géantes.

Bien utiliser la fenêtre de contexte, en pratique

Passons du concept au terrain. Comment tirer le meilleur parti d'une fenêtre de contexte, quelle que soit sa taille ? Quelques principes se dégagent des enseignements précédents.

D'abord, placer l'information cruciale aux bons endroits. Puisque les modèles retiennent mieux le début et la fin, il est judicieux de positionner les instructions clés et les documents les plus importants en tête ou en queue de contexte, plutôt qu'enfouis au milieu d'une longue masse de texte. Cette précaution simple améliore sensiblement la fiabilité sur les longs contextes.

Ensuite, ne pas confondre capacité et nécessité. Ce n'est pas parce qu'un modèle accepte un million de tokens qu'il faut le remplir à ras bord. Pour la plupart des tâches, quelques milliers de tokens bien choisis produisent une réponse meilleure, plus rapide et moins coûteuse qu'un contexte pléthorique et mal ciblé. La bonne démarche consiste à fournir le contexte le plus concis possible qui contienne tout le nécessaire — ni plus, ni moins.

Enfin, tester sur ses propres cas. Les chiffres de fenêtre et les scores de benchmarks donnent une première idée, mais rien ne remplace une évaluation sur les documents et les questions qui comptent réellement pour vous. Un modèle peut exceller sur le test de l'aiguille tout en peinant sur votre tâche de synthèse spécifique, ou l'inverse. Mesurer sur son propre terrain reste la seule boussole fiable.

La question utile n'est pas « quelle est la plus grande fenêtre disponible ? » mais « quel est le contexte le plus concis qui contient tout ce dont le modèle a besoin pour bien répondre ? »

Une capacité qui continue de mûrir

Où en est-on aujourd'hui, et où va-t-on ? Le mouvement de fond est clair : les fenêtres de contexte s'agrandissent et, surtout, deviennent plus fiables. Les progrès sur les mécanismes d'attention efficaces — attentions creuses, compression du cache mémoire — rendent les contextes très longs de moins en moins coûteux à exploiter. Parallèlement, les protocoles d'évaluation s'affinent, ce qui pousse les concepteurs à combler l'écart entre contexte annoncé et contexte effectif.

Il serait imprudent de prédire un vainqueur définitif entre le contexte long et le RAG. Tout indique plutôt une convergence : des systèmes qui combinent une grande fenêtre de contexte avec une étape de récupération intelligente, chacun jouant son rôle. La récupération réduit le volume à traiter et garde la connaissance à jour ; le contexte long permet de raisonner finement sur ce qui a été récupéré. Les deux approches, longtemps présentées comme rivales, apparaissent de plus en plus comme complémentaires.

Ce qui restera vrai, en revanche, c'est la valeur de la compréhension. Un praticien qui sait ce qu'est un token, comment fonctionne l'attention, pourquoi le milieu du contexte est fragile et quand le RAG l'emporte, saura toujours faire de meilleurs choix qu'un utilisateur ébloui par le plus gros chiffre. Ces mécanismes ne sont pas la propriété d'un modèle particulier : ils forment le socle commun sur lequel se construira la prochaine génération de systèmes.

Ce qu'il faut retenir

Résumons le chemin parcouru. La fenêtre de contexte est la mémoire de travail d'un modèle de langage, mesurée en tokens — ces fragments de texte qui valent, en moyenne, trois quarts de mot. Sa croissance spectaculaire, jusqu'au million de tokens et au-delà, a ouvert des usages concrets : analyse de longs documents, raisonnement sur des bases de code entières, conversations prolongées et cohérentes, traitement de contenus audio et vidéo.

Mais cette puissance a deux faces. D'un côté, un coût qui croît de façon quadratique avec la longueur du contexte, ce qui invite à la parcimonie. De l'autre, une limite d'attention bien documentée — le phénomène du « perdu au milieu » — qui rappelle que disposer d'une grande fenêtre ne signifie pas l'exploiter uniformément. D'où la distinction essentielle entre contexte annoncé et contexte effectif, que seuls des tests sérieux permettent de démêler.

Enfin, le débat entre contexte long et RAG ne se tranche pas par un dogme, mais par le besoin : corpus fermé et cohérent pour le premier, base vaste et évolutive pour le second, et de plus en plus souvent une combinaison intelligente des deux. Le million de tokens n'est donc ni une baguette magique ni un simple argument marketing : c'est un outil puissant, dont la valeur se révèle pleinement à celui qui en comprend les mécanismes et les limites. C'est, au fond, tout l'objet de cette chronique — vous donner les clés pour lire l'IA en acteur informé, plutôt qu'en spectateur impressionné par un grand nombre.

Sources

Cet article s'appuie sur des sources publiques et vérifiables :

• Google, « Introducing Gemini 1.5, Google's next-generation AI model » (15 février 2024) — blog.google (fenêtre d'un million de tokens, capacités de traitement, récupération à 99 %).
• Nelson F. Liu et al., « Lost in the Middle: How Language Models Use Long Contexts » — arXiv 2307.03172 (courbe en U, biais de primauté et de récence).
• « Lost in the Middle: How Language Models Use Long Contexts », version publiée — ACL Anthology, TACL 2024.
• OpenAI Help Center, « What are tokens and how to count them? » — help.openai.com (définition du token, ratio caractères/mots).
• Zhuowan Li et al. / Google DeepMind, « Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach » — arXiv 2407.16833 (comparaison RAG vs contexte long, EMNLP 2024).
• Arize AI, « The Needle In a Haystack Test: Evaluating the Performance of LLM RAG Systems » — arize.com (test de Greg Kamradt, protocole).
• Anthropic, « Introducing the next generation of Claude » — anthropic.com (fenêtre de 200 000 tokens).