Fenêtre de contexte à 1 million de tokens : fiabilité réelle et méthode de test

La promesse du million de tokens et son angle mort

Depuis l'arrivée de Gemini 1.5 en 2024, la course à la fenêtre de contexte s'est accélérée. Les systèmes à contexte long ont rapidement atteint des fenêtres annoncées de plusieurs centaines de milliers à plusieurs millions de tokens, avec des évaluations Google allant jusqu'à 10 millions de tokens sur des tâches de récupération. En 2026, six modèles frontières revendiquent désormais une fenêtre d'1 million de tokens ou plus : Claude Opus 4.8, GPT-5.5, et DeepSeek V4 sit at 1 million, le palier où se concentre l'essentiel du travail réel, tandis que Llama 4 Scout annonce 10 millions de tokens, et Gemini et Grok proposent 2 millions en production.

Le problème n'est pas la taille annoncée, c'est l'écart entre ce que le fournisseur vend et ce que le modèle exploite réellement. L'API accepte dix millions de tokens sans jamais renvoyer d'erreur, et facture chaque token — mais rien ne garantit que le modèle attend réellement l'information enfouie loin dans le prompt. Pour une équipe data qui envisage de simplifier son architecture en remplaçant un pipeline de retrieval augmenté (RAG) par un unique appel à contexte long, cette distinction est la question centrale, bien avant celle du coût ou de la latence.

Ce que mesurent réellement les benchmarks 2026

Le benchmark historique, le Needle in a Haystack (NIAH) conçu par Greg Kamradt, consiste à injecter un fait isolé dans un long contexte et à demander au modèle de le retrouver. Il a longtemps servi de preuve marketing, mais il est aujourd'hui jugé insuffisant par la recherche : ce test de récupération lexicale simple est souvent utilisé pour généraliser abusivement la capacité d'un modèle à gérer un contexte long de façon fiable. Deux évolutions ont changé la donne en 2026 :

• Le benchmark RULER de NVIDIA, qui combine plusieurs tâches de récupération et de raisonnement. Rapporté via Iternal en mars 2026, il montre que les modèles n'exploitent de façon fiable que 50 à 65 % de leur fenêtre annoncée. Concrètement, un modèle annoncé à 1 million de tokens se comporte plutôt comme un modèle à 500 000-650 000 tokens quand on mesure le rappel réel.
• MRCR v2, un test de récupération multi-faits plus exigeant. Les écarts entre modèles y sont considérables : à un million de tokens, Claude Opus 4.6 conserve environ 76 %, GPT-5.4 et Gemini 3.1 Pro chutent sous les 50 %, et Llama 4 Scout, malgré ses 10 millions de tokens annoncés, ne score plus qu'environ 15 %.

Les classements publiés début 2026 confirment cette hiérarchie : Claude Opus 4.6 atteint 76,0 % à 1M, Gemini 3.1 Pro chute à 26,3 % malgré un bon score à 128K (84,9 %), et GPT-5.5 progresse à 74,0 %, soit un bond de 37 points par rapport à GPT-5.2. Un autre test, NoLiMa, qui évite les correspondances lexicales directes entre la question et le passage à retrouver, est encore plus sévère : dès 32 000 tokens, la plupart des modèles tombent sous 50 % de leur performance de référence en contexte court, et GPT-4.1, qui revendique 1 million de tokens de contexte, n'a qu'une capacité effective de 16 000 tokens sur ce test.

Le constat de synthèse le plus utile vient d'une analyse datée de mars 2026 : empiler un million de tokens dans une fenêtre relève de l'ingénierie ; faire en sorte que le modèle utilise réellement ce qui se trouve enfoui au token 600 000 relève de la science.

Trois mécanismes de perte d'information à connaître

La dégradation en fonction de la position (lost in the middle)

Les informations placées au milieu d'un long document sont statistiquement moins bien récupérées que celles situées au début ou à la fin. Une analyse appliquée à des cas d'usage RAG résume l'ordre de grandeur à anticiper : il faut prévoir une dégradation de précision de 5 à 15 % lorsque l'information critique se trouve dans la moitié centrale du contexte. Le même travail souligne un point souvent négligé par les équipes qui misent tout sur la taille de contexte : un contexte de 8 000 tokens contenant uniquement des passages pertinents surpasse un contexte de 64 000 tokens contenant tout le document.

La multiplication des faits à retrouver

Un document métier contient rarement une seule information isolée à extraire : il faut souvent croiser plusieurs éléments répartis dans le texte. Les premiers travaux sur le sujet montrent que ce cas est beaucoup plus fragile que la recherche d'un seul fait : l'effet de dégradation apparaît dès environ 25 000 tokens dans le cas multi-faits, contre environ 73 000 tokens pour un seul fait chez GPT-4. Plus récemment, les benchmarks 2026 confirment l'ampleur du phénomène à plus grande échelle : les données RULER et MRCR v2 du début 2026 montrent que les modèles frontières perdent 30 à 60 points de précision sur la récupération multi-faits au-delà de 200 000 tokens, même lorsqu'ils annoncent une fenêtre d'1 million de tokens. Le même travail est catégorique sur le cas général : pour la récupération multi-faits au-delà de 200 000 tokens, tous les modèles frontières de 2026 se dégradent de façon mesurable.

Le bruit et la similarité sémantique entre la question et le document

Un document d'entreprise n'est pas un texte neutre comme les essais utilisés dans les premiers NIAH : il contient du bruit, des répétitions, des formulations proches mais non identiques à la question posée. Les travaux récents sur l'extension du test NIAH montrent que la similarité entre le fait recherché et la question augmente le taux de dégradation de performance lorsqu'elle est faible, et qu'une plus forte proportion de bruit dans un contexte long a un effet documenté : dans un contexte long avec un taux de bruit supérieur à 97 %, les hallucinations augmentent fortement, un effet amplifié chez les modèles de plus petite taille.

Méthode de test avant de remplacer un pipeline RAG

Ces résultats disqualifient toute décision architecturale fondée sur la seule fiche technique d'un fournisseur. Avant d'envisager de simplifier un pipeline RAG au profit d'un contexte long, une équipe data devrait construire son propre protocole, calqué sur les méthodologies académiques mais appliqué à ses propres documents :

1. Construire un jeu de "needles" métier, pas génériques. Insérer dans vos vrais documents (contrats, rapports, tickets support) des faits représentatifs de vos requêtes réelles, formulés de façon proche ou éloignée lexicalement de la question — c'est la logique du test NoLiMa, plus exigeante que le NIAH classique.
2. Tester plusieurs profondeurs et plusieurs longueurs de contexte. Faire varier la position du fait recherché (début, milieu, fin) et la longueur totale du document, par paliers allant de 10 000 à la limite annoncée du modèle, pour repérer le point de rupture propre à votre cas d'usage plutôt que de se fier à une moyenne publique.
3. Passer au multi-faits dès que c'est pertinent. La plupart des usages métier (synthèse de dossier, comparaison de clauses, audit de conformité) exigent de croiser plusieurs informations dispersées. Les scores à un seul fait masquent une dégradation bien plus sévère sur ce type de tâche.
4. Mesurer, pas seulement la présence, mais le raisonnement. Demander au modèle de combiner les faits retrouvés plutôt que de les restituer tels quels : la récupération et le raisonnement se dégradent tous deux à mesure que le contexte s'allonge, mais le raisonnement accuse un retard supplémentaire par rapport à la simple récupération.
5. Comparer contexte long et RAG à coût et périmètre égal. Faire tourner le même jeu de questions sur votre pipeline RAG existant et sur un appel à contexte long intégral, en mesurant précision, coût par requête et latence. Le gain d'un contexte long n'a de sens que s'il dépasse la perte de précision mesurée.

Ce protocole rejoint les conclusions des équipes de recherche qui ont formalisé des cadres comparatifs entre RAG et contexte long : des benchmarks unifiés intégrant des variations réalistes — multi-faits, fragmentation, bruit — permettent une analyse approfondie de la performance, de la robustesse et des modes de défaillance des systèmes de récupération de connaissances, une rigueur indispensable avant toute décision de bascule en production.

Garder, adapter ou remplacer : une décision par cas d'usage

Les chiffres disponibles en 2026 ne justifient pas un remplacement généralisé du RAG par le contexte long, mais ils ne justifient pas non plus un statu quo automatique. Trois situations se distinguent :

• Documents courts à moyens (jusqu'à 100-150 000 tokens), faits peu nombreux : le contexte long des meilleurs modèles actuels offre un rapport simplicité/fiabilité favorable, à condition de valider le placement des informations critiques.
• Corpus volumineux, requêtes multi-faits ou comparatives : le RAG reste préférable, car il réduit mécaniquement le bruit soumis au modèle et limite l'effet de dilution documenté par les benchmarks 2026.
• Architectures hybrides : un retrieval grossier suivi d'un contexte long sur les passages sélectionnés permet souvent de combiner la robustesse du filtrage et la richesse contextuelle, une piste que nous explorons avec les équipes data dans le cadre de nos missions de conseil en architecture IA.

Dans tous les cas, la décision doit reposer sur un test mesuré sur vos propres documents et vos propres questions, pas sur un score moyen publié par un fournisseur ou un benchmark académique généraliste. C'est également l'objet des formations que nous proposons aux équipes techniques souhaitant industrialiser ce type d'évaluation ; retrouvez le détail sur notre page offre.

Ce qu'il faut retenir avant la prochaine itération de contexte

La taille de la fenêtre de contexte continuera de croître en 2026 et au-delà, mais l'écart entre capacité annoncée et capacité effective restera un paramètre à mesurer, pas à supposer. Les benchmarks RULER, MRCR v2 et NoLiMa donnent un ordre de grandeur utile pour arbitrer en première approche, mais seule une évaluation construite sur vos propres documents métier permet de décider sereinement de simplifier — ou non — un pipeline RAG existant. Le risque n'est pas technique, il est organisationnel : une mauvaise décision d'architecture sur ce sujet se traduit directement par des réponses incomplètes ou erronées livrées à des décideurs qui, eux, considèrent la réponse du modèle comme fiable par défaut.