Une hallucination IA est une réponse fausse ou inventée qu'un modèle de langage produit avec assurance. L'IA invente parce qu'elle prédit le texte le plus probable, pas parce qu'elle vérifie un fait : quand l'information lui manque, elle comble quand même le vide. On peut réduire fortement le phénomène, on ne le supprime pas.
Pour un chatbot d'entreprise, la réduction passe par le RAG (Retrieval-Augmented Generation), qui oblige le modèle à répondre depuis vos documents, puis par des garde-fous : sources affichées, seuil de confiance, réponse « je ne sais pas » et supervision humaine. Même ainsi, des erreurs subsistent : une étude de Stanford sur des outils de recherche juridique fondés sur le RAG a mesuré des hallucinations dans 17 à 33 % des réponses testées, soit moins qu'un modèle généraliste, mais loin de zéro (Magesh et al., 2024).
Ce guide définit l'hallucination IA, explique ses causes, montre ce que le RAG change pour un chatbot, détaille les garde-fous à déployer et la façon de tester la fiabilité avant la mise en production. Il se termine par une checklist et une FAQ de 9 questions.
Sommaire
Qu'est-ce qu'une hallucination IA ?
Une hallucination IA (on dit aussi « confabulation ») est un contenu faux, inventé ou non fondé, généré par un modèle d'IA et présenté comme s'il était exact. Le modèle ne ment pas : il produit une suite de mots plausible, sans mécanisme interne qui distingue le vrai du vraisemblable.
Le phénomène touche tous les modèles de langage (ChatGPT, Claude, Gemini, Mistral), à des degrés variables selon la tâche, la question et le contexte fourni.
Les trois formes d'hallucination à connaître
- Hallucination factuelle : le modèle affirme un fait inexact (une date, un chiffre, une clause, une référence juridique qui n'existe pas).
- Hallucination d'ancrage : même avec des documents fournis, la réponse s'en écarte ou ajoute des détails absents de la source.
- Hallucination de raisonnement : les faits de départ sont justes, mais la conclusion tirée ne l'est pas (calcul faux, condition mal appliquée).
Un cas réel : le chatbot d'Air Canada
En février 2024, un tribunal canadien (décision Moffatt v. Air Canada, 2024 BCCRT 149) a jugé la compagnie responsable des informations erronées données par son chatbot sur les tarifs de deuil. Le chatbot affirmait qu'un remboursement rétroactif était possible, ce que la politique de la compagnie contredisait. Le tribunal a retenu que l'entreprise n'avait pas pris les précautions raisonnables pour garantir l'exactitude de son chatbot (analyse du cabinet McCarthy Tétrault).
Le point à retenir pour une PME : l'hallucination n'est pas qu'un défaut technique, c'est un risque qui engage l'entreprise qui déploie le chatbot.
Pourquoi un chatbot IA hallucine-t-il ?
Un LLM (Large Language Model) comme GPT-4, Gemini ou Claude ne « sait » rien au sens propre du terme. Il prédit le token le plus probable à chaque étape de génération, sur la base de milliards de paramètres appris lors de l'entraînement. Il n'a pas accès à la vérité, il a accès à des probabilités statistiques.
Quand vous lui posez une question sur votre produit, votre tarification ou votre procédure interne, le modèle n'a aucune source fiable à laquelle se référer. Il extrapole à partir de patterns généraux. Et si aucun pattern proche n'existe dans ses données d'entraînement, il génère quand même une réponse, souvent plausible en surface, fausse dans les détails.
Les 3 causes mécaniques des hallucinations
Comprendre les causes aide à choisir les bons garde-fous.
- Absence de base de connaissance ancrée : le modèle n'a pas accès à vos documents internes. Il génère depuis son entraînement général, qui ne contient aucune information sur votre produit, vos tarifs ou vos procédures spécifiques.
- Sycophanie : les LLM sont entraînés par renforcement humain (RLHF) à produire des réponses qui semblent utiles et satisfaisantes. Admettre « je ne sais pas » est peu valorisé lors de l'entraînement, inventer une réponse plausible l'est davantage.
- Fenêtre contextuelle saturée : dans une conversation longue ou avec un contexte chargé, les informations importantes peuvent « sortir » de la fenêtre d'attention du modèle. Les informations récentes écrasent les plus anciennes, créant des incohérences.
Ce que les études disent vraiment
Les taux d'hallucination dépendent fortement de la tâche, du modèle et du domaine : aucun chiffre unique ne vaut pour tous les cas. Les chercheurs de Stanford ont comparé des outils de recherche juridique avec RAG à un modèle généraliste : les outils avec RAG hallucinent moins, mais entre 17 % et 33 % de leurs réponses restaient problématiques (Magesh et al., 2024).
Le RAG réduit le risque, il ne le supprime pas. Méfiez-vous de tout éditeur qui promet « zéro hallucination » : l'étude de Stanford a justement été menée pour vérifier ce type de promesse.
Hallucination vs erreur factuelle : la distinction qui compte
Une hallucination, c'est une affirmation inventée présentée avec assurance. Une erreur factuelle, c'est une information fausse issue de données périmées. Les deux sont problématiques, mais leurs remèdes diffèrent.
Le RAG corrige les hallucinations en ancrant les réponses sur des sources réelles. La mise à jour régulière de votre base documentaire corrige les erreurs factuelles. Les deux mécanismes sont complémentaires, et tous deux sont intégrés dans l'architecture Heeya.
Le RAG réduit-il vraiment les hallucinations ?
Oui, à condition que le RAG soit correctement implémenté, et sans jamais atteindre zéro erreur. C'est la nuance que les vendeurs de chatbots oublient souvent.
Pour aller en détail sur le mécanisme, consultez notre article qu'est-ce que le RAG. En résumé : le RAG découpe vos documents en chunks (morceaux), les convertit en vecteurs numériques stockés dans une base vectorielle (chez Heeya : Qdrant), puis, à chaque question utilisateur, récupère les chunks les plus pertinents et les injecte dans le prompt avant que le LLM génère sa réponse.
Ce que le RAG change concrètement
Sans RAG, la question « Quels sont vos délais de livraison ? » génère une réponse inventée plausible. Avec RAG, le système récupère d'abord le passage exact de votre FAQ ou de vos CGV qui mentionne les délais, puis demande au LLM de formuler une réponse à partir de ce texte précis.
Le LLM devient un rédacteur qui paraphrase vos documents, pas un oracle qui invente. C'est un changement architectural fondamental, pas une amélioration marginale.
Les limites du RAG seul
Le RAG ne suffit pas si ces conditions ne sont pas remplies :
- Base documentaire lacunaire : si la question porte sur un sujet absent de vos documents, le système peut tenter de répondre hors sources. D'où l'importance du garde-fou « je ne sais pas ».
- Chunks mal découpés : un chunk trop court perd le contexte ; un chunk trop long noie l'information pertinente. La qualité du découpage conditionne directement la qualité des réponses.
- Score de similarité trop permissif : si le seuil de pertinence pour retrieval est trop bas, des chunks non pertinents sont injectés dans le prompt, induisant des réponses partiellement correctes et partiellement inventées.
- Prompt système mal configuré : un system prompt ambigu ne dit pas clairement au LLM qu'il doit s'en tenir aux sources fournies, ce qui rouvre la porte aux extrapolations.
La comparaison détaillée entre un LLM généraliste et un chatbot RAG dédié est couverte dans notre article ChatGPT vs chatbot RAG personnalisé en entreprise.
Tableau : LLM seul vs chatbot RAG avec garde-fous
| Critère | LLM seul (ex. ChatGPT) | Chatbot RAG + garde-fous |
|---|---|---|
| Risque d'hallucination | Fréquentes, sans moyen de les repérer | Réduites, jamais nulles |
| Source des réponses | Données d'entraînement génériques | Vos documents internes |
| Réponse hors périmètre | Invente | Répond « je ne sais pas » |
| Traçabilité | Aucune | Source citée dans la réponse |
| Mise à jour des infos | Cutoff date fixe | Immédiate dès la réindexation |
| Supervision humaine | Difficile (boîte noire) | Possible via logs + sources |
Quels garde-fous mettre en place concrètement ?
Le RAG est la couche fondatrice. Les garde-fous sont les mécanismes complémentaires qui capturent les cas résiduels. Voici les six qui comptent vraiment.
1. Restriction stricte à la base documentaire (grounding)
Le system prompt doit contenir une instruction explicite du type : « Tu ne réponds qu'à partir des documents fournis. Si l'information n'est pas dans les sources, tu l'indiques clairement. Tu n'inventes aucune information. »
Cette instruction, appelée grounding instruction, est non négociable. Elle est présente dans tous les agents Heeya par défaut. Sans elle, le LLM continue d'extrapoler même lorsque des chunks RAG sont fournis. Elle constitue également la première ligne de défense contre les tentatives de manipulation : notre guide sur la protection contre les prompt injections et les contournements de garde-fous détaille comment renforcer cette couche de sécurité face aux utilisateurs malveillants.
2. Le fallback « je ne sais pas »
Quand le score de similarité entre la question et les chunks récupérés est trop faible, le système ne doit pas forcer une réponse. Il doit répondre clairement qu'il ne dispose pas de l'information et proposer une alternative, rediriger vers un email, un formulaire, ou un agent humain.
Ce comportement est contre-intuitif pour beaucoup de décideurs. Pourtant, un chatbot qui admet son ignorance construit plus de confiance qu'un chatbot qui invente. Les utilisateurs pardonnent l'absence de réponse. Ils ne pardonnent pas la fausse réponse.
Pour le service client notamment, ce fallback est un levier de confiance majeur, voir notre analyse du RAG pour le service client.
3. Affichage des sources dans la réponse
Chaque réponse du chatbot doit indiquer de quelle source elle provient, numéro de page, nom du document, URL scrapée. Ce mécanisme remplit deux fonctions :
- Pour l'utilisateur : il peut vérifier lui-même la réponse, ce qui renforce la crédibilité du chatbot.
- Pour vous : les logs de sources permettent d'identifier rapidement les documents qui génèrent des réponses imprécises et de les corriger.
Les citations de sources sont un signal E-E-A-T fort pour votre chatbot. Elles transforment une réponse IA opaque en une réponse vérifiable et auditée.
4. Seuil de confiance (confidence threshold)
Chaque retrieval RAG produit un score de similarité cosinus entre la question et les chunks candidats. Ce score varie de 0 (aucune pertinence) à 1 (pertinence parfaite). En fixant un seuil minimal, typiquement entre 0,65 et 0,80 selon votre domaine, vous forcez le système à ne répondre que lorsque les sources récupérées sont réellement pertinentes.
En dessous du seuil : le chatbot déclenche le fallback « je ne sais pas ». Au-dessus : il génère une réponse ancrée sur les chunks récupérés. C'est ce mécanisme qui réduit les hallucinations résiduelles après grounding, sans les supprimer.
5. Supervision humaine et boucle d'amélioration
Aucun système automatique n'est parfait à 100 %. La supervision humaine, revue des conversations signalées, analyse des logs, ajustement de la base documentaire, est le dernier rempart.
Concrètement, cela signifie :
- Un tableau de bord d'analyse des conversations (volumétrie, questions sans réponse, conversations escaladées).
- Un mécanisme de feedback utilisateur (pouce haut/bas, ou signalement « réponse incorrecte »).
- Une revue hebdomadaire des conversations à faible score de confiance pour enrichir la base documentaire.
- Un escalade automatique vers un humain quand la question dépasse le périmètre ou quand l'utilisateur signale une insatisfaction.
Cette boucle n'est pas un aveu d'échec du système IA. C'est le standard de l'industrie pour tout système conversationnel critique. Notez que ces logs d'audit sont eux-mêmes des données sensibles : leur protection relève de la sécurité des données d'un chatbot IA, un sujet complémentaire aux garde-fous anti-hallucination.
6. Noter automatiquement chaque réponse en production
Le jeu de test avant mise en ligne couvre 30 à 50 questions. En production, les visiteurs en posent des centaines d'autres, formulées autrement. Relire toutes les conversations à la main n'est pas tenable au-delà de quelques dizaines par semaine.
L'approche consiste à faire vérifier chaque réponse par un second modèle, juste après son envoi. Ce modèle reçoit la question, les passages que le chatbot a retrouvés dans vos contenus, vos instructions et la réponse donnée. Il ne rédige pas de texte : il renvoie une probabilité pour chaque diagnostic possible (réponse fondée, réponse non fondée, information manquée, information absente de la base, simple salutation).
Dans Heeya, c'est l'outil « Score de fiabilité des réponses ». Chaque réponse reçoit dans la page « Analyse » l'un de ces résultats :
- Réponse probablement fiable (au-dessus de 70 %) : la réponse s'appuie sur vos contenus.
- Réponse à vérifier (entre 50 et 70 %) : elle ne s'y appuie peut-être qu'en partie.
- Risque d'être incorrecte (sous 50 %) : elle ne s'y appuie probablement pas.
- Information probablement non trouvée : l'agent n'a pas trouvé l'information dans votre base.
Trois points pour lire ce score correctement :
- C'est une estimation, pas une preuve. Une réponse marquée à risque peut être juste, et l'inverse arrive aussi. Le score sert à choisir quelles réponses relire en premier.
- Il juge l'ancrage, pas la vérité. Si un document contient une erreur, une réponse fidèle à ce document sera notée fiable. La qualité de la base reste votre responsabilité.
- Il ne bloque rien. La réponse est déjà partie quand le score arrive. C'est un outil de supervision, pas un filtre.
Le résultat « Information probablement non trouvée » est souvent le plus utile : il liste les questions que vos visiteurs posent et auxquelles votre base ne répond pas. Le bouton « Ajouter en Q&R », sous la réponse, ouvre un formulaire avec la question déjà remplie : vous écrivez la bonne réponse, et l'agent s'en sert pour les visiteurs suivants. C'est la boucle d'amélioration du point 5, sans relire chaque conversation.
Checklist : 8 garde-fous anti-hallucinations à activer
Utilisez cette checklist avant la mise en production de votre chatbot. Chaque point non coché est un risque d'hallucination identifiable et corrigeable.
- Grounding instruction dans le system prompt : le LLM est explicitement contraint de répondre uniquement depuis les sources fournies. L'objectif : aucune information inventée, vérifié par les tests.
- Base documentaire complète et à jour : tous les sujets que le chatbot doit couvrir sont présents dans la base. Les documents périmés sont supprimés ou mis à jour. Fréquence de révision définie (ex. mensuelle).
- Découpage des chunks optimisé : taille des chunks adaptée au type de document (200 à 500 tokens pour les textes denses, plus larges pour les procédures). Chevauchement activé pour préserver le contexte entre chunks.
- Seuil de confiance configuré : un score de similarité minimal est défini. Les réponses sous ce seuil déclenchent le fallback, pas une réponse générée.
- Fallback « je ne sais pas » activé et personnalisé : message clair, non frustrant, avec une alternative concrète (formulaire, email, numéro de téléphone).
- Affichage des sources dans les réponses : chaque réponse cite le document source (nom de fichier, URL ou section) pour permettre la vérification.
- Jeu de test pré-production : 30 à 50 questions couvrant les sujets clés + les cas limites (questions hors périmètre, questions ambiguës, questions pièges). Chaque réponse validée manuellement avant la mise en ligne.
- Boucle de supervision post-production : tableau de bord de monitoring actif, mécanisme de feedback utilisateur, notation automatique des réponses, revue périodique des conversations signalées.
L'expertise RAG de Heeya couvre l'ensemble de ces points dès la configuration initiale de votre agent.
Comment tester la fiabilité de votre chatbot avant la mise en ligne ?
Déployer sans tester, c'est découvrir les hallucinations en production, devant vos clients. Voici la méthode de test que nous recommandons chez Heeya, applicable en moins d'une journée.
Construire votre jeu de questions de référence
Commencez par collecter les 30 à 50 questions les plus fréquentes que vos utilisateurs posent réellement, depuis votre support client, votre FAQ actuelle, ou vos tickets. Ajoutez-y :
- 5 à 10 questions hors périmètre (sujets absents de votre base documentaire), pour vérifier que le fallback fonctionne.
- 5 questions pièges (informations incorrectes énoncées comme vraies, ex. « Votre livraison est gratuite à partir de 20 €, c'est bien ça ? » si ce n'est pas vrai), pour vérifier que le chatbot corrige et ne confirme pas l'erreur.
- 3 à 5 questions ambiguës, formulées de plusieurs façons différentes, pour tester la robustesse du retrieval.
Évaluer les réponses selon 4 critères
Pour chaque question, évaluez la réponse obtenue sur :
- Exactitude factuelle : la réponse est-elle correcte par rapport à vos documents ? (Oui / Non / Partiel)
- Source correcte : le chatbot cite-t-il la bonne source ? La source existe-t-elle dans votre base ?
- Comportement hors périmètre : pour les questions hors base, le fallback a-t-il été déclenché ? Le chatbot n'a-t-il pas inventé ?
- Formulation : la réponse est-elle claire, concise et adaptée à votre ton de marque ?
Un taux d'exactitude factuelle inférieur à 95 % avant mise en production est un signal d'alerte. Identifiez les questions problématiques, enrichissez la base documentaire sur ces sujets, et relancez le test.
Le test de régression après chaque mise à jour documentaire
Chaque fois que vous ajoutez ou modifiez des documents dans la base, relancez un sous-ensemble de votre jeu de test (15 à 20 questions clés). Une mise à jour documentaire peut parfois dégrader des réponses qui fonctionnaient, c'est le test de régression qui le détecte avant vos utilisateurs.
La métrique cible selon l'usage
Les exigences de fiabilité varient selon le contexte :
- FAQ / support client standard : taux d'exactitude factuelle cible > 95 %, taux de fallback approprié > 90 % sur les questions hors périmètre.
- Chatbot juridique ou contractuel : taux d'exactitude > 99 %, supervision humaine obligatoire sur toutes les réponses à fort enjeu.
- Qualification de leads : la fiabilité factuelle est moins critique que la cohérence du parcours, tester prioritairement les scénarios de qualification complets.
FAQ : hallucination IA et fiabilité des chatbots
Qu'est-ce qu'une hallucination IA ?
Une hallucination IA désigne une affirmation fausse ou inventée, formulée avec assurance, par un modèle de langage (LLM). Le modèle ne ment pas délibérément : il génère le texte statistiquement le plus probable sans avoir accès à une source de vérité. Résultat : des chiffres erronés, des procédures inexistantes, des clauses contractuelles inventées, ou des informations produit incorrectes présentées comme certaines. C'est le problème structurel de tout LLM utilisé sans ancrage documentaire.
Le RAG élimine-t-il totalement les hallucinations ?
Non. Le RAG réduit nettement les hallucinations par rapport à un LLM seul, mais ne les supprime pas : l'étude de Stanford de 2024 sur des outils juridiques avec RAG a relevé des réponses problématiques dans 17 à 33 % des cas testés. Des hallucinations résiduelles subsistent quand la base documentaire est incomplète, quand les chunks sont mal découpés, ou quand le system prompt n'impose pas strictement le grounding. Les garde-fous complémentaires (seuil de confiance, fallback « je ne sais pas », affichage des sources, supervision humaine) sont nécessaires pour atteindre un niveau de fiabilité acceptable en production.
Quelle est la différence entre un chatbot IA fiable et ChatGPT ?
ChatGPT est un LLM généraliste qui répond depuis ses données d'entraînement génériques. Il ne connaît pas vos documents internes, vos tarifs, vos procédures ou vos produits spécifiques. Un chatbot IA fiable pour l'entreprise est un LLM connecté en temps réel à votre base documentaire via RAG, il répond uniquement depuis vos sources, cite ses références, et refuse de répondre quand l'information n'est pas dans sa base. C'est cette architecture qui fait la différence entre un outil expérimental et un chatbot déployable en production.
Comment configurer le garde-fou « je ne sais pas » ?
Le fallback « je ne sais pas » se configure à deux niveaux. Premièrement dans le system prompt, en indiquant explicitement au LLM qu'il doit signaler l'absence d'information plutôt qu'inventer. Deuxièmement dans le moteur RAG, en fixant un seuil de score de similarité minimum (ex. 0,70) en dessous duquel aucun chunk n'est injecté dans le prompt, déclenchant automatiquement la réponse d'absence d'information. Dans Heeya, ce fallback est personnalisable : vous définissez le message affiché à l'utilisateur et l'action proposée (formulaire de contact, email de support, numéro de téléphone).
Un chatbot IA fiable peut-il être déployé sans compétences techniques ?
Oui, si la plateforme choisie intègre le RAG et les garde-fous anti-hallucination nativement. Avec Heeya, vous créez votre agent, uploadez vos documents (PDF, Docx, PPTX, TXT) ou indiquez des URLs à scraper, configurez le system prompt via une interface no-code, et le chatbot est prêt. Les mécanismes de grounding, seuil de confiance et fallback sont activés par défaut. Aucune ligne de code n'est requise pour bénéficier de l'architecture anti-hallucination.
Comment mesurer le taux d'hallucination de son chatbot ?
La méthode la plus fiable est le test manuel sur un jeu de questions de référence (30 à 50 questions couvrant vos sujets clés + des questions hors périmètre). Pour chaque réponse, vérifiez l'exactitude factuelle contre vos documents sources. Le ratio réponses correctes / total donne votre taux d'exactitude (inverse : taux d'hallucination). Pour des volumes plus importants, des outils d'évaluation automatisée comme RAGAS (framework open-source) permettent de mesurer les métriques de fidélité et de pertinence du retrieval à grande échelle. En production, un modèle de vérification peut aussi noter chaque réponse au fil de l'eau, comme le fait l'outil « Score de fiabilité des réponses » de Heeya.
Les hallucinations engagent-elles la responsabilité juridique de l'entreprise ?
C'est une question ouverte en droit français en 2026, mais la tendance jurisprudentielle et réglementaire va dans un sens clair : si votre chatbot donne une information incorrecte qui cause un préjudice à un utilisateur (ex. un tarif erroné engageant un contrat, une procédure médicale incorrecte), la responsabilité de l'entreprise qui déploie le chatbot peut être engagée. L'AI Act 2026 impose d'ailleurs des obligations de transparence et de supervision humaine pour les systèmes IA à risque. La mise en place de garde-fous documentés (grounding, fallback, logs) constitue une démonstration de diligence raisonnable, et réduit sensiblement le risque juridique. Consultez votre conseil juridique pour une analyse propre à votre secteur.
Pourquoi l'IA hallucine-t-elle ?
Un modèle de langage prédit le mot le plus probable à chaque étape, sans vérifier la véracité de ce qu'il écrit. Quand l'information manque dans ses données ou dans le contexte fourni, il produit quand même une réponse plausible. L'entraînement qui récompense les réponses jugées utiles aggrave la tendance à répondre plutôt qu'à reconnaître qu'il ne sait pas.
Comment éviter les hallucinations de l'IA au quotidien ?
Fournissez vos propres sources dans la question, demandez explicitement de répondre « je ne sais pas » en cas de doute, exigez les références, puis vérifiez les chiffres, dates et citations avant de les utiliser. Pour un chatbot d'entreprise, ajoutez le RAG, un seuil de confiance et une revue régulière des conversations. Ces pratiques réduisent le risque sans l'annuler : toute information à enjeu doit être contrôlée.
Déployez un chatbot IA fiable depuis vos propres documents
Heeya intègre le RAG, le grounding, le fallback « je ne sais pas » et les logs de supervision dans chaque agent, sans ligne de code. Essai gratuit, sans engagement. Application hébergée en France (OVH).
Créer mon chatbot gratuitement Voir les tarifs Heeya