RAG en 2026 : ce qui tient encore et ce qui a été remplacé

RAG en 2026 : la réponse directe

Le RAG n’est pas mort en 2026. Ce qui est mort, c’est sa version 2023 : un découpage mécanique en blocs de taille fixe, une recherche vectorielle unique sans filtre, et le pari qu’une fenêtre de contexte assez grande finirait par rendre la récupération inutile. Ce pari a échoué : en 2026, envoyer un corpus entier dans le prompt à chaque requête coûte, selon les architectures observées en mission, de 8 à 80 fois plus cher qu’une récupération ciblée, pour une precision souvent inférieure sur les corpus volumineux. La bonne question n’est donc plus « RAG ou contexte long ? » mais « quel volume de données, quel budget par requête et quelle latence mon usage tolère-t-il ? ». Le reste de cet article détaille ce qui a réellement été abandonné, ce qui tient encore, et la méthode que nous appliquons en mission pour trancher sur un projet client.

Ce qui a été abandonné depuis 2023

Trois pratiques qui définissaient le RAG de première génération ont perdu leur justification technique.

Le découpage mécanique à taille fixe

Couper un document tous les 500 tokens, sans tenir compte des titres, des paragraphes ou du sens, produisait des extraits tronqués au milieu d’une idée. Le modèle recevait alors une phrase sans sa conclusion, ou une conclusion sans sa prémisse. Le découpage sémantique, qui respecte la structure du document et ajuste la taille des blocs au contenu, a remplacé cette approche dans la quasi-totalité des projets récents que nous voyons passer.

La recherche vectorielle seule, sans filtre

La similarité cosinus entre deux embeddings ne dit rien de la fraîcheur d’un document, de son statut (brouillon ou validé) ni de sa source. Un système qui ne fait que « chercher ce qui ressemble » remonte parfois une version obsolète d’une politique interne parce qu’elle est linguistiquement proche de la question posée, ou pire, deux versions contradictoires d’un même document sans indiquer laquelle fait foi. La recherche hybride, qui combine similarité lexicale et vectorielle et ajoute des filtres de métadonnées (date, statut, périmètre), a rendu cette faiblesse gérable sans jamais la supprimer complètement. Le mot-clé exact reste souvent plus fiable que la proximité sémantique pour une référence de contrat, un numéro de norme ou un nom de produit : c’est précisément ce que la recherche purement vectorielle rate le plus souvent.

Le pari sur la fenêtre de contexte infinie

L’hypothèse selon laquelle des fenêtres de contexte d’un million de tokens rendraient le RAG inutile ne s’est pas vérifiée en production. Deux problèmes documentés l’expliquent. D’abord, le phénomène dit du « milieu perdu » : un modèle retrouve moins bien une information placée au centre d’un contexte très long qu’une information placée au début ou à la fin. Ensuite, le temps avant le premier token de réponse augmente fortement avec la taille du contexte envoyé, ce qui rend l’approche difficile à tenir dans une application interactive.

Ce qui tient encore, et pourquoi : le calcul de coût

Sur une base de connaissances de mille pages (environ 600 000 tokens) interrogée cent fois par jour, le calcul penche nettement en faveur d’une récupération ciblée plutôt que d’un envoi systématique du corpus entier. Le tableau ci-dessous résume l’ordre de grandeur observé selon plusieurs analyses d’architecture publiées en 2026.

Ce calcul change dès que le corpus est petit et stable : en dessous d’environ 25 000 tokens, avec un faible volume de requêtes, tout charger dans le contexte reste souvent plus simple à maintenir qu’un pipeline de récupération, pour un surcoût qui ne pèse pas encore sur le budget.

Contexte long et RAG : complémentaires, pas rivaux

La lecture la plus utile pour un projet d’entreprise en 2026 n’oppose pas les deux approches, elle les combine. Le RAG réduit d’abord le champ des candidats parmi des milliers ou des millions de documents ; la fenêtre de contexte longue permet ensuite d’envoyer au modèle plusieurs documents entiers, plutôt que des fragments isolés, une fois ce champ réduit à une dizaine d’éléments pertinents. C’est cette combinaison, et non le remplacement de l’un par l’autre, que l’on retrouve dans les architectures qui tiennent la charge en production.

RAG agentique : la vraie évolution de 2026

Le changement le plus concret ne porte pas sur l’algorithme de recherche, mais sur le moment où la décision de chercher est prise. Les architectures récentes ajoutent une étape de raisonnement avant la récupération elle-même, généralement organisée en quatre décisions successives.

1. Faut-il chercher ? Une question de culture générale ne justifie pas une requête vers la base documentaire ; une question sur une procédure interne, si.
2. Quoi chercher ? La question brute de l’utilisateur est reformulée en requête structurée, avec extraction des entités et des filtres pertinents (date, produit, périmètre).
3. Où et comment chercher ? Choix de la collection de documents et de la stratégie (recherche lexicale, vectorielle, ou les deux combinées et reclassées).
4. Générer la réponse. Le modèle reçoit un contexte réduit et déjà trié, ce qui limite le risque du « milieu perdu » évoqué plus haut.

Cette architecture coûte plus cher à construire qu’un pipeline RAG classique, parce qu’elle ajoute une décision avant chaque recherche. Elle se justifie quand le volume de requêtes et l’hétérogénéité des questions posées le justifient : en dessous d’un certain volume, elle ajoute de la complexité sans bénéfice mesurable.

Une brique complémentaire, souvent négligée dans les déploiements rapides, est le reclassement (reranking) : un second modèle, plus petit et moins coûteux que le modèle de génération, réordonne les extraits candidats avant de les transmettre au modèle principal. Sans cette étape, le système fait confiance au premier tri de la recherche vectorielle, qui privilégie la proximité sémantique globale et rate parfois l’extrait le plus pertinent pour la question précise posée. Ajouter un reclassement coûte quelques dizaines de millisecondes supplémentaires ; c’est un investissement mesurable dès que la précision des réponses conditionne la confiance des utilisateurs dans l’outil.

Méthode : choisir pour un projet de PME romande

Sur les projets que nous menons pour des PME et des startups suisses, la décision se prend en trois questions, dans cet ordre.

Un point mesuré systématiquement en mission : la fraîcheur de la source compte davantage que la sophistication du pipeline. Un système RAG connecté à une documentation qui n’a pas été resynchronisée depuis six mois répond avec la même assurance sur des informations obsolètes que sur des informations à jour. Aucune architecture de récupération ne corrige un problème de gouvernance documentaire en amont.

Avant de choisir une architecture, mesurez trois chiffres sur votre propre cas : le nombre de tokens que représente votre corpus actuel, le nombre de requêtes attendu par jour une fois l’outil déployé, et la fréquence à laquelle le contenu source change. Ces trois chiffres, mesurés avant d’écrire la moindre ligne de pipeline, évitent la majorité des choix d’architecture regrettés six mois plus tard : soit un RAG construit pour un corpus qui aurait tenu dans un simple prompt, soit l’inverse, un prompt complet qui devient intenable à mesure que la documentation grossit.

Quand le RAG n’est pas le bon choix

Trois situations où construire un pipeline de récupération ajoute du coût sans ajouter de valeur :

• Un corpus petit et stable (quelques dizaines de pages qui changent rarement) : le contexte complet, éventuellement mis en cache, est plus simple à maintenir.
• Un prototype ou un MVP destiné à valider un usage avant d’investir dans l’infrastructure : un pipeline de récupération ajouté trop tôt ralentit les itérations sans améliorer la validation du besoin.
• Un besoin de raisonnement sur l’intégralité d’un corpus plutôt que sur des extraits (par exemple résumer l’ensemble d’un rapport) : le RAG, qui ne renvoie que des fragments, est structurellement mal adapté à ce type de question.

Ce que nous observons en mission

Sur les projets d’intégration IA que nous livrons, la question du RAG arrive presque toujours trop tôt dans la conversation avec le client, avant que le volume réel de requêtes ou la taille du corpus ne soient connus. Notre méthode consiste à démarrer avec l’architecture la plus simple qui couvre le besoin, contexte complet quand c’est suffisant, puis à ajouter une couche de récupération seulement quand la mesure en production montre que c’est nécessaire. Cette approche progressive limite le risque de construire une infrastructure de recherche sophistiquée pour un usage qui n’en avait pas besoin. Vous pouvez consulter nos réalisations pour voir comment cette méthode s’applique à des cas concrets, ou lire notre article sur ce qui casse en premier quand un agent IA passe en production, qui détaille les points de rupture d’un système déjà en place.

Aller plus loin

Ce sujet fait partie du cluster Forward Deployed Engineer, où nous documentons ce que l’intégration d’IA en entreprise change concrètement au travail d’ingénierie. Retrouvez tous les articles du blog pour approfondir les sujets connexes.