Une hallucination est une sortie qui paraît plausible mais n’est pas étayée par les preuves disponibles. Elle peut inventer une citation, fusionner deux personnes, employer une politique obsolète, mal lire un tableau ou combler avec assurance une lacune à laquelle la source n’a jamais répondu. La fluidité rend ces erreurs dangereuses, car la qualité de présentation peut être confondue avec la fiabilité.
Ce comportement découle du fonctionnement des modèles génératifs. Ils produisent des continuations probables à partir des consignes et du contexte fournis ; ils ne consultent pas un registre interne qui garantit la vérité de chaque phrase. De meilleurs modèles peuvent réduire le taux d’erreur, mais aucun système généraliste ne supprime le besoin de contrôles.
Le risque dépend du travail. Une métaphore surprenante dans une séance d’idéation peut être utile. Un chiffre inventé dans un rapport financier ne l’est pas. Avant de choisir le niveau d’automatisation, définissez les affirmations qui exigent des preuves, l’incertitude acceptable et la personne qui supporte le coût d’une erreur.
L’ancrage dans les sources est la première défense. Fournissez des sources actuelles et pertinentes, puis demandez au modèle de les utiliser. La génération augmentée par récupération peut amener des documents privés ou changeants dans la requête. L’ancrage doit néanmoins être évalué : récupérer un passage non pertinent ou obsolète peut produire une erreur très bien citée.
Exigez une traçabilité au niveau de chaque affirmation. Une liste de sources à la fin d’une réponse ne dit pas quelle source soutient quel énoncé. Demandez des citations à côté des affirmations factuelles, conservez les identifiants de document et permettez à un relecteur d’ouvrir facilement le passage référencé. Ne considérez jamais une citation générée par le modèle comme vérifiée avant d’avoir contrôlé sa destination et son soutien.
Donnez au modèle la permission de s’abstenir. Si les preuves ne répondent pas à la question, la bonne sortie peut être « informations insuffisantes », une demande de document manquant ou une liste de points non résolus. Une application qui récompense l’achèvement à tout prix encouragera les suppositions confiantes.
La validation doit correspondre à la sortie. Les données structurées peuvent être vérifiées par rapport à un schéma, une plage ou un vocabulaire connu. Les calculs peuvent être refaits. Les noms et identifiants peuvent être comparés à une base de données. Les citations peuvent être retrouvées dans le texte source. Le code peut être compilé et testé. Ces contrôles déterministes détectent des défaillances qu’une autre revue libre par modèle pourrait répéter.
Pour les documents difficiles, séparez l’extraction de l’interprétation. Capturez d’abord les valeurs et passages pertinents avec des coordonnées ou des citations. Demandez ensuite au modèle de les expliquer. Cela crée un artefact intermédiaire qu’une personne ou un test peut inspecter et réduit le risque qu’un récit soigné masque une erreur de lecture.
Utilisez une revue indépendante pour les décisions à fort impact. Le relecteur a besoin des preuves originales, pas seulement de la réponse. La supervision humaine est la plus utile lorsque la personne a l’autorité d’arrêter le workflow et suffisamment de temps pour examiner les affirmations risquées ; une simple case d’approbation offre peu de protection.
Surveillez les échecs en production au lieu de vous appuyer uniquement sur les évaluations de lancement. Dans les limites de la confidentialité, conservez des prompts représentatifs, les preuves récupérées, les sorties, les corrections et les versions de modèle. Regroupez les erreurs par cause : source absente, mauvaise récupération, ambiguïté du prompt, synthèse non étayée, données périmées ou échec de validation. Chaque cause appelle un correctif différent.
Communiquez honnêtement l’incertitude dans l’interface. Affichez les dates de vérification, la couverture des sources et indiquez si la réponse a été générée à partir de documents fournis par l’utilisateur ou de connaissances générales du modèle. Évitez les badges qui suggèrent une garantie que le système ne peut pas donner.
L’objectif pratique n’est pas de promettre qu’une IA n’hallucine jamais. Il consiste à rendre les affirmations non étayées plus difficiles à produire, plus faciles à détecter, moins coûteuses à corriger et moins susceptibles d’atteindre sans être remarquées une décision lourde de conséquences.
Nous croisons sources primaires, documentation produit et cas d’usage réels pour vous aider à déterminer si un outil convient à votre manière de travailler.