Hallucination IA : définition, causes et comment la limiter

Une hallucination d'IA est une réponse fausse formulée avec exactement la même assurance qu'une réponse juste. Ce n'est ni un bug isolé ni un mensonge : c'est une conséquence directe de la façon dont un modèle génératif fonctionne. Le choix du modèle influence la fréquence de l'erreur, jamais son existence : même le modèle le plus capable continue d'halluciner.

Qu'est-ce qu'une hallucination d'IA, précisément ?

Une hallucination désigne une sortie qui paraît plausible et bien construite, mais qui est factuellement fausse : une référence qui n'existe pas, une date inventée, une citation jamais prononcée. Le texte est grammaticalement irréprochable et le ton est celui d'une certitude, ce qui rend l'erreur difficile à repérer à la simple lecture.

Ce comportement n'est pas un défaut de conception qu'un correctif viendrait effacer un jour. Un modèle d'IA génère la suite de mots la plus probable compte tenu de ce qu'il a appris, pas la suite la plus vraie compte tenu des faits. La plupart du temps, probable et vrai coïncident. Une hallucination survient quand ils divergent, sans que le modèle en soit averti autrement que par ses propres statistiques internes.

Pourquoi le vrai danger n'est-il pas l'erreur, mais l'absence de signal d'erreur ?

C'est le point qui change tout dans un usage professionnel. Un moteur de recherche classique, quand il ne trouve rien, le dit : zéro résultat, page blanche, message d'échec explicite. Un modèle génératif, lui, produit presque toujours quelque chose, que la réponse existe réellement dans ce qu'il a appris ou non.

Ce déplacement est le cœur du problème. L'absence d'échec visible retire au lecteur le réflexe naturel de doute. Une page blanche invite à chercher ailleurs. Un paragraphe fluide et structuré invite à croire. Le risque ne vient donc pas de la fréquence des erreurs, mais du fait qu'elles ne se signalent jamais elles-mêmes.

Quelles formes prend une hallucination en entreprise ?

Quatre formes reviennent le plus souvent dans un usage professionnel, toutes plausibles au premier regard.

• Une source ou une référence inventée : un rapport, une étude ou un article cité avec un titre et une date crédibles, qui n'a jamais existé sous cette forme.
• Un chiffre plausible mais faux : un pourcentage, un montant ou une statistique cohérents avec le sujet, mais fabriqués faute de donnée réelle disponible.
• Une clause réglementaire qui n'existe pas : un article de loi ou une obligation citée avec assurance, qui ne figure dans aucun texte réel.
• Une fonctionnalité logicielle imaginée : une capacité d'un outil ou d'un ERP décrite comme existante, alors qu'elle n'a jamais été développée.

Ces quatre cas partagent un point commun : rien dans la forme de la réponse ne distingue le vrai du faux. La vérification doit venir d'ailleurs.

Comment réduire le risque d'hallucination ?

Quatre réflexes réduisent réellement le risque, et ils demandent tous la même discipline : ne pas s'en remettre à la mémoire du modèle.

Donner la source dans la question. Plutôt que de demander « que dit la convention collective sur les congés », coller l'extrait pertinent directement dans la question. Le modèle lit alors un document réel au lieu de reconstituer une réponse à partir de ce qu'il a mémorisé.

Demander de citer ses passages. Exiger que chaque affirmation s'appuie sur une phrase précise du document fourni oblige le modèle à s'ancrer sur un texte vérifiable, et rend l'absence de source immédiatement visible.

Autoriser explicitement la réponse « je ne sais pas ». Un modèle poussé à toujours répondre invente plus souvent. Préciser dans la consigne qu'une absence d'information est une réponse valable réduit mécaniquement la pression à produire du plausible.

Réserver la relecture humaine à ce qui engage. Tout ne mérite pas le même niveau de vérification. Un chiffre, une date, un nom propre, un montant ou une clause qui engagent une décision ou une responsabilité doivent systématiquement être recoupés. Une reformulation ou un plan de paragraphe n'a pas besoin du même contrôle.

Pourquoi une réponse bien écrite ne suffit-elle pas à la valider ?

Deux réflexes rassurants ne protègent de rien. Demander au modèle « ne te trompe pas » n'a aucun effet mesurable : la consigne ne change pas le mécanisme de prédiction sous-jacent. Faire confiance parce que la réponse est bien écrite est pire encore : la qualité de forme et la justesse factuelle sont deux dimensions indépendantes, et un modèle génératif excelle précisément dans la première.

La vraie protection ne se joue pas dans la formulation de la question, mais dans ce qu'on donne au modèle à lire. C'est tout l'enjeu du choix entre RAG et fine-tuning : ancrer les réponses sur les documents réels de l'entreprise plutôt que sur la mémoire générale du modèle change structurellement la fréquence des hallucinations, là où une simple consigne de prudence ne change rien.