Call-bot.ai

Chatbots & assistants conversationnelsMis à jour le 18 min de lecture

Chatbot RAG : brancher un assistant sur ses documents

Pour qu'un chatbot réponde à partir des documents d'une entreprise plutôt que de la seule mémoire d'un modèle de langage, on utilise une méthode appelée RAG (génération augmentée par récupération). Elle réduit le risque de réponses inventées, sans le supprimer. Selon la Direction générale des entreprises (DGE), le prétraitement des données est « une étape essentielle pour garantir la performance du système de RAG ».

Femme assise devant un ordinateur portable, des documents imprimés posés à côté sur une table en marbre

Photo : Anna Tarazevich · Pexels

Corrigé le 22/10/2026 : la première version de cet article (23/09/2026) présentait comme établis, sans source, plusieurs constats (la méthode « la plus répandue », la primauté des documents sur le modèle, l'adaptation du RAG à « la grande majorité des cas d'usage d'entreprise », la frontière entre chatbot RAG et agent IA, l'effet des citations sur la confiance, des repères de taille et de chevauchement des fragments (pour les FAQ, 10 à 20 % de chevauchement, là où la source désormais citée n'en prévoit aucun), des durées de déploiement) ; elle exposait l'étude de Stanford sans son périmètre (trois outils juridiques américains testés entre mars et mai 2024) ; elle renvoyait vers des pages du site qui ne traitent pas les sujets annoncés ; elle affirmait enfin que notre méthodologie de test est appliquée aux solutions que nous évaluons, alors que nous n'avons mené à ce jour aucun test pratique de produit de tiers. Notre politique de corrections.

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 produit parfois une réponse plausible mais fausse plutôt que d'admettre qu'il ne sait pas (Kalai et al., arXiv, septembre 2025) — 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 de base se contente de répondre à partir de ce qu'il trouve dans vos documents : son déroulement est fixé à l'avance (chercher, puis rédiger). Selon Anthropic, ce qui distingue un agent IA, c'est que le modèle y dirige lui-même son processus et son usage des outils, alors qu'un « workflow » suit des chemins de code prédéfinis (Building effective AI agents, 19 décembre 2024). 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 surtout sur l'interface, texte ou voix ; en voix, l'étape de récupération s'ajoute au délai de réponse (environ 250 ms sur la plateforme d'agents d'ElevenLabs, selon sa documentation).

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 (Magesh et al., prépublication de mai 2024, publiée en 2025 dans le Journal of Empirical Legal Studies) a posé 202 questions de droit américain, entre mars et mai 2024, à trois outils juridiques commerciaux construits sur une architecture de ce type : Lexis+ AI, Westlaw AI-Assisted Research et Ask Practical Law AI. Ses auteurs rappellent que des éditeurs juridiques présentaient le RAG comme éliminant ou évitant les hallucinations, ou comme garantissant des citations juridiques sans hallucination. Ils ont relevé une hallucination, définie comme une information fausse ou une source citée à tort à l'appui d'une affirmation, dans 17 % à 33 % des réponses selon l'outil, contre 43 % pour GPT-4 interrogé sans base documentaire. Ces chiffres ne valent que pour ces trois produits à cette date : l'étude ne mesure pas des chatbots branchés sur des documents d'entreprise. Brancher un assistant sur des documents change la nature du risque, il ne le supprime pas.

Pourquoi vos documents sont un sujet à part entière

Quel modèle de langage choisir ? La question vient naturellement en premier, mais ce n'est pas forcément la première à poser. Un modèle performant ne corrige pas à lui seul une base documentaire obsolète, contradictoire ou mal structurée : la Direction générale des entreprises (DGE), dans son guide du RAG de novembre 2024, cite la mise en qualité des données (élimination des contradictions internes de la base documentaire) parmi les solutions aux hallucinations qui persistent.

Plusieurs défauts documentaires peuvent dégrader 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 peuvent passer inaperçus pendant une démonstration menée 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 qui mobilise vos équipes : même lorsqu'un intégrateur se charge du prétraitement des données, la DGE juge l'expertise métier du client « indispensable » à ce travail.

Un éventail de fiches cartonnées lignées, posé sur une table en bois sombre
Photo : Pixabay · Pexels

Découpage et indexation : la mécanique discrète qui pèse sur la qualité des réponses

Un modèle de langage ne relit pas, en pratique, 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 peut diluer 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, et pourtant déterminante : un mauvais découpage produit de mauvaises réponses, même avec un modèle performant. 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 repères publiés ne coïncident pas. La DGE se borne à noter que la taille des segments est « un paramètre crucial dans la réussite du RAG », sans en chiffrer. SurrealDB, éditeur de base de données, propose en mai 2026 les repères du tableau ci-dessous, qu'il présente comme des points de départ à ajuster ; Microsoft recommande, pour Azure AI Search, de partir de 512 tokens avec 25 % de chevauchement :

Type de contenu Taille de fragment proposée (SurrealDB) Chevauchement proposé (SurrealDB)
Contenu court : FAQ, fiches produit 128 à 256 tokens Aucun
Questions-réponses généralistes sur des documents (bases de connaissances, wikis internes) 512 à 1 024 tokens 10 à 20 %
Documentation technique longue, articles de recherche, documents juridiques 1 024 à 2 048 tokens 10 à 15 %

Un token est une unité de texte : un caractère, une partie de mot, un mot entier ou un signe de ponctuation. Pour de l'anglais courant, l'aide d'OpenAI donne un repère d'environ 4 caractères par token, soit environ trois quarts de mot, et précise que d'autres langues peuvent avoir un rapport différent : ce n'est qu'un ordre 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 surcoût d'indexation, en temps d'ingestion et en stockage (Bennani et Moslonka, arXiv, janvier 2026 : moteur de recherche SPLADE, questions portant sur Wikipédia en anglais ; les auteurs invitent à valider ce résultat sur des corpus d'entreprise spécialisés).

Dans une recherche sémantique (l'une des trois familles de méthodes que distingue la DGE, avec la recherche lexicale et la recherche hybride), les fragments découpés 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 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 est un sujet à part entière, que cet article ne traite pas.

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 expérience publiée dans les actes de la conférence AAAI 2025 (Ding et al.) a mesuré une hausse significative de la confiance dans les réponses d'un chatbot lorsque des citations les accompagnent, y compris quand ces citations sont aléatoires, et une baisse de confiance chez les participants qui ouvraient les citations. Une source affichée peut donc rassurer sans prouver que la réponse est juste.

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. Notre méthodologie de test prévoit, pour les callbots et les agents IA, un protocole qui comprend une demande hors périmètre ; à ce jour, nous n'avons mené aucun test pratique de produit de tiers (voir la page Rédaction).

Les erreurs qui ruinent un projet RAG

Un projet RAG peut décevoir à cause d'un choix de conception ou d'un défaut de gouvernance identifiable, sans que le modèle de langage soit en cause :

  • 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 peut combler les trous avec une réponse plausible plutôt que d'admettre une limite.
  • Découpage réalisé sans relecture humaine. Un découpage automatique jamais vérifié sur un échantillon peut produire 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 : la DGE cite la gestion des accès (contrôler les droits d'accès) parmi les points à discuter avec un prestataire de RAG.
  • 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 risque de décevoir 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), peut diluer la qualité de récupération et compliquer 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 réduit le risque de déconvenues ; la DGE recommande de sélectionner soigneusement les cas d'usage et d'associer le plus tôt possible les utilisateurs finaux. Pour décrire un 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 (2024) sur trois outils juridiques commerciaux construits sur ce principe a relevé une hallucination, c'est-à-dire une information fausse ou une source citée à tort, dans 17 à 33 % des réponses à 202 questions de droit américain, alors que des éditeurs présentaient la technique comme éliminant ou évitant les hallucinations. La qualité de la base documentaire et la conception du système restent déterminantes.

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

Selon la Direction générale des entreprises (DGE), le RAG convient aux tâches qui demandent d'interroger une base de connaissances interne et de répondre en langage naturel, et en général moins aux comparaisons entre documents ; elle le juge aussi moins adapté aux synthèses d'un grand nombre de documents, tout en notant que les méthodes de RAG les plus récentes tendent à pallier cette faiblesse. Il permet de mettre à jour les réponses simplement en mettant à jour les documents, sans réentraîner de modèle, et de citer ses sources. Le fine-tuning répond à un autre besoin : OpenAI le rattache à l'apprentissage d'une tâche pour l'exécuter de façon régulière et fiable (format, ton, style), alors que mettre à jour ce que sait un modèle suppose de le réentraîner avec les nouveaux documents (Meta AI, 2020). Les deux approches ne s'excluent pas : OpenAI les décrit comme « additive, not exclusive » dans son guide d'optimisation de la précision.

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 du mode de déploiement et de la complexité du cas d'usage. À titre indicatif, la Direction générale des entreprises (DGE) compte environ 3 mois pour une solution personnalisée installée par un intégrateur, et 3 mois pour un produit minimum viable développé en interne, avec quelques mois de plus pour un outil fonctionnel ; elle juge une solution SaaS plus adaptée à qui veut un déploiement plus rapide, sans chiffrer de durée. Le même guide cite, pour un même projet, 6 mois en hébergement local contre 2 mois dans le cloud. Il décrit aussi le prétraitement des données (nettoyage, découpage, vectorisation) comme une étape essentielle du projet.

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 — trois outils juridiques commerciaux construits sur ce principe, testés par une étude de Stanford entre mars et mai 2024, ont produit une hallucination dans 17 à 33 % de leurs réponses. Au-delà du choix du modèle de langage, la qualité d'un projet RAG dépend de l'état de la base documentaire : versions à jour sans contradictions, découpage soigné, droits d'accès contrôlés et citation des sources utilisées. La Direction générale des entreprises présente d'ailleurs le prétraitement des données comme une étape essentielle à la performance du système. Un projet peut échouer faute d'avoir fait le travail, moins spectaculaire, de mettre de l'ordre dans les documents avant de les brancher sur un assistant.

Sources

Pour aller plus loin

Parler de votre projet