Hallucination d'une IA

Une hallucination désigne une réponse produite par une intelligence artificielle qui est présentée comme un fait mais qui est fausse : une citation inexistante, une référence légale inventée, une fonctionnalité ou un code qui n'a jamais existé, un chiffre plausible mais erroné. Nous avons tous déjà expérimenté ces situations.

Le terme est trompeur, car il suggère un bug ou un dysfonctionnement. C'est en réalité une conséquence directe du fonctionnement d'un modèle de langage : il est entraîné à produire la suite la plus plausible d'un texte, et une information fausse mais bien formulée est parfaitement plausible.

Pourquoi c'est attendu

Comprendre l'origine du phénomène.

• Aucune représentation de la vérité : un modèle manipule des régularités statistiques du langage et n'est pas doté (nativement en tout cas) d'une base de faits vérifiés.
• Aucune notion d'ignorance : rien dans son fonctionnement purement technique ne lui permet de constater qu'il ne sait pas. Il produit toujours une réponse.
• Un entraînement qui valorise la fluidité : les réponses assurées et bien tournées sont privilégiées lors de l'ajustement des modèles. La formulation confiante est donc mise en valeur et exploitée, indépendamment de l'exactitude.
• Confiance n'est pas véracité : le ton d'une réponse ne donne aucune indication sur sa fiabilité. C'est ce qui rend le phénomène dangereux pour un utilisateur non averti ou un algorithme qui exploiterait ces données directement.

Comment réduire le risque

On ne supprime pas ainsi les hallucinations, on réduit leur fréquence et surtout leur impact.

• Ancrer les réponses dans des sources : une architecture RAG qui fournit au modèle les documents pertinents réduit nettement l'invention, à condition de lui interdire explicitement de répondre au-delà de ces documents.

• Afficher les sources : chaque affirmation renvoie au passage dont elle est tirée. L'utilisateur peut vérifier, et la simple possibilité de vérifier change son usage.

• Autoriser la réponse « je ne sais pas » : une consigne qui valorise l'aveu d'incertitude, et une interface qui traite cette réponse comme un succès et non comme un échec.

• Vérifier par du code, pas par un modèle : lorsqu'une réponse contient une référence, un identifiant ou un montant, un contrôle programmatique peut confirmer son existence avant affichage.

• Réserver le modèle aux tâches où l'erreur est tolérable : reformuler, résumer, classer ou suggérer acceptent une marge d'erreur. Établir un droit, un diagnostic précis ou une somme dûe ne peuvent se satisfaire d'approximations.

Une question d'interface autant que de modèle

La conception de l'interface est un levier sous-estimé. Une réponse affichée dans une bulle de conversation, sans source ni réserve, invite à la confiance. La même information présentée avec ses extraits d'origine, une mention de la date des documents et une invitation explicite à vérifier est une meilleure approche.

C'est un sujet d'expérience utilisateur et d'accessibilité : l'information sur la fiabilité doit être perceptible par tous, y compris via une aide technique, et ne pas reposer uniquement sur une nuance de couleur ou une icône discrète.

Une règle simple pour décider : si une réponse fausse non détectée cause un préjudice, l'intelligence artificielle ne doit pas être en position de décider seule. Elle peut assister une personne mais pas la remplacer.