La promesse tient en une phrase : connectez vos documents à un modèle de langage et obtenez des réponses précises, actualisées et sourcées. Elle n’est pas fausse, elle est incomplète.
Le RAG, pour Retrieval-Augmented Generation, est une architecture qui fait chercher un LLM (un grand modèle de langage) dans des sources externes avant qu’il produise sa réponse. Au lieu de s’appuyer seulement sur ce qu’il a appris pendant son entraînement, le modèle reçoit les passages jugés pertinents pour la question posée. Il peut donc répondre à partir de données internes, spécialisées ou mises à jour régulièrement, sans réentraînement complet. Trois traductions circulent en français : génération augmentée par récupération, génération à enrichissement contextuel et génération enrichie par récupération, les deux premières étant celles que retient l’encyclopédie francophone.
Source : Wikipedia FR, Génération à enrichissement contextuel, vérifié le 12 août 2026.
Le RAG ne rend pas un modèle fiable pour autant. Il déplace le problème vers la recherche d’information, et c’est là que tout se joue.
Ce que le RAG déplace : la mémoire du modèle contre les documents consultés
Un modèle de langage répond avec ce qu’il a absorbé pendant son entraînement, et cette connaissance reste figée à une date. Le RAG ouvre un second canal : au moment de la question, le système lit des documents et les transmet au modèle. AWS décrit ce procédé comme le « processus consistant à optimiser le résultat d’un grand modèle de langage » en lui faisant consulter « une base de connaissances fiable externe aux sources de données utilisées pour l’entraîner avant de générer une réponse », et souligne qu’il donne accès à « la base de connaissances interne d’une organisation » sans qu’il soit nécessaire de réentraîner le modèle.
Source : Amazon Web Services, Qu’est-ce que la génération à enrichissement contextuel (RAG) ?, vérifié le 12 août 2026.
Une procédure modifiée la semaine dernière n’existe pas pour le modèle : elle existe pour l’index. Pour corriger une information fausse, nous corrigeons un document, pas un modèle.
Le terme n’est pas neuf : il vient de l’article « Retrieval-augmented generation for knowledge-intensive NLP tasks », signé Patrick Lewis, Ethan Perez, Aleksandra Piktus et Fabio Petroni, publié aux actes de NeurIPS le 6 décembre 2020.
Source : NeurIPS 2020, Retrieval-augmented generation for knowledge-intensive NLP tasks, vérifié le 12 août 2026.
Ce déplacement change la nature du projet. Nous préférons considérer un RAG comme un système de recherche avant d’y voir un système de rédaction. Ce n’est pas d’abord un projet de génération de texte, c’est un projet de recherche d’information.
Comment un RAG répond, étape par étape
Le trajet d’une question dans un RAG tient en trois moments, et chacun peut ruiner les suivants.
Préparer et découper le corpus
Tout part des documents. Nous les découpons en segments courts, les chunks, transformés en vecteurs, les embeddings, pour que le moteur retrouve plus facilement les passages pertinents. Ce découpage décide de ce qui pourra être retrouvé, et de rien d’autre. Imaginez une notice dont la réponse tient dans une phrase qui commente un tableau : si le découpage sépare l’une de l’autre, le système peut ramener le tableau sans la phrase qui lui donne son sens. Aucune taille de segment ne vaut pour tous les corpus.
Retrouver les bons passages
La recherche vient ensuite, et elle prend plusieurs formes : lexicale sur les mots de la question, sémantique via les embeddings qui rapprochent deux formulations différentes du même sens, filtrée par métadonnées comme la date ou la version, ou hybride, c’est-à-dire plusieurs de ces méthodes fusionnées. Un système peut aussi interroger un graphe de connaissances, une base relationnelle ou une API métier. Une base vectorielle n’est donc pas la définition du RAG, c’est une solution fréquente. La nuance sépare ce qui se règle par un choix d’outil de ce qui se règle par un travail sur les documents.
Reclasser, puis rédiger
Les passages récupérés arrivent rarement dans le bon ordre. Le reranking les reclasse au regard de la question posée, et non de leur seule proximité statistique. Le modèle reçoit ce contexte et rédige à partir de lui, et de rien d’autre s’il est correctement tenu.
Le vrai point de fragilité n’est pas la rédaction, c’est la récupération
Pourquoi un RAG donne-t-il de mauvaises réponses ? Dans la plupart des cas, l’erreur est commise avant que le modèle n’écrive son premier mot. Sept ruptures se succèdent, et six précèdent la rédaction.
- Le bon document n’est pas indexé. Il dort dans une messagerie ou dans un format que la chaîne d’ingestion ne lit pas.
- Le document est mal découpé. Une règle se retrouve séparée de son exception, une procédure de ses prérequis.
- La question est mal interprétée. L’utilisateur emploie le mot du métier, la documentation celui du fournisseur.
- Les bons passages ne sont pas récupérés. Le système ramène du plausible, plus difficile à repérer qu’une absence de résultat.
- Les résultats pertinents sont mal classés. Ils ont été trouvés, mais ils arrivent trop bas et ne franchissent pas la fenêtre de contexte.
- Le contexte fourni est insuffisant ou contradictoire. La nouvelle version d’une procédure a été indexée, l’ancienne est restée : le système dispose de deux réponses exactes à deux dates différentes.
- Le modèle interprète mal des sources pourtant correctes. Un titre d’accroche lu au premier degré suffit à tirer une affirmation fausse d’un document juste.
S’y ajoute la question des droits : sans permissions appliquées à la récupération, le système peut répondre à partir d’un document que l’utilisateur n’aurait jamais dû consulter.
Nous ne disposons d’aucun chiffre public sur la part des projets qui échouent : ces sept points décrivent des mécanismes, pas une statistique.
Reste le plus dérangeant. Une réponse peut être parfaitement écrite et reposer sur le mauvais passage. Nous insistons sur ce point, parce qu’il change la façon de corriger un système : si vos réponses sont fausses, changer de modèle ne règle rien quand ce modèle a reçu le mauvais paragraphe. Le modèle rédige, la récupération décide de ce qu’il a le droit de lire.
RAG et fine-tuning ne répondent pas au même besoin
Faut-il un RAG ou un fine-tuning ? Les deux ne traitent pas le même manque. Le fine-tuning modifie des réflexes du modèle : son ton, son format de sortie, sa terminologie. Le RAG donne accès à une information qui bouge et qui devra rester juste demain matin. Un modèle affiné parlera comme votre entreprise, il ne connaîtra pas pour autant le tarif entré en vigueur hier. Ce n’est pas une alternative, c’est une combinaison. Nous détaillons ce que le fine-tuning modifie réellement dans un article dédié.
Le RAG supprime-t-il les hallucinations ?
Non, le RAG ne les supprime pas. Il en réduit certaines et il en rend d’autres possibles. En fournissant au modèle des passages pertinents et vérifiables, il diminue la part d’invention pure. Il ne protège plus dès qu’aucun document pertinent n’est récupéré, dès que le passage est ambigu, dès que deux sources se contredisent, ou dès que le modèle comble un vide avec ses connaissances internes. Un système doit pouvoir répondre que l’information ne figure pas dans sa documentation, et cette capacité se décide à la conception. Une source affichée rend une réponse vérifiable, elle ne la rend pas exacte : il arrive qu’elle ne soutienne que la moitié de la phrase qu’elle accompagne.
Évaluer un RAG, c’est évaluer deux choses séparément
Évaluer la seule réponse finale empêche de savoir si l’erreur vient de la recherche ou du modèle. France Num, le portail de l’État, présente le RAG comme « une technologie qui consiste à améliorer les réponses des modèles d’IA générative en les alimentant avec des connaissances issues des bases de données internes de l’entreprise » : l’entreprise et ses données sont dans la définition. La question métier précède donc la question technique. Pour quelle tâche, avec quelles données, pour quels utilisateurs, avec quel niveau de risque ? Cet aspect-là nous paraît essentiel : dix questions de démonstration réussies ne disent rien du comportement sur des milliers de questions réelles.
Source : France Num, Génération augmentée par récupération (RAG) : guide pour exploiter les données de sa TPE PME avec l’IA générative, vérifié le 12 août 2026.
La récupération : a-t-on retrouvé les bons passages ?
Cette mesure s’établit sans lire une seule réponse rédigée. Nous vérifions que le bon document remonte, que le bon passage est présent et que le classement place l’essentiel en tête. Un bon score ne dit rien sur un corpus incomplet : retrouver ce qui est indexé ne sert à rien si le document décisif manque.
La génération : la réponse dit-elle ce que disent les passages ?
L’autre mesure porte sur la fidélité au contexte fourni. Chaque affirmation est-elle soutenue par les passages ? Le modèle ajoute-t-il ce qui n’y figure pas ? Un système peut récupérer parfaitement et répondre de travers, et l’inverse se produit tout autant.
RAG simple, RAG avancé, RAG agentique : plus complexe ne veut pas dire meilleur
Le RAG initial, que le secteur appelle souvent RAG naïf, suit une séquence unique : une question, une recherche, quelques passages, une réponse. Les architectures avancées ajoutent des étapes : reformulation de la question, sous-requêtes multiples, recherche dans plusieurs index, fusion des classements, reranking, boucle de vérification. Le RAG agentique confie ces étapes à des composants distincts qui planifient, cherchent, rédigent, puis contrôlent.
L’étude IteraSim RAG (arXiv, 22 juillet 2026), un preprint non relu par les pairs, en donne un exemple récent. Son auteur désigne trois limites des systèmes existants : une requête unique et plate, une même stratégie de récupération appliquée à des demandes pourtant distinctes, un agent unique qui rédige puis relit sa propre production. Son architecture répond à chacune : un LLM développe la requête en variantes (physique, mots-clés de solveur, dépannage), Reciprocal Rank Fusion fusionne les listes obtenues, Maximal Marginal Relevance reclasse les candidats dans un index vectoriel HNSW, un routeur déterministe par mots-clés oriente les questions vers des parcours de récupération distincts, et la génération se répartit entre trois agents, Architect, InputWriter et Reviewer.
Source : arXiv (Cornell University), IteraSim RAG: A Multi-Stage Retrieval-Augmented Agentic Back-End for OpenFOAM-Based Computational Fluid Dynamics, vérifié le 12 août 2026.
Ce preprint porte sur la mécanique des fluides numérique, et nous le citons pour son architecture, pas pour ses scores : un benchmark de ce domaine ne dit rien d’un RAG documentaire d’entreprise. Chaque composant ajouté apporte du coût, de la latence, un point de défaillance supplémentaire et une évaluation plus lourde.
Les moteurs de réponse décomposent une question en plusieurs recherches avant de rédiger, comme le fait un RAG avancé. Le fonctionnement de chaque plateforme reste largement inconnu : ce rapprochement porte sur un mécanisme, pas sur une mesure. La visibilité dans un moteur génératif ne dépend donc pas seulement du modèle, mais de la façon dont le système cherche et classe ses sources : c’est le terrain d’un accompagnement GEO. Un bon RAG n’est pas celui qui répond à tout avec assurance, c’est celui qui retrouve les bonnes informations et reconnaît le moment où la réponse ne figure pas dans sa documentation.
