Imagine la scène. Tu as mis un chatbot sur ton site, branché sur ta documentation produit. Un client demande si telle option est incluse dans son forfait. Le chatbot répond oui, avec assurance, en trois lignes bien tournées.
La réponse est fausse. L'option n'est pas incluse.
Personne ne s'en aperçoit. Pas le client, qui n'a aucune raison de douter. Pas toi, qui ne lis pas les conversations une par une. Vous le découvrirez dans trois semaines, au moment de la facture, quand il faudra choisir entre offrir l'option et expliquer à un client mécontent que ton assistant s'est trompé.
Le problème n'est pas l'erreur, c'est l'aplomb
Un moteur de recherche qui ne trouve rien affiche zéro résultat. C'est frustrant, mais c'est honnête : l'utilisateur sait qu'il doit chercher ailleurs.
Un modèle de langage ne fonctionne pas comme ça. Confronté à une question dont la réponse n'est pas dans ce qu'il a sous les yeux, sa pente naturelle est de combler le trou avec ce qui ressemble le plus à une bonne réponse. Le résultat est plausible, bien écrit, cohérent avec le reste — et faux.
C'est ce qui rend le problème vicieux : l'erreur ne ressemble pas à une erreur. Elle ressemble exactement à une bonne réponse. Un chatbot qui invente est donc pire qu'un moteur de recherche, parce qu'il retire à l'utilisateur le seul signal qui lui permettait de se méfier.
Les deux propriétés qui changent tout
La bonne nouvelle, c'est que le problème est traitable. Deux propriétés suffisent à faire basculer un assistant du côté utilisable, et aucune des deux ne s'obtient en branchant simplement un modèle sur tes documents.
Première propriété : chaque affirmation renvoie à sa source. Pas une liste de documents consultés en bas de page — un lien précis, derrière chaque phrase, vers le passage qui la justifie. La différence est énorme : ton client peut vérifier en un clic, et surtout, toi tu peux auditer.
Deuxième propriété : l'assistant s'abstient. Quand la réponse n'est pas dans la documentation, il doit dire « ce n'est pas couvert » au lieu de produire une supposition élégante. Cette phrase-là vaut plus cher que dix réponses brillantes.
Ces deux propriétés se construisent volontairement. Elles ne viennent pas toutes seules.
La question que personne ne pose
Voici la question à poser à quiconque te propose un chatbot sur ta base de connaissances, et elle tient en cinq mots : comment sais-tu que ça marche ?
La réponse habituelle, c'est qu'on a essayé quelques questions et que les réponses avaient l'air bonnes. C'est une impression, pas une mesure. Et une impression se forme sur les questions qu'on a en tête — c'est-à-dire précisément celles auxquelles le système répond bien.
Une mesure, c'est autre chose : une liste de questions écrites à l'avance, dont on connaît la bonne page de réponse, qu'on repasse à chaque modification. Y compris des questions hors sujet, dont la bonne réponse est un refus.
Ce que la mesure a révélé chez moi
J'ai construit un assistant de ce type sur la documentation d'un outil que j'utilise, et je l'ai mesuré sur vingt-cinq questions de référence. Deux choses en sont sorties, et aucune n'était visible en relisant le code.
Ma recherche « améliorée » dégradait les résultats. J'avais combiné deux méthodes de recherche en supposant que deux valent mieux qu'une. La mesure a montré que la combinaison faisait moins bien que l'une des deux toute seule : la seconde méthode remontait du bruit qui poussait les bonnes pages hors de la sélection. Il a fallu la doser pour qu'elle apporte quelque chose.
La recherche avait raison, la réponse avait tort. Le système trouvait la bonne page dans 100 % des cas, mais ne la citait correctement que dans 82 % — parce que je ne transmettais au modèle que les huit premiers passages, et que de bonnes pages arrivaient en neuvième position. Elles étaient trouvées, jamais lues.
Deux réglages, deux corrections, zéro ligne de code visiblement fautive. C'est tout l'intérêt de mesurer : sans jeu de référence, ces deux défauts partaient en production et personne ne les aurait jamais vus.
Les questions à poser avant de signer
Si tu envisages ce genre d'outil, voici ce qui mérite d'être demandé, quel que soit le prestataire :
- Que répond l'assistant à une question dont la réponse n'est pas dans mes documents ? Montrez-le-moi en direct.
- Puis-je remonter de n'importe quelle phrase de la réponse au passage exact qui la justifie ?
- Sur quel jeu de questions la qualité a-t-elle été mesurée, et quels sont les chiffres ?
- Quand ma documentation change, que devient l'ancienne version ? Est-ce que l'assistant peut encore citer une page qui n'existe plus ?
- Combien coûte une question, et qu'est-ce qui m'empêche de recevoir une facture surprise ?
Un prestataire qui répond précisément à ces cinq questions a déjà fait le travail. Un prestataire à qui elles n'ont jamais été posées va te répondre que le modèle est très performant — ce qui n'est une réponse à aucune des cinq.
Ce que ça ne résout pas
Soyons honnête sur les limites, parce qu'elles sont réelles.
Citer ses sources ne rend pas l'assistant infaillible : il peut citer la bonne page et mal la résumer. Le lien de source ne supprime pas l'erreur, il la rend détectable — ce qui est déjà tout ce qu'on peut demander.
Un jeu de vingt-cinq questions est un garde-fou, pas une preuve statistique. Il détecte une régression franche, il ne départage pas deux réglages proches. C'est mieux que rien, et très en dessous d'une certitude.
Enfin, la qualité des réponses est plafonnée par celle de ta documentation. Si deux de tes pages se contredisent, un bon assistant signalera la contradiction — il ne la tranchera pas à ta place.
Vous pouvez l'essayer
L'assistant dont je parle est en ligne, et le code est public. Pose-lui une question hors sujet pour voir comment il refuse, c'est le test le plus parlant : noriax.fr/demo/assistant-n8n — et le code, mesures comprises, ici : github.com/gregoirlong-sys/rag-assistant-n8n.
C'est un projet que j'ai conçu et publié moi-même, pas une commande client. Si tu te demandes ce que ça donnerait sur ta propre documentation, c'est typiquement le genre de sujet qui se clarifie en quinze minutes d'appel.
