Chatbot RAG : brancher un assistant sur ses documents

Qu'est-ce qu'un chatbot RAG, sans jargon

Demandez à un assistant IA généraliste quelle est la politique de remboursement de votre entreprise, ou quelle clause figure dans votre contrat-cadre fournisseur : il n'en sait rien. Pire, un grand modèle de langage préfère souvent produire une réponse plausible plutôt que d'admettre qu'il ignore la réponse — c'est le phénomène d'hallucination. Le RAG (Retrieval-Augmented Generation, génération augmentée par récupération) répond à ce problème précis : brancher l'assistant sur vos propres documents, pour qu'il réponde à partir de ce que vous avez réellement écrit plutôt qu'à partir de ce qu'il a mémorisé pendant son entraînement.

Le principe tient en deux étapes exécutées à chaque question posée. D'abord, un moteur de recherche va chercher, dans votre base documentaire, les quelques passages les plus pertinents pour la question : c'est la récupération (retrieval). Ensuite, un modèle de langage rédige une réponse en s'appuyant sur ces passages, un peu comme un collaborateur qui rouvre le bon classeur avant de répondre plutôt que de répondre de mémoire : c'est la génération. Le terme a été formalisé en 2020 par des chercheurs de Facebook AI Research, aujourd'hui Meta AI, dans un article qui décrit un modèle combinant une mémoire « paramétrique » — ce que le modèle a appris pendant son entraînement — et une mémoire « non paramétrique » : un corpus de documents que l'on peut faire évoluer sans jamais réentraîner le modèle.

C'est ce qui distingue le RAG d'un réentraînement du modèle (fine-tuning) sur vos documents : le fine-tuning ajuste les paramètres internes à partir de vos textes, une opération coûteuse à relancer à chaque mise à jour documentaire, et peu adaptée à la citation précise d'une source. Le RAG ne modifie pas le modèle : il change les documents consultés, ce qui suffit à mettre à jour les réponses sans nouvel entraînement.

Un chatbot RAG se contente de répondre à partir de ce qu'il trouve dans vos documents ; il ne réserve rien, ne modifie aucun système, ne déclenche aucune action — c'est la frontière qui le sépare d'un agent IA, capable lui d'agir sur des outils tiers en plus de répondre. Le même moteur de récupération documentaire peut d'ailleurs alimenter aussi bien un widget de chat écrit qu'un callbot au téléphone : la différence se joue sur l'interface, texte ou voix, pas sur le moteur documentaire lui-même.

Un point mérite d'être posé dès cette définition, parce qu'il structure tout le reste de cet article : le RAG réduit le risque d'hallucination, il ne l'élimine pas. Une étude du RegLab de Stanford portant sur des outils juridiques commerciaux construits sur une architecture de ce type — vendus par leurs éditeurs comme quasiment exempts d'erreurs — a mesuré des taux d'hallucination compris entre 17 % et 33 % des requêtes testées. Brancher un assistant sur des documents change la nature du risque, il ne le supprime pas.

Pourquoi vos documents sont le vrai sujet, pas le modèle

La question la plus posée à propos d'un projet RAG est presque toujours la même : quel modèle de langage choisir ? C'est rarement la bonne question à se poser en premier. Un modèle récent et performant nourri par une base documentaire obsolète, contradictoire ou mal structurée produira des réponses de moins bonne qualité qu'un modèle plus modeste connecté à une documentation propre et à jour. Le goulot d'étranglement d'un projet RAG se situe presque toujours du côté des documents, pas du côté du modèle.

Plusieurs défauts documentaires, très courants en entreprise, dégradent silencieusement la qualité des réponses :

• Les versions concurrentes d'un même document. Une politique de congés existe en trois versions dans trois dossiers partagés différents, dont une seule est réellement en vigueur. Le moteur de récupération n'a aucun moyen de deviner laquelle privilégier ; il peut très bien remonter la mauvaise.
• Les documents rédigés pour être lus en entier, pas par extraits. Une clause qui ne prend son sens qu'à la lumière d'un paragraphe situé plusieurs pages plus haut perd ce sens une fois isolée dans un fragment récupéré séparément.
• Les formats peu exploitables. PDF scanné sans reconnaissance de caractères, tableau complexe, présentation où l'information tient dans la mise en page plutôt que dans le texte : tout cela nuit à ce qu'un moteur de récupération peut effectivement lire et retrouver.
• L'absence de mise à jour. Un document modifié dans son outil d'origine (intranet, wiki, CRM) mais jamais réindexé continue d'alimenter des réponses avec une information périmée, sans qu'aucun signal n'alerte les utilisateurs.

Ces défauts sont invisibles pendant une démonstration commerciale, construite sur un jeu de documents propre et restreint. Ils apparaissent une fois le système confronté au volume réel et désordonné d'une base documentaire d'entreprise — contrats, politiques RH, fiches produit, comptes rendus, FAQ jamais mise à jour depuis un changement de tarif. C'est un travail de gouvernance documentaire, pas un paramètre technique qu'un fournisseur peut régler à votre place. Les cas d'usage où cette gouvernance paie le plus — support client, juridique, ressources humaines — sont détaillés secteur par secteur dans notre pilier cas d'usage.

Découpage et indexation : la mécanique invisible qui décide de tout

Un modèle de langage ne peut pas relire une base documentaire de plusieurs milliers de pages à chaque question posée : le volume de texte qu'il peut prendre en compte dans une seule requête reste limité, et même quand cette limite est large, y déverser des documents entiers dilue les passages réellement utiles au milieu de contenu hors sujet. Le système doit donc, en amont, découper les documents en fragments plus courts — les chunks — et n'aller chercher, au moment de la question, que les quelques fragments les plus pertinents.

Ce découpage est une étape technique discrète, presque invisible dans les démonstrations commerciales, et pourtant déterminante : un mauvais découpage produit de mauvaises réponses, même avec le meilleur modèle du marché. Couper au milieu d'une phrase, séparer une clause de sa condition d'application énoncée juste avant, isoler une ligne de tableau de son en-tête de colonne : dans chacun de ces cas, le fragment récupéré perd le sens qu'il avait dans son document d'origine.

La taille des fragments influence directement la qualité des réponses. Un fragment trop court manque de contexte pour être compris isolément ; un fragment trop long dilue l'information pertinente et complique la tâche du moteur de récupération, qui doit repérer l'utile au milieu du superflu. Les praticiens du secteur convergent aujourd'hui vers quelques repères, à ajuster selon la nature des documents :

Type de contenu	Taille de fragment usuelle	Chevauchement recommandé
Contenu court : FAQ, fiches produit	Environ 250 tokens (~1 000 caractères)	10 à 20 %
Documentation générale d'entreprise	512 à 1 024 tokens	10 à 20 %
Contenu technique dense : contrats, normes, documentation produit longue	1 024 à 2 048 tokens	10 à 15 %

Un token correspond, en français, à une fraction de mot d'environ 3 à 4 caractères en moyenne — un repère grossier mais suffisant pour situer les ordres de grandeur.

Le chevauchement (overlap) consiste à répéter volontairement quelques phrases entre deux fragments consécutifs, pour qu'une information à cheval sur la frontière de découpe ne soit pas perdue. Ces repères restent des points de départ à tester sur ses propres documents, pas des règles universelles : certaines configurations de recherche ne montrent aucun gain mesurable du chevauchement, seulement un coût de stockage supplémentaire.

Une fois découpés, les fragments sont transformés en vecteurs par un modèle d'embedding (plongement vectoriel) : une représentation numérique du sens du texte, qui permet de retrouver un fragment pertinent même si la question posée n'utilise pas les mêmes mots que le document source — un utilisateur qui tape « annuler ma réservation » doit pouvoir retrouver un paragraphe qui parle de « résiliation du contrat », sans partager un seul mot avec sa question. Ces vecteurs sont stockés dans une base de données vectorielle — Pinecone, Weaviate, Milvus, Qdrant ou l'extension pgvector de PostgreSQL comptent parmi les choix courants — avec des arbitrages différents entre simplicité, coût et volume supporté. À chaque fragment sont en général associées des métadonnées — document source, date de mise à jour, service propriétaire, niveau de confidentialité — qui permettent de filtrer la recherche et, condition trop souvent négligée, de restreindre l'accès à certains documents selon l'utilisateur qui pose la question. Le choix du modèle d'embedding et du modèle de génération reste un sujet à part entière, traité dans notre pilier IA et modèles.

Citer ses sources dans les réponses

Un chatbot RAG bien conçu ne se contente pas de répondre : il indique d'où vient sa réponse, en général sous la forme d'un lien vers le document source, parfois accompagné du passage exact utilisé et de sa date de mise à jour. Cette citation transforme une affirmation invérifiable en affirmation vérifiable en un clic — un changement de nature, pas seulement de présentation.

La citation n'a de valeur que si elle est réellement rattachée à ce que le modèle a utilisé pour construire sa réponse, et non simplement ajoutée après coup pour rassurer l'utilisateur. Un système correctement conçu ne cite que les fragments effectivement récupérés et transmis au modèle au moment de la génération ; un système mal conçu peut afficher un document plausible sans garantie qu'il corresponde réellement au contenu de la réponse générée. C'est un point de vigilance plus délicat qu'il n'y paraît : une réponse fausse accompagnée d'une source qui semble légitime inspire souvent davantage confiance qu'une réponse fausse sans aucune source, précisément parce que l'utilisateur relâche sa vérification en voyant une référence citée.

Concrètement, une citation utile réunit trois éléments : le nom du document d'origine, avec un lien direct quand c'est possible ; le passage exact — ou au moins le paragraphe — sur lequel s'appuie la réponse ; et une indication de fraîcheur, pour savoir si l'on consulte la version en vigueur ou une version remplacée depuis. Sans cette fraîcheur affichée, un document exact au moment de son indexation peut continuer à alimenter des réponses fausses des mois après avoir été remplacé.

C'est aussi un point qu'il vaut la peine de vérifier avant de choisir un fournisseur plutôt qu'un autre : demander une démonstration où l'on interroge volontairement le système sur un sujet absent de sa base documentaire, pour observer s'il répond honnêtement qu'il ne sait pas ou s'il invente une réponse plausible avec une fausse référence à l'appui. C'est le type de vérification que couvre notre méthodologie de test, appliquée aux solutions conversationnelles que nous évaluons.

Les erreurs qui ruinent un projet RAG

La plupart des projets RAG qui déçoivent ne souffrent pas d'un mauvais modèle de langage, mais d'un choix de conception ou d'un défaut de gouvernance identifiable :

• Aucune réponse prévue pour « je ne sais pas ». Sans consigne explicite pour reconnaître l'absence d'information pertinente dans les fragments récupérés, un modèle de langage a tendance à combler les trous avec une réponse plausible plutôt que d'admettre une limite — souvent la cause la plus directe d'hallucination visible par les utilisateurs.
• Découpage réalisé sans relecture humaine. Un découpage automatique jamais vérifié sur un échantillon produit régulièrement des coupures absurdes — une clause séparée de sa condition, un tableau tarifaire sans son en-tête — invisibles tant que personne ne les relit.
• Confusion entre droits d'accès documentaire et droits d'accès au chatbot. Un assistant branché sur l'ensemble d'un espace documentaire partagé, sans filtrage par utilisateur, peut exposer à n'importe quel collaborateur des informations RH, contractuelles ou financières auxquelles il n'aurait normalement pas accès — un sujet qui relève autant de la conformité que de la technique, détaillé dans notre pilier réglementation & confiance.
• Aucun test avant mise en production. Sans un jeu de questions représentatif du vocabulaire réel des utilisateurs — formulations maladroites, fautes de frappe, questions hors périmètre —, un système validé sur des questions de démonstration bien formulées échoue en silence dès les premières semaines réelles.
• Un périmètre documentaire mal défini dès le départ. Brancher un chatbot sur l'ensemble des documents de l'entreprise d'un coup, sans prioriser un périmètre cohérent (un seul service, un seul type de demande), dilue la qualité de récupération et complique la gouvernance dès le premier jour.

Ces erreurs se corrigent plus facilement avant le déploiement qu'après : un cadrage initial qui identifie le périmètre documentaire, les droits d'accès nécessaires et les cas où le système doit explicitement refuser de répondre évite l'essentiel des déconvenues. C'est l'objet d'un premier échange avant tout projet — voir notre page de demande de devis.

Questions fréquentes

Un chatbot RAG élimine-t-il complètement les hallucinations ?

Non. Le RAG réduit le risque d'hallucination en ancrant les réponses dans des documents réels, mais il ne le supprime pas : le modèle peut ignorer un passage pertinent, mélanger plusieurs sources, ou afficher une citation qui ne correspond pas exactement à ce qu'il a réellement utilisé. Une étude du RegLab de Stanford sur des outils juridiques commerciaux construits sur ce principe a mesuré des taux d'hallucination de 17 à 33 %, malgré des promesses commerciales de fiabilité quasi totale. La qualité de la base documentaire et la conception du système restent déterminantes.

RAG ou fine-tuning : lequel choisir pour une entreprise ?

Le RAG convient à la grande majorité des cas d'usage d'entreprise : il permet de mettre à jour les réponses simplement en mettant à jour les documents, sans réentraîner de modèle, et il permet de citer ses sources. Le fine-tuning garde un intérêt pour ajuster un style de réponse ou un comportement spécifique, mais reste plus coûteux à maintenir dans le temps et se prête mal à la citation précise d'un document source. Les deux approches ne s'excluent pas : certains projets combinent un modèle légèrement ajusté et un système RAG par-dessus.

Quels types de documents peut-on brancher à un chatbot RAG ?

La plupart des formats texte s'y prêtent : PDF, Word, pages d'un intranet ou d'un wiki, exports de CRM, feuilles de FAQ. Les documents scannés sans reconnaissance de caractères, les tableaux complexes ou les informations qui tiennent uniquement dans une mise en page (schéma, infographie) demandent un traitement préparatoire spécifique avant d'être exploitables, sous peine de fragments de mauvaise qualité une fois découpés.

Combien de temps faut-il pour déployer un chatbot RAG ?

Cela dépend presque entièrement de l'état de la base documentaire de départ, plus que de la technique elle-même : quelques jours pour un périmètre restreint et déjà propre, plusieurs semaines dès qu'il faut nettoyer des versions contradictoires, définir des droits d'accès par document ou traiter des formats peu exploitables. Le temps de préparation documentaire dépasse presque toujours le temps de configuration technique du système.

En résumé

Un chatbot RAG répond à partir de vos propres documents en combinant une étape de récupération, qui va chercher les passages pertinents dans votre base documentaire, et une étape de génération, où un modèle de langage rédige la réponse à partir de ces passages. Cette architecture réduit le risque d'hallucination par rapport à un modèle généraliste répondant de mémoire, mais ne l'élimine pas — des outils commerciaux construits sur ce principe continuent de se tromper dans une proportion mesurable de leurs réponses. Le facteur qui détermine le plus la qualité d'un projet RAG n'est presque jamais le modèle de langage choisi, mais l'état réel de la base documentaire : versions à jour, découpage soigné, droits d'accès cohérents et citation fiable des sources utilisées. Les projets qui échouent le font rarement à cause d'un mauvais modèle ; ils échouent parce que personne n'a fait le travail, moins spectaculaire, de mettre de l'ordre dans les documents avant de les brancher sur un assistant.