L'hallucination des LLM, c'est-à-dire la génération d'information fausse présentée comme vraie, est un problème connu et largement discuté côté chatbot. Il est différent côté agent. Un chatbot qui hallucine fait dire une bêtise. Un agent qui hallucine agit sur la bêtise : appelle le mauvais outil, transfère la mauvaise somme, supprime le mauvais fichier, contacte le mauvais client.
Le passage du "dire" au "faire" change la nature du risque. Et les défenses classiques contre l'hallucination (RLHF, RAG, prompts soignés) sont nécessaires mais pas suffisantes pour les agents.
Les trois familles d'hallucination chez un agent
1. Hallucination factuelle
L'agent affirme un fait qui n'est pas vrai. Exemple : "le client a un solde de 12 000 €" alors que le bon montant est 1 200 €. Conséquence dans un agent : il agit sur le faux montant.
2. Hallucination de capability
L'agent croit qu'il dispose d'un outil qu'il n'a pas, ou inversement. Exemple : il tente d'appeler cancel_subscription() qui n'existe pas, ou il croit qu'update_user() ne change pas le mot de passe alors que c'est le cas.
3. Hallucination de contexte
L'agent invente du contexte manquant. Exemple : confronté à une demande ambiguë, il décide "l'utilisateur veut sûrement…" et agit selon cette interprétation inventée plutôt que de demander.
Les trois ont en commun qu'elles produisent une action confiante sur une base fausse. Cette confiance est précisément ce qui rend l'agent dangereux : un humain saurait douter.
5 défenses qui marchent en pratique
1. Grounding strict sur les données autoritatives
Les informations factuelles dont l'agent agit doivent venir d'outils explicites, pas de la connaissance du modèle. Pratique :
- Pour parler du solde du client, l'agent doit appeler
get_account_balance(client_id)et utiliser uniquement ce retour, pas une estimation. - Le prompt système doit explicitement interdire au modèle de produire des faits métier sans grounding.
- L'output utilisateur doit citer la source ("selon votre dashboard à 14h27").
C'est moins fluide. C'est aussi ce qui empêche les hallucinations factuelles d'arriver à l'action.
2. Validation structurée avant exécution
Quand l'agent émet un tool call, le payload doit passer par un validateur avant exécution :
- Schema JSON strict.
- Types et plages de valeurs vérifiés.
- Cohérence avec le contexte connu (ex: si la session est ouverte par user_id=42, refuser un tool call qui spécifie user_id=43).
Beaucoup d'hallucinations de capability se révèlent à ce stade — le LLM invente un paramètre qui n'existe pas, le validateur rejette.
3. Confirmation humaine sur les actions à fort impact
Cf. Outils tiers : matrice de risque. Pour tout ce qui est orange (impact fort, réversible difficilement), demander confirmation à l'utilisateur avec récap structuré :
"L'agent va envoyer cet email àclient@exemple.com. Sujet : 'Votre devis'. Pièce jointe :devis-2026-05.pdf. Confirmer ?"
Avec ce récap, l'utilisateur a un signal clair. Une hallucination de destinataire ("envoyé à clent@exemple.com") est détectée à l'œil avant l'envoi.
4. "Forced ask" en cas d'ambiguïté
Configurer l'agent pour qu'il demande plutôt que d'inférer quand un paramètre est ambigu. Au prompt système :
"En cas d'information manquante pour exécuter une action, ne pas deviner. Poser la question à l'utilisateur."
Cette instruction simple réduit fortement les hallucinations de contexte. Elle a un coût : plus de friction côté utilisateur. C'est un compromis assumé. Sur les actions sensibles, la friction est une vertu.
5. Détection de divergence par double inférence
Pour les décisions critiques :
- Faire générer la décision deux fois, idéalement par deux modèles différents (Claude + GPT par exemple).
- Si les deux convergent : OK.
- Si elles divergent : escalade vers humain, ou troisième modèle comme arbitre.
C'est cher en tokens. C'est précieux sur les actions critiques. Beaucoup d'agents financiers (fintech) le font déjà.
La métrique à suivre : faux positifs et faux négatifs au sens action
Côté observabilité, deux indicateurs spécifiques aux agents :
Faux négatifs d'action
L'agent refuse une action légitime parce qu'il pense qu'elle est dangereuse ou ambiguë. Visible côté UX : l'utilisateur se plaint que "l'agent ne fait rien". À calibrer pour ne pas devenir un agent inutile.
Faux positifs d'action
L'agent exécute une action illégitime parce qu'il a halluciné un contexte. Le pire. Souvent invisible immédiatement, détecté plus tard par l'utilisateur ou par un audit.
Une cible raisonnable en 2026 : moins de 0,1% de faux positifs d'action à impact externe sur un échantillon représentatif. Si vous êtes au-dessus, l'agent n'est pas prêt pour l'autonomie sur ce périmètre.
Le cas particulier des actions cumulables
Un risque sous-évalué : l'agent qui hallucine petit mais répété. Exemple :
- À chaque tour de conversation, l'agent décide que "l'utilisateur a sûrement envie qu'on lui envoie une notification".
- Aucune notification individuellement n'est aberrante.
- L'utilisateur reçoit 47 notifications en une heure.
Défenses :
- Rate limit par outil et par session.
- Détection statistique d'écart par rapport à la moyenne (un user qui reçoit 47 notifs est en queue de distribution).
- Quota global par jour avec alerte au seuil.
Ce qu'il ne faut pas attendre
Attendre que les modèles "ne hallucinent plus"
L'amélioration des modèles est réelle. Le taux d'hallucination de Claude Opus 4.7 ou GPT-5 est mesurablement plus bas que celui de GPT-4. Mais il n'est pas nul. Il ne le sera probablement pas avant longtemps. Construire un système qui suppose des hallucinations résiduelles, c'est construire un système qui marche en 2026 et en 2028.
Compter sur l'utilisateur final pour rattraper
Dans un produit consumer-grade, l'utilisateur ne lit pas attentivement les récaps. Les études HCI 2025-2026 sur l'automation bias sont sans ambiguïté : passé un certain niveau de confiance dans un agent, les humains valident les confirmations sans vraiment lire. Pour les actions critiques, le système ne peut pas reposer uniquement sur le clic humain.
Pour la matrice de risque par outil, Outils tiers : la matrice de risque. Pour le confinement runtime, Confinement d'un agent.