RAG en entreprise : passer du POC à la production

La scène nous est racontée presque chaque mois. Une équipe présente un prototype d'assistant documentaire. On lui pose une question, il répond en quelques secondes en citant des documents internes. La salle est convaincue.

Puis six mois passent et rien n'a été déployé. Non pas parce que la technologie a déçu, mais parce que personne n'a su répondre à la question posée juste après la démonstration : est-ce qu'on peut s'en servir tous les jours sans vérifier derrière ?

Cet article explique où se situe réellement la difficulté, et dans quel ordre s'y prendre. Il est écrit pour être lisible que vous soyez développeur ou responsable métier.

D'abord, de quoi parle-t-on ?

On appelle ça un système RAG, pour Retrieval-Augmented Generation — littéralement « génération assistée par recherche ». Derrière le sigle, l'idée est très simple, et elle tient en deux temps.

Quand vous posez une question, le système commence par aller chercher les passages pertinents dans vos documents. Ensuite seulement, il rédige une réponse à partir de ce qu'il vient de trouver, en citant ses sources.

La comparaison qui parle le mieux est celle du documentaliste. Vous pouvez interroger quelqu'un qui répond de mémoire : il ira vite, sera souvent juste, et se trompera parfois avec assurance. Ou vous pouvez interroger quelqu'un qui va d'abord chercher le bon dossier, le pose sur la table et vous répond en pointant le paragraphe. C'est ce second comportement que l'on cherche à reproduire.

Tout l'enjeu tient alors dans une question : est-ce que le bon dossier a été trouvé ?

Ce qu'une démonstration prouve, et ce qu'elle ne prouve pas

Une démo réussie prouve que le système sait reformuler correctement un extrait de document. C'est acquis, et ce n'est pas là que se cachent les problèmes.

En revanche, elle ne dit presque jamais si le système tient dans ces situations, qui sont pourtant le quotidien :

• la question est mal formulée, approximative, ou utilise un mot maison ;
• l'information se trouve dans un document rare, ancien, ou qui en contredit un autre ;
• l'utilisateur doit vérifier la réponse sans relire l'ensemble du corpus ;
• la personne qui pose la question n'a pas le droit de consulter le document qui contient la réponse.

Une démonstration se joue toujours sur les questions faciles. L'usage réel, lui, commence par les questions difficiles.

Retenons surtout ceci : la qualité perçue dépend bien davantage de l'étape de recherche que du modèle qui rédige. Un excellent modèle appliqué au mauvais passage produit une réponse fausse, mais formulée avec aplomb. C'est le pire résultat possible, parce que rien ne signale l'erreur.

Le vrai travail : retrouver la bonne page

D'où une recommandation qui surprend souvent : on optimise la recherche d'abord, la rédaction ensuite.

Découper les documents, ou l'art de faire de bonnes fiches

Un système de ce type ne manipule pas des documents entiers, mais des fragments : des morceaux de quelques paragraphes, un peu comme des fiches de lecture. C'est ce que le jargon appelle le chunking. C'est le réglage le plus décisif d'un projet, et le plus souvent bâclé.

La méthode paresseuse consiste à couper tous les 500 mots, mécaniquement. Le résultat est prévisible : un tableau se retrouve coupé en deux, un article de règlement est séparé de son titre, une clause perd la phrase qui lui donnait son sens.

Un bon découpage suit la structure réelle du document — les sections, les articles, les en-têtes de tableau que l'on répète sur chaque fragment. Sur des textes réglementaires, le simple fait de conserver la référence de l'article dans chaque fiche transforme la qualité des citations.

Chercher par le sens et par les mots exacts

Il existe deux façons de chercher, et elles ne trouvent pas les mêmes choses.

La recherche par le sens rapproche les formulations proches : « congé parental » et « interruption de carrière pour enfant » se répondent, même sans mot commun. C'est puissant, et c'est ce que font les moteurs modernes.

La recherche par les mots exacts est l'approche classique : elle retrouve une chaîne précise. Moins élégante, mais irremplaçable dès qu'il s'agit d'une référence de contrat, d'un code produit, d'un numéro de dossier ou d'un acronyme interne — c'est-à-dire une bonne partie des questions posées en entreprise.

Combiner les deux, puis faire reclasser les résultats par un second modèle spécialisé, corrige la majorité des échecs. C'est, de loin, le meilleur rapport effort/résultat de tout le projet.

Et quand les liens comptent plus que les textes

Parfois, la réponse ne se trouve dans aucun document pris isolément : elle dépend des relations entre les éléments. Quelle filiale est concernée par quelle obligation ? Quel avenant modifie quel contrat ? Quelle version d'une procédure remplace la précédente ?

Dans ces cas, on ajoute une carte des liens entre entités — c'est ce qu'on appelle le Graph RAG. Ce n'est pas un choix par défaut : un tel graphe demande un vrai travail de modélisation et d'entretien. On ne le met en place que si le besoin de naviguer entre entités est réel.

Sans mesure, pas de mise en production

C'est le point qui sépare le plus nettement un prototype d'un outil exploitable, et c'est le plus souvent négligé.

Tant que la qualité s'évalue en essayant trois questions à la main, personne ne peut démontrer qu'une modification améliore les choses, ni s'apercevoir qu'une autre a dégradé le système. On avance à l'intuition.

Le minimum utile tient en trois éléments :

1. Une liste de questions de référence, rédigée avec les personnes qui utiliseront l'outil, en notant pour chacune le passage qui devrait être retrouvé. Cinquante questions bien choisies suffisent largement pour démarrer.
2. Une mesure de la recherche : le bon passage figure-t-il dans les résultats ? C'est vérifiable objectivement, sans avis humain.
3. Une mesure de la fidélité : chaque affirmation de la réponse est-elle réellement appuyée par un passage cité ?

Séparer les deux dernières mesures est essentiel pour comprendre d'où vient un problème. Si le bon passage n'est jamais retrouvé, changer de modèle de rédaction ne servira strictement à rien — et pourtant c'est le premier réflexe de beaucoup d'équipes.

Une règle simple, et un peu brutale : si vous ne pouvez pas démontrer qu'une modification améliore le système, vous ne pouvez pas la déployer.

Trois contraintes qui décident de l'architecture

Dans la finance, le secteur public ou la santé, trois sujets pèsent plus lourd que la performance.

Les droits d'accès s'appliquent à la recherche, pas à l'affichage. Filtrer la réponse à la fin est une fausse sécurité : le document a déjà été lu par le système. Les autorisations doivent intervenir au moment où l'on cherche, en tenant compte de l'identité de la personne qui pose la question. Concrètement, deux collègues posant la même question ne doivent pas obtenir la même réponse s'ils n'ont pas les mêmes droits.

La traçabilité conditionne l'adoption. Un professionnel n'accepte pas une réponse qu'il ne peut pas vérifier — et il a raison. Chaque affirmation doit renvoyer au document, à la page, à l'article. C'est ce qui rend l'outil utilisable au quotidien, et accessoirement auditable.

L'endroit où résident les données n'est souvent pas négociable. Cette contrainte détermine le choix entre un modèle hébergé en Europe, un déploiement en cloud privé ou un modèle ouvert installé chez vous. Elle se tranche au début du projet, parce qu'elle conditionne tout le reste.

Ce qui distingue les projets qui aboutissent

Les projets qui arrivent en production se ressemblent beaucoup :

• un périmètre documentaire volontairement étroit au départ, sur un usage où l'utilité saute aux yeux ;
• des utilisateurs métier impliqués dès la construction de la liste de questions, et pas seulement à la recette ;
• une interface qui affiche les sources aussi visiblement que la réponse ;
• un bouton pour signaler une mauvaise réponse, et surtout quelqu'un qui exploite ces signalements.

Ceux qui s'enlisent tentent généralement d'indexer l'ensemble du patrimoine documentaire dès le premier essai, sans jamais mesurer la qualité, en espérant que le prochain modèle réglera le problème.

Une trajectoire réaliste

Sur un périmètre bien délimité :

1. Choisir un usage précis, avec des utilisateurs identifiés et une perte de temps mesurable.
2. Construire la liste de questions de référence avant de construire le système.
3. Mettre en place la recherche combinée et mesurer si le bon passage remonte.
4. Ajouter la rédaction, avec obligation de citer ses sources.
5. Appliquer les droits d'accès et journaliser les usages.
6. Ouvrir à un groupe pilote, observer, corriger les documents et le découpage.
7. Élargir le périmètre progressivement.

L'intérêt de cette progression est qu'elle est mesurable à chaque étape. On peut arrêter, réorienter ou accélérer en connaissance de cause, sans avoir tout misé d'un coup.

---

Vous avez un prototype qui ne décolle pas, ou une masse de documents que vous aimeriez rendre réellement interrogeable ? Parlons-en — ou regardez comment nous avons traité des situations comparables dans nos cas clients.