Une hallucination est une sortie générée par un LLM qui semble cohérente, bien écrite, et qui s'avère factuellement incorrecte — chiffres inventés, citations qui n'existent pas, articles de loi imaginaires, fonctions API qui n'ont jamais existé. Le modèle ne « ment » pas au sens humain : il prédit la suite de texte la plus probable étant donné son entraînement, et quand il manque d'information, il interpole dans le vide. C'est un comportement structurel, pas un bug ponctuel.
Les facteurs qui amplifient les hallucinations : questions hors-périmètre du training set, prompts ambigus, fenêtre de contexte sans informations factuelles, demandes de citations précises (dates, chiffres, sources), modèles plus petits ou plus anciens. Les techniques de mitigation efficaces : ancrer le modèle via RAG avec citations obligatoires, utiliser le function calling pour vérifier les faits via des APIs réelles, instruire explicitement le modèle à dire « je ne sais pas » dans le prompt, et valider les sorties critiques par programme.
Le bon réflexe en production : ne jamais faire confiance aveuglément à la sortie d'un LLM sur un sujet à risque (juridique, médical, financier, contractuel). On met en place un workflow de validation : citations obligatoires + sources vérifiables, validation humaine sur les cas sensibles, monitoring du taux d'hallucination via un dataset de référence. Pour un déploiement maîtrisé en secteur juridique, santé ou finance, le RAG bien fait + la validation humaine restent obligatoires en 2026.
5 mesures qui réduisent vraiment les hallucinations
- RAG avec injection des passages pertinents et citation obligatoire des sources.
- Function calling pour faire vérifier les faits par une API réelle (CRM, base produit).
- Prompt explicite : « si l'info n'est pas dans le contexte, réponds 'je ne sais pas' ».
- Validation programmatique de la sortie (regex, JSON schema, appels de vérification croisée).
- Monitoring continu : dataset de référence + taux d'hallucination mesuré dans le temps.
