Hallucinations IA : pourquoi une IA se trompe et comment encadrer sa fiabilité
Un modèle de langage peut produire une réponse fausse, bien rédigée et convaincante. Ce guide explique d’où viennent ces erreurs, comment les mesurer avant la mise en service et comment les encadrer au quotidien.
Par Enzo Airault, fondateur de Pecora · Mis à jour le
Qu’est-ce qu’une hallucination en IA ?
On parle d’hallucination lorsqu’un modèle d’IA produit une information fausse ou inventée en la présentant comme exacte : une référence qui n’existe pas, un chiffre approximatif donné pour certain, une clause attribuée au mauvais contrat. Le terme est imagé, mais le phénomène est concret, et il concerne tous les modèles de langage actuels.
Le plus gênant n’est pas l’erreur elle-même, mais sa forme. Une réponse inventée a souvent le même ton assuré qu’une réponse exacte. Sans vérification, rien ne permet de les distinguer. C’est ce qui rend les hallucinations plus délicates à gérer que les erreurs d’un logiciel classique, qui échoue en général de façon visible.
Pourquoi une IA se trompe-t-elle ?
Un modèle de langage ne consulte pas une base de faits. Il produit, mot après mot, la suite la plus probable compte tenu de ce qu’il a appris et de ce qu’on lui fournit. Dans la plupart des cas, la suite probable est aussi la bonne. Mais pas toujours, et le modèle n’a pas de moyen fiable de savoir quand il se trompe.
Dans une entreprise, les erreurs ont en général l’une de ces causes :
- L’information manque : la réponse ne figure ni dans les sources fournies ni dans ce que le modèle a appris, et il comble le vide par une estimation plausible.
- La source est mauvaise : le document retrouvé est périmé, incomplet ou erroné. Le modèle le restitue fidèlement, erreur comprise.
- Les sources se contredisent : deux documents donnent deux valeurs, et le modèle en retient une sans le signaler.
- La recherche échoue : le bon document existe mais n’a pas été retrouvé, et le modèle répond avec ce qu’il a.
- La consigne est ambiguë : une règle formulée à l’oral, comme « au-dessus de 65 % », peut se lire avec ou sans la valeur limite.
Ces causes montrent qu’une grande partie de la fiabilité se joue hors du modèle : dans la qualité des sources, la précision des consignes et l’architecture du système. Changer de modèle règle rarement un problème de sources ou de consignes.
Hallucination ou problème de données : comment faire la différence ?
Face à une réponse fausse, le réflexe est d’accuser le modèle. Un diagnostic simple permet de corriger la bonne cause, en partant de la source citée :
- la source citée contient l’erreur : c’est un problème de données, à corriger dans le document ou dans le logiciel qui fait foi ;
- la source citée est juste mais la réponse la déforme : c’est une erreur du modèle ou de la consigne, à traiter par des contrôles ou une consigne plus précise ;
- aucune source n’est citée : soit l’information manque, soit la recherche a échoué, et le système aurait dû le signaler plutôt que répondre ;
- la source est juste mais périmée : c’est un problème de gestion documentaire, qui appelle une date de validité et un propriétaire.
Quelles erreurs surveiller selon l’usage ?
Toutes les tâches ne se trompent pas de la même façon. Un jeu de test utile cible les erreurs propres à l’usage. En extraction, on surveille les champs mal lus, les confusions de dates, d’unités ou de références. En classement, les mauvaises catégories et les urgences manquées, qui coûtent souvent plus cher qu’une erreur de catégorie. En rédaction, les affirmations non sourcées, les engagements que l’entreprise n’a pas pris et les écarts de ton. En recherche documentaire, le mauvais document ou la mauvaise version. Nommer ces erreurs à l’avance permet de les compter, et donc de savoir si le système progresse.
À retenir
Une réponse appuyée sur des sources n’est pas une réponse garantie exacte. Elle devient vérifiable, ce qui est déjà beaucoup.
Comment mesurer la fiabilité d’une IA avant de l’utiliser ?
La fiabilité ne se constate pas lors d’une démonstration, elle se mesure. La méthode tient en quatre étapes :
- Constituer un jeu de test : une série de cas réels ou représentatifs, avec la réponse attendue pour chacun, y compris des cas difficiles, des cas limites et des questions sans réponse dans les sources.
- Définir les critères : exactitude des faits, présence des sources, respect des consignes, capacité à signaler une information manquante.
- Mesurer : faire passer le jeu de test, noter chaque réponse et relever les types d’erreurs, pas seulement leur nombre.
- Rejouer à chaque changement : nouveau modèle, nouvelle consigne, nouvelles sources. Une amélioration sur un point peut en dégrader un autre.
Le seuil acceptable dépend du coût d’une erreur. Pour un brouillon relu par une personne, une correction occasionnelle est tolérable. Pour une information transmise à un client sans relecture, elle ne l’est pas. C’est au dirigeant de fixer ce seuil, en connaissance de cause, avant la mise en service. Chez Pecora, ce seuil fait partie des critères de recette écrits au cadrage.
Comment réduire les hallucinations d’une IA ?
Aucune méthode ne les supprime entièrement. Plusieurs mesures, combinées, les rendent rares, visibles et sans conséquence grave :
- Fournir les sources : un système de recherche augmentée (RAG) donne au modèle les passages utiles de vos documents plutôt que de le laisser répondre de mémoire.
- Exiger les citations : chaque affirmation renvoie au document et au passage qui la justifient, pour qu’une personne puisse vérifier en quelques secondes.
- Autoriser l’absence de réponse : la consigne prévoit de répondre « information manquante » plutôt que d’estimer.
- Hiérarchiser les sources : en cas de contradiction, une règle désigne le document qui fait foi, ou signale le conflit à la personne responsable.
- Sortir les chiffres du modèle : prix, quantités, dates et totaux viennent des logiciels de référence, par des règles informatiques.
- Ajouter des contrôles automatiques : après génération, vérifier la présence des mentions obligatoires, l’absence de termes interdits et la cohérence des chiffres avec les sources.
- Réduire le périmètre : une tâche étroite, avec des consignes précises, laisse moins de place à l’improvisation qu’une demande ouverte.
Ces mesures déplacent la question. Il ne s’agit plus de savoir si le modèle peut se tromper, mais de s’assurer qu’une erreur est détectée avant de produire un effet.
Une réponse qui cite ses sources est-elle forcément juste ?
Non. Une citation peut renvoyer à un passage qui ne dit pas exactement ce que la réponse affirme : un chiffre arrondi, une condition oubliée, une exception passée sous silence. Elle peut aussi renvoyer au bon document dans une version dépassée. La citation rend la vérification rapide, elle ne la remplace pas. Un contrôle utile consiste à vérifier, sur l’échantillon de test, que chaque affirmation figure réellement dans le passage cité, et à compter les écarts comme des erreurs à part entière.
Quel rôle pour la validation humaine ?
La validation humaine est le dernier contrôle, pas le seul. Elle est indispensable pour tout ce qui engage l’entreprise : un message envoyé à l’extérieur, une dépense, une suppression, une décision qui touche une personne. Pour être efficace, elle doit être outillée : la personne voit le résultat, ses sources et les points signalés comme incertains, et peut corriger ou refuser simplement.
Une validation qui consiste à cliquer sur « accepter » sans rien voir n’est pas une validation. Si le volume rend la relecture impossible, c’est le périmètre du système qu’il faut revoir. À l’inverse, une relecture systématique de résultats toujours justes finit par être bâclée : les mesures servent aussi à placer la validation là où elle compte.
Comment suivre la fiabilité après la mise en service ?
Les documents changent, les demandes évoluent, les fournisseurs mettent à jour leurs modèles. La fiabilité mesurée au lancement ne reste pas acquise. Un suivi simple suffit souvent :
- la part des résultats validés sans correction ;
- les types de corrections apportées, pour repérer une cause récurrente ;
- la part des cas signalés comme incertains ou hors périmètre ;
- un nouveau passage du jeu de test à chaque changement important.
Chaque système doit aussi pouvoir être arrêté, avec une reprise manuelle documentée, si la qualité se dégrade. Une erreur ne doit pas disparaître silencieusement parce que le traitement a continué.