Comment réduire les hallucinations de l’IA : trouver où la réponse déraille

Une hallucination de l’IA est une réponse qui présente comme établie une information inventée, déformée ou non étayée. Pour réduire ces erreurs, trouvez l’étape où la réponse a déraillé, corrigez-la, puis testez la correction sur le cas en échec et sur des cas qui doivent continuer à fonctionner.

Un chatbot peut promettre un remboursement que la politique ne prévoit pas. Un bot de support peut inventer une règle pour expliquer un bug. Un outil de recherche peut citer une décision de justice inexistante. Un assistant de code peut installer un paquet que personne n’a publié. Chaque réponse paraît solidement étayée, et c’est ce qui la rend coûteuse.

Ce guide explique pourquoi les modèles devinent, retrace quatre échecs publics jusqu’à l’étape où chacun a commencé, puis classe 14 méthodes selon cette étape. Choisissez celles qui correspondent à l’erreur observée : chacune demande de la maintenance. Les citations de sources en anglais sont traduites par nos soins.

La réponse en 60 secondes

• Conservez une réponse erronée avec sa question, les documents transmis et les résultats d’outils, puis remontez le parcours de l’affirmation contestée.
• Source incorrecte ou périmée : décidez quel document fait foi et synchronisez la copie utilisée pour la recherche.
• Éléments présents mais déformés : extrayez d’abord les éléments probants, puis vérifiez chaque affirmation.
• État actuel ou chiffres : lisez-les avec un outil ou calculez-les avec un programme, jamais à partir de la mémoire du modèle.
• Information manquante : donnez à l’assistant une issue légitime (une question, une réponse partielle, un passage de relais), puis rejouez le cas en échec après chaque modification.

Dans cet article

1. Pourquoi les modèles d’IA inventent des réponses
2. Quatre échecs publics retracés jusqu’à leur origine
3. Remonter une réponse fausse jusqu’à sa première erreur
4. Corriger ce que reçoit le modèle
5. Limiter les suppositions pendant la rédaction
6. Vérifier la réponse avant son envoi
7. Code : paquets et fonctions inventés
8. Empêcher le retour des erreurs corrigées
9. Les conseils que nous contestons
10. Quand un assistant doit répondre, demander ou passer la main

1. Pourquoi les modèles d’IA inventent des réponses

Un modèle de langage rédige la suite la plus plausible de ce qu’il reçoit. Quand cette entrée ne contient pas la réponse, une supposition plausible et une réponse exacte peuvent se ressembler parfaitement.

L’entraînement et l’évaluation aggravent le problème. Dans un article de septembre 2025, des chercheurs d’OpenAI soutiennent que « les modèles de langage hallucinent parce que les procédures d’entraînement et d’évaluation récompensent la supposition plutôt que la reconnaissance de l’incertitude » (Kalai et al., 2025). Un test qui ne compte que les bonnes réponses donne à une supposition une chance de marquer des points, et aucune à « je ne sais pas ». L’article d’OpenAI qui accompagne l’étude montre l’effet sur le banc d’essai SimpleQA :

Au seul taux de bonnes réponses, le second modèle semble légèrement meilleur. Il se trompe pourtant près de trois fois plus souvent. Un modèle ne dira donc pas « je ne sais pas » de manière fiable si votre système ne le lui permet pas et ne l’accepte pas comme résultat, et un score de classement renseigne peu sur la fréquence de ses inventions dans votre contexte.

Toute réponse fausse n’est pas une invention : un assistant peut reprendre fidèlement une consigne périmée. La correction n’est pas la même, d’où l’intérêt de diagnostiquer d’abord.

2. Quatre échecs publics retracés jusqu’à leur origine

Chaque cas est documenté par une décision de justice, une correction publique ou une déclaration de l’entreprise. Aucun n’a été résolu par un meilleur modèle, et chacun a commencé à une étape différente.

Air Canada : le chatbot contredit la page de la politique tarifaire

Un passager interroge le chatbot d’Air Canada sur les tarifs de deuil. Celui-ci indique que les voyageurs qui « ont déjà voyagé » peuvent demander le tarif réduit « dans les 90 jours suivant la date d’émission du billet ». La page de la politique dit le contraire, et Air Canada refuse le remboursement. Devant le Civil Resolution Tribunal de Colombie-Britannique, la compagnie soutient qu’elle ne répond pas des informations fournies par ses représentants, « y compris un chatbot ». Le tribunal juge l’argument « remarquable » : « Que l’information provienne d’une page statique ou d’un chatbot ne fait aucune différence. » Il accorde 812,02 dollars canadiens de dommages, intérêts et frais (Moffatt v. Air Canada, 2024 BCCRT 149).

Première étape défaillante : une question sur une politique a reçu une réponse sans lien avec la page qui fait foi, pourtant présente sur le même site.

Cursor : le bot de support invente une politique pour expliquer un bug

En avril 2025, un utilisateur de l’éditeur de code Cursor est déconnecté chaque fois qu’il change de machine. La réponse du support affirme : « Cursor est conçu pour fonctionner avec un seul appareil par abonnement, ce qui constitue une fonctionnalité de sécurité essentielle. » Cette politique n’existe pas ; la réponse vient d’un bot de support IA, et des utilisateurs annoncent leur résiliation. Un cofondateur parle d’« une réponse incorrecte d’un bot de support IA de premier niveau », puis attribue les déconnexions à « une situation de concurrence qui apparaît sur les connexions internet très lentes ». L’entreprise rembourse l’utilisateur, corrige le bug et signale désormais les réponses de l’IA (Hacker News, Ars Technica).

Première étape défaillante : le bot ignorait le seul fait qui comptait, l’existence d’un bug, et a comblé ce manque par une règle plausible.

Mata v. Avianca : des décisions inventées, confirmées par le même outil

En 2023, des avocats plaidant devant un tribunal fédéral de New York déposent des conclusions citant des décisions générées par ChatGPT ; six n’existent pas. Le dossier contient l’échange où ChatGPT, interrogé sur l’une d’elles, répond : « Après une nouvelle vérification, j’ai constaté que la décision […] existe bel et bien et peut être consultée dans des bases de données juridiques telles que Westlaw et LexisNexis. » Le juge inflige 5 000 dollars aux deux avocats et à leur cabinet, et rappelle que « les règles existantes confient aux avocats un rôle de garde-fou pour garantir l’exactitude de leurs écritures » (Opinion and Order on Sanctions, 22 juin 2023).

Première étape défaillante : personne n’a vérifié les références dans les bases que le modèle citait lui-même. Lui demander de confirmer sa réponse a produit une seconde invention, tout aussi assurée.

Deloitte : des références introuvables dans un rapport public

En 2025, Deloitte remet une revue d’assurance du système qu’utilise le ministère australien de l’Emploi et des Relations au travail pour appliquer les pénalités aux allocataires. Un chercheur de l’Université de Sydney y relève jusqu’à 20 erreurs, dont un livre cité qui, selon l’agence AP, n’existe pas, et une citation attribuée à une juge de la Cour fédérale, supprimée de la version corrigée. Celle-ci mentionne « une chaîne d’outils fondée sur un grand modèle de langage d’IA générative (Azure OpenAI GPT-4o) ». Deloitte affirme que les conclusions restent valables et rembourse la dernière échéance, 97 587,11 dollars australiens, d’un contrat de 439 142 dollars australiens (DEWR ; registre des marchés publics australiens, CN4118426).

Première étape défaillante : les références sont parvenues au client sans que personne vérifie que chaque source existe et dit bien ce que le rapport lui attribue.

Les quatre cas côte à côte

Deux leçons s’en dégagent. L’organisation répond de ce que dit son IA, quel que soit le canal. Et la correction se trouve autour du modèle : sa source, l’issue qu’il peut prendre et la vérification avant l’envoi.

3. Remonter une réponse fausse jusqu’à sa première erreur

Conservez la réponse erronée avec la question, les documents transmis et les résultats d’outils, puis remontez l’affirmation contestée jusqu’à la première étape où elle est devenue fausse.

Avec le RAG (génération augmentée par la recherche d’informations), recherche et rédaction sont deux étapes distinctes : un document pertinent dans les résultats ne prouve pas que le modèle a utilisé le passage décisif.

4. Corriger ce que reçoit le modèle

Méthode 1. Déterminer quelle source fait foi

Pour chaque type d’information, désignez la source autorisée à l’établir : la page de politique en vigueur pour les remboursements, la documentation de la version installée d’une bibliothèque, l’édition signée d’un contrat. La bonne politique d’Air Canada figurait sur le même site que son chatbot : ajouter des documents n’aide pas tant que le système ignore lequel fait foi.

Pour vérifier l’effet : posez une question dont la réponse change selon la version et examinez quel document la réponse suit.

Méthode 2. S’assurer que le bon passage atteint le modèle

• Copies périmées. Modifier l’original ne met pas à jour l’index. Synchronisez à chaque modification, testez les suppressions autant que les ajouts et rendez visibles les échecs de mise à jour.
• Mauvais périmètre. Séparez les contenus par produit, version ou finalité chaque fois que cela change la réponse.
• Identifiants perdus. Combinez recherche sémantique et correspondance exacte pour qu’un code comme SYNC-42 retrouve ses propres instructions.
• Contexte perdu. Gardez le titre, le nom du produit ou l’exception attachés à chaque extrait.

Pour vérifier l’effet : examinez le texte réellement transmis au modèle avant de juger la rédaction. Nous détaillons ces étapes dans nos guides sur l’indexation des documents sans réponses périmées et sur l’évaluation de la fraîcheur et de la recherche.

Méthode 3. Lire les informations changeantes avec un outil

L’état d’un compte, d’une commande, d’un test ou de toute donnée qui évolue doit provenir d’un appel d’outil qui lit l’enregistrement actuel, pas des documents ni de la mémoire du modèle. Le bot de Cursor avait besoin d’un seul fait, l’existence d’un bug de connexion, et n’avait aucun moyen de le lire.

Pour vérifier l’effet : testez un enregistrement absent et un appel en échec. Un appel en échec doit laisser l’état inconnu, sans devenir une réponse assurée.

Méthode 4. Confier le calcul à un programme

Faites choisir une fonction ou rédiger une requête par le modèle, et laissez la base de données calculer. Si les expériences terminées sont marquées status = 'completed' et que la requête filtre sur complete, elle s’exécute sans erreur et ne renvoie rien : « aucune expérience n’a été terminée » devient une conclusion fausse.

Pour vérifier l’effet : comparez la requête et son résultat à un cas dont vous connaissez la réponse.

5. Limiter les suppositions pendant la rédaction

Méthode 5. Demander la précision manquante

Listez les informations dont dépend la tâche (version, système d’exploitation, période, compte). Si l’une manque, posez une question ciblée au lieu de choisir une valeur par défaut sans le dire.

Méthode 6. Extraire les éléments probants avant de rédiger

Repérez d’abord les passages ou les champs nécessaires, puis rédigez uniquement à partir d’eux en laissant les manques visibles. Si un rapport ne mesure jamais le temps gagné, son résumé ne doit pas afficher de pourcentage.

Méthode 7. Donner à l’assistant une issue légitime

Puisque les modèles sont récompensés quand ils devinent (section 1), « n’invente rien » ne suffit pas. Concevez les alternatives : répondre à la partie étayée, signaler ce qui manque, poser une question ou transmettre le cas à une personne désignée. Notre guide sur quand l’IA d’entreprise doit répondre, préparer, demander une validation ou exécuter précise où placer ces limites.

Pour vérifier l’effet : mesurez séparément les réponses sans fondement et les refus inutiles. Corriger l’un aggrave souvent l’autre.

Méthode 8. Utiliser des réponses validées pour les politiques fixes

Règles de remboursement, conditions de résiliation et politiques de sécurité doivent provenir d’un texte validé et tenu à jour, dont les champs variables sont remplis à partir de données vérifiées. L’assistant identifie la situation ; il ne rédige pas de politique. Air Canada comme Cursor se sont retrouvés avec un bot qui énonçait une politique que l’entreprise n’avait pas.

Pour vérifier l’effet : testez une demande correspondant au scénario et une demande proche qui doit suivre un autre parcours.

6. Vérifier la réponse avant son envoi

Méthode 9. Vérifier chaque affirmation dans sa source

Décomposez la réponse en affirmations factuelles et comparez chacune à son passage, à son enregistrement ou à la source citée, conditions et quantités comprises. Pour une référence, confirmez dans la base d’origine que la source existe et dit bien ce qu’on lui attribue. C’est l’étape qui a manqué dans l’affaire Avianca et le rapport de Deloitte, et elle doit remonter à la source, pas revenir au modèle.

Pour vérifier l’effet : glissez une fausse référence dans une réponse de test et observez si la vérification la détecte.

Méthode 10. Contrôler séparément les règles et la structure

Lorsqu’une exigence peut s’écrire sous forme de règle (une période, un champ obligatoire, un montant maximal), contrôlez-la dans le code, en dehors du texte généré. Une réponse conforme à un schéma prouve sa forme, pas ses faits.

Méthode 11. Tester le vérificateur

Si un autre modèle juge les réponses, comparez ses verdicts à des exemples examinés par des personnes selon des critères explicites, y compris des réponses fausses mais convaincantes. Relevez séparément les erreurs manquées et les fausses alertes. L’accord entre deux modèles ne prouve pas que l’un ou l’autre a raison.

7. Code : paquets et fonctions inventés

Une étude présentée à USENIX Security 2025 a généré 576 000 extraits de code avec 16 modèles. Sur 2,23 millions de références à des paquets, 19,7 % désignaient des paquets inexistants : au moins 5,2 % pour les modèles commerciaux et 21,7 % pour les modèles open source, soit 205 474 noms inventés distincts. 43 % de ces noms sont revenus lors des dix répétitions de la même requête (Spracklen et al., 2025).

Des noms qui se répètent sont prévisibles : un attaquant peut les enregistrer et attendre. La pratique s’appelle le slopsquatting, un terme forgé par Seth Larson et publié pour la première fois par Andrew Nesbitt en avril 2025.

Méthode 12. Vérifier chaque paquet et chaque API avant l’exécution

• Avant d’installer un paquet suggéré, vérifiez qu’il existe, qu’il s’agit bien de celui attendu et que son éditeur est crédible. Verrouillez les versions et examinez chaque nouvelle dépendance.
• Fournissez à l’assistant la documentation de la version installée au lieu de vous fier à la mémoire du modèle.
• Exigez une preuve pour « terminé » : sortie des tests, fichier sur le disque, réponse de l’API. Un agent qui affirme que les tests passent formule une affirmation, pas un résultat.

Le durcissement du code écrit par l’IA et de ses dépendances fait partie de notre service Sécurité IA & durcissement du code.

8. Empêcher le retour des erreurs corrigées

Méthode 13. Rejouer les cas difficiles après chaque modification

Conservez un ensemble stable de questions ordinaires, d’exceptions, de demandes ambiguës et de questions sans réponse disponible, dans chaque langue prise en charge. Rejouez-le à chaque changement de modèle, de consignes, de réglages de recherche ou de documents importants, pour qu’une régression apparaisse à côté de l’amélioration.

Méthode 14. Conserver de quoi retracer une erreur

Enregistrez les passages sélectionnés, le contexte transmis au modèle, les paramètres et résultats des outils, et les versions. Si le bon document n’a jamais été trouvé, examinez la recherche. Si son exception a disparu, examinez la préparation du contexte. Si l’exception a atteint le modèle puis disparu de la réponse, examinez la génération et la vérification. Transformez chaque erreur réelle en cas de test conservé.

9. Les conseils que nous contestons

« Connectez vos documents et il cessera d’inventer. » La recherche change ce que le modèle voit, pas sa tendance à deviner. La bonne politique d’Air Canada figurait sur son propre site. Les documents n’aident que si le système sait lequel fait foi et y confronte la réponse.

« Un deuxième modèle vérifiera. » Un vérificateur est utile pour repérer des erreurs probables, pas pour accepter des réponses. Invité à revérifier, ChatGPT a confirmé les décisions inventées de l’affaire Mata v. Avianca. Testez tout vérificateur sur des exemples examinés par des personnes avant de vous fier à son verdict.

« Il suffit de prendre un modèle plus puissant. » Les modèles récents devinent peut-être moins, mais le taux de bonnes réponses masque les suppositions : dans l’exemple d’OpenAI, le modèle au meilleur taux de réponses exactes se trompait 75 % du temps. Changer de modèle ne corrige ni une source périmée, ni un outil manquant, ni une référence non vérifiée.

« Réglez la température à zéro. » Une température basse rend les réponses plus reproductibles, pas plus exactes. Une réponse fausse produite de façon déterministe est fausse à chaque fois.

« Dites-lui de ne pas halluciner. » Une consigne n’aide que si le système offre une vraie alternative (demander, répondre partiellement, passer la main) et si vous mesurez la fréquence à laquelle l’assistant la choisit.

10. Quand un assistant doit répondre, demander ou passer la main

Dans les quatre cas, les erreurs coûteuses étaient des engagements : un remboursement, une politique, une référence juridique, une source publiée. Nous fixons la limite selon la conséquence, pas selon l’assurance avec laquelle la réponse est formulée.

Partir d’une erreur que l’on peut reproduire

Choisissez une réponse régulièrement fausse et conservez les éléments qui l’ont produite. Corrigez la première étape où elle a déraillé, puis rejouez-la avec des cas qui doivent continuer à fonctionner. Suivez séparément les réponses sans fondement, les refus inutiles et le temps de correction pour décider si la correction reste en place.

Questions fréquentes