RAG en entreprise : faire répondre un agent depuis vos documents

Le principe, sans jargon

Un modèle de langage sait beaucoup de choses sur le monde, et rien sur votre entreprise. Il ne connaît ni vos conditions générales, ni votre procédure de réclamation, ni la dernière version de votre catalogue. Si vous lui posez la question, il répondra quand même, avec une phrase plausible et souvent fausse.

La génération augmentée par recherche, que l'on désigne souvent par son sigle anglais RAG, corrige ce défaut par un mécanisme simple. Avant de répondre, le système cherche dans vos documents les passages qui concernent la question, puis les transmet au modèle avec la question. Anthropic la décrit comme une méthode qui récupère l'information pertinente dans une base de connaissance et l'ajoute à la demande de l'utilisateur. Le modèle ne répond plus de mémoire : il répond à partir de ce qu'on vient de lui mettre sous les yeux.

Trois briques suffisent à décrire l'ensemble :

• Le corpus. Les documents que l'agent a le droit d'utiliser : procédures, fiches produit, contrats types, foire aux questions, notes internes.
• La recherche. Le mécanisme qui, pour une question donnée, retrouve les quelques passages utiles parmi des milliers.
• La génération. Le modèle, qui rédige une réponse à partir de ces passages et indique d'où elle vient.

Cette architecture est au cœur de la plupart des agents que nous construisons, qu'il s'agisse d'un assistant interne pour une équipe support ou d'un agent qui répond aux visiteurs d'un site. Notre page sur la conception d'un agent IA la replace dans l'ensemble du projet. Ici, nous détaillons ce qui la fait fonctionner, et ce qui la fait échouer.

Avant la technique : préparer le corpus

Dans un projet de ce type, une grande part de la qualité se joue avant la première ligne de code. Un agent qui répond depuis vos documents ne sera jamais meilleur que ces documents. S'ils se contredisent, sont périmés ou incomplets, l'agent le sera aussi, avec l'aplomb en plus.

La qualité des documents

Commencez par un inventaire honnête. Où vivent les documents qui font foi : un intranet, un drive partagé, un outil de gestion documentaire, la boîte mail d'une seule personne ? Lesquels sont réellement à jour ? Lesquels existent en plusieurs versions, dont aucune n'est marquée comme la bonne ?

Les formats comptent aussi. Un PDF scanné de travers, un tableau mis en page pour l'impression ou une présentation où le sens tient à la position des blocs se lisent mal par une machine. Il faut parfois les convertir, les restructurer, ou accepter de les laisser de côté au premier lot. Mieux vaut un corpus restreint et propre qu'un corpus exhaustif où la bonne réponse côtoie trois réponses obsolètes.

Un signal simple aide à trier : si un collaborateur expérimenté hésite lui-même sur le document qui fait foi pour une question donnée, l'agent hésitera aussi. Ce sujet doit être tranché par le métier avant d'être indexé.

La mise à jour

Un corpus n'est pas une photographie. Les conditions changent, les procédures évoluent, un produit sort du catalogue. La question à poser dès le départ : quand un document change à la source, combien de temps faut-il pour que l'agent le sache, et qui s'en charge ?

La réponse technique est une synchronisation automatique avec la source, qui réindexe ce qui a été modifié et retire ce qui a été supprimé. La réponse organisationnelle est un propriétaire nommé pour chaque famille de documents. Sans ce propriétaire, le corpus se dégrade en silence, et personne ne le remarque avant qu'un client ne reçoive une réponse fausse.

Les droits d'accès

C'est le point le plus souvent négligé. Dans votre entreprise, tout le monde ne voit pas tout : la grille salariale, les contrats d'un client, les notes d'un comité de direction. Si ces documents entrent dans le corpus sans leurs droits, l'agent devient un moyen de les lire pour quiconque sait poser la bonne question.

L'OWASP, qui publie une liste de référence des risques propres aux applications de modèles de langage, classe ce problème parmi les faiblesses des bases vectorielles. Elle recommande un contrôle d'accès fin, avec un cloisonnement logique strict des données selon les groupes d'utilisateurs, et une journalisation des recherches effectuées. En pratique, chaque passage indexé garde la trace de qui a le droit de le lire, et la recherche filtre selon l'identité de la personne qui pose la question, avant que quoi que ce soit n'atteigne le modèle. Demander au modèle de ne pas révéler certaines informations ne protège rien : si le passage lui a été transmis, il peut ressortir. Notre équipe sécurité et conformité IA traite ce sujet dès la conception.

Découper et retrouver les bons passages

Un modèle ne relit pas toute votre documentation à chaque question. Le système découpe donc les documents en passages, et ne transmet que les plus pertinents. Ce découpage paraît anodin. Il décide pourtant d'une bonne partie de la qualité des réponses.

Le problème du passage orphelin

Un passage extrait de son document perd son contexte. Anthropic donne l'exemple d'une phrase tirée d'un rapport financier qui annonce une hausse du chiffre d'affaires sans dire de quelle entreprise ni de quelle période il s'agit. Chez vous, ce sera un paragraphe qui précise « cette garantie ne couvre pas les pièces d'usure », sans que l'on sache de quelle garantie ni de quelle gamme il est question.

Plusieurs réponses existent et se combinent :

• découper selon la structure du document (titres, articles, rubriques) plutôt qu'à longueur fixe ;
• conserver avec chaque passage le titre du document, la section d'origine et la date ;
• ajouter à chaque passage une courte phrase de contexte, rédigée à partir du document entier. C'est l'approche qu'Anthropic décrit sous le nom de recherche contextuelle.

Deux façons de chercher, à combiner

La recherche dite sémantique compare le sens de la question à celui des passages. Elle retrouve un passage sur la résiliation quand l'utilisateur demande comment arrêter son abonnement. Elle est en revanche moins fiable sur les correspondances exactes : une référence produit, un numéro d'article, un code interne. La recherche lexicale, par mots-clés, fait l'inverse. Anthropic recommande de combiner les deux, puis d'ajouter une étape de reclassement qui trie les passages retrouvés et ne garde que les plus pertinents avant de les transmettre au modèle.

Pour un dirigeant, le point à retenir est simple : la recherche est un composant à part entière, qui se règle et se mesure. Quand un agent répond mal, la première question à poser est « a-t-il trouvé le bon passage ? », avant « le modèle a-t-il mal compris ? ». Dans les diagnostics que nous menons, c'est souvent là que se trouve le problème.

Le branchement aux sources (drive, gestion documentaire, base de connaissance, outil de tickets) relève du travail de data et d'intégration. C'est lui qui garantit que ce qui est indexé correspond à ce qui existe, avec les bons droits et la bonne version.

Citer ses sources, systématiquement

Une réponse sans source demande un acte de foi. Une réponse qui cite le passage exact sur lequel elle s'appuie se vérifie en quelques secondes. C'est la différence entre un agent que les équipes consultent et un agent qu'elles contournent.

Les modèles récents savent le faire de façon fiable. La fonction de citations de Claude, par exemple, renvoie pour chaque affirmation le passage du document qui la soutient, et la documentation précise que ces citations pointent nécessairement vers les documents fournis. L'utilisateur voit la réponse, le nom du document et l'extrait. Il peut ouvrir la source et vérifier.

Nous en tirons trois règles de conception :

• Pas de source, pas de réponse. Si la recherche ne ramène rien de pertinent, l'agent le dit et oriente vers une personne ou une page de contact. Il ne comble pas le vide avec ses connaissances générales.
• La source est visible. Le lien vers le document d'origine apparaît dans l'interface, et pas seulement dans les journaux techniques.
• La date compte. Quand un document a une date de validité, elle est affichée avec la citation. Cela évite qu'une ancienne procédure soit prise pour la procédure en vigueur.

La citation a un effet secondaire utile : elle rend les erreurs du corpus visibles. Quand un utilisateur voit qu'une réponse fausse s'appuie sur un document périmé, il sait quoi signaler, et à qui.

Ce que la recherche documentaire ne règle pas

La génération augmentée par recherche améliore nettement la pertinence d'un agent. Elle ne résout pas tout, et deux limites méritent d'être posées clairement avant de lancer un projet.

Les données qui engagent l'entreprise

Un prix, une disponibilité, un délai de livraison, une référence, une adresse : ces informations engagent l'entreprise. Même si elles figurent dans un document du corpus, nous ne laissons jamais le modèle les recopier ou les reformuler. Il peut se tromper de ligne dans un tableau, mélanger deux gammes, ou restituer un tarif ancien resté dans un vieux PDF.

Notre règle maison : ce qui engage est calculé côté serveur, depuis la source de vérité (le catalogue, l'outil de gestion commerciale, la base de stock), et vérifié avant affichage. Le modèle décide qu'il faut afficher un prix, le système va le chercher. Nous avons développé ce point dans pourquoi un agent IA ne doit jamais annoncer un prix.

Les documents contradictoires

Deux documents disent des choses différentes sur le même sujet. La recherche remonte les deux. Que fait le modèle ? Il choisit, souvent sans le dire, ou il produit une synthèse qui n'existe dans aucun des deux. L'OWASP mentionne ce risque de conflit de connaissances quand plusieurs sources alimentent la même base.

Il n'existe pas de solution purement technique à ce problème, parce qu'il est d'abord organisationnel. Les parades que nous mettons en place :

• une hiérarchie explicite des sources, par exemple la procédure officielle avant la note de service ;
• des métadonnées de version et de date pour écarter l'ancien ;
• une consigne qui demande à l'agent de signaler une contradiction plutôt que de trancher ;
• un signalement automatique vers le propriétaire du corpus, qui corrige à la source.

Un agent bien construit devient ainsi un détecteur d'incohérences documentaires, ce qui a une valeur en soi, indépendamment des réponses qu'il donne.

Évaluer avant d'ouvrir aux utilisateurs

Un agent qui répond depuis des documents s'évalue à deux niveaux, qu'il faut mesurer séparément.

• La recherche. Pour une question donnée, le bon passage figure-t-il parmi ceux qui ont été retrouvés ? C'est le type de mesure qu'utilise Anthropic dans ses travaux sur la recherche contextuelle : la part des documents pertinents qui manquent parmi les premiers résultats.
• La réponse. À partir des bons passages, la réponse est-elle juste, complète, fidèle à la source, et dans le ton attendu ?

Séparer les deux mesures évite de chercher au mauvais endroit. Si la recherche ramène le bon passage et que la réponse reste fausse, le problème est dans les consignes ou le modèle. Si le bon passage n'est jamais retrouvé, aucun modèle ne sauvera la réponse.

Pour mesurer, il faut un jeu de cas : des questions réelles, posées par de vrais utilisateurs ou tirées de l'historique du support, avec pour chacune la réponse attendue et le document qui la contient, validés par quelqu'un du métier. Le jeu doit inclure des questions difficiles, des questions ambiguës, et des questions hors périmètre auxquelles la bonne réponse est « je ne sais pas, voici qui contacter ». La documentation de Claude insiste sur ce point : un bon jeu d'évaluation reflète la répartition réelle des tâches, cas limites compris.

Ce jeu se rejoue à chaque modification : nouveau découpage, nouveau modèle, nouveaux documents. Sans lui, on améliore un point et on en casse un autre sans le savoir. Notre article sur le déploiement d'un agent IA en entreprise montre où cette étape se place dans le projet.

Les erreurs que nous voyons le plus souvent

• Tout indexer d'un coup. Brancher l'intégralité du drive partagé semble efficace. C'est la façon la plus sûre de faire remonter des brouillons, des doublons et des documents confidentiels. Commencez par un périmètre choisi, puis élargissez.
• Oublier les droits. Un agent qui ignore les droits d'accès est une fuite de données en attente. Le filtrage se fait dans la recherche, avant le modèle.
• Accuser le modèle en premier. Quand une réponse est fausse, vérifiez d'abord ce que la recherche a ramené. Changer de modèle ne corrige pas un mauvais découpage.
• Négliger la mise à jour. Un index construit une fois et jamais rafraîchi dérive dès le premier changement de procédure.
• Transmettre trop de contexte. Envoyer beaucoup de passages « au cas où » dilue l'information utile et alourdit la facture à chaque appel. Ce poste est détaillé dans notre article sur le coût d'un agent IA en production.
• Ne pas prévoir la sortie. Un agent doit savoir dire qu'il ne sait pas et passer la main. S'il ne le peut pas, il inventera.
• Ignorer l'hébergement. Vos documents transitent par l'index, le moteur de recherche et le modèle. Où sont-ils stockés, qui y a accès, sous quel contrat ? Voir notre article sur l'hébergement d'un projet IA en France.

Par où commencer

Un premier projet réussi part d'une question métier précise, posée souvent, dont la réponse existe déjà quelque part dans vos documents. Une équipe support qui répond chaque jour aux mêmes questions sur les conditions de garantie. Un service achats qui cherche la bonne clause dans des contrats cadres. Une direction financière qui veut retrouver la règle applicable à un cas particulier.

Ensuite, dans cet ordre : délimiter le corpus et lui donner un propriétaire, poser les droits d'accès, construire le jeu d'évaluation avec le métier, puis seulement régler la recherche et choisir le modèle. Nous travaillons en forward deployed : l'ingénieur s'installe chez vous, sur vos documents réels, aux côtés de ceux qui poseront les questions. C'est la façon la plus directe de découvrir ce que le corpus contient vraiment, et ce qui lui manque.

Si vous avez un cas en tête et voulez savoir si vos documents sont prêts, notre diagnostic IA permet de faire le point sur le corpus, les droits et le périmètre avant d'engager un développement.

Sources

• Anthropic, Introducing Contextual Retrieval
• OWASP GenAI Security Project, LLM08 (2025), Vector and Embedding Weaknesses
• Documentation Claude, Citations
• Documentation Claude, Define success criteria and build evaluations

Questions fréquentes

Faut-il réentraîner un modèle sur nos documents ?

Rarement. La recherche documentaire laisse le modèle tel quel et lui fournit les bons passages au moment de la question. C'est plus simple à mettre à jour, puisqu'il suffit de réindexer un document modifié, et plus facile à contrôler, puisque chaque réponse peut citer sa source.

Nos documents sont en désordre. Faut-il tout ranger avant de commencer ?

Non, mais il faut choisir. Nous commençons par un périmètre restreint, sur un cas d'usage précis, et nous rangeons ce périmètre avec le métier. Le reste du corpus suit par lots, à mesure que l'usage le justifie.

Un agent de ce type peut-il répondre à nos clients directement ?

Oui, si le corpus exposé est limité à ce qu'un client peut lire et si les données qui engagent sont produites par le système, jamais par le modèle. Nous recommandons souvent de commencer en interne, où les erreurs sont repérées par des personnes qui connaissent la bonne réponse.

Que se passe-t-il quand un collaborateur pose une question sur un document qu'il n'a pas le droit de voir ?

Si les droits sont correctement portés dans l'index, la recherche ne ramène tout simplement pas ce document, et l'agent répond qu'il ne trouve pas l'information. Le modèle ne voit jamais le passage, ce qui est la seule protection fiable.

Qui maintient l'agent une fois en service ?

Les documents restent la responsabilité des équipes qui les produisent, avec un propriétaire nommé par famille. La partie technique (synchronisation, index, suivi des réponses, rejeu des tests) demande une maintenance régulière, que nous pouvons assurer ou transmettre à votre équipe.