RAG : brancher l'IA sur les données de votre entreprise, expliqué simplement
Posez une question pointue sur vos procédures internes à ChatGPT : il ne peut pas répondre, il ne connaît pas vos documents. Le RAG — Retrieval-Augmented Generation — résout exactement ce problème. C'est aujourd'hui la brique la plus demandée dans les projets de création d'agents IA en entreprise.
Explication sans jargon, pour décider en connaissance de cause.
Le principe en une phrase
Avant de répondre, l'IA va d'abord chercher les passages pertinents dans vos documents, puis rédige sa réponse uniquement à partir de ces passages — en citant ses sources.
Concrètement : vos documents (PDF, wikis, contrats, procédures, tickets, e-mails, bases de données) sont découpés et indexés dans une base spécialisée appelée base vectorielle. À chaque question, le système calcule quels extraits sont les plus proches sémantiquement de la question, les fournit au modèle de langage avec la consigne de s'y tenir et de citer ses sources — puis génère la réponse.
C'est la combinaison de deux composants bien distincts : un système de recherche (le R de RAG — Retrieval) et un modèle de génération (le G — Generation). La qualité du résultat dépend autant du premier que du second.
Ce que ça change par rapport à un chatbot classique
Un chatbot classique répond à partir de sa mémoire d'entraînement — figée à la date du dernier entraînement du modèle, et totalement ignorante de vos documents internes. Ses réponses peuvent sembler confiantes sur des sujets qu'il ne connaît pas, ce qu'on appelle les hallucinations.
Le RAG renverse cette logique. L'IA ne répond plus à partir de ce qu'elle a appris pendant son entraînement, mais à partir de ce que vous lui fournissez au moment de la question. Cela a plusieurs conséquences directes.
- Les réponses s'appuient sur vos données à jour, pas sur la mémoire figée du modèle
- Chaque réponse peut citer le document source (numéro de page, nom du fichier) : la confiance se vérifie
- Le risque d'hallucination chute drastiquement, car le modèle est contraint par les sources fournies
- Vos données restent sous votre contrôle : seuls les extraits pertinents transitent vers le modèle, à la demande
- Le système se met à jour sans ré-entraînement : il suffit de mettre à jour vos documents dans l'index
RAG vs fine-tuning : quelle différence ?
On confond souvent RAG et fine-tuning. Ce sont deux approches très différentes, adaptées à des besoins différents.
Le fine-tuning consiste à ré-entraîner un modèle de langage sur vos données pour qu'il intègre votre style, votre vocabulaire ou votre domaine. C'est long, demande une infrastructure spécialisée, et les données apprises ne sont pas facilement effaçables. Si une donnée devient obsolète ou confidentielle, il faut ré-entraîner.
Le RAG est plus rapide à mettre en place (quelques heures à quelques jours), plus flexible (mettre à jour un document dans l'index prend quelques secondes), plus transparent (on sait exactement quelles sources ont été utilisées), et plus adapté à la plupart des cas d'usage en entreprise. La quasi-totalité de nos projets de Q&A documentaire utilisent le RAG, pas le fine-tuning.
Le fine-tuning a sa place pour intégrer un style rédactionnel très spécifique, traiter un domaine spécialisé ou créer un modèle plus léger. Mais en pratique, pour 90 % des cas d'usage en PME, le RAG répond mieux aux besoins.
Les cas d'usage typiques
La force du RAG est qu'il s'adapte à n'importe quel corpus de documents, dans n'importe quel secteur. Les cas d'usage sont très variés — voici les plus fréquents dans nos projets.
- Assistant interne RH : « Quelle est notre procédure de déplacement professionnel ? » — réponse instantanée avec citation du règlement intérieur
- Support client produit : réponses fondées sur la documentation technique, les FAQs existantes et les tickets résolus
- Juridique et conformité : retrouver la clause ou la norme applicable en secondes, avec référence précise
- Onboarding collaborateurs : les nouveaux arrivants trouvent eux-mêmes les réponses à leurs 200 premières questions
- Préparation commerciale : interroger l'historique des deals pour préparer une proposition
- Veille interne : recherche sémantique dans les comptes rendus de réunion et les rapports d'activité
Les étapes techniques d'un projet RAG
Pour comprendre ce que vous achetez et ce que vous maintenez, voici les quatre étapes d'un projet RAG, sans entrer dans le code.
Étape 1 — Constitution et nettoyage du corpus. Les documents sources sont identifiés, collectés et nettoyés. Les doublons sont supprimés, les documents obsolètes retirés, les droits d'accès documentés. C'est l'étape la plus longue et la plus critique : un corpus mal entretenu produit des réponses erronées, même avec le meilleur modèle.
Étape 2 — Découpage et indexation. Les documents sont découpés en morceaux (chunks) de taille adaptée, puis convertis en représentations vectorielles (embeddings) par un modèle spécialisé. Ces vecteurs sont stockés dans une base vectorielle comme Pinecone, Weaviate ou pgvector.
Étape 3 — Retrieval. À chaque question, la même opération de vectorisation est appliquée à la question, puis le système cherche les chunks les plus proches dans la base. En général, on récupère les 3 à 10 extraits les plus pertinents.
Étape 4 — Génération. Les extraits récupérés sont fournis au modèle de langage avec la question et la consigne de répondre uniquement à partir de ces sources. Le modèle rédige la réponse et cite ses sources.
Comment choisir sa base vectorielle
La base vectorielle est le composant le moins visible mais l'un des plus importants d'un système RAG. Elle stocke vos documents vectorisés et effectue les recherches de similarité. Plusieurs options selon votre contexte.
Pour les PME qui démarrent avec un volume modeste, une solution simple comme pgvector ou ChromaDB suffit souvent. L'avantage : architecture lisible, maintenance accessible et peu de dépendances externes.
Pour des volumes plus importants ou des besoins de performance élevés (centaines de milliers de documents, temps de réponse sous la seconde), des solutions dédiées comme Pinecone, Weaviate ou Qdrant offrent de meilleures performances. Pinecone est la plus simple à démarrer en SaaS ; Qdrant et Weaviate sont open source et auto-hébergeables si la souveraineté des données est une priorité.
Pour les organisations sous contrainte réglementaire forte (santé, défense, secteur public), l'auto-hébergement est souvent une exigence. Dans ce cas, Qdrant ou pgvector déployés sur votre cloud ou sur site sont les choix les plus courants.
Les conditions de réussite
Un projet RAG réussit d'abord par la qualité de son corpus. Des documents à jour, sans doublons, avec des droits d'accès clairs et une structure cohérente. C'est la condition numéro un — et souvent celle qui nécessite le plus de travail préparatoire.
La deuxième condition : soigner l'évaluation avant le déploiement. Constituer un jeu de 50 à 100 vraies questions métiers avec leurs réponses attendues, et mesurer le taux de réponses correctes, complètes et sourcées. Ne pas déployer tant que le taux n'atteint pas votre seuil de tolérance.
La troisième condition : définir la gouvernance de mise à jour. Qui est responsable de maintenir le corpus à jour ? À quelle fréquence ? Que se passe-t-il si un document est supprimé ou modifié ? Un système RAG dont le corpus n'est pas maintenu se dégrade progressivement et perd la confiance des utilisateurs.
C'est précisément le type de projet que JNS-IA cadre et construit : un pilote sur un périmètre documentaire précis, évalué avec vos équipes sur de vraies questions métiers, puis étendu une fois la valeur prouvée. Si vous souhaitez approfondir, notre guide sur la création d'agents IA explique comment un système RAG s'intègre dans une architecture d'agent plus large.
Pièges et erreurs courantes
- Corpus mal nettoyé : des documents obsolètes ou contradictoires produisent des réponses incohérentes, même avec un excellent modèle
- Chunks trop grands ou trop petits : des extraits trop longs noient l'information pertinente ; des extraits trop courts perdent le contexte nécessaire à la compréhension
- Pas d'évaluation avant déploiement : mettre en production sans tester sur de vraies questions métiers crée des déceptions et des résistances
- Ignorer les droits d'accès : un assistant RAG ne doit pas répondre avec des documents auxquels l'utilisateur n'a pas accès — cette règle doit être codée, pas espérée
- Corpus statique : ne pas prévoir de processus de mise à jour régulière du corpus fait dégrader la pertinence avec le temps
Questions fréquentes
Le RAG nécessite-t-il d'entraîner un modèle sur nos données ?
Non, et c'est tout son intérêt : aucun entraînement n'est nécessaire. Vos documents sont indexés dans une base vectorielle, pas appris par le modèle. Mise en place plus rapide, confidentialité mieux maîtrisée, et mise à jour immédiate quand un document change.
Quel volume de documents faut-il pour que ce soit utile ?
Dès quelques dizaines de documents fréquemment consultés, le gain est réel. La pertinence et la fraîcheur du corpus comptent plus que le volume. Un RAG sur 50 procédures à jour surpasse un RAG sur 5 000 documents obsolètes.
Nos données sont-elles envoyées chez OpenAI ou Anthropic ?
Dans une architecture RAG standard, seuls les extraits pertinents sélectionnés pour répondre à la question sont envoyés au modèle — pas l'ensemble de vos documents. Pour les organisations avec des données très sensibles, nous déployons des modèles sur infrastructure privée, sans aucun envoi vers l'extérieur.
Quelle est la différence entre RAG et ChatGPT Entreprise ?
ChatGPT Entreprise est une version de ChatGPT avec des garanties de confidentialité renforcées, mais sans connexion à vos documents internes. Le RAG connecte spécifiquement le modèle à votre base documentaire, avec des réponses sourcées et un contrôle précis des accès.