RAG en entreprise : comment interroger ses documents internes avec l'IA ?

RAG signifie retrieval-augmented generation, en français génération augmentée par récupération. Le système cherche d'abord, dans vos documents, les passages qui répondent à la question posée. Il demande ensuite à un modèle de langage de rédiger la réponse à partir de ces seuls passages, en indiquant d'où vient chaque information.

Le terme apparaît dans un article de recherche publié en 2020, qui associait un modèle capable de rédiger du texte à un index de documents consultable. L'objectif : s'appuyer sur une source de connaissances que l'on peut mettre à jour, plutôt que sur la seule mémoire du modèle, et montrer sur quoi repose une réponse.

En entreprise, cela donne un assistant à qui l'on pose une question en langage courant, comme « Quel est le délai de préavis dans le contrat de ce fournisseur ? » ou « Que faire quand un client retourne un produit abîmé ? ». La réponse arrive avec un lien vers le paragraphe qui la justifie.

Un grand modèle de langage, ou LLM, est un programme entraîné sur de très grandes quantités de textes généralistes pour produire du texte. Il n'a jamais lu vos contrats, vos procédures ni vos fiches produits, et ce qu'il sait est figé à la date de son entraînement. Le guide de la DGE consacré au RAG fait le même constat.

Interrogé sur votre entreprise, un modèle seul ne s'arrête pas toujours pour dire qu'il ne sait pas. Il peut produire la réponse la plus plausible, bien rédigée et fausse. On parle d'hallucination. Le risque est plus grand sur ce qui est propre à votre activité : un nom de produit interne, une clause particulière, une règle maison.

Copier un document dans une conversation avec un assistant d'IA dépanne pour un fichier isolé. Cela ne marche plus pour toute la documentation d'une entreprise, qui évolue sans cesse et existe souvent en plusieurs versions. Le RAG règle ce problème d'échelle : à chaque question, il sélectionne les quelques passages utiles et ne transmet qu'eux au modèle.

Un système RAG travaille en deux moments. Une préparation, faite une première fois puis à chaque document ajouté ou modifié : collecte, découpage, indexation. Puis une réponse, à chaque question : recherche, puis rédaction sourcée. Le modèle de langage n'est pas réentraîné sur vos documents, il les consulte au moment de répondre. Un document corrigé ou retiré est donc pris en compte dès que la base est mise à jour.

Un système RAG répond à partir de ce qu'il trouve. Si la procédure indexée est périmée, la réponse sera périmée, avec une source à l'appui. La citation donne confiance, mais elle prouve seulement que l'information vient d'un document, pas que ce document est juste. C'est pourquoi le tri documentaire passe avant le choix des outils.

Quand deux versions d'une procédure se contredisent, le système peut s'appuyer sur l'une ou l'autre selon la formulation de la question. Deux collaborateurs obtiennent alors deux réponses à la même question, et cessent vite de faire confiance à l'outil. Le guide de la DGE recommande de supprimer les doublons et les documents contradictoires avant l'indexation.

Ce tri est un travail métier, pas informatique : seule une personne qui connaît le sujet sait quelle version fait foi. Il n'est pas perdu pour autant, car une documentation rangée, datée et sans doublon sert aussi à ceux qui cherchent encore à la main.

Un assistant documentaire qui ignore les droits d'accès devient un moyen de les contourner. Une question sur les salaires, un contrat confidentiel ou un dossier du personnel ne doit faire ressortir que ce que la personne pouvait déjà ouvrir. Un outil qui ne garantit pas cela ne peut pas être ouvert à toute l'entreprise.

Le filtrage se fait au moment de la recherche, avant que les passages n'atteignent le modèle. Demander au modèle de « ne pas révéler » une information ne suffit pas : s'il l'a reçue, elle peut ressortir dans une réponse. Le projet de l'OWASP consacré à la sécurité de l'IA générative recommande des contrôles d'accès fins sur les bases d'embeddings et une séparation stricte entre groupes d'utilisateurs.

Le système reprend les droits tels qu'ils existent dans vos outils. S'ils sont trop larges aujourd'hui, par exemple un dossier de direction partagé à tous par erreur, l'assistant le rendra visible : il retrouve en une question ce que personne ne serait allé ouvrir. La revue des droits fait donc partie du projet, au même titre que le tri des documents.

Décidez aussi où les documents sont traités : où sont stockés les embeddings, où fonctionne le modèle, ce qui quitte l'entreprise à chaque question. Ces choix se tranchent avant l'indexation, avec le responsable de la sécurité informatique, et dans le respect du RGPD si les documents contiennent des données personnelles.

Le RAG réduit le risque de réponse inventée sans le supprimer. Le guide de la DGE le rappelle : des hallucinations peuvent persister. Le système peut aussi échouer plus discrètement. La bonne réponse existe dans vos documents, mais la recherche ne l'a pas retrouvée, et le modèle répond avec ce qu'il a sous la main.

Trois questions de démonstration bien choisies ne prouvent rien. Pour juger un système RAG, constituez un jeu de questions réelles, posées par les équipes. Pour chacune, faites écrire la bonne réponse et le document qui la contient par une personne qui connaît le sujet. Ajoutez des questions dont la réponse ne figure dans aucun document.

Pour chaque question, vérifiez les points ci-dessous séparément. Cette séparation indique quoi corriger : un mauvais passage retrouvé se règle dans les documents, le découpage ou la recherche ; une réponse qui déforme un bon passage se règle dans les consignes données au modèle.

Rejouez le même jeu de questions à chaque changement : nouveaux documents, nouveau découpage, nouveau modèle. Une fois l'outil en service, un bouton « réponse fausse » et la liste des questions restées sans réponse montrent où la documentation manque. Faire noter les réponses par un second modèle accélère le contrôle, sans dispenser de relire un échantillon.

Commencez par un périmètre documentaire restreint, consulté souvent, avec une personne capable de dire quelle version fait foi. Par exemple les procédures d'un service, la documentation technique d'une gamme ou les contrats fournisseurs. Indexer tout le drive dès le départ multiplie les contradictions et rend chaque erreur difficile à expliquer.

Partez des questions avant les documents : celles que l'on pose chaque semaine à la personne qui sait, celles qui arrivent au support, celles des nouveaux arrivants. Elles disent quels documents comptent vraiment, puis elles servent de jeu d'évaluation. C'est l'ordre que suit OMEGA : le métier d'abord, une preuve sur un cas réel, puis l'élargissement.