Hallucinations des LLM : pourquoi elles sont structurelles, comment elles sont mesurées, et l'architecture qui les rend exploitables en production

Un modèle de langage ne « sait » rien : il détient une version compressée et approximative de ses données d'entraînement, et ses procédures d'évaluation le récompensent quand il devine plutôt que quand il avoue son incertitude. C'est la démonstration du papier d'OpenAI « Why Language Models Hallucinate » (septembre 2025) : l'hallucination n'est pas un bug en attente de correctif, c'est une conséquence statistique de la façon dont nous entraînons et notons ces modèles.

La bonne nouvelle, c'est que ce comportement est prévisible, mesurable et contournable par l'architecture. Cet article fait le tour du problème en praticien : la taxonomie des hallucinations, trois défaillances documentées qui ont coûté cher, le mécanisme exact qui les produit, ce que valent les classements publics, et les garde-fous que nous appliquons sur nos propres workflows chez Origin Labs.

L'essentiel en bref

• Une hallucination est intrinsèque quand elle contredit le contenu fourni dans la conversation, extrinsèque quand elle porte sur ce que le modèle croit savoir de son entraînement (taxonomie de Ji et al., ACM Computing Surveys, 2023). La fiabilité est très différente selon le cas.
• Sur 576 000 échantillons de code générés par 16 LLM, au moins 5,2 % des paquets recommandés par les modèles commerciaux et 21,7 % par les modèles open source n'existent pas (Spracklen et al., USENIX Security 2025). Des attaquants enregistrent ces noms inventés pour piéger les développeurs : c'est le slopsquatting.
• Le 8 février 2023, une erreur factuelle de Bard dans une publicité Google a coïncidé avec une chute de 7,7 % de l'action Alphabet en clôture, soit environ 100 milliards de dollars de capitalisation évaporés (Reuters).
• Le 14 février 2024, Air Canada a été condamné à rembourser un client à qui son chatbot avait inventé une politique de tarif de deuil (Moffatt v. Air Canada, 2024 BCCRT 149). Le tribunal a rejeté l'argument selon lequel le chatbot serait une entité responsable de ses propres actes.
• Pourquoi les modèles devinent : les benchmarks notent en binaire, une tentative fausse et un « je ne sais pas » valent le même zéro, donc deviner est la stratégie optimale (Kalai et al., OpenAI, septembre 2025).
• Sur le leaderboard Vectara (mai 2026), les meilleurs modèles n'hallucinent « que » 1,8 % du temps en résumé de documents fournis, le pire 24,2 %. Mais ce classement est calculé par l'outil du vendeur et ne mesure que le résumé ancré : un indicateur, pas une mesure absolue.
• La contremesure qui marche n'est pas un meilleur modèle, c'est une architecture : fournir les sources dans le contexte, forcer l'outil de recherche, exiger des citations vérifiables, garder une revue humaine sur les domaines critiques.

Deux familles d'hallucination, une seule règle de fiabilité

La littérature distingue deux familles depuis la survey de référence de Ji et al. (ACM Computing Surveys, mars 2023) :

• Hallucination intrinsèque : la réponse contredit le contenu source que vous venez de fournir. Vous donnez un contrat de 40 pages au modèle et lui demandez la clause de résiliation ; il cite une clause qui n'y figure pas. Vous dites « mon chat s'appelle Bandit » puis demandez son nom trois messages plus tard ; il répond « Félix ».
• Hallucination extrinsèque : la réponse porte sur un fait absent de la conversation, que le modèle puise dans la trace compressée de son entraînement. Elle n'est vérifiable ni confirmable à partir du contexte : c'est le modèle qui « répond de mémoire ».

La taxonomie exhaustive publiée par Manuel Cossio (arXiv:2508.01781, août 2025) décline ensuite les manifestations : erreurs factuelles, entités fabriquées, incohérences contextuelles ou logiques, désorientation temporelle, hallucinations de code. Utile pour nommer les choses. Mais pour un ingénieur, une seule règle opérationnelle compte :

Un LLM est nettement plus fiable sur l'information que vous venez de placer dans sa fenêtre de contexte que sur celle qu'il restitue de mémoire. C'est contre-intuitif seulement en apparence : dans le premier cas, la réponse est un problème de lecture ; dans le second, c'est un problème de reconstruction à partir d'une compression avec pertes. La suite explique pourquoi.

Trois défaillances qui ont coûté cher

L'erreur factuelle extrinsèque : Bard et le télescope James Webb. Le 6 février 2023, Google publie une publicité pour Bard dans laquelle le chatbot affirme que le JWST « a pris les toutes premières images d'une planète en dehors de notre système solaire ». C'est faux : la première image directe d'une exoplanète (2M1207b) date de 2004, par le VLT de l'ESO. Personne n'a relu la démo. Le 8 février, Reuters signale l'erreur et l'action Alphabet clôture en baisse de 7,7 %, soit environ 100 milliards de dollars de capitalisation évaporés (Reuters, 8 février 2023). Prudence d'usage : ce chiffre est une variation boursière rapportée par la presse, dans un contexte de concurrence Microsoft/OpenAI ; attribuer toute la chute à la seule hallucination serait exagéré. La leçon n'en est pas moins nette : une erreur extrinsèque dans un asset marketing vérifié par personne.

L'entité fabriquée : les paquets qui n'existent pas. Demandez à un LLM d'écrire du code et il importera des bibliothèques. Certaines n'existent pas. Spracklen et al. ont mesuré le phénomène proprement : 16 modèles, 576 000 échantillons de code Python et JavaScript, et au minimum 5,2 % de paquets hallucinés pour les modèles commerciaux, 21,7 % pour les modèles open source, soit 205 474 noms de paquets inventés distincts (arXiv:2406.10279, publié à USENIX Security 2025). Le détail qui transforme un défaut en vulnérabilité : environ 43 % de ces noms réapparaissent à l'identique quand on régénère dix fois le même code. Un attaquant n'a donc qu'à demander au modèle, enregistrer le nom inventé sur PyPI ou npm avec un paquet malveillant, et attendre que des développeurs suivent la recommandation. Cette attaque a un nom, le slopsquatting, attribué à Seth Larson (Python Software Foundation). Chez nous, c'est arrivé deux fois en un trimestre sur des scripts utilitaires ; seule la vérification systématique du lockfile avant installation a empêché le pire.

L'incohérence contextuelle : le chatbot d'Air Canada. Le cas le plus troublant, parce que l'information était dans le contexte. En novembre 2022, Jake Moffatt demande au chatbot d'Air Canada comment obtenir un tarif de deuil. Le bot lui répond qu'il peut voyager puis demander le remboursement « dans les 90 jours suivant l'émission du billet ». Cette politique n'existe pas : la vraie règle, pourtant accessible au chatbot, exigeait la demande avant le voyage. Le 14 février 2024, le Civil Resolution Tribunal de Colombie-Britannique condamne Air Canada pour déclaration négligente et ordonne le remboursement (812,02 dollars canadiens au total). L'argument de la compagnie, selon lequel son chatbot serait « une entité juridique distincte responsable de ses propres actes », est rejeté comme « une soumission remarquable » (Moffatt v. Air Canada, 2024 BCCRT 149, 14 février 2024). C'est une hallucination intrinsèque documentée devant une autorité de décision : même avec la bonne information dans la fenêtre, le modèle peut l'ignorer ou la déformer. La fenêtre de contexte réduit le risque, elle ne l'annule pas.

Pourquoi le problème est structurel

Première cause : la compression. L'entraînement prend un corpus gigantesque et le condense en des poids qui tiennent sur des GPU. L'image que donne Matt Pocock dans sa vidéo « Never Trust An LLM » (printemps 2026) est juste : compressez une photo à l'extrême, il reste une silhouette floue. Vous pouvez encore répondre « le micro est bleu » ou « cet homme est chauve » ; vous ne pouvez plus dire qui c'est ni quel âge il a. Un LLM interrogé sur un fait rare de son corpus « voit » exactement ça : une version dégradée de l'information. Kalai et Vempala l'ont formalisé dès 2024 : tout modèle de langage étalonné (dont les probabilités reflètent la réalité statistique) hallucine nécessairement sur les faits arbitraires et non redondants (« Calibrated Language Models Must Hallucinate », STOC 2024). Un fait qui n'apparaît qu'une fois dans le corpus n'est pas compressible : le modèle ne peut pas le « savoir » avec certitude, il ne peut que le deviner.

Deuxième cause : la récompense de la témérité. Reste une question : si le modèle ne détient qu'une image floue, pourquoi devine-t-il au lieu de dire « je ne sais pas » ? La réponse d'OpenAI est dans « Why Language Models Hallucinate » (Kalai, Nachum, Vempala, Zhang, arXiv:2509.04664, 4 septembre 2025) :

« Language models are optimized to be good test-takers, and guessing when uncertain improves test performance. »

Prenez un benchmark noté en binaire : 1 pour une bonne réponse, 0 pour tout le reste. Un modèle A qui répond « je ne sais pas » quand il doute obtient 0 sur toutes ses questions incertaines. Un modèle B qui tente sa chance en marque quelques-unes. B domine le classement, A paraît moins capable. Comme la quasi-totalité des leaderboards fonctionne ainsi, la pression de sélection favorise les modèles qui tentent toujours, exactement comme un étudiant qui sait qu'une copie blanche et une réponse fausse valent le même zéro. Le papier ajoute le remède, et il est socio-technique : plutôt que d'empiler de nouvelles évaluations d'hallucination, modifier la notation des benchmarks dominants pour que l'abstention calibrée ne soit plus perdante.

Il y a une tension de design que tout fournisseur de modèle doit arbitrer : un modèle assez humble pour s'abstenir souvent sous-performera sur les tâches où une tentative audacieuse aurait réussi ; un modèle optimisé pour le score devinera trop. Ce curseur « confiance contre humilité » ne disparaîtra pas avec la prochaine génération de modèles. Il faut donc concevoir nos systèmes pour un composant qui, par construction, répond avec aplomb y compris quand il ne sait pas.

Ce que mesurent vraiment les classements d'hallucination

Le seul classement public tenu à jour sur le sujet est le Hallucination Leaderboard de Vectara (instantané du 11 mai 2026). Protocole : on fournit environ 7 700 documents aux modèles, on leur demande un résumé, et un modèle d'évaluation (HHEM-2.3) détecte les affirmations non supportées par le document. Résultats : le meilleur modèle du classement (finix_s1_32b d'Ant Group) n'hallucine que 1,8 % du temps ; les modèles de frontière se répartissent grossièrement entre 3 % et 12 % ; le moins bon plafonne à 24,2 %.

Trois réserves avant d'en tirer quoi que ce soit. D'abord, l'évaluateur est le produit du vendeur qui publie le classement : ce n'est pas une mesure peer-reviewed. Ensuite, le protocole mesure la fidélité en résumé de documents fournis, c'est-à-dire précisément le cas intrinsèque le plus favorable ; il ne dit rien du question-answering de mémoire, le cas extrinsèque où le risque est maximal. Enfin, un taux global masque la distribution : sur vos documents, votre domaine, votre langue, le taux réel peut être très différent.

La conclusion pratique tient en une phrase : un leaderboard d'hallucination vous dit quel modèle essayer en premier, jamais ce qui se passera dans votre système. C'est la même leçon que pour les benchmarks agentiques (voir notre analyse de Harvey LAB-AA) : ce que mesure un classement public, c'est un couple modèle plus harnais qui n'est pas le vôtre.

L'architecture qui rend un LLM exploitable en production

Puisque l'hallucination est structurelle, la fiabilité se construit au niveau du système, pas du modèle. Voici les quatre couches que nous appliquons, de la plus efficace à la plus coûteuse.

1. Déplacer l'information dans la fenêtre de contexte. Ne jamais interroger un modèle sur ses connaissances d'entraînement pour un fait qui compte : lui passer le document, la page de documentation, l'extrait de code, puis poser la question dessus. C'est le principe du RAG, mais il vaut aussi pour un simple copier-coller. On transforme un problème extrinsèque (le pire) en problème intrinsèque (le meilleur). Concrètement, sur nos assistants documentaires, la question ne part jamais seule au modèle : elle part avec les extraits sources, et le prompt impose de répondre uniquement à partir d'eux.

2. Forcer l'outil de recherche. La plupart des harnais conversationnels exposent un outil de recherche web, mais le modèle ne l'invoque que s'il se juge incertain ; or on vient de voir qu'il est entraîné à se croire certain. Il faut donc le forcer, par l'instruction (« utilise ton outil de recherche ») ou par le harnais (appel d'outil obligatoire sur certaines classes de requêtes). La réponse est alors fondée sur des articles présents dans la fenêtre, avec des citations traçables. Matt Pocock résume l'astuce en quatre mots : « use your search tool ». C'est trivial et ça change tout sur les questions d'actualité, les API récentes, les versions de bibliothèques.

3. Exiger des citations vérifiables, puis vérifier. Une réponse qui cite sa source peut être contrôlée mécaniquement : le lien existe-t-il, le passage cité est-il dans la page, le chiffre est-il identique ? Nous avons automatisé ce contrôle sur les workflows où la réponse alimente un livrable client. Ce que la vérification attrape le plus souvent n'est pas l'invention pure, c'est la déformation : le bon document, le mauvais chiffre.

4. Garder l'humain sur les points critiques. Même ancré, un modèle peut être incohérent avec son propre contexte : Air Canada l'a appris devant un tribunal. Pour le droit, la santé, la finance, le code qui touche à la production, la règle est simple : le modèle prépare, l'humain relit les sources citées avant de décider. « Use your search tool » puis ouvrir les documents soi-même. C'est aussi, depuis l'affaire Moffatt, la position que nous documentons dans nos dossiers d'architecture : le déployeur reste juridiquement responsable des propos de son chatbot.

Type d'hallucination	Exemple documenté	Contremesure principale	Résidu
Erreur factuelle extrinsèque	Bard et le JWST (2023)	Recherche web forcée + citation	Vérifier la citation
Entité fabriquée	5,2 à 21,7 % de paquets inventés (2025)	Lockfile, registre officiel, scan de sécurité	Revue de l'import avant exécution
Incohérence contextuelle	Chatbot Air Canada (2024)	Prompt d'ancrage strict, tests sur cas réels	Revue humaine sur les domaines critiques
Désorientation temporelle	Versions, dates, actualité	Données horodatées dans le contexte	Reformuler la date dans la question

Côté code, notre protocole tient en trois réflexes : le modèle ne propose jamais une dépendance sans que le nom soit vérifié sur le registre officiel ; tout code généré passe la suite de tests existante avant relecture ; et quand le modèle affirme quelque chose sur le comportement d'une bibliothèque, on lui fait citer la documentation en ligne plutôt que sa mémoire. La vidéo de Pocock le dit crûment, et notre expérience confirme : un LLM qui explore votre base de code réelle donne des analyses remarquablement justes ; le même, interrogé de mémoire sur « le meilleur paquet pour faire X », vous expose au slopsquatting.

Ce que ça change dans le choix d'un modèle

Si la fiabilité se construit en architecture, le critère « taux d'hallucination du modèle » recule dans la liste des priorités de sélection. Ce qui compte davantage : la discipline d'ancrage du modèle (sa capacité à rester fidèle aux documents fournis, c'est ce que mesure Vectara), sa propension à invoquer ses outils quand on le lui demande, et sa tenue sur vos propres cas de test. Nous maintenons pour cela un petit jeu d'évaluation interne, une cinquantaine de questions pièges tirées de nos dossiers réels, que chaque modèle candidat rejoue avant d'entrer dans un workflow : mélange de questions extrinsèques (fait rare, réponse attendue : « je ne sais pas ») et intrinsèques (document fourni, une subtilité à ne pas rater). Deux heures à constituer, rejoué en vingt minutes à chaque release de modèle. C'est le seul classement qui mesure ce qui nous intéresse.

FAQ

Un modèle peut-il ne plus halluciner du tout ?

Non, et ce n'est pas une question de temps ou de budget. Kalai et Vempala ont démontré en 2024 (STOC) qu'un modèle étalonné hallucine nécessairement sur les faits arbitraires non redondants : si un fait n'apparaît qu'une fois dans le corpus, aucune compression ne permet de le restituer avec certitude. Le papier OpenAI de septembre 2025 ajoute que les procédures d'évaluation actuelles récompensent la tentative plutôt que l'abstention. On peut réduire la fréquence et surtout l'impact, pas supprimer le phénomène.

Les modèles récents hallucinent-ils moins ?

En résumé ancré sur documents fournis, oui : le leaderboard Vectara (mai 2026) place les meilleurs modèles autour de 2 à 4 % contre plus de 10 % pour les générations antérieures. Mais ce classement ne mesure que le cas favorable et repose sur l'évaluateur du vendeur. Sur la restitution de mémoire de faits rares, aucune source fiable ne montre de disparition du problème, et l'étude sur les paquets logiciels (USENIX Security 2025) mesure encore 5,2 % d'invention chez les meilleurs modèles commerciaux.

Faut-il faire confiance aux réponses avec sources citées ?

Plus que les réponses sans source, mais pas aveuglément. La citation rend la vérification possible, pas superflue : le cas fréquent est la déformation (bon document, mauvais chiffre, bonne page, mauvaise date). L'affaire Air Canada montre qu'un système peut ignorer une règle présente dans son propre contexte. Sur les sujets critiques, ouvrez les sources vous-même ; c'est le coût d'usage d'un outil qui répond vite et avec aplomb.

Le RAG supprime-t-il les hallucinations ?

Il change leur nature. En fournissant les documents dans la fenêtre de contexte, le RAG transforme un problème extrinsèque (restitution de mémoire, taux d'erreur élevé et mal connu) en problème intrinsèque (fidélité à un document fourni, quelques pourcents chez les bons modèles). Il ajoute en revanche ses propres points de défaillance : mauvais document récupéré, extraits tronqués, contradiction entre sources. D'où la citation vérifiable et la revue humaine sur les domaines à enjeu.

Comment tester la fiabilité d'un modèle avant de le déployer ?

Constituez un jeu de 40 à 60 questions tirées de vos cas réels, en deux moitiés : questions dont la réponse est dans des documents que vous fournirez (fidélité intrinsèque) et questions de mémoire sur des faits rares de votre domaine, dont la bonne réponse est « je ne sais pas » (discipline extrinsèque). Faites rejouer ce jeu à chaque modèle candidat et à chaque release. Deux heures de constitution, vingt minutes par run : c'est le seul benchmark qui mesure votre risque.

Sources

• Kalai, Nachum, Vempala, Zhang (OpenAI), « Why Language Models Hallucinate », arXiv:2509.04664, 4 septembre 2025 : https://arxiv.org/abs/2509.04664
• Kalai, Vempala, « Calibrated Language Models Must Hallucinate », STOC 2024 : https://dl.acm.org/doi/10.1145/3618260.3649777
• Ji et al., « Survey of Hallucination in Natural Language Generation », ACM Computing Surveys, mars 2023 : https://doi.org/10.1145/3571730
• Cossio, « A Comprehensive Taxonomy of Hallucinations in Large Language Models », arXiv:2508.01781, août 2025 : https://arxiv.org/abs/2508.01781
• Spracklen et al., « We Have a Package for You! », USENIX Security 2025 / arXiv:2406.10279 : https://arxiv.org/abs/2406.10279
• Reuters, « Google AI chatbot Bard offers inaccurate information in company ad », 8 février 2023 : https://www.reuters.com/technology/google-ai-chatbot-bard-offers-inaccurate-information-company-ad-2023-02-08/
• Moffatt v. Air Canada, 2024 BCCRT 149, Civil Resolution Tribunal de Colombie-Britannique, 14 février 2024 : https://canlii.org/en/bc/bccrt/doc/2024/2024bccrt149/2024bccrt149.html
• Vectara, Hallucination Leaderboard, instantané du 11 mai 2026 : https://github.com/vectara/hallucination-leaderboard
• Matt Pocock, « Never Trust An LLM », YouTube, printemps 2026 (vidéo source de cet article) : https://www.youtube.com/watch?v=9VNG0h4pLh0