Le cycle se répète tous les quelques mois avec une ponctualité suspecte. Un laboratoire annonce une fenêtre de contexte plus grande, l’annonce devient une capture d’écran, et à la réunion suivante quelqu’un lâche la phrase : « donc on n’a plus besoin du RAG, on colle les documents entiers dans le prompt et c’est réglé ». Ça sonne comme une simplification, et c’est exactement ce que tout le monde veut entendre à propos d’une architecture qui a coûté des mois. C’est aussi le genre de simplification qu’on paie trois fois : en précision, en facture, et la nuit où quelque chose répond mal sans que personne sache pourquoi.
La thèse en une ligne : « grande fenêtre de contexte ou RAG » n’est pas une alternative, parce que les deux ne résolvent pas le même problème. La fenêtre de contexte est une mesure de capacité — ce qui tient dans un appel. La recherche est une décision de sélection — ce qui entre, parmi tout ce qu’on a. Augmenter la première ne répond pas à la seconde. Et quand on renonce à décider ce qui entre, la suite est mesurée : la précision chute bien avant la limite annoncée, le coût par appel grimpe tarif en main, et la panne cesse d’être débogable parce qu’on ne sait plus quel fragment le modèle a utilisé.
Il ne s’agit pas de défendre une architecture par affection. Il existe des cas — ils sont à la fin, nommés — où la grande fenêtre est effectivement la bonne réponse et où monter de la recherche serait du sur-ingénierie. Il s’agit de trancher pour les vraies raisons, pas pour le titre d’un lancement.
Grande fenêtre de contexte ou RAG : ce n’est pas deux fois la même question
La confusion a une racine précise : les deux finissent au même endroit — du texte devant le modèle au moment de répondre — et paraissent donc interchangeables. Elles ne le sont pas. La fenêtre de contexte est l’espace de travail de cet appel : on la remplit, on l’utilise, on la vide. La recherche est le mécanisme qui choisit, dans un corpus qui ne tient pas et ne tiendra jamais, les fragments qui méritent d’occuper cet espace. L’une est la taille de la table ; l’autre décide quels papiers on pose dessus.
La taxonomie complète — contexte de la conversation, connaissance consultable et mémoire à long terme, où vit chaque couche et ce qu’elle coûte — est déjà écrite dans le guide sur la mémoire d’un agent IA, et la réargumenter ici n’aurait aucun intérêt. Ce que ce guide ne couvre pas, parce que ce n’est pas sa question, c’est celle-ci : que se passe-t-il exactement quand le marché vous offre plus de table et que vous décidez que ça vous économise celui qui choisit les papiers.
Ce qui casse en premier, ce n’est pas la limite : c’est la précision
La partie contre-intuitive, c’est que le problème apparaît bien avant de remplir la fenêtre. Un modèle annonçant un million de tokens ne tient pas sa qualité jusqu’au token 999 999 pour tomber ensuite d’une falaise : il se dégrade progressivement, et assez tôt. Le benchmark NoLiMa l’a mesuré avec un protocole qui évite le raccourci des anciens tests « aiguille dans une botte de foin » — dans NoLiMa, la question et le fragment pertinent partagent presque aucun mot, donc le modèle ne peut pas le trouver par correspondance littérale et doit inférer l’association, ce qu’on lui demande précisément en production.
Les résultats : GPT-4o partait de 99,3 % en contexte court et descendait à 69,7 % à 32K tokens et à 56 % à 128K. Et ce n’était pas un cas isolé : à 32K, 11 des 13 modèles évalués tombaient à la moitié ou moins de leur propre référence en contexte court. Source : NoLiMa: Long-Context Evaluation Beyond Literal Matching, Modarressi et al., arXiv, février 2025.
À cela s’ajoute un effet de position documenté plus tôt et de façon indépendante : la précision dépend de l’endroit où se trouve l’information dans le contexte. L’article qui a inventé le terme décrit une courbe en U — le modèle récupère correctement ce qui est au début et à la fin, et échoue sur ce qui reste au milieu. Source : Lost in the Middle: How Language Models Use Long Contexts, Liu et al., Transactions of the ACL, 2024.
Ensemble, les deux effets décrivent le vrai mode de panne de la stratégie « on met tout ». Le modèle ne refuse pas de répondre : il répond avec aplomb en utilisant ce qu’il a trouvé, qui n’est pas nécessairement ce qui comptait. La réponse arrive bien écrite, bien structurée et mal fondée. C’est le pire type d’erreur pour un système d’entreprise, parce qu’on ne la distingue pas d’une bonne réponse sans aller vérifier à la main.
| Ce que dit l’annonce | Ce que mesure le benchmark | Ce que ça implique pour votre système |
|---|---|---|
| « Fenêtre d’1M de tokens » | La dégradation commence bien en dessous de ce chiffre | La limite annoncée est une capacité d’entrée, pas une garantie de qualité |
| « Toute votre documentation tient » | À 32K, 11 modèles sur 13 tombent à ≤50 % de leur base (NoLiMa, 2025) | Tenir n’est pas être utilisé |
| « Le modèle trouve ce qu’il lui faut » | Ce qui est au milieu du contexte est moins bien récupéré (Liu et al., 2024) | L’ordre d’empilement des documents devient une variable cachée |
| « Vous économisez la recherche » | Les benchmarks ne mesurent ni la facture ni la traçabilité | L’ingénierie économisée devient un coût récurrent et de l’opacité |
Le fournisseur qui vous vend le million de tokens vous le facture au double
Ici, pas besoin d’argumenter : il suffit de lire le tarif de celui qui vend la grande fenêtre. Dans la liste de prix publique de l’API Gemini, deux modèles ont leur prix scindé par longueur de prompt, avec la coupure à exactement 200 000 tokens. Sur Gemini 3.1 Pro Preview, tarif standard, l’entrée passe de 2,00 à 4,00 dollars par million de tokens au franchissement du seuil, et la sortie de 12,00 à 18,00. Sur Gemini 2.5 Pro, de 1,25 à 2,50 en entrée et de 10,00 à 15,00 en sortie. Le cache de contexte double aussi. Source : Gemini Developer API pricing, Google, consultée le 4 octobre 2026.
Ce qui compte n’est pas le montant, qui changera. C’est la forme du tarif : le fournisseur qui vous offre l’énorme fenêtre a décidé de vous facturer le double pour l’utiliser vraiment. C’est une déclaration sur le coût réel de servir ces prompts, écrite par celui qui le paie. Quand on vous présente « grande fenêtre de contexte ou RAG » comme si la première option était la gratuite, on ignore que le fabricant lui-même l’a tarifée comme un produit différent et plus cher.
Et c’est l’effet cumulé qui déséquilibre les budgets. La recherche concentre la dépense sur la construction et la maintenance d’un index : un coût qui existe une fois et s’amortit sur toutes les requêtes. Tout mettre dans le prompt déplace cette dépense du côté variable, où elle se multiplie par chaque appel, chaque jour, pour toujours. Un pilote à deux cents requêtes par mois ne le remarque pas. Le même système ouvert à trois cents personnes, si. L’arithmétique est ennuyeuse, et c’est pour ça que personne ne la fait avant la réunion : multipliez vos tokens d’entrée par votre volume attendu et comparez au coût d’un index. Le guide sur le modèle à utiliser dans un agent couvre les autres axes de cette décision, parce que la taille de fenêtre est une spécification parmi plusieurs et presque jamais celle qui tranche.
La panne que vous ne pouvez pas déboguer
C’est l’argument qui n’apparaît dans aucun benchmark et qui coûte le plus cher en exploitation. Avec de la recherche, quand une réponse sort mal, on a une trace : on sait quels fragments ont été récupérés, avec quelle requête, avec quel score. Le diagnostic se réduit à deux questions qui ont une réponse — le bon fragment était-il dans l’index ? la recherche l’a-t-elle remonté ? — et chacune pointe vers un correctif différent : réingérer la source, ou ajuster la recherche.
Sans recherche, pas de trace, parce qu’il n’y a pas eu de sélection à enregistrer. On a passé deux cent mille tokens et le modèle a utilisé ce qu’il a utilisé. Impossible de savoir sur quoi il s’est appuyé, impossible de reproduire le chemin, impossible de corriger par une intervention ciblée : le seul levier est de réordonner les documents et de réessayer, c’est-à-dire déboguer par superstition. Dans un système interne tolérant, c’est une gêne. Dans un système qui répond à des clients ou alimente une décision, c’est la différence entre un incident qu’on clôt et un incident qui reste ouvert.
Quand la grande fenêtre est bien la bonne réponse
Monter de la recherche sur un corpus qui n’en a pas besoin est l’autre façon de se tromper, et elle est plus fréquente qu’on ne croit. Trois situations où la grande fenêtre gagne nettement :
- Le corpus est petit et stable. Si tout ce que le système doit consulter tient largement sous le seuil où le modèle se dégrade, et ne change pas chaque semaine, un index est une infrastructure à maintenir pour ne rien gagner.
- La preuve est répartie dans tout le document. Quand la tâche est de synthétiser, de comparer des sections ou de détecter des contradictions sur un texte long, la recherche travaille contre vous : découper, c’est précisément ce qui détruit la relation entre les parties. Ici, le contexte long n’est pas un luxe, c’est l’exigence.
- C’est une analyse ponctuelle, pas un système. Un contrat, un rapport, un export de données analysé une fois. Personne ne devrait monter une chaîne d’ingestion pour une question posée une seule fois.
La lecture honnête de la littérature récente, c’est que le cadrage binaire est dépassé des deux côtés : le contexte long rend mieux quand la preuve est distribuée, et la recherche rend mieux quand la preuve est rare et qu’il faut la trouver. L’architecture qui gagne ne choisit pas : elle recherche pour réduire l’univers au plausible, puis utilise la longue fenêtre pour raisonner sur cet ensemble déjà réduit. La recherche cesse d’être un filtre de précision chirurgicale et devient un réducteur de bruit, ce qui détend nettement les exigences sur votre index.
Le test de deux minutes avant de rien jeter
Si quelqu’un dans votre équipe propose de retirer la recherche parce qu’un modèle est sorti avec plus de contexte, ces quatre questions règlent la conversation sans réunion de suivi :
- Combien de tokens fait le corpus complet, aujourd’hui et dans douze mois ? Si la réponse à douze mois franchit le seuil où le modèle se dégrade — et il est très en dessous de la limite annoncée —, la fenêtre n’est pas une solution, c’est un sursis.
- Combien coûterait le volume réel de requêtes au tarif prompt long ? Avec le prix scindé à 200K tokens, le calcul tient sur une feuille. Faites-le au volume visé, pas à celui du pilote.
- La preuve typique est à un endroit ou répartie ? Ponctuelle et localisée : recherche. Distribuée dans tout le document : contexte long. Les deux selon la question : hybride, et c’est la réponse la plus fréquente.
- Que répondez-vous quand un client demande d’où vient cette phrase ? Si la réponse doit être vérifiable, il faut la trace de ce qui est entré. Seule la sélection la donne.
Aucune des quatre ne se règle avec la taille de la fenêtre, et c’était précisément le point à démontrer.
Ce que ça change à l’exploitation
Il y a une raison moins technique au succès de la proposition de jeter le RAG, et il faut la nommer : ce n’est pas que la grande fenêtre soit meilleure, c’est que maintenir un index est un travail continu et que personne n’a envie de le faire. La connaissance vieillit, les sources changent, les documents sont remplacés, et si personne ne réingère ni n’invalide le périmé, le système commence à répondre avec la version de l’an dernier. C’est la vraie faille qu’exploite l’argument du contexte infini : il promet de se débarrasser d’une fonction d’exploitation, pas d’un logiciel.
Le problème, c’est que la fonction ne disparaît pas, elle devient invisible. Si vous collez les documents entiers dans le prompt, il faut toujours que ces documents soient les documents en vigueur — sauf que vous n’avez plus ni index ni pipeline où le vérifier. C’est pourquoi la fraîcheur de la base de connaissance est une fonction continue qu’on exploite, pas un projet qu’on clôt : le rafraîchissement par source, l’invalidation du périmé et le responsable de chaque décision éditoriale existent de toute façon, avec ou sans RAG.
Et si le débat réellement ouvert chez vous n’est pas celui-ci mais l’autre — faut-il réentraîner le modèle sur vos données —, il est tranché ailleurs et avec la même logique : la recherche l’emporte presque toujours sur le fine-tuning, par le coût et par la capacité de mettre à jour sans réentraîner. Les trois conversations — fenêtre, recherche et entraînement — se mélangent dans les mêmes réunions, et il vaut mieux les tenir séparées, parce qu’une seule change quand un nouveau modèle sort.
La conclusion opérationnelle est courte. Plus de contexte est une bonne nouvelle : ça permet de passer plus de preuve pertinente par appel et ça détend la précision exigée de votre recherche. Ce que ça ne fait pas, c’est décider ce qui est pertinent. Ce travail, quelqu’un le fait encore — un index, une requête, une politique — ou personne ne le fait, et alors ce qu’on a n’est pas une architecture plus simple : c’est la même complexité, sans registre et au tarif double.