RAG en entreprise : ce qu'un chatbot branché sur vos documents ne sait pas faire, et ce qu'apportent une mémoire et un agent IA

Le RAG (retrieval augmented generation, ou génération augmentée de récupération) est une technique qui relie un modèle d'IA générative aux documents d'une entreprise : à chaque question, un moteur de recherche interne sélectionne les passages les plus pertinents, puis le modèle rédige une réponse à partir de ces passages, en citant ses sources. C'est la technologie qui se cache derrière la plupart des offres « chattez avec vos documents » et derrière une bonne partie des assistants d'entreprise.

Le RAG est utile, peu coûteux et rapide à mettre en place. Mais il est souvent vendu, ou compris, comme ce qu'il n'est pas : une mémoire de l'organisation, voire un agent capable d'agir. Ce guide explique comment fonctionne un système de RAG, ce qu'il fait bien, ses sept limites documentées, puis ce qui distingue un RAG d'une mémoire d'entreprise et d'un agent IA. Il se termine par une méthode pour tester un outil avant de lui confier des dossiers réels. Il fait partie de notre série sur le deuxième cerveau, l'IA agentique et l'IA en environnement réglementé.

Qu'est-ce que le RAG ? Définition et fonctionnement en cinq temps

Définition. Le RAG combine deux briques : un module de recherche, qui trouve dans une base documentaire les passages proches de la question, et un grand modèle de langage (LLM), qui rédige la réponse à partir de ces passages. Le terme vient d'un article de recherche de Patrick Lewis et de ses coauteurs, présenté à la conférence NeurIPS en 2020 (« Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks »).

La Direction générale des entreprises (DGE) en donne une définition simple dans son Guide de la génération augmentée par récupération (novembre 2024) : le RAG permet à un LLM de « consulter » les données de l'entreprise avant de répondre. Le modèle n'apprend rien de nouveau ; c'est la base documentaire qui est interrogée au moment de la question. Concrètement, un système de RAG fonctionne en cinq temps.

1. Préparer les documents. Conversion en texte (y compris par reconnaissance de caractères pour les scans), suppression des doublons, retrait des en-têtes et pieds de page, et, si nécessaire, pseudonymisation des données personnelles.
2. Découper (chunking). Chaque document est divisé en segments de quelques paragraphes. La DGE qualifie la taille et la méthode de découpage de « paramètre crucial » de la réussite du projet.
3. Vectoriser et indexer. Chaque segment est converti en une suite de nombres (un vecteur, ou embedding) qui représente son sens, puis rangé dans une base vectorielle. Des métadonnées (date, auteur, type de document) peuvent y être associées.
4. Récupérer. La question est elle aussi vectorisée ; le moteur sélectionne les segments les plus proches, par recherche sémantique, lexicale (mots-clés) ou hybride. Les meilleurs, souvent entre cinq et vingt, sont retenus.
5. Générer. Les segments retenus sont placés dans la consigne envoyée au modèle, qui rédige une réponse et indique les passages utilisés.

Ce schéma explique à la fois la force et la faiblesse du RAG. Sa force : la base se met à jour sans réentraîner le modèle, et chaque réponse peut renvoyer à sa source. Sa faiblesse : le modèle ne voit jamais l'ensemble des documents, seulement les quelques segments que la recherche lui a transmis. Tout ce que la recherche ne remonte pas n'existe pas pour lui.

Ce que le RAG fait bien, et ce qui le distingue du fine-tuning et du contexte long

Le RAG excelle dans un cas précis : répondre à une question ponctuelle dont la réponse se trouve dans un petit nombre de passages d'un corpus de textes relativement stable. Retrouver la procédure interne de traitement d'une réclamation, la clause d'un contrat-cadre, la règle de conservation d'un type de document : c'est son terrain. La DGE cite aussi la rédaction d'e-mails à partir du serveur de messagerie comme premier usage accessible aux entreprises dont les bases sont peu organisées.

Il est souvent comparé à deux autres manières de « donner ses données » à une IA. Les trois ne répondent pas au même besoin.

Pour une entreprise, et a fortiori une profession réglementée, le fine-tuning sur des données clients pose une difficulté supplémentaire : une information intégrée dans les paramètres d'un modèle ne se rectifie ni ne s'efface simplement, alors que le RGPD impose l'exactitude des données et le respect des durées de conservation. Le RAG laisse au contraire les documents à leur place : on corrige ou on retire le document, et la réponse suivante en tient compte. C'est l'une des raisons pour lesquelles il s'est imposé comme l'architecture de référence des assistants d'entreprise.

Les sept limites d'un chatbot branché sur des documents

Une équipe de l'université Deakin (Australie) a analysé trois projets de RAG dans la recherche, l'éducation et la biomédecine (Barnett et al., « Seven Failure Points When Engineering a Retrieval Augmented Generation System », conférence CAIN 2024). Sa conclusion principale : la fiabilité d'un RAG ne se constate qu'en fonctionnement, sur de vraies questions. En croisant ces travaux avec le guide de la DGE et d'autres études publiées, on peut regrouper les défaillances en sept limites, que tout acheteur devrait connaître.

1. L'information n'est pas dans le corpus

Le RAG ne connaît que ce qui a été indexé. Si l'essentiel de l'historique d'un client se trouve dans la messagerie, dans des notes manuscrites ou dans la tête d'un collaborateur, une base limitée aux PDF du serveur répondra à côté, ou pire, répondra avec assurance à partir d'un document partiel. Barnett et ses coauteurs en font le premier point de défaillance : un bon système doit savoir dire « je ne sais pas » plutôt que combler le vide. C'est pourquoi tout projet commence par une cartographie des sources.

2. Le découpage a séparé le passage de son contexte

Un segment isolé perd souvent ce qui lui donnait du sens. Dans une note publiée en septembre 2024, l'éditeur Anthropic prend l'exemple d'un segment financier indiquant que « le chiffre d'affaires a progressé de 3 % » sans préciser de quelle société ni de quelle période il s'agit (« Contextual Retrieval »). Dans un dossier client, l'équivalent est une phrase comme « le client souhaite réduire son exposition » détachée du nom du client et de la date du rendez-vous. En ajoutant à chaque segment un court résumé de son contexte, puis un reclassement des résultats, l'éditeur indique avoir réduit le taux d'échec de récupération de 5,7 % à 1,9 % sur ses jeux de test : la technique compte, mais le problème ne disparaît pas.

3. La question exige de parcourir tout le corpus

« Combien de clients ont un contrat qui arrive à échéance cette année ? », « Quels sont les sujets qui reviennent dans les réclamations depuis janvier ? » : ces questions ne se résolvent pas avec cinq passages. La DGE l'écrit explicitement : le RAG est « moins adapté » aux requêtes qui nécessitent l'ensemble des documents plutôt qu'un petit nombre d'entre eux, comme une synthèse ou une comparaison entre de nombreux documents. Des chercheurs de Microsoft ont proposé une parade, le GraphRAG, qui construit au préalable un graphe des entités et de leurs relations (Edge et al., « From Local to Global », 2024) : la réponse aux questions globales passe alors par une structure, pas par la seule proximité de sens.

4. Plusieurs versions coexistent, et le RAG ne sait pas laquelle est en vigueur

La recherche sémantique retient ce qui ressemble à la question, pas ce qui est à jour. Le projet de lettre de mission, la version signée et l'avenant de l'an dernier se ressemblent beaucoup ; l'ancien questionnaire de profil de risque et le nouveau aussi. Sans métadonnées de statut (projet, signé, remplacé) et de date exploitées par la recherche, le système peut citer un document périmé avec une parfaite traçabilité. C'est l'un des défauts de qualité des données que l'IA amplifie au lieu de les corriger.

5. L'information est dans un tableau ou une base structurée

Le RAG a été conçu pour du texte. La DGE note qu'il est « en général plus performant sur des données de texte » que sur d'autres modalités, « notamment les tableaux ». Un relevé de situation, un tableau d'allocation ou un export de CRM découpés en segments de texte perdent leurs lignes et leurs colonnes : le modèle peut alors associer un montant à la mauvaise ligne. Pour les données structurées (montants, dates, statuts), une requête directe dans la base d'origine reste plus fiable qu'une recherche par similarité.

6. L'index ne respecte pas les droits d'accès

Une base vectorielle construite par un compte technique qui lit tout peut restituer à n'importe quel utilisateur un passage qu'il n'aurait jamais dû voir. L'OWASP classe ce risque parmi les dix principaux des applications de LLM (LLM08:2025, faiblesses des vecteurs et des embeddings) et recommande un cloisonnement logique et des contrôles d'accès fins sur la base. Nous détaillons les mécanismes de contournement dans notre guide sur les droits d'accès d'une IA d'entreprise.

7. Trop de contexte noie l'information utile

Fournir plus de passages au modèle ne garantit pas une meilleure réponse. Des chercheurs de Stanford ont montré que les performances des modèles sont meilleures quand l'information pertinente se trouve au début ou à la fin du contexte, et se dégradent nettement quand elle est au milieu, y compris pour les modèles conçus pour les textes longs (Liu et al., « Lost in the Middle », TACL 2024). Et même lorsque le bon passage est fourni, le modèle peut mal le lire : le Stanford RegLab a mesuré entre 17 % et 33 % de réponses erronées ou mal sourcées sur des outils de recherche juridique fondés sur le RAG (Magesh et al., 2024). Une citation prouve d'où vient l'information ; elle ne prouve pas que la réponse soit juste. Notre guide sur la fiabilité des réponses d'une IA d'entreprise propose une grille de vérification.

Une réponse sans source ne compte pas

Plusieurs de ces limites tiennent à une seule chose : des documents isolés de leur contexte. Brain relie les sources existantes du cabinet (messagerie, agenda, documents, CRM, tableurs) pour reconstituer le contexte de chaque client, et chaque réponse cite ses sources. La page « Utiliser Brain » montre ce que l'on peut lui demander au quotidien, et comment vérifier ce qu'il répond.

Voir Brain au quotidien La méthode de test sur dossiers réels

Réponses sourcées • Sources existantes, sans ressaisie • Aucune action sans votre accord

RAG, mémoire d'entreprise, agent IA : trois notions à ne pas confondre

Les trois termes sont souvent employés l'un pour l'autre dans les présentations commerciales. Ils désignent pourtant des choses de nature différente : une technique, une organisation de l'information et un mode de fonctionnement.

• RAG : technique de recherche qui retrouve, dans une base, les passages proches d'une question et les fournit à un modèle. Son unité de travail est le segment de document.
• Mémoire d'entreprise : ensemble organisé des faits, documents, échanges, décisions et savoir-faire d'une organisation, rattachés aux personnes et aux dossiers qu'ils concernent, datés, versionnés et mis à jour au fil de l'activité. Son unité de travail est l'entité (un client, un foyer, une société, un contrat) et son histoire. Nous en avons détaillé les cinq couches dans un guide dédié.
• Agent IA : système qui poursuit un objectif en enchaînant des étapes et en utilisant des outils (rechercher, lire, rédiger, proposer une action), avec un degré d'autonomie défini. Son unité de travail est la tâche. Voir notre définition de l'IA agentique et des niveaux d'autonomie.

Ces trois notions ne s'opposent pas : elles s'emboîtent. Le RAG peut être l'une des techniques de recherche d'une mémoire ; la mémoire est la base de connaissance d'un agent. L'erreur consiste à croire qu'un RAG suffit à faire une mémoire, ou qu'un agent sans mémoire fiable peut agir correctement. Un agent qui prépare un rendez-vous à partir d'un RAG mal maîtrisé produira une synthèse convaincante… fondée sur l'ancien profil de risque.

Le deuxième cerveau d'entreprise désigne précisément cette combinaison : une mémoire qui relie les sources, interrogeable en langage naturel, sur laquelle s'appuient des assistants et des agents.

Ce qu'une mémoire d'entreprise ajoute au RAG

Passer d'un chatbot documentaire à une mémoire ne consiste pas à changer de modèle d'IA, mais à structurer ce que le modèle consulte. Six apports répondent directement aux limites décrites plus haut.

1. Le rattachement aux entités. Chaque document, e-mail ou note est relié au client, au foyer, à la société ou au contrat qu'il concerne. La question « que sait-on de M. et Mme X ? » interroge alors un dossier, pas une base entière par similarité. Cela suppose un travail de dédoublonnage et de résolution des homonymes.
2. La chronologie et les versions. Chaque élément est daté et porte un statut (projet, signé, remplacé, archivé). La mémoire sait quel document est en vigueur et peut écarter, ou signaler, une version périmée.
3. La distinction des natures d'information. Un fait (« le client a 58 ans »), une décision (« arbitrage vers le fonds euros le 12 mars ») et un avis (« le client semblait hésitant ») ne se traitent pas de la même façon. Notre guide sur la capitalisation des connaissances détaille cette séparation.
4. Les décisions et leurs raisons. Les documents disent ce qui a été signé ; les échanges et comptes rendus disent pourquoi. Une mémoire qui intègre ces échanges restitue le raisonnement, là où un RAG limité aux PDF ne voit que le résultat. C'est souvent la part la plus précieuse, et la plus tacite, de la connaissance d'une organisation.
5. L'accès direct aux données structurées. Les montants, dates et statuts sont lus dans la source structurée (CRM, outil métier) plutôt que reconstitués à partir de texte découpé.
6. Les droits portés par la donnée. Le périmètre de chaque utilisateur est appliqué au moment de la recherche, pas seulement dans l'interface.

Ces apports correspondent à ce que décrit Majors Brain sur son site : relier les sources existantes du cabinet (messagerie, agenda, documents, conversations, tableurs, CRM) pour reconstituer le contexte client et retrouver les décisions déjà prises, avec un paramétrage où chaque collaborateur n'accède qu'au périmètre qui le concerne. Brain distingue aussi la mémoire du cabinet, qui s'enrichit en continu et reste la propriété du cabinet, des modèles d'IA, présentés comme interchangeables : la mémoire est l'actif, le modèle est un outil.

RAG en environnement réglementé : traçabilité, minimisation et versions

Dans une profession réglementée (conseil en gestion de patrimoine, expertise comptable, avocat, banque, assurance), les limites du RAG ne sont pas seulement des défauts de qualité : elles touchent à des obligations. Trois points méritent l'attention.

• Traçabilité de la source ≠ traçabilité du conseil. Un RAG peut montrer de quel document vient une phrase. Il ne reconstitue pas, à lui seul, le chemin d'une recommandation : informations recueillies, profil retenu à cette date, options écartées, validation par le conseiller. Pour un CGP, c'est pourtant ce que l'on attend d'un dossier lors d'un contrôle de l'adéquation du conseil.
• Minimisation et durée de conservation. L'index d'un RAG est une copie des données sources. Il est soumis aux mêmes principes que l'original : minimisation (article 5.1.c du RGPD), exactitude et limitation de la conservation. Un document supprimé de la GED mais resté dans la base vectorielle continue de nourrir les réponses. La DGE recommande d'ailleurs d'anonymiser ou de pseudonymiser les données personnelles dès la préparation des documents.
• Versions réglementaires. Document d'entrée en relation, lettre de mission, questionnaire de connaissance et d'expérience, profil de risque : ces documents se succèdent dans le temps et doivent être conservés, souvent plusieurs années, alors qu'un seul est en vigueur. Un système qui ne gère pas les statuts confond l'archive réglementaire et l'état actuel du dossier.

Illustration (cabinet fictif). Prenons un cabinet de trois conseillers équipé d'un chatbot branché sur son serveur de fichiers. Une collaboratrice demande : « Quel est le profil de risque de M. Martin et pourquoi a-t-il changé ? » Le système remonte le questionnaire de 2022 (profil dynamique), le plus proche de la question par les mots employés, et ignore celui de 2025 (profil équilibré), rangé dans un sous-dossier mal nommé. La raison du changement, un départ à la retraite évoqué en rendez-vous, n'existe que dans un e-mail non indexé. La réponse est fluide, citée… et fausse. Avec une mémoire où les deux questionnaires sont rattachés au client, datés et dotés d'un statut, et où le compte rendu du rendez-vous est relié au dossier, la même question renvoie le profil en vigueur, la date du changement et sa raison, avec les trois sources.

Ces enjeux rejoignent ceux du secret professionnel face à l'IA : savoir où vont les données, qui peut les lire et ce qui en reste après usage.

Tester un outil de RAG avant de lui confier vos dossiers : méthode en six étapes

Le guide de la DGE recommande d'associer les futurs utilisateurs à l'élaboration de « questions-types et réponses-types » et d'évaluer le système en continu. Barnett et ses coauteurs concluent, eux, que la robustesse d'un RAG « évolue » avec l'usage plutôt qu'elle ne se conçoit d'emblée. D'où une méthode simple, applicable avant l'achat comme après chaque changement.

1. Constituer un jeu de 20 à 40 questions réelles, posées par les futurs utilisateurs, dont la bonne réponse et la bonne source sont connues (la méthode complète, avec dix familles de questions, une grille de notation et les règles de rejeu, est dans notre guide du jeu de test pour évaluer un outil d'IA).
2. Couvrir les sept familles de questions du tableau ci-dessous, et pas seulement les questions ponctuelles où le RAG excelle.
3. Tester avec plusieurs profils d'utilisateurs, pour vérifier le respect des droits d'accès.
4. Noter chaque réponse sur quatre critères : exactitude, source citée, version utilisée, aveu d'ignorance quand l'information manque.
5. Fixer un seuil d'acceptation par usage : une recherche de procédure interne tolère une erreur ponctuelle vite repérée ; une synthèse destinée à un client, non.
6. Rejouer le jeu après chaque changement de modèle, de sources ou de paramétrage, et à intervalles réguliers.

Les deux dernières lignes sont les plus révélatrices. Un outil qui échoue sur les droits d'accès n'est pas déployable dans une profession réglementée ; un outil qui échoue sur l'historique client est un moteur de recherche documentaire, utile mais pas une mémoire. Les deux constats sont légitimes, à condition de les faire avant de lui confier des dossiers. Pour inscrire ces tests dans une démarche par paliers, voir notre guide sur le déploiement progressif de l'IA.