Hallucination IA : comprendre les erreurs pour mieux les bloquer

Un chatbot de support ne doit pas inventer une dérogation aux conditions de l’entreprise. Un assistant de reporting ne doit pas improviser un total. Un agent, c’est-à-dire un logiciel qui utilise un modèle pour choisir des actions et appeler des outils, ne doit pas deviner quel dossier client modifier. L’objectif concret : empêcher une réponse ou une action sans fondement de sortir de votre application.

Vérifié le 17 octobre 2026 à partir des recommandations des concepteurs de modèles, de la documentation des API, des exemples de recherche et de la décision de justice cités en lien. Les exemples ci-dessous sont des observations attribuées à leurs sources. Le validateur et le programme de la semaine sont des recommandations de mise en œuvre, pas des résultats obtenus en production.

Hallucination IA : de quoi parle-t-on et d’où vient-elle ?

Une hallucination de LLM est une affirmation fausse ou non étayée, présentée comme une réponse. LLM signifie large language model, ou grand modèle de langage : un modèle entraîné à produire du langage à partir de régularités dans les textes. Une affirmation peut aussi être sans fondement au regard des documents fournis, même si elle est vraie dans un autre contexte.

Imaginez un rédacteur habile qui complète une note à partir des documents posés sur son bureau. Il peut rédiger un paragraphe manquant très convaincant. Cela ne prouve pas que ce paragraphe a sa place dans les données de votre entreprise.

Prédire un texte plausible ne revient pas à vérifier un fait

Dans son billet de recherche sur les causes des hallucinations des modèles de langage, publié le 5 septembre 2025, OpenAI explique que le préentraînement apprend à prédire du texte sans disposer, pour chaque affirmation, d’une étiquette « vrai » ou « faux ». Les faits rares et arbitraires sont particulièrement difficiles à retrouver à partir de régularités. Les entraînements ultérieurs améliorent le comportement, mais l’aisance rédactionnelle ne garantit toujours pas la véracité.

Pour les développeurs, la conséquence est simple : les règles applicables aux produits, l’état des comptes et les stocks doivent figurer dans des sources de référence que l’application peut consulter. Utiliser la réponse mémorisée par le modèle comme une base de données crée un risque de défaillance évitable.

Un contexte incomplet ou périmé laisse des blancs

Le modèle n’a peut-être jamais reçu l’information dont le client a besoin. Un document importé peut être obsolète ; une recherche peut renvoyer vers la mauvaise édition d’un produit ; la consultation d’un compte peut échouer. Dans son explication des réponses incorrectes de Claude, Anthropic cite explicitement l’absence d’informations récentes parmi les sources de confusion.

Il faut distinguer deux incidents. Si l’assistant invente une règle, c’est la génération qui a échoué. S’il restitue fidèlement une règle qui n’est plus en vigueur, c’est la gestion des sources qui a échoué. Dans les deux cas, le client reçoit une réponse fausse. Mais modifier le prompt ne remettra pas à jour un document et ne réparera pas une requête de consultation de compte.

Exiger une réponse à tout prix encourage les mauvaises pratiques

Selon OpenAI, les évaluations fondées uniquement sur l’exactitude peuvent récompenser les réponses devinées plutôt que l’incertitude reconnue. Vos propres indicateurs peuvent reproduire ce biais si toute réponse fournie compte comme un succès et tout transfert à un humain comme un échec.

Un client qui demande une date de livraison garantie a besoin d’une estimation provenant du transporteur. Si celui-ci n’en a pas fourni, le résultat utile consiste à expliquer précisément quelle information manque. Valorisez ce résultat dans vos tests et dans votre tableau de bord opérationnel.

Exemples d’hallucinations des LLM : quatre erreurs à détecter

Classez les erreurs selon ce que votre application doit vérifier. Ces catégories se recoupent, mais elles donnent à une petite équipe des points de contrôle concrets.

Faits inventés : les exemples de titres de thèse proviennent du compte rendu de recherche d’OpenAI. Reconnaître un nom n’a pas permis de retrouver le titre manquant. Dans une entreprise, l’équivalent consiste à inventer une fonctionnalité parce que des produits similaires la proposent.

Chiffres erronés : les dates de naissance rapportées dans ce même compte rendu montrent qu’une date apparemment précise ne constitue pas une preuve. Dans votre application, distinguez les chiffres sans source des erreurs de calcul. Récupérez les quantités dans les données de référence et calculez les totaux avec du code classique ; demandez au modèle d’expliquer le résultat qui lui est transmis.

Fausses références : la décision du 20 mars 2024 dans l’affaire United States v. Cohen décrit trois affaires inexistantes obtenues auprès de Google Bard, le nom que portait alors l’assistant génératif de Google. L’une de ces références supposées était United States v. Figueroa-Florez. Un nom d’affaire plausible et une référence correctement présentée ne renvoyaient à aucune décision réelle.

Mauvais arguments transmis aux outils : les auteurs du Berkeley Function Calling Leaderboard présentent un appel contenant annual_interest_rate: 5 pour un taux demandé de 5%, à côté de la bonne représentation décimale, 0.05. Les deux valeurs sont des nombres. Un simple contrôle de type ne permet pas de les départager. Il s’agit d’une erreur sur le sens de l’argument : tout appel d’outil incorrect n’est pas un fait inventé, mais il relève du même contrôle avant exécution.

Comment réduire les hallucinations avant qu’elles n’atteignent les clients ?

Encadrez la génération par des sources et des validations, puis décidez du comportement attendu si les unes ou les autres manquent. Les développeurs prennent en charge les contrôles ; les équipes opérationnelles, les sources de référence et le circuit d’escalade.

Appuyer les réponses sur des sources à jour et pertinentes

La génération augmentée par la recherche, ou RAG (retrieval-augmented generation), recherche des informations dans des ressources externes et fournit au modèle les passages pertinents. Elle donne au rédacteur de la matière sur laquelle travailler. L’explication du Contextual Retrieval par Anthropic montre pourquoi il faut préserver le contexte d’un passage retrouvé : un extrait isolé peut omettre l’entreprise, la période ou le sujet dont il parle.

Pour une fonctionnalité de support, choisissez le corpus de règles qui fait autorité et associez-lui des métadonnées de produit, de région, de date d’entrée en vigueur et de droits d’accès. Filtrez les documents à l’aide de ces champs avant la génération. Récupérez ensemble la règle d’annulation et ses exceptions : séparé de ses réserves, un paragraphe peut justifier une promesse erronée.

Pour connaître l’état actuel d’un compte, interrogez la base de données ou le service de l’application. Une recherche documentaire remplace mal la consultation du statut d’expédition de la commande de ce client. Si cette consultation échoue, renvoyez un état d’indisponibilité au lieu de substituer discrètement des connaissances générales aux données manquantes.

Commencez par un circuit de recherche simple. Utilisez le RAG agentique, dans lequel le modèle peut choisir des étapes de recherche supplémentaires, lorsque les questions nécessitent des recherches complémentaires dans plusieurs sources. Ces recherches supplémentaires exigent des règles d’arrêt et les mêmes contrôles sur les sources.

La question utile pour le diagnostic est de savoir si les bonnes preuves sont parvenues au modèle. Conservez les identifiants et les versions des sources avec la réponse : un opérateur pourra ainsi distinguer une recherche infructueuse d’un ajout sans fondement.

Faire de « je ne sais pas » un état prévu par l’application

Le guide d’Anthropic pour réduire les hallucinations recommande d’autoriser l’incertitude, de travailler à partir d’extraits cités, d’indiquer les sources et de supprimer les affirmations non étayées. Traduisez ces recommandations en règles de réponse explicites.

Prévoyez des états tels que answered, needs_clarification et insufficient_evidence. N’imposez pas de remplir un champ obligatoire avec une réponse inventée lorsqu’aucune réponse n’est disponible. L’interface doit rendre chaque état utile : une question complémentaire ciblée, une explication de la donnée manquante ou un transfert accompagné du contexte déjà récupéré.

Voici une consigne utile : « Utilisez uniquement les règles et les données de compte fournies. Si ces données ne permettent pas d’établir la réponse, précisez les informations manquantes. Ne déduisez pas l’éligibilité à partir de cas similaires. » Testez cette consigne avec des preuves manquantes, pas seulement avec des questions faciles.

Un résultat inconnu n’est ni un refus pour raison de sécurité, ni un dépassement du délai d’attente d’un outil, ni une demande non autorisée. Distinguez ces états dans les journaux pour que chaque problème parvienne à la bonne personne.

Rendre les références vérifiables par le code

Une référence doit désigner une preuve que votre application connaît déjà. Faites attribuer des identifiants aux sources lors de la recherche, puis associez ces identifiants à des URL approuvées côté serveur. Évitez de demander au modèle de reconstituer de mémoire une bibliographie ou une URL de destination.

Vérifiez trois propriétés distinctes :

• Existence : l’identifiant cité correspond à une source autorisée fournie pour cette requête.
• Exactitude de l’extrait : le texte cité figure dans la version exacte de la source utilisée pour répondre.
• Justification de l’affirmation : le passage établit bien cette affirmation pour la situation de ce client.

Les deux premières se contrôlent simplement par le code. La troisième nécessite une règle métier, un champ structuré fiable ou un examen distinct du lien entre l’affirmation et ses preuves. Trouver le mot « éligible » dans un document ne prouve pas qu’un client donné l’est.

La documentation d’Anthropic sur les citations décrit des références liées aux documents qui facilitent la localisation des preuves. Un lien vers une source aide à auditer une réponse ; il ne suffit pas à établir que cette source est à jour, fait autorité ou a été correctement interprétée.

Structurer les sorties, puis valider leurs valeurs

Les sorties structurées imposent à la réponse un schéma, c’est-à-dire une définition des champs et des types de valeurs autorisés. Elles facilitent l’écriture des contrôles applicatifs. Le guide Structured Outputs d’OpenAI avertit explicitement que les sorties peuvent encore contenir des erreurs et qu’une entrée incompatible peut provoquer des hallucinations si les règles de réponse ne prévoient aucune solution de repli adaptée.

Avant d’exécuter un appel d’outil, validez l’opération, les arguments requis, les unités, les valeurs autorisées, l’existence des enregistrements et les droits de l’appelant. Déterminez le tenant et l’utilisateur authentifié dans le code de l’application. Laissez le modèle choisir parmi les enregistrements autorisés lorsque c’est pertinent ; ne considérez jamais un identifiant client fourni par le modèle comme une preuve de droit d’accès.

Même après un appel d’outil réussi, la réponse au client doit rester fidèle au résultat. N’annoncez pas une annulation terminée si l’outil a renvoyé un état en attente ou une erreur. Fondez le message final sur le statut renvoyé. Le guide des garde-fous pour les agents IA du site détaille les limites à poser autour de ces actions.

Détecter les hallucinations d’un LLM : un contrôle à exécuter

Pour un champ factuel bien délimité, comparez la valeur proposée à un enregistrement approuvé, puis composez vous-même la réponse. Vous obtenez ainsi une garantie plus solide pour ce champ qu’en jugeant la cohérence apparente d’un texte libre.

L’exemple Python suivant utilise un jeu de données fictif sur les modalités du support, pas les règles d’une entreprise réelle. Enregistrez-le sous verify_answer.py, puis lancez python3 verify_answer.py. Il utilise uniquement la bibliothèque standard et n’effectue aucun appel d’API.

# Records must be filtered for the caller's access and policy scope
# before reaching this function. These are illustrative fixtures.
records = {
    "support-policy": {
        "text": "The support channel for this workspace is email.",
        "current": True,
        "fields": {"support_channel": "email"},
    }
}


def validate(result, sources):
    keys = {"status", "field", "value", "source_id", "quote"}
    if not isinstance(result, dict) or set(result) != keys:
        return False
    if result["field"] != "support_channel":
        return False
    if result["status"] == "unknown":
        return all(result[k] is None
                   for k in ("value", "source_id", "quote"))
    if result["status"] != "answered":
        return False
    if not all(isinstance(result[k], str)
               for k in ("value", "source_id", "quote")):
        return False
    source = sources.get(result["source_id"])
    if source is None or source["current"] is not True:
        return False
    quote = result["quote"].strip()
    return (
        bool(quote)
        and quote in source["text"]
        and result["value"]
        == source["fields"].get(result["field"])
    )


proposal = {
    "status": "answered",
    "field": "support_channel",
    "value": "chat",
    "source_id": "support-policy",
    "quote": "The support channel for this workspace is email.",
}

if not validate(proposal, records):
    print("Hold: evidence or value check failed.")
elif proposal["status"] == "unknown":
    print("I cannot confirm the support channel from these records.")
else:
    print(f"Your support channel is {proposal['value']}.")

La réponse proposée, chat, échoue au contrôle alors que l’extrait cité est authentique. Avec la valeur email, elle passe ce contrôle ciblé. C’est le champ de confiance qui établit la réponse, pas la seule correspondance de l’extrait.

Cette limite est essentielle : le validateur ne peut pas établir la véracité d’une explication libre, confirmer que le responsable des règles a saisi le bon fait, ni vérifier que le filtrage des accès en amont a fonctionné. Sa branche unknown valide une forme de réponse autorisée, sans déterminer s’il était nécessaire de s’abstenir. Traitez ces questions dans des contrôles et des évaluations distincts. Pour des faits fixes aux conséquences importantes, un modèle de texte rempli à partir de données fiables peut rendre la génération entièrement superflue.

Des évaluations qui valorisent les bonnes réponses et les arrêts justifiés

Une évaluation, ou eval, est un test reproductible qui compare le comportement de votre application à ce qui est attendu. Construisez vos évaluations autour des erreurs subies par les clients et relancez-les dès que le modèle, le prompt, l’index de recherche, le schéma d’un outil ou les règles métier changent.

Consignez séparément les résultats : réponse correcte et étayée, réponse non étayée, abstention justifiée, abstention inutile et action proposée invalide. Une moyenne unique masque l’origine des progrès : de meilleures preuves ou, simplement, davantage de questions laissées sans réponse.

Utilisez du code classique pour contrôler les valeurs exactes, l’appartenance d’une source au corpus, les champs obligatoires, les permissions et les résultats des outils. Réservez un modèle juge aux questions qui dépendent du langage, par exemple pour déterminer si un passage justifie une reformulation. Calibrez ses décisions avec des exemples revus par des humains. Un LLM utilisé comme juge reste un modèle faillible, pas une source indépendante de faits.

Promptfoo est un outil d’évaluation dont les assertions évaluées par un modèle permettent notamment de vérifier l’exactitude factuelle par rapport à une référence et la fidélité au contexte fourni. Cette distinction est utile : une réponse peut être conforme à un document périmé tout en étant fausse aujourd’hui. Appuyez-vous sur le guide Promptfoo pour mettre en place le dispositif de test, après avoir défini les critères de réussite.

Dans chaque trace de test, conservez ensemble la requête, les preuves récupérées, les arguments proposés, le résultat de l’outil exécuté et la réponse finale. En cas d’échec, cet ensemble vous indique où intervenir. Considérez explicitement les références manquantes et les arguments invalides comme des échecs, même si le modèle juge attribue une bonne note au texte.

Quelles promesses faut-il relativiser ?

Le RAG ne rend pas toutes les réponses vraies. Un passage pertinent peut être retrouvé puis mal interprété ; un passage périmé peut être cité à la lettre. Testez séparément la recherche et la génération, et confiez la responsabilité du corpus de sources à une personne identifiée.

Une fenêtre de contexte plus grande ne remplace pas la sélection des sources. Les recommandations d’Anthropic sur l’ingénierie du contexte avertissent que le rappel et la précision peuvent se dégrader à mesure que le contexte s’allonge. Incluez la règle pertinente, ses exceptions et les données de compte nécessaires. Déverser tous les documents dans le prompt ne garantit pas leur actualité.

L’approbation d’un second modèle ne constitue pas, à elle seule, une vérification. Fournissez aux évaluateurs les preuves réelles et un critère clair. Sans preuve indépendante, leur accord peut simplement perpétuer la même hypothèse sans fondement.

Un JSON valide n’est pas un certificat d’exactitude. Le schéma peut imposer un identifiant de source et un argument numérique ; votre application doit encore établir que la source existe et que le nombre a le bon sens.

Les limites à connaître sont les questions auxquelles vos sources ne peuvent pas répondre, les champs que vos contrôles ne peuvent pas vérifier et les actions que vous ne pouvez pas annuler sans risque. Aucun taux d’hallucination universel ne permet de savoir si votre workflow précis est prêt.

Une feuille de route pour votre petite équipe, dès cette semaine

Agissez dès maintenant si votre fonctionnalité fait des promesses factuelles aux clients ou modifie des données métier. Si elle se limite à rédiger des contenus qu’une personne responsable vérifie déjà à partir des sources, commencez par le jeu d’évaluation et améliorez cette relecture avant d’ajouter une architecture automatisée complexe. Une requête déterministe qui renvoie déjà des champs faisant autorité peut se passer entièrement de modèle.

Ce programme est une proposition pour démarrer. Il ne prouve pas qu’une semaine de travail suffit à rendre un système fiable en production.

Le premier geste du lundi consiste à reprendre une réponse erronée récente et à en conserver la trace complète. Déterminez si les preuves étaient absentes, périmées, mal interprétées ou ignorées. Ajoutez le contrôle le plus simple capable de détecter cet échec, puis faites de l’incident un cas permanent de non-régression.

Questions fréquentes sur les hallucinations des LLM

Pour recevoir des guides pratiques sur la création de workflows IA fiables, abonnez-vous à la newsletter.