Depuis l’arrivée des fenêtres de contexte à 200 000 tokens et au-delà, une question revient dans chaque projet IA : faut-il encore faire du RAG, ou suffit-il de tout mettre dans le prompt ? La réponse courte : ce n’est pas l’un contre l’autre. Ce sont deux outils qui répondent à des contraintes différentes — coût, latence, fraîcheur, taille du corpus — et le bon réflexe est de choisir selon ces contraintes, pas selon la mode.
Ce guide pose un cadre de décision clair, en s’appuyant sur des chiffres réels et sur notre propre retour d’expérience d’infrastructure : ce que le contexte long fait vraiment bien, là où il s’effondre, et comment combiner les deux.
Les deux approches en une phrase
- RAG (Retrieval-Augmented Generation) : on indexe le corpus, et à chaque question on récupère uniquement les passages pertinents que l’on injecte dans le prompt. Le modèle ne voit que ce dont il a besoin.
- Contexte long : on place l’intégralité des documents dans la fenêtre de contexte du modèle à chaque requête. Le modèle voit tout, et c’est à lui de retrouver l’information.
Le mythe de la fenêtre « illimitée »
Le principal argument contre le RAG, c’est : « les fenêtres font maintenant 200k, 1M tokens, donc on peut tout y mettre ». C’est vrai sur la fiche technique. Ça l’est beaucoup moins en pratique.
Sur nos propres bancs de test de contexte long, nous avons mesuré un écart systématique entre la fenêtre annoncée et la fenêtre réellement utilisable. La capacité du modèle à retrouver un fait précis enfoui au milieu d’un long document chute bien avant la limite affichée : la falaise apparaît souvent entre 100k et 120k tokens utiles, alors que la fiche annonce 262k. C’est le phénomène connu sous le nom de « lost in the middle » : l’information placée au centre d’un très long contexte est nettement moins bien restituée que celle placée au début ou à la fin.
Notre conclusion d’infrastructure a été nette : la mémoire (ce que l’on choisit de montrer au modèle) compte plus que l’architecture du modèle. Un système qui sélectionne intelligemment 4 000 tokens pertinents bat presque toujours un système qui en noie 120 000 dans l’espoir que le modèle trie.
Le vrai facteur décisif : le coût par requête
C’est là que tout se joue en production. Comparons une question posée sur une base documentaire de 100 000 tokens :
Le coût d’un LLM en production est dominé par les tokens d’entrée. Multiplier l’entrée par 25, c’est multiplier la facture d’inférence par un facteur du même ordre. À volume élevé, c’est la différence entre un service viable et un gouffre financier.
Latence, fraîcheur, traçabilité
Latence (TTFT)
Plus le prompt est long, plus le time-to-first-token augmente : le modèle doit lire tout le contexte avant de répondre. Un prompt de 100k tokens ajoute des secondes de pré-remplissage à chaque requête. Le RAG, en n’injectant que quelques milliers de tokens, garde une latence basse et stable.
Fraîcheur des données
Avec le RAG, mettre à jour la connaissance = ré-indexer un document. Avec le tout-en-contexte, il faut recharger l’intégralité du corpus à chaque évolution. Si vos données changent plus d’une fois par mois, le RAG est presque toujours le bon choix.
Traçabilité des sources
Le RAG sait d’où vient une réponse : le passage récupéré est la citation. Le tout-en-contexte rend la traçabilité plus floue — le modèle a « tout lu », difficile de pointer la source exacte. Pour un usage réglementé ou un besoin de vérifiabilité, c’est un argument décisif.
Tableau de décision
| Critère | RAG | Contexte long |
|---|---|---|
| Corpus volumineux / évolutif | ✅ Idéal | ❌ Coûteux, plafonné |
| Document unique tenant dans la fenêtre | ➖ Surdimensionné | ✅ Idéal |
| Coût à fort volume | ✅ Bas et stable | ❌ Élevé |
| Raisonnement global sur tout le texte | ➖ Fragmenté | ✅ Naturel |
| Sources vérifiables / citations | ✅ Natif | ➖ Flou |
| Latence (TTFT) | ✅ Basse | ❌ Croît avec la taille |
L’architecture qui gagne souvent : le RAG à large fenêtre
La meilleure réponse n’est généralement pas binaire. On utilise le RAG pour borner ce que le modèle voit (coût, latence, fraîcheur, citations), puis une fenêtre de contexte large pour raisonner sur plusieurs passages récupérés en même temps. Le RAG choisit 8 à 12 passages pertinents ; le contexte long permet de les synthétiser sans les fragmenter. On garde le meilleur des deux : un coût maîtrisé et une capacité de raisonnement multi-documents.
Notre position
Pour 80 % des cas de production — base de connaissances, support, recherche documentaire, corpus qui évolue — le RAG reste le choix par défaut, pour des raisons de coût, de latence et de traçabilité. Le contexte long brille sur le cas « un document, un raisonnement global, faible volume ». Et l’hybride bat souvent les deux. La vraie question n’est jamais « RAG ou contexte long ? » mais « quelles sont mes contraintes de coût, de fraîcheur et de volume ? ».
Pour aller plus loin : RAG en production, Fine-tuning vs RAG vs Prompt Engineering et comparatif des bases vectorielles.