Hallucination (LLM)

Définition

Une hallucination désigne la production, par un grand modèle de langage (LLM), d'un contenu factuellement faux, inventé ou non vérifiable, mais formulé avec la même assurance stylistique qu'une réponse exacte. Le modèle ne « ment » pas au sens intentionnel : il génère la suite de mots statistiquement la plus plausible, sans disposer d'un mécanisme interne de vérification de vérité. Cette absence de distinction entre plausible et vrai constitue un risque de premier plan dès qu'un LLM alimente une chaîne de décision en cybersécurité : triage d'alertes, analyse de vulnérabilités, génération de code ou rédaction de rapports d'incident.

Fonctionnement technique

Un LLM est un modèle auto-régressif : il prédit le token suivant à partir d'une distribution de probabilités conditionnée par le contexte. Plusieurs mécanismes expliquent l'apparition d'hallucinations :

• Compression paramétrique — les connaissances sont stockées de façon distribuée dans les poids du réseau, pas dans une base de faits interrogeable. Une information rare ou peu représentée dans le corpus est reconstruite par interpolation plutôt que restituée.
• Échantillonnage stochastique — une temperature élevée ou un top_p permissif favorise des tokens moins probables, donc plus créatifs et plus faux.
• Biais de complaisance (sycophancy) — l'alignement par apprentissage par renforcement récompense les réponses utiles et affirmatives, ce qui décourage le « je ne sais pas ».
• Coupure de connaissances — au-delà de la date d'entraînement, le modèle extrapole. Il inventera volontiers une CVE de l'année en cours.
• Contexte bruité ou contradictoire — en architecture RAG, des documents récupérés incomplets poussent le modèle à combler les vides.

Exemples concrets en cybersécurité

• CVE fantômes — un assistant produit un identifiant du type CVE-2025-48211 associé à un produit qui n'a jamais été affecté, avec un score CVSS et une description crédibles. L'équipe vulnérabilités perd des heures à investiguer une faille inexistante — ou, pire, ignore la vraie.
• Slopsquatting — le modèle recommande une dépendance logicielle qui n'existe pas (pip install requests-oauth2-helper). Des attaquants recensent ces noms hallucinés récurrents et publient sur PyPI ou npm des paquets malveillants portant exactement ce nom. L'hallucination devient alors un vecteur d'attaque sur la chaîne d'approvisionnement.
• Code non sécurisé présenté comme durci — génération d'une requête SQL concaténée décrite comme « protégée contre l'injection », ou d'une vérification de signature JWT qui accepte l'algorithme none.
• Fausse conformité — citation d'un article de la directive NIS 2 ou d'un contrôle ISO/IEC 27001 avec une numérotation inventée dans un rapport d'audit.
• Triage SOC erroné — un copilote qualifie un faux positif un comportement de type living-off-the-land en s'appuyant sur une règle de détection qu'il a lui-même fabriquée.

Liens avec d'autres concepts

L'hallucination est référencée dans l'OWASP Top 10 for LLM Applications sous l'entrée « Misinformation ». Elle interagit avec plusieurs risques voisins :

• L'injection de prompt et l'empoisonnement de données transforment un défaut probabiliste en hallucination induite par un attaquant.
• Le RAG (génération augmentée par récupération) réduit le taux d'hallucination en ancrant les réponses sur des sources, mais crée une nouvelle surface : un index vectoriel corrompu propage des faits faux avec une apparence de citation.
• Le shadow AI — usage non gouverné d'assistants par les métiers — multiplie les points d'entrée d'informations non vérifiées dans les processus internes.
• Sur le plan réglementaire, l'AI Act et la norme ISO/IEC 42001 imposent des exigences de robustesse, d'exactitude et de supervision humaine pour les systèmes à risque élevé.

Bonnes pratiques de mitigation

• Ancrer systématiquement les réponses sur des sources faisant autorité (NVD, CERT-FR, MITRE ATT&CK) via RAG, et exiger des citations vérifiables plutôt que des affirmations libres.
• Valider par outils déterministes — vérifier l'existence réelle d'une CVE ou d'un paquet par appel d'API avant restitution. Le modèle propose, le code dispose.
• Réduire l'entropie sur les tâches factuelles : temperature proche de 0, sorties structurées (JSON schema), contraintes de format.
• Autoriser explicitement l'abstention dans le prompt système : « si l'information n'est pas présente dans le contexte fourni, réponds que tu ne sais pas ».
• Human in the loop obligatoire pour toute action à effet de bord : modification de règle firewall, isolation d'un poste, clôture d'un ticket d'incident.
• Mesurer le taux d'hallucination avec un jeu d'évaluation métier et une revue contradictoire (juge LLM + relecture humaine), puis suivre cet indicateur dans le temps.
• Journaliser prompts et réponses pour permettre l'analyse post-incident et la traçabilité exigée par les référentiels de conformité.

À retenir

L'hallucination n'est pas un bug corrigeable par une mise à jour : c'est une propriété structurelle des modèles génératifs. La bonne posture consiste donc à concevoir l'architecture applicative en supposant que le modèle se trompera — ancrage documentaire, vérification programmatique et validation humaine sur les décisions sensibles.