Détecter les hallucinations IA : 3 garde-fous pour le B2B

À quoi ressemblent les hallucinations IA dans les workflows B2B

Une hallucination, c'est quand le modèle génère une réponse au ton assuré mais fausse. En B2B, elle se manifeste sous trois formes classiques : (1) inventer un numéro de commande inexistant pour une demande support, (2) « citer » une date qui n'est pas réellement dans le contrat lors de la synthèse, (3) inventer une nouvelle catégorie en classant des factures hors du jeu défini.

Les trois partagent le même schéma : faute d'ancrage réel, le modèle comble le vide. Le problème, c'est que la sortie semble sûre — même fausse. Dire « l'IA se trompe » ne suffit pas ; il faut savoir où et pourquoi. Les trois garde-fous ci-dessous le permettent.

Trois garde-fous : source, règle, humain

Contrôle des sources : affichez le document et le passage qui étayent la réponse ; vérifiez leur pertinence, pas seulement la présence d’une référence. Une preuve absente ou contradictoire doit déclencher une vérification.

Contrôle des règles : vérifiez dans l’application l’existence de la commande, les droits, le montant et la catégorie. Un format valide ne garantit pas une information exacte.

Validation humaine : avant un paiement, un remboursement ou un message engageant, une personne habilitée examine la sortie exacte. Toute modification exige une nouvelle validation. Il n’existe pas de taux de réussite universel. Testez des cas corrects, faux et sans source : les sorties invalides doivent être bloquées et les dossiers transmis à leur responsable.

Construire un processus d'évaluation avant la mise en production

On ne détecte pas un taux d'hallucination en examinant les résultats à l'œil nu ; il faut un jeu de test. Constituez un jeu de référence de 50 à 200 exemples réels avec des réponses correctes connues, et assurez-vous qu'il couvre les cas limites — données manquantes, requêtes ambiguës, demandes hors périmètre. Faites tourner le modèle dessus avant chaque changement de prompt ou de modèle, pas seulement au lancement.

Suivez deux chiffres distincts : la précision (a-t-il donné la bonne réponse) et le taux d'abstention (a-t-il correctement dit « je ne sais pas » quand il le fallait). Un modèle qui n'admet jamais son ignorance paraît sûr de lui, mais il est plus risqué ; un modèle qui s'abstient trop souvent est agaçant, mais plus sûr. Le bon seuil dépend du coût relatif d'une mauvaise réponse par rapport à une réponse évitée.

Les tests adversariaux comptent autant que les tests de cas normaux — soumettez délibérément au modèle des requêtes conçues pour provoquer une hallucination : questions sur des entités qui n'existent pas, demandes qui mélangent deux dossiers, prompts qui lui demandent d'extrapoler au-delà du document source. S'il n'échoue pas proprement dans un test contrôlé, il n'échouera pas proprement en production non plus.

Traitez cela comme un pipeline vivant, et non comme un contrôle ponctuel. Chaque fois que vous modifiez le prompt, changez de modèle ou ajoutez une nouvelle source de documents, relancez le jeu d'évaluation et comparez les nouveaux chiffres de précision et d'abstention à votre référence avant tout déploiement. C'est la même discipline que les tests de non-régression dans les logiciels traditionnels — sauf qu'elle teste le jugement plutôt que la logique.

Quelles tâches présentent le plus grand risque d'hallucination

Le risque ne dépend pas uniquement du caractère libre ou structuré du texte. Une écriture comptable erronée dans une catégorie valide peut aussi causer un dommage. Évaluez l’impact, la réversibilité, la sensibilité des données et les destinataires. Préparer un brouillon ne doit pas donner les mêmes droits que contacter un client ou déplacer de l’argent.