RAG : faire répondre l'IA depuis les documents, pas depuis sa mémoire

Un RAG ne réentraîne rien : il cherche les bons extraits dans les documents, puis laisse le modèle répondre avec eux. Comment ça marche, ce que ça règle et ce que ça ne règle pas.

22 octobre 2026 · lecture ~8 minragiaexplication

La plupart des modèles répondent de mémoire. Ils ont lu beaucoup de textes pendant leur entraînement, en ont tiré des régularités, et reformulent ce qu’ils « savent » — parfois avec assurance, et parfois à tort. Un RAG déplace la source : le modèle ne répond plus de mémoire, il part de documents fournis pour tenter de répondre à la question. Ce déplacement, technique en apparence, décide d’une bonne partie des usages sérieux de l’IA en entreprise.

00Le problème que le RAG résout

Un modèle seul bute sur trois choses, et ce sont exactement les trois qui comptent dans une PME.

• Il ne connaît pas les documents internes. Procédures, contrats, comptes-rendus, fiches produits, historique de tickets : rien de tout cela n’était dans son entraînement, et rien ne le sera jamais.
• Sa connaissance s’arrête à une date. Le barème publié le mois dernier, la nouvelle grille tarifaire, la note de service d’hier : le modèle les ignore.
• Il peut inventer avec aplomb. Une réponse fausse formulée avec assurance coûte plus cher qu’un « je ne sais pas », parce qu’elle ne se voit pas.

Le RAG attaque les trois d’un coup, sans réentraîner quoi que ce soit. Il transforme une question en recherche documentaire, puis confie au modèle la tâche la plus modeste et la plus utile : lire les extraits et répondre avec eux.

Un RAG ne rend pas l’IA plus intelligente : il lui donne juste les informations dont elle a réellement besoin.

01Trois temps, dont deux invisibles

Un RAG se décompose en trois étapes. La première se fait à froid, les deux autres à chaque question.

L’indexation prépare le corpus : on extrait le texte des fichiers, on le découpe en morceaux, on convertit chaque morceau en une suite de nombres (un vecteur), et on range tout cela dans un index interrogeable.

La recherche fait le chemin inverse : la question devient elle aussi un vecteur, et l’index renvoie les passages dont le sens est le plus proche.

La génération ne voit jamais la base documentaire. Elle reçoit une question et quelques extraits, et rédige à partir d’eux. C’est ce qui rend la réponse vérifiable : chaque affirmation peut renvoyer à un document précis.

02Le découpage décide de la qualité

Un document entier ne s’indexe pas utilement. Un PDF de quarante pages condensé en un seul vecteur ne ressemble plus à rien : sa « moyenne de sens » est trop vague pour être retrouvée par une question précise. On découpe donc en morceaux de quelques centaines de mots — assez longs pour porter une idée complète, assez courts pour rester spécifiques — avec un léger chevauchement pour ne pas couper une phrase en deux au mauvais endroit.

Ce réglage paraît anodin. En pratique, il explique une grande partie des RAG décevants : des morceaux trop gros noient l’information utile, des morceaux trop petits la morcellent. Il n’y a pas de valeur universelle, seulement des essais sur les documents réels.

03Retrouver le bon passage

La recherche vectorielle rapproche les formulations qui veulent dire la même chose sans partager un mot : « remboursement », « avoir » et « somme recréditée » se retrouvent ensemble. C’est sa force, et c’est aussi sa limite : elle peut manquer une référence exacte — un numéro d’article, un code produit, un nom propre — qu’une recherche par mots-clés aurait trouvée les yeux fermés.

La solution courante combine les deux.

La combinaison hybride — lexicale et vectorielle, suivie d’un réordonnancement des meilleurs candidats — est devenue le réglage par défaut des systèmes sérieux. Elle coûte un peu plus de calcul et évite les échecs les plus visibles.

04Répondre sans inventer

Les extraits retrouvés sont insérés dans une consigne, avec la question. Cette consigne fait une partie du travail : elle interdit au modèle de sortir du dossier, et l’oblige à signaler les documents qu’il utilise.

RÈGLES
- Répondre uniquement à partir des extraits fournis.
- Citer le document et la section pour chaque affirmation.
- Si les extraits ne contiennent pas la réponse, l'écrire explicitement.
- Ne pas compléter par des connaissances générales.

Une réponse qui cite ses sources change de nature : elle n’est plus une opinion de machine, elle est une lecture assistée d’un document que l’on peut ouvrir et vérifier. C’est souvent ce que demande un métier — pas de la magie, de la traçabilité.

05Ce que le RAG ne résout pas

L’honnêteté est nécessaire ici, parce que la promesse commerciale dépasse souvent la technique.

• Les questions d’agrégation. « Combien de litiges en 2025 ? », « quel est le total des factures impayées ? » : la réponse est dans une base de données, pas dans un document. Un RAG qui compte des extraits se trompe ou renonce ; il faut interroger la base.
• Les documents mal extraits. Tableaux à colonnes fusionnées, formulaires scannés, présentations pleines de zones de texte : l’information existe à l’écran et disparaît à l’indexation.
• La fraîcheur. Un index est un instantané. Sans mécanisme de mise à jour, il répond avec les documents d’il y a six mois, et sans le dire.
• Le coût et la latence. Chaque question envoie plusieurs extraits au modèle : plus de tokens en entrée, un aller-retour de recherche en plus. Négligeable sur dix documents, sensible sur un usage intensif.

06Par où commencer

L’ordre de mise en œuvre compte plus que le choix de l’outil.

1. Écrire trente questions réelles, avec la réponse attendue et le document qui la contient. C’est le jeu d’évaluation, et il se construit en une heure avec les utilisateurs. Sans lui, on ne saura jamais si le système s’améliore.
2. Restreindre le corpus. Cinquante documents utiles et à jour valent mieux que cinq mille documents douteux. On commence par un périmètre étroit qui marche.
3. Indexer simplement. Découpage classique, recherche hybride, cinq passages renvoyés. Mesurer combien de fois le bon document est dans ces cinq passages — le reste s’ajuste ensuite.
4. Interdire la réponse hors dossier, avec citations obligatoires.
5. Boucler. Chaque question ratée devient un test de non-régression. L’index et les consignes évoluent ; le jeu d’évaluation garantit qu’ils évoluent dans le bon sens.

Côté briques, rien d’exotique : un extracteur de texte, un modèle d’embedding, un index vectoriel, un modèle de génération. Les outils managés évitent d’assembler les quatre ; les solutions auto-hébergées gardent les documents sur place. Le choix se fait surtout sur une question de confidentialité — le même arbitrage que pour l’IA en local.

07RAG, fine-tuning ou contexte long ?

Trois réponses différentes à trois besoins différents, souvent confondus. Chacune apporte quelque chose de distinct : le RAG des connaissances sourcées, le fine-tuning un comportement, le contexte long la simplicité.

Les coûts ne sont pas de même nature : un index à maintenir pour le RAG, des données annotées et un entraînement pour le fine-tuning, des tokens envoyés à chaque appel pour le contexte long. Les risques non plus — corpus sale et permissions oubliées d’un côté, comportement figé et faits oubliés de l’autre, facture et latence qui grimpent pour le dernier.

Le fine-tuning n’apprend pas des faits de façon fiable : il ajuste une manière de répondre. Le contexte long suffit tant que le corpus tient dans une fenêtre et change peu. Le RAG reste la bonne réponse quand la connaissance est vaste, mouvante et doit être citée.

Récapitulatif

  DOCUMENTS      ──►      RECHERCHE      ──►      RÉPONSE
  découpés, indexés   les passages utiles   citée, vérifiable

À retenir : un RAG est un système de documentation avant d’être un système d’IA. Sa qualité vient du corpus, du découpage et du jeu d’évaluation — le modèle, lui, n’est que la dernière pièce.