Audit RAG : améliorer ou remplacer votre chatbot interne

Le scénario revient dans beaucoup des DSI que nous rencontrons. Une équipe technique a monté un RAG maison en 2024 ou 2025 : un chatbot interne branché sur SharePoint ou Confluence, une base vectorielle, l'API d'un grand modèle. La démo a convaincu, l'outil est en production, et il déçoit : il répond à côté, ou trop lentement pour qu'on prenne la peine d'attendre. Gartner prévoyait qu'au moins 30 % des projets d'IA générative seraient abandonnés après le POC avant fin 2025. Pour ceux qui ont survécu, la question suivante est celle de l'audit RAG : d'où viennent ces défauts, et que faire ?

Le réflexe est de changer de modèle. C'est rarement là que se trouve le problème. Nous l'avons constaté sur notre propre RAG : sur le benchmark public FinanceBench, remplacer Qwen3.8 27B, le modèle retenu pour notre benchmark, par Gemini 3.8 Flash n'a fait apparaître aucune différence significative, pas plus qu'augmenter le budget de réflexion du modèle. Un RAG plafonne d'abord à cause de son architecture, pas de son LLM.

Cet article donne une grille d'audit en sept couches, avec des tests que vous pouvez lancer cette semaine sur votre propre outil, une méthode pour mesurer, et des critères pour décider s'il faut l'améliorer ou le remplacer. Les tests viennent de ce que nous avons dû construire pour faire tenir notre propre RAG sur plus de 100 000 documents chez plusieurs de nos clients.

Quels symptômes montrent qu'un RAG interne doit être audité ?

Un utilisateur ne dit jamais « le rappel de la recherche est mauvais ». Il dit « il ne trouve pas ». Traduire chaque plainte en couche technique, c'est déjà la moitié de l'audit. Scott Barnett et ses coauteurs ont recensé sept points de défaillance d'un RAG à partir de trois déploiements. Le tableau ci-dessous les reprend et ajoute ceux que nous rencontrons en entreprise : synchronisation, droits, exploitation.

Les mêmes auteurs tirent de leurs cas une leçon qui vaut pour tout RAG d'entreprise : sa validation n'est possible qu'en exploitation, et sa robustesse se construit au fil de l'usage plutôt qu'à la conception. Un RAG livré sans mesure en production se dégrade sans que personne ne le voie.

Pourquoi un RAG maison plafonne : la recherche en un seul passage

La plupart des RAG construits en suivant les tutoriels de 2023 et 2024 suivent le même schéma. La question est transformée en vecteur, la base renvoie les 5 ou 10 passages les plus proches, le modèle rédige la réponse à partir de ces passages. Ce schéma marche bien pour « quelle est notre politique de télétravail ? ». Il échoue dès que la question demande de comparer plusieurs documents, de lister, de compter ou de lire un document long.

FinanceBench le montre de façon chiffrée. Ce jeu de questions d'analystes financiers, publié par Patronus AI fin 2023, oblige à chercher la réponse dans des centaines de rapports annuels et trimestriels. Selon la façon dont le système cherche, les résultats changent du tout au tout :

Les chiffres de Mistral et d'ATG sont publiés par chaque éditeur sur sa propre solution. Nous publions le protocole et le verdict de chaque question, pour que chacun puisse vérifier.

Changer de LLM ne fait pas passer d'une ligne à l'autre du tableau. Avec le même modèle, Mistral passe de 22,7 % à 78,7 % en changeant uniquement la façon de chercher. Notre expérience va dans le même sens : sur FinanceBench, Qwen3.8 27B et Gemini 3.8 Flash obtiennent des scores sans écart significatif, et donner au modèle plus de budget de réflexion n'y change rien non plus. Pour retrouver les bons passages, le modèle pèse peu.

Il fait en revanche une grosse différence ailleurs : pour élaborer un plan de recherche complexe en plusieurs étapes, pour rédiger une réponse longue et structurée, ou pour interpréter une question mal formulée. Dans un chatbot interne, où les questions arrivent rarement aussi précises que dans un benchmark, ces écarts se voient. Si votre RAG est construit en un passage, l'audit conclura probablement qu'il faut changer d'architecture, pas de modèle. Nous détaillons ce passage du RAG linéaire au RAG agentique dans notre guide.

Pourquoi un chatbot interne lent finit abandonné

Vos salariés ne comparent pas votre assistant à l'ancien moteur de recherche de l'intranet. Ils le comparent à ChatGPT, dont la réponse commence à s'écrire presque aussitôt, et aux Aperçus IA que Google affiche en haut de ses résultats. À côté, un chatbot interne qui laisse tourner un sablier pendant vingt secondes perd la comparaison, même quand sa réponse est meilleure. Personne ne vient se plaindre : les utilisateurs retournent chercher dans SharePoint ou demandent au collègue d'à côté, et la courbe d'usage baisse. Un assistant juste mais lent finit délaissé. Un audit qui ne mesure que la justesse des réponses passe à côté.

Les seuils sont connus depuis longtemps en ergonomie. Jakob Nielsen les résume ainsi : une seconde est la limite pour que le fil de pensée de l'utilisateur ne soit pas interrompu, dix secondes celle pour garder son attention. Au-delà, il faut montrer où en est le traitement. Un RAG qui enchaîne calcul du vecteur, recherche, reclassement et rédaction sans rien afficher dépasse facilement ces seuils.

La recherche agentique, qui fait gagner 56 points sur FinanceBench, rend le problème plus aigu : plusieurs recherches prennent plus de temps qu'une seule. Il n'y a pas à choisir entre justesse et vitesse pour autant. Trois leviers permettent d'avoir les deux :

• réserver le raisonnement long aux questions qui le demandent, et répondre tout de suite aux questions simples ;
• montrer le travail pendant qu'il se fait : recherches lancées, documents consultés, puis texte qui s'écrit au fil de la génération ;
• lancer les étapes en parallèle et donner à chacune un délai maximal, pour qu'un composant lent ne retienne pas toute la réponse.

Chez ATG, un petit modèle classe chaque question en 300 millisecondes pour l'orienter vers un modèle rapide ou vers un modèle de raisonnement. Le vecteur de la question est demandé à deux fournisseurs en même temps, et le plus rapide l'emporte. Les recherches partent en parallèle avec un budget de 8 secondes, le reclassement en a 2, et un fournisseur de modèle qui n'a pas commencé à répondre au bout de 5 secondes est remplacé par un autre. Pendant ce temps, l'utilisateur voit chaque outil appelé et sa durée, puis la réponse s'écrire mot à mot. Sur FinanceBench, où une question d'analyste demande souvent plusieurs recherches dans des centaines de rapports, la réponse complète arrive en 10,5 secondes en moyenne.

Comment auditer un RAG : la grille en sept couches

Chaque couche ci-dessous liste ce qu'il faut vérifier et des tests concrets. La plupart se lancent sans accès au code : un compte utilisateur et quelques documents dont vous connaissez le contenu suffisent. Pour chaque couche, nous indiquons ce que fait ATG, à titre de point de comparaison.

1. Ingestion : ce que votre RAG a vraiment lu

La qualité d'une réponse ne dépassera jamais la qualité de ce qui a été indexé. PDF scannés, tableaux sur plusieurs pages, fichiers Excel, schémas : une grande partie des erreurs naît ici, bien avant le modèle.

• Prenez un tableau de tarifs qui s'étale sur trois pages et posez une question sur une ligne de la dernière page. Si la réponse confond les colonnes, le fragment qui contient la page 3 a perdu l'en-tête du tableau.
• Demandez un chiffre précis tiré d'un fichier Excel. Vérifiez qu'il vient de la cellule, pas d'un résumé rédigé par un modèle au moment de l'indexation.
• Déposez un PDF scanné, puis retrouvez-le par une phrase qu'il contient.
• Posez une question dont la réponse se trouve uniquement dans un schéma ou une capture d'écran.

Chez ATG, quand un tableau est découpé, chaque suite répète l'en-tête et la légende : sans cela, la deuxième moitié d'un tableau n'est qu'une suite de chiffres sans colonnes. Les tableurs sont relus à la source au moment de répondre, feuilles masquées et formules calculées comprises. Les descriptions d'images produites par un modèle de vision sont marquées comme à vérifier, parce qu'elles se trompent souvent, et l'agent peut les contrôler sur l'image d'origine.

2. Connecteurs et synchronisation : ce qui se passe au bout de six mois

Brancher une source prend une journée. La garder synchronisée pendant des mois, sans rien perdre ni dupliquer, est la partie difficile, et la moins visible en démo.

• Renommez ou déplacez un document dans votre GED. Combien de temps l'assistant le cite-t-il sous son ancien nom ou dans son ancien dossier ?
• Demandez à l'équipe ce qui se passe si l'API de la GED renvoie une liste vide à cause d'un incident. Si la réponse est « on supprime ce qui n'est plus listé », un incident d'une minute peut vider votre base de connaissances.
• Même question pour le compte de service d'un connecteur dont le mot de passe expire.
• Cherchez dans l'index une page « Veuillez vous connecter » ou un captcha indexé à la place du vrai contenu d'un site.

Chez ATG, une baisse de plus de 30 % du nombre de documents d'une source bloque toute suppression jusqu'à ce qu'un second scan complet la confirme. Un échec d'authentification arrête le rafraîchissement au lieu d'être interprété comme « contenu supprimé ». Le robot qui indexe les sites web reconnaît les captchas, les pages de connexion et les pages « accès refusé », y compris en français.

3. Recherche : trouver le bon passage parmi des centaines de milliers

• Cherchez un document par une référence exacte : « NF-2024-117 », un code produit, un numéro de contrat. La recherche vectorielle seule échoue souvent sur ce cas, parce qu'une référence n'a pas de sens que les embeddings sauraient capter. C'est le rôle de la recherche hybride.
• Limitez la recherche à un petit dossier et comparez les résultats avec ce que vous savez y trouver.
• Demandez « combien de procédures parlent de X ? » ou « liste tous les contrats signés en 2025 ». Un RAG qui ramène 10 passages ne peut pas compter : il extrapole à partir de ce qu'il a vu.
• Posez une question qui oblige à lire en entier un cahier des charges de 400 pages, par exemple « liste toutes les exigences de sécurité ».

Chez ATG, la recherche combine un index lexical (BM25), un index vectoriel et un reranker qui reclasse les résultats. Le deuxième test nous a coûté cher à comprendre : sur 341 000 fragments, une recherche filtrée naïve prenait 13,5 secondes, et forcer l'index vectoriel approximatif (HNSW) ne retrouvait aucun des 8 résultats attendus quand le filtre couvrait 2,5 % de la collection. Le système choisit désormais sa méthode selon la taille du filtre : 369 millisecondes au 90e centile, avec 99,8 % de rappel. Les index vectoriels approximatifs perdent des résultats sans le signaler. Les questions d'inventaire, elles, passent par des requêtes SQL déterministes, avec un contrôle qui vérifie que toutes les pages de résultats ont été lues avant de déclarer la liste complète.

4. Génération : ce que le modèle fait des passages trouvés

• Posez une question dont vous savez que la réponse n'est pas dans les documents. Le bon comportement est « je ne trouve pas cette information », pas une réponse plausible.
• Soumettez un document plus long que la fenêtre de contexte du modèle. L'assistant dit-il qu'il n'a pas tout lu, ou coupe-t-il la fin sans prévenir ?
• Pour un assistant connecté à une base de données, posez une question en deux parties. Signale-t-il qu'il n'a répondu qu'à l'une des deux ?
• Vérifiez que chaque réponse cite ses sources, avec un lien qui mène au passage exact.

Même des outils professionnels se trompent. Selon des chercheurs de Stanford, Lexis+ AI et les outils de Thomson Reuters hallucinent entre 17 % et 33 % du temps sur des questions juridiques. Si des éditeurs spécialisés n'y échappent pas, un RAG interne non mesuré n'a aucune raison d'y échapper. Chez ATG, la lecture d'un document entier est plafonnée, et au-delà l'outil refuse et oriente l'agent vers une exploration passage par passage plutôt que de tronquer en silence. Une réponse du type « je vais relire les pages restantes » alors que rien n'a été fait est détectée et relancée, puis signalée comme un échec si la relance ne suffit pas.

5. Droits d'accès, sécurité et souveraineté

Un RAG met la connaissance de toute l'entreprise derrière une seule zone de saisie. C'est aussi une surface d'attaque.

• Retirez à un utilisateur l'accès à un document. Peut-il encore le retrouver dans une ancienne conversation avec l'assistant ?
• Demandez où sont stockés les vecteurs, et quels fournisseurs reçoivent le contenu des documents au moment de l'indexation (description d'images, étiquetage, traduction), pas seulement au moment de la réponse.
• Lisez les journaux applicatifs : contiennent-ils des extraits de documents ou les questions posées par les salariés ?
• Pour un assistant RH ou juridique : qui, à la DSI, peut lire les questions posées ?

Chez ATG, les droits sont vérifiés à chaque lecture, y compris pour un tableau déjà extrait dans une conversation. La politique de fournisseurs (Europe ou monde) se fixe pour toute l'organisation et s'applique aussi au traitement des documents, car un mode « souverain » limité à la réponse finale laisse passer l'essentiel. Un agent peut être marqué privé : ses conversations deviennent illisibles pour les administrateurs, les statistiques restent disponibles. Pour aller plus loin sur l'hébergement et le droit applicable, voir notre page IA souveraine.

6. Exploitation : vitesse, pannes et charge

• Chronométrez une dizaine de vraies questions, simples et complexes : délai avant le premier signe de vie à l'écran, puis délai avant la réponse complète. Posez les mêmes à ChatGPT, c'est la comparaison que font vos utilisateurs.
• Dites « bonjour » ou posez une question triviale. Si la réponse prend autant de temps qu'une analyse, toutes les questions passent par la même chaîne lourde.
• Que voient vos utilisateurs quand votre unique fournisseur de modèle est en panne ou vous limite ? Nous avons détaillé ce risque dans les erreurs qui arrivent après le POC.
• Déposez 50 fichiers d'un coup et observez les temps de traitement.
• Sur mobile, posez une question longue, verrouillez l'écran 30 secondes, revenez. La réponse est-elle là ?
• Si un traitement d'indexation plante en cours de route, savez-vous quels documents sont à jour, à moitié traités ou manquants ?

Le test des 50 fichiers vient d'un incident réel chez nous : 56 fichiers déposés en même temps avaient déclenché 56 recalculs complets, qui ont tourné en file pendant deux heures. Depuis, ces traitements sont regroupés. Chez ATG, chaque tâche dispose de plusieurs fournisseurs de modèles avec bascule automatique, et une réponse continue de se générer même si la connexion du navigateur tombe.

7. Mesure et amélioration continue

• Après le dernier changement de modèle ou de prompt, comment avez-vous su que l'assistant ne répondait pas moins bien qu'avant ?
• Que deviennent les avis négatifs des utilisateurs ? Sont-ils lus, classés par cause, suivis jusqu'à correction ?
• Si deux versions d'une procédure coexistent dans vos sources, laquelle l'assistant cite-t-il ?
• Quand une réponse métier est fausse, qui corrige les instructions : l'expert du domaine, ou un ticket à la DSI ?

Chez ATG, chaque avis négatif devient une tâche classée par cause : instructions de l'agent, documentation, recherche, source, bug. Les responsables métier modifient et testent eux-mêmes les instructions de leur agent avant publication. La plateforme repère aussi les contradictions entre documents, une cause fréquente de réponses fausses alors que le RAG fonctionne techniquement. Sans cette boucle, la qualité baisse à mesure que les documents changent.

Comment évaluer un RAG : jeu de test et LLM juge

Corriger sans mesurer revient à déplacer les erreurs. Avant de toucher au système, il faut un moyen de savoir s'il répond mieux ou moins bien qu'hier.

Un jeu de test tiré des vraies questions

Constituez 100 à 300 questions à partir des journaux d'usage, chacune avec sa bonne réponse et le document qui la contient. Mélangez les types : questions simples, références exactes, comparaisons entre plusieurs documents, comptages, documents anciens, et questions hors périmètre dont la bonne réponse est « je ne sais pas ». Barnett et ses coauteurs notent que ces paires question-réponse propres à l'entreprise manquent souvent : les construire est le premier livrable d'un audit, et un actif qui vous reste quelle que soit la suite. Rejouez ce jeu après chaque changement de modèle, de prompt ou de traitement des documents.

Le LLM juge

Noter des centaines de réponses à la main chaque semaine est irréaliste. Un LLM juge compare chaque réponse à la réponse attendue et la note. La méthode est sérieuse : dans l'étude de Zheng et ses coauteurs, GPT-4 rejoignait les préférences humaines dans plus de 80 % des cas, autant que deux évaluateurs humains entre eux. Le même papier décrit aussi ses biais : préférence pour la première réponse présentée, pour les réponses longues, pour ses propres réponses. Faites relire un échantillon à la main. Sur FinanceBench, nos verdicts sont notés par un LLM juge puis revus par un humain.

Ce qu'un score ne montre pas

Un jeu de test ne voit que les questions qu'il contient. Un document jamais indexé, une source vidée par un incident de synchronisation, un droit d'accès mal hérité ou une panne de fournisseur passent inaperçus tant qu'aucune question ne les touche, et les questions d'inventaire y sont souvent absentes. Un jeu de test évalue la chaîne de réponse, un audit évalue le système entier.

Améliorer ou remplacer votre RAG : comment décider

Un audit débouche sur l'une de ces situations :

Le dernier cas existe. Quand le RAG est votre produit, le construire est votre métier. Dans les autres cas, le prototype coûte peu. Ce qui coûte, c'est tout ce qui l'entoure, et cela ne s'arrête jamais. Les modèles changent à chaque version, les API des sources évoluent, les documents se contredisent. Le rapport du MIT sur l'IA générative en entreprise donne un ordre de grandeur : les solutions achetées à des éditeurs spécialisés réussissent environ 67 % du temps, les développements internes trois fois moins souvent. La méthode de ce rapport est discutée, mais l'écart correspond à ce que nous voyons sur le terrain.

Ce qu'il faut garder si vous remplacez

Le moteur se remplace. Votre connaissance des usages, non. Avant de changer de solution, sauvegardez :

• les journaux de questions, qui disent ce que les utilisateurs cherchent vraiment ;
• le jeu de test et ses réponses attendues ;
• le vocabulaire métier : acronymes, noms de produits, anciennes appellations ;
• les instructions métier et la liste des sources qui font autorité.

On peut aussi remplacer le moteur et garder le reste. Une solution comme ATG peut servir de moteur derrière votre interface existante, par API ou par un widget intégré au portail que vos équipes utilisent déjà.

Les contrepoints à garder en tête

Un éditeur crée une dépendance. Vérifiez la réversibilité (export des données, des conversations et des réglages), le lieu d'hébergement et le droit applicable à la maison-mère. Les benchmarks qu'un éditeur publie sur lui-même, les nôtres compris, restent des déclarations : demandez à tester sur vos propres documents, avec votre jeu de test.

Ce que propose ATG pour un RAG qui déçoit

Deux portes d'entrée, selon où vous en êtes.

Faire auditer votre RAG, même si nous ne l'avons pas construit. Notre audit combine des entretiens avec les concepteurs et les utilisateurs, une lecture de la conception, des tests sur vos documents avec des questions dont la réponse est connue, et l'analyse des journaux réels quand ils existent. Comptez de quelques jours à quelques semaines selon le périmètre. Vous repartez avec un diagnostic écrit et des recommandations classées par impact, des réglages rapides jusqu'au changement d'approche. Si un outil tiers répond mieux à votre besoin que notre plateforme, nous vous le disons.

Remplacer le moteur par une solution qui tourne déjà. Les mécanismes décrits dans cette grille existent dans le RAG d'ATG : connecteurs vers vos outils, reprise des droits d'accès, recherche hybride et agentique, aiguillage entre modèle rapide et modèle de raisonnement, réponses affichées au fil de l'eau, citations, campagnes d'évaluation, suivi des avis. Hébergement en Europe ou sur vos serveurs. Sur les projets que nous avons menés, le coût total baisse d'environ 80 % par rapport à un développement interne.

Questions fréquentes sur l'audit d'un RAG

Comment auditer un RAG d'entreprise ?

En traduisant chaque plainte des utilisateurs en couche technique, puis en testant sept couches : ingestion des documents, connecteurs et synchronisation, recherche, génération, droits et sécurité, exploitation, mesure. La plupart des tests se lancent avec un simple compte utilisateur : un tableau sur trois pages, une référence exacte, une question de comptage, une question hors périmètre. On complète par un jeu de questions dont la réponse est connue, rejoué et noté.

Comment améliorer un RAG qui donne de mauvaises réponses ?

Mesurer d'abord, avec un jeu de 100 à 300 questions réelles, puis localiser la panne. Si le bon passage n'est pas retrouvé, il faut agir sur l'ingestion ou la recherche (recherche hybride, reranker, recherches multiples). Si le passage est retrouvé mais mal utilisé, sur la génération. Changer de modèle aide rarement à retrouver les bons passages : dans nos essais sur FinanceBench, passer de Qwen3.8 27B à Gemini 3.8 Flash n'a pas changé le score de façon significative, alors que Mistral passe de 22,7 % à 78,7 % de bonnes réponses en changeant seulement la façon de chercher.

Comment évaluer la qualité d'un RAG ?

Avec un jeu de test tiré des vraies questions, chacune avec sa bonne réponse et son document source, noté par un LLM juge et relu en partie par un humain. Ce score ne remplace pas un audit, qui vérifie aussi l'indexation, la synchronisation des sources et les droits d'accès.

Pourquoi mon RAG ne trouve-t-il pas un document qui existe ?

Trois causes reviennent le plus souvent. Le document a été mal extrait ou jamais indexé (PDF scanné, échec silencieux). Le bon passage est retrouvé mais classé au-delà des 5 ou 10 résultats transmis au modèle. Ou la question contient une référence exacte, un code ou un nom propre, que la recherche vectorielle seule retrouve mal : il faut alors une recherche hybride qui combine mots exacts et sens.

Quel temps de réponse viser pour un chatbot interne ?

Un premier signe de vie à l'écran en moins d'une seconde, et le début de la réponse en quelques secondes pour une question simple : c'est ce à quoi ChatGPT et les Aperçus IA de Google ont habitué les utilisateurs. Une question qui demande plusieurs recherches peut prendre plus longtemps, à condition que l'outil montre ce qu'il fait. En ergonomie, dix secondes sans retour sont la limite au-delà de laquelle on perd l'attention de l'utilisateur. Pour comparaison, ATG répond en 10,5 secondes en moyenne aux questions d'analyste financier de FinanceBench.

Faut-il changer de LLM pour améliorer un RAG ?

Rarement en premier. La plupart des déceptions viennent de ce que le modèle reçoit, pas de ce qu'il en fait. Sur FinanceBench, GPT-4 Turbo répond juste à 19 % des questions avec une recherche simple et à 85 % quand on lui donne la bonne page. Un modèle plus puissant aide ensuite, surtout pour planifier des recherches complexes, rédiger des réponses longues et comprendre des questions mal formulées.

Combien de temps prend l'audit d'un RAG ?

De quelques jours à quelques semaines selon le périmètre : nombre de sources, accès à la documentation technique et aux journaux d'usage, existence ou non d'un jeu de test. La construction de ce jeu de test prend souvent une bonne part du temps, et reste utile quelle que soit la décision prise ensuite.

Faut-il remplacer un chatbot interne développé en interne ?

Pas forcément. Si l'audit montre des causes localisées, on corrige. Si l'architecture fait une seule recherche par question, si les connecteurs cassent régulièrement ou si personne ne mesure la qualité, remplacer le moteur coûte souvent moins cher que le reconstruire. On garde alors les journaux, le jeu de test et le vocabulaire métier, et on peut conserver l'interface existante.

---

Un RAG interne qui déçoit a le plus souvent été construit pour la démo, puis livré sans les couches qui le rendent juste et rapide en production. L'audit dit lesquelles manquent. Reste une décision économique : les construire vous-même, ou partir d'une base qui les a déjà. Pour en parler sur votre cas, réservez un échange.