Non, le RAG n’est pas mort
Le RAG reste pertinent. Ce qui devient dépassé, c’est l’idée selon laquelle brancher une base vectorielle sur un LLM suffit à résoudre la question de la connaissance.
À chaque génération de modèles, la même question revient : faut-il encore construire des architectures RAG ? Trois contraintes imposent la réponse, et aucune n’est levée par une fenêtre de contexte plus large. Les paramètres d’un modèle sont figés à la fin de son entraînement, alors que la connaissance utile à une entreprise change chaque semaine. Cette connaissance est privée, donc absente des données d’entraînement. Et elle est soumise à des droits d’accès qui se vérifient au moment de la question, pas au moment de l’apprentissage. Tant qu’un système doit répondre à partir d’informations qu’il n’a pas apprises, il faut aller les chercher, filtrer ce que l’utilisateur a le droit de voir, et pouvoir rattacher la réponse à sa source.
Ce qui change, c’est le périmètre de la question. Retrouver les bons documents ne couvre qu’une partie de ce dont un agent a besoin pour décider. La question utile est devenue : quelles informations mettre à disposition du modèle, à quel moment et sous quelle forme, pour maximiser ses chances de prendre la bonne décision ?
C’est l’objet du Context Engineering. Dans la publication Effective context engineering for AI agents (septembre 2025), Anthropic le définit comme les stratégies de sélection et de maintien de l’ensemble optimal d’informations présentes pendant l’inférence. Le contexte y désigne bien plus que le prompt : instructions système, outils, données externes, historique des messages ou informations remontées via MCP (Model Context Protocol, le protocole ouvert publié par Anthropic pour relier un modèle à des outils et à des sources de données) en font partie.
Ce que le RAG résout, et ce qu’il laisse de côté
Une architecture RAG classique suit une logique simple :
Question → recherche → documents pertinents → contexte → LLM → réponse
Elle reste la bonne réponse chaque fois que l’information recherchée réunit trois propriétés : elle existe en dehors des paramètres du modèle, elle est trop volumineuse pour rester chargée en permanence, et elle évolue plus vite qu’un cycle d’entraînement. C’est le cas d’une base documentaire, d’un référentiel de procédures internes, d’un catalogue produits ou d’une base de connaissances support. Un conseiller assisté par un agent n’a pas besoin que le modèle « connaisse » la politique de remboursement : il a besoin que l’agent cite la version en vigueur, celle qui a été mise à jour la semaine dernière.
Le RAG répond donc à une question précise : quels documents faire entrer dans le contexte. Or un agent ne manipule pas que des documents.
Le contexte d’un agent dépasse les documents
Prenons un agent de service client chargé d’instruire une demande de remboursement. Le motif exprimé par le client et l’historique de la conversation lui disent ce qui est demandé et ce qui a déjà été dit. La fiche client et le contrat associé lui disent à qui il s’adresse et ce à quoi cette personne a droit. La procédure métier applicable lui dit ce qu’il est autorisé à faire, et l’appel à l’API de commande lui donne l’état réel du dossier, que ni le modèle ni la base documentaire ne peuvent produire. Restent la liste des outils dont il dispose et la trace des actions qu’il a déjà exécutées, sans laquelle il rembourse deux fois la même commande.
Ces éléments n’ont ni la même origine ni la même durée de vie : les instructions système valent pour toute la session, la fiche client pour toute la conversation, le résultat d’une API pour quelques secondes. Un seul d’entre eux relève de la recherche documentaire. Le problème d’architecture n’est donc plus de retrouver un document, mais d’orchestrer des sources hétérogènes dans une fenêtre partagée.
Plus de contexte n’est pas forcément mieux
Anthropic formule un principe directement opérationnel : chercher le plus petit ensemble possible de tokens à fort signal, celui qui maximise la probabilité d’obtenir le résultat attendu.
L’intuition inverse est fréquente : puisque la fenêtre de contexte le permet, autant tout envoyer. Elle se heurte au fonctionnement même des modèles. Anthropic décrit le contexte comme une ressource finie à rendement décroissant : dans une architecture transformer, chaque token peut se rapporter à tous les autres, ce qui produit n² relations pour n tokens et consomme un « budget d’attention » que chaque ajout entame. S’y ajoute un phénomène établi par les évaluations de type « aiguille dans une botte de foin », le context rot : plus le nombre de tokens présents dans la fenêtre augmente, plus la capacité du modèle à y retrouver précisément une information diminue.
Les effets pratiques suivent. Chaque token transmis se paie et allonge la latence, à chaque appel et à chaque étape de la boucle. Surtout, un contexte trop large introduit du bruit : si deux versions d’une même procédure y cohabitent, le modèle doit arbitrer entre des informations contradictoires sans disposer du critère qui permettrait de trancher. La taille maximale de la fenêtre n’est donc pas un objectif à atteindre, et c’est aussi l’un des postes qui pèsent le plus sur la facture d’un agent en production.
Du retrieval « au cas où » au retrieval « au bon moment »
Pour un agent qui exécute une tâche longue, tout charger au démarrage revient à payer dès la première étape un contexte dont l’essentiel ne servira jamais. Anthropic décrit une approche plus robuste, dite just in time : l’agent ne conserve que des identifiants légers, chemins de fichiers, requêtes enregistrées ou liens, et charge la donnée au moment où l’étape en cours la rend nécessaire. La même publication détaille trois compléments pour les tâches longues. La compaction résume une conversation arrivée près de la limite de la fenêtre, puis repart de ce résumé. La mémoire structurée fait écrire à l’agent des notes persistées hors du contexte, qu’il rappelle plus tard. Les architectures à sous-agents confient une tâche cadrée à des agents spécialisés travaillant dans une fenêtre propre, pendant qu’un agent principal conserve le plan d’ensemble.
Aucune de ces techniques ne supprime la recherche d’information : elle la déplace. Le système cherche toujours, mais il décide quand chercher au lieu de tout précharger. Le retrieval cesse d’être un prétraitement pour devenir une action que l’agent déclenche.
RAG ou Context Engineering ?
Les deux termes ne désignent pas des options concurrentes, mais deux niveaux différents. Le RAG est un mécanisme ; le Context Engineering est la discipline qui décide quand et comment l’employer.
| RAG | Context Engineering |
|---|---|
| Récupérer des informations externes | Construire le contexte global du modèle |
| Recherche documentaire | Instructions + outils + mémoire + données + historique |
| Répond à « quoi récupérer ? » | Répond à « quoi montrer au modèle maintenant ? » |
| Composant | Discipline d’architecture |
Cette filiation n’est pas nouvelle. Dès Building effective agents (décembre 2024), Anthropic décrivait la brique de base d’un agent comme un LLM augmenté de trois capacités : la recherche d’information, les outils et la mémoire. Le RAG n’en était déjà qu’une.
Une architecture de contexte à penser explicitement
En pratique, la discipline se ramène à un examen de chaque information susceptible d’être transmise au modèle. La première question est celle de la nécessité : si une donnée ne change pas la décision de l’agent, elle n’a rien à faire dans la fenêtre, quel que soit l’espace disponible. Vient ensuite celle du moment : une contrainte réglementaire doit être posée dès le départ, tandis que le détail d’une facture n’a de sens qu’à l’étape qui la traite.
Restent la forme et la durée de vie. Une même information ne coûte pas le même nombre de tokens et ne produit pas le même résultat selon qu’elle arrive en document brut, en résumé, en données structurées ou en sortie d’outil. Et une donnée utile à une étape n’a pas à peser sur toutes les suivantes : décider explicitement ce qui reste dans le contexte et ce qui en sort est précisément ce qui distingue une architecture d’une accumulation.
Ces arbitrages ne se devinent pas. Chaque choix de contexte est une hypothèse sur le comportement du modèle, et se vérifie comme telle, avec un dispositif d’évaluation capable de comparer deux versions. Ils pèsent aussi en amont sur le choix du modèle et de sa fenêtre de contexte, d’autant plus que les agents travaillent sur des horizons longs.
À retenir
Dans une application IA moderne, le contexte est une ressource à administrer. Le RAG y garde toute sa place, comme l’un des moyens d’y faire entrer une information que le modèle n’a pas apprise. Mais il ne répond plus seul à la question d’architecture, qui a changé de formulation.
La bonne question n’est plus « qu’est-ce que mon agent peut retrouver ? », mais « de quoi mon agent a-t-il réellement besoin, maintenant, pour prendre la bonne décision ? ».
