Hallucination

Une réponse plausible, fausse, et sûre d'elle

Une hallucination est une sortie de modèle de langage qui présente comme un fait un contenu inexact ou inventé : une référence qui n'existe pas, un appel à une méthode d'API absente de la bibliothèque, un chiffre sans source, une CVE fictive citée avec aplomb. Le modèle produit du texte vraisemblable par construction ; rien dans sa sortie ne distingue ce qu'il sait de ce qu'il complète. Arthur AI, dans ses bonnes pratiques d'évaluation continue du 4 mars 2026, en donne une définition opérationnelle, testable sur chaque interaction : l'agent a-t-il énoncé des faits que son contexte n'étayait pas ?

Le phénomène prend plusieurs formes dans le développement logiciel. Les hallucinations d'API font appeler des méthodes qui n'existent pas ou ont changé de signature. Les hallucinations d'outils font improviser un agent qui ne sait ni quand ni pourquoi appeler lequel de ses dix serveurs MCP. Kent Beck décrit une forme plus retorse : un agent qui désactive ou supprime des tests pour simuler un succès, une erreur masquée plutôt qu'une erreur visible. Alexandre Mogère, chez Carrefour France, a vu un agent d'audit isolé générer une CVE inexistante avec toute l'apparence de la vraisemblance.

Pourquoi l'entreprise ne peut pas s'en remettre à la confiance

Le rapport DORA 2025 chiffre le malaise : 90 % des développeurs utilisent l'IA au quotidien, environ 30 % font confiance à sa sortie sans la vérifier. Le développeur devient vérificateur, et une hallucination ne se signale pas d'elle-même. Après sa cinquantième revue de la journée, le vérificateur fatigué approuve sans vraiment lire, et le bug glisse en production. Le rework rate, la métrique ajoutée par DORA en 2025, mesure ce que ces corrections tardives coûtent à l'équipe.

La gravité dépend du domaine. Une hallucination dans un texte créatif gêne ; dans une analyse financière restituée par un tableau de bord conversationnel, elle trompe une décision. Dans un bien commun de correctifs partagés entre agents, un correctif halluciné contamine tous ceux qui le consomment, à la vitesse de l'API. La discipline retenue par le cadre ADLC pour la revue de code s'applique partout : un constat produit par un agent est une affirmation à reproduire, pas un verdict, et il n'autorise aucune modification tant qu'un test, une trace ou un input ne l'a pas prouvé.

Comment on la mesure

Deux niveaux de mesure coexistent. Au niveau du modèle, des tests indépendants comparent les taux d'hallucination : sur AA-Omniscience, Artificial Analysis mesure celui de Gemini 4 Argon à 15 %, le plus bas parmi les modèles de tête en octobre 2026. Au niveau du système, les evals non supervisées d'Arthur AI tournent sur chaque interaction en production, sans réponse attendue, et rendent un verdict binaire sur quatre contrôles : hallucination, complétude de la réponse, adhérence thématique, exactitude de l'objectif. Une passerelle de sortie peut appliquer la même détection, à côté de celle de la toxicité et des fuites de données.

Sur un système RAG en production, SFEIR recommande une revue hebdomadaire des réponses dégradées, classées par cause : chunk manquant, récupération incorrecte, hallucination, question hors périmètre. Un score de benchmark ne dispense pas de cette mesure : le même modèle, testé la même semaine, a produit un jeu 3D en trois prompts chez un testeur et des hallucinations sur une question triviale chez un autre. Ce qui les séparait était le harnais, pas le modèle.

Comment on la réduit

Le premier levier est l'ancrage. Le RAG fournit au modèle les passages d'une base documentaire avant qu'il réponde, et un RAG agentique peut signaler qu'une information est absente du corpus au lieu de la fabriquer. Le levier sous-estimé est le context engineering : une équipe dont les agents hallucinent sur les standards internes monte six semaines de pipeline d'embeddings, et les hallucinations changent de forme sans disparaître, parce que la question était la structure de l'environnement cognitif de l'agent, pas la récupération. Des spécifications versionnées, des règles métier documentées et des décisions d'architecture enregistrées ferment l'espace que le modèle remplirait seul.

Le deuxième levier est la vérification croisée. La cross-validation multi-agents de Mogère confronte les conclusions de plusieurs agents indépendants et remonte les divergences à un humain ; elle a divisé le temps d'audit par trois. Le troisième consiste à fermer l'espace de sortie par construction : un modèle de décision comme Jev choisit parmi des réponses typées et ne peut rien inventer, ce qui n'empêche pas une décision d'être fausse. Dans tous les cas, l'humain conserve l'arbitrage sur les domaines critiques.

• Ancrer : RAG, contexte structuré et versionné, règles métier explicites.
• Mesurer : evals non supervisées sur chaque interaction, revue hebdomadaire des réponses dégradées.
• Croiser : plusieurs agents indépendants, divergences arbitrées par un humain.
• Contraindre : espace de sortie fermé quand la tâche s'y prête, tests et traces avant toute modification.