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

1) Citation de source : le modèle retourne chaque réponse avec l'id ou le numéro de ligne du document source. Sans source, il répond « je ne sais pas ». Les hallucinations chutent d'environ 80%.

2) Pré-vérification par règles : valider la sortie contre des règles métier avant qu'elle n'arrive — le numéro de commande fait-il 8 chiffres ? La catégorie de facture est-elle dans la liste ? Le format de date est-il valide ? Ces vérifications Python peu coûteuses attrapent la majorité.

3) Approbation humaine préalable : les actions à enjeu (remboursements, signatures de contrats) sont proposées par l'IA mais approuvées par un humain. L'IA gère ~95% seule ; les 5% d'exceptions sont routées vers vous pour revue.

Les trois ensemble : en audit tiers indépendant, le taux d'hallucinations passe sous 2%.

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

Toutes les tâches d'IA ne présentent pas le même risque, votre budget de garde-fous ne devrait donc pas non plus être réparti uniformément. La génération ouverte — rédiger un e-mail client, résumer une réunion, écrire un texte marketing — laisse de la place à la créativité, mais c'est précisément dans cet espace que se cache l'hallucination : statistiques inventées, citations fabriquées, promesses que l'entreprise n'a jamais faites. C'est la catégorie à plus haut risque, car il n'existe pas de résultat « correct » fixe auquel se référer, seulement un éventail de résultats acceptables.

L'extraction numérique et financière arrive juste derrière. Extraire un total d'une facture, calculer une remise, extraire un numéro fiscal — les erreurs y sont silencieuses (le chiffre paraît plausible) et coûteuses (elles alimentent directement des mouvements d'argent). Les affirmations juridiques et proches du médical — obligations contractuelles, déclarations de conformité, posologie ou consignes de sécurité — appartiennent à la même catégorie à haut risque : une seule erreur, et le préjudice qui en résulte n'est pas de l'embarras, c'est de la responsabilité.

À l'autre extrémité, l'extraction structurée selon un schéma fixe — analyser ce CV pour en extraire nom/e-mail/compétences, classer ce ticket dans l'une de 12 catégories, associer cette transaction à un code marchand — est comparativement peu risquée. Le modèle a moins de marge pour inventer, car l'espace de sortie est contraint et facile à valider mécaniquement : on peut vérifier que la catégorie existe, que l'e-mail contient un signe @, que la valeur fait partie des 12 options. La classification dans un petit ensemble fermé se comporte de la même façon — même quand le modèle se trompe, il échoue à l'intérieur des limites que vous avez définies, ce qui constitue un mode d'échec fondamentalement moins coûteux.

Utilisez ce gradient pour décider où investir vos efforts de garde-fous. Les tâches à faible risque, à schéma fermé, peuvent souvent fonctionner avec une validation légère et des contrôles ponctuels. Les tâches à haut risque, ouvertes ou de nature numérique/juridique, méritent l'ensemble complet décrit dans la section précédente — citation des sources, contrôles de règles et supervision humaine — avant de laisser l'automatisation toucher un client ou un registre comptable.