Hallucination
Définition
Réponse plausible mais factuellement fausse générée par un LLM. Risque inhérent qu'on limite via RAG, validation côté serveur et garde-fous métier sur les actions critiques.
Le phénomène
Une hallucination est une réponse plausible mais factuellement fausse générée par un LLM. Le modèle invente une référence (un nom d'API qui n'existe pas, une fonction inventée d'une lib), une statistique sortie de nulle part, un nom propre erroné, une citation fabriquée. Le phénomène est inhérent au mécanisme statistique : le modèle prédit le prochain token le plus probable, et il n'a pas de notion de vrai versus faux. Il a appris à produire du texte fluide et cohérent, pas du texte vérifié. Tant qu'on n'a pas de mécanisme de vérification externe, l'hallucination reste un risque structurel.
Quand ça arrive le plus
Les hallucinations surviennent dans plusieurs contextes prévisibles. Sur les domaines spécialisés peu présents dans les données d'entraînement (médecine de pointe, jurisprudence récente, API privées). Sur les chiffres précis : dates, statistiques, montants, où le modèle confond souvent des valeurs proches. Sur les références : il invente des noms d'articles scientifiques, des livres, des arrêts juridiques qui ressemblent à du vrai. Sur les noms propres rares. Et chaque fois qu'on lui demande quelque chose qu'il ne sait pas mais qu'il croit deviner. À l'inverse, sur les sujets très couverts dans son corpus, le taux d'hallucination chute drastiquement.
Les leviers pour réduire
Quatre leviers complémentaires. Le RAG ancre les réponses dans des sources réelles : le modèle ne s'appuie plus sur sa mémoire mais sur des extraits fournis, avec consigne explicite de ne pas extrapoler. La sortie structurée cadre le format de réponse, ce qui élimine les hallucinations de format. La validation côté serveur vérifie chaque champ critique (l'ID existe-t-il, le montant est-il cohérent) avant action. La formulation du prompt compte aussi : ajouter réponds 'je ne sais pas' si l'information n'est pas dans le contexte fourni réduit significativement les inventions, sans éliminer le risque.
La détection automatique
Plusieurs techniques permettent de détecter les hallucinations a posteriori. Le self-consistency check : on génère plusieurs réponses à la même question et on vérifie la cohérence ; si les réponses divergent, c'est un signal. Le grounding check : on demande au modèle de citer le passage source de sa réponse, et on vérifie que le passage existe réellement dans le contexte fourni. L'évaluation par un second LLM (LLM-as-a-judge) qui compare la réponse à la source attendue. Pour les cas critiques, ces vérifications tournent en pipeline avant de remonter la réponse à l'utilisateur, au prix d'une latence accrue.
Le rôle de l'humain dans la boucle
Les hallucinations ne disparaîtront pas à 100%, même avec les meilleurs garde-fous. Sur les actions à fort impact (paiement, e-mail à un client, modification d'une donnée légale, prescription médicale), on garde un humain dans la boucle ou une couche de validation déterministe. Le LLM propose, l'humain valide. Pour les actions à faible impact (suggérer un titre, classer un ticket), on accepte le risque résiduel. C'est une question de gouvernance autant que de technique : on définit explicitement où l'IA peut agir seule, où elle ne peut que recommander, où elle ne doit pas intervenir du tout.
Les modèles ne se valent pas
Tous les modèles n'hallucinent pas avec la même fréquence. Les modèles plus gros et plus récents (Claude 4.5, GPT-5, Gemini 2.5 Pro) hallucinent moins que les modèles économiques (GPT-4o-mini, Claude Haiku, Mistral Small). Les modèles de raisonnement (série o d'OpenAI, Claude avec extended thinking) hallucinent encore moins sur les questions complexes parce qu'ils prennent le temps de vérifier leur raisonnement avant de répondre. Sur un cas où l'exactitude factuelle compte (juridique, médical, financier), on choisit le modèle haut de gamme malgré son coût, et on combine avec RAG et validation. Le compromis coût/risque doit toujours être explicite.