RAG en entreprise : à quoi ça sert et comment en créer un ?

Un collaborateur pose une question simple :

« Quelle est notre procédure lorsqu’un client demande une résiliation anticipée ? »

La réponse existe peut-être dans une condition générale de vente, une procédure interne ou une note mise à jour le mois dernier. Un modèle d’IA généraliste ne connaît pas forcément ces documents. Et lui transmettre toute la base documentaire à chaque question serait lent, coûteux et peu fiable.

Un RAG permet de chercher d’abord les passages utiles, puis de demander à l’IA de répondre à partir de ces passages.

RAG : une définition simple

RAG signifie Retrieval-Augmented Generation, traduit en français par « génération augmentée par récupération ».

Le principe associe deux opérations :

1. retrouver dans une base documentaire les extraits les plus pertinents pour la question ;
2. générer une réponse en donnant ces extraits au modèle d’IA comme contexte.

Le modèle ne mémorise donc pas toute l’entreprise. À chaque demande, le système sélectionne quelques sources autorisées et les place devant lui, comme un dossier préparé avant une réunion.

Le terme RAG a été formalisé dans un article de recherche publié en 2020. L’approche combinait déjà la mémoire contenue dans le modèle avec une mémoire externe consultable.[1] Pour une entreprise, cette mémoire externe peut être constituée de procédures, contrats, fiches produit, documentation technique ou comptes rendus validés.[2][3]

Comment fonctionne un RAG ?

Un RAG simple suit cette chaîne :

Question → recherche → extraits pertinents → réponse sourcée

En pratique :

1. les documents autorisés sont collectés et nettoyés ;
2. ils sont découpés en passages de taille raisonnable ;
3. chaque passage reçoit des métadonnées : source, date, version, équipe, droits d’accès ;
4. les passages sont indexés pour pouvoir être retrouvés par mots-clés, par proximité de sens, ou par une combinaison des deux ;[4][5]
5. lorsqu’une question arrive, le moteur récupère les extraits les plus pertinents ;
6. le modèle rédige une réponse à partir de ce contexte ;
7. l’interface affiche la réponse, ses sources et, si nécessaire, un avertissement ou une demande de validation.

La recherche sémantique est utile lorsque la question et le document n’emploient pas exactement les mêmes mots. Mais une recherche par mots-clés reste précieuse pour les références exactes, noms de produits, codes ou numéros de contrat. C’est pourquoi une recherche hybride est souvent un bon point de départ.[4]

À quoi un RAG peut-il servir dans une PME ?

Le RAG devient utile lorsque le travail dépend d’une connaissance répartie dans de nombreux documents.

Il peut par exemple aider à :

• retrouver une procédure interne sans parcourir plusieurs dossiers ;
• préparer une réponse de support à partir de la documentation produit ;
• comparer une demande client avec les conditions contractuelles applicables ;
• préparer un commercial avant un rendez-vous avec les fiches produit, études de cas et règles tarifaires autorisées ;
• répondre aux questions récurrentes des équipes sur des règles internes ;
• résumer un dossier en citant les documents qui justifient chaque point important.

Le gain de temps compte, mais il ne suffit pas. Une réponse utile doit être ancrée dans des sources identifiables, que l’utilisateur peut vérifier.

Dans quels cas le RAG n’est-il pas la bonne solution ?

Le RAG n’est pas utile partout.

Une recherche classique peut suffire si l’utilisateur veut seulement retrouver un document précis. Une règle déterministe est préférable lorsqu’un calcul ou une décision doit toujours produire le même résultat. Une API ou un serveur MCP est souvent plus adapté pour consulter une donnée structurée en temps réel ou agir dans un outil.

Exemple : pour connaître le montant exact d’une facture, mieux vaut interroger le logiciel de facturation. Pour expliquer une clause à partir de plusieurs documents contractuels, un RAG peut être pertinent.

Il faut également éviter le RAG lorsque :

• la base documentaire est petite, obsolète ou mal tenue ;
• personne ne sait quelle source fait autorité ;
• les droits d’accès ne peuvent pas être reproduits dans la recherche ;
• le besoin réel est d’exécuter une action, et non de retrouver de la connaissance ;
• une erreur non détectée pourrait entraîner une décision irréversible.

Les limites à connaître

Un RAG peut encore se tromper

Donner des documents à un modèle réduit certains risques d’hallucination, mais ne les supprime pas. Le moteur peut récupérer le mauvais passage. Le bon document peut manquer. Le modèle peut aussi interpréter une source de travers.[2][4]

La réponse doit donc montrer ses références et savoir dire : « je n’ai pas assez d’information ».

Une mauvaise base produit de mauvaises réponses

Un RAG ne corrige pas une procédure contradictoire, un PDF périmé ou trois versions concurrentes d’une même règle. La qualité documentaire, les dates et les responsables de mise à jour comptent autant que le choix du modèle.

Les permissions doivent suivre l’utilisateur

Une recherche pertinente mais non autorisée reste une fuite de données. Un salarié ne doit pas obtenir, par l’intermédiaire du RAG, un document auquel il n’aurait normalement pas accès.

Si des données personnelles sont utilisées, la finalité doit être définie et les données limitées à ce qui est nécessaire. Les règles de conservation, d’accès, de rectification et de suppression doivent aussi être prévues.[6]

Une source citée n’est pas forcément correcte

La citation prouve d’où vient l’information, pas que cette information est vraie, à jour ou applicable au cas traité. Pour un sujet juridique, financier, RH ou commercial engageant, la validation humaine reste nécessaire.

Comment mettre en place un premier RAG ?

1. Choisir une seule question métier

Évitez « connecter toute la connaissance de l’entreprise ». Commencez par une tâche mesurable, par exemple :

« Retrouver la procédure applicable à une demande de support et préparer une réponse avec ses sources. »

Définissez qui pose la question, quels documents sont autorisés et ce qu’une bonne réponse doit contenir.

2. Préparer un corpus limité et fiable

Sélectionnez un petit ensemble de documents à jour. Pour chaque source, notez au minimum :

• son propriétaire ;
• sa date de mise à jour ;
• sa version ;
• son niveau de confidentialité ;
• les personnes autorisées à la consulter.

Retirez les doublons et archivez les versions périmées avant de chercher à optimiser l’IA.

3. Construire la chaîne de recherche

Découpez les documents en passages cohérents, puis créez un index. Un premier prototype peut utiliser une solution RAG prête à l’emploi ou un magasin vectoriel. Pour des références exactes, combinez si possible recherche sémantique et mots-clés.[2][3][5]

Le réglage important n’est pas seulement la taille des passages. Il faut aussi vérifier si le moteur retrouve le bon extrait pour les formulations réelles des utilisateurs.

4. Encadrer la génération

Demandez au modèle de :

• répondre uniquement à partir des extraits fournis ;
• citer le document et le passage utilisés ;
• distinguer un fait, une interprétation et une information absente ;
• refuser de conclure lorsque les sources sont insuffisantes ou contradictoires.

Ces règles améliorent la lisibilité du résultat, mais elles ne remplacent pas les tests.

5. Tester avec de vraies questions

Constituez un jeu de 20 à 50 questions représentatives, avec les réponses et sources attendues. Mesurez séparément :

• la recherche : le bon passage apparaît-il parmi les extraits récupérés ?
• la réponse : respecte-t-elle les sources sans ajouter d’affirmation ?
• la traçabilité : l’utilisateur peut-il contrôler l’origine de chaque point important ?
• le refus : le système s’arrête-t-il lorsque l’information manque ?
• les permissions : un utilisateur ne voit-il que ce qu’il est autorisé à consulter ?

Testez aussi des questions ambiguës, des documents contradictoires et des demandes hors périmètre.

6. Lancer un pilote supervisé

Commencez avec une petite équipe et un corpus maîtrisé. Le RAG prépare une réponse ; l’utilisateur la relit avant de l’utiliser ou de l’envoyer.

Suivez les erreurs : mauvaise source, passage manquant, document périmé, réponse trop affirmative ou droit d’accès incorrect. Ces corrections montrent où améliorer le corpus, la recherche ou les consignes.

RAG, fine-tuning et connexion aux outils : ne pas les confondre

• Le RAG apporte au modèle des connaissances retrouvées au moment de la question.
• Le fine-tuning modifie le comportement d’un modèle à partir d’exemples ; ce n’est pas le meilleur moyen de maintenir une base documentaire fréquemment mise à jour.
• Une API ou MCP permet de consulter un outil ou d’y préparer une action selon des permissions définies.

Ces briques peuvent se compléter. Un employé IA peut utiliser un RAG pour retrouver une procédure, consulter un CRM par API, puis préparer une action. Les permissions et validations doivent rester explicites à chaque étape.

Le bon premier objectif

Un bon prototype de RAG ne cherche pas à répondre à tout. Il prouve qu’un périmètre documentaire précis permet de retrouver de meilleures sources, plus vite, avec des réponses vérifiables.

Pour une PME, le point de départ n’est donc pas : « quelle base vectorielle choisir ? ». La première question est :

« Quelle décision ou quelle tâche serait réellement améliorée si la bonne information arrivait, avec sa source, au bon moment ? »

Si vos équipes perdent du temps à chercher et recouper des informations avant d’agir, demandez un Diagnostic Pulse. Nous identifierons un cas d’usage limité, les sources autorisées et les contrôles humains nécessaires avant tout déploiement.

Sources

[1] Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks [2] Direction générale des Entreprises — Guide de la génération augmentée par récupération [3] France Num — Exploiter les données de sa TPE-PME avec le RAG [4] Microsoft Learn — RAG and Generative AI [5] OpenAI — Retrieval [6] CNIL — IA : comment être en conformité avec le RGPD ?