L’essentiel
- Le risque le plus matériel des modèles d’IA générative est la production de contenu infidèle, que le NIST désigne formellement par le terme de confabulation et que les équipes opérationnelles connaissent sous le nom d’hallucination.
- L’hallucination domine pour deux raisons : c’est le mode de défaillance le plus fréquemment observé en production, et c’est celui qui amplifie tous les autres risques (biais, fuite de données, atteinte à la propriété intellectuelle deviennent plus difficiles à détecter dans une sortie fluide mais fausse).
- La taxonomie de référence est le NIST AI 600-1, qui dénombre 12 risques propres à l’IA générative ou aggravés par elle, chacun rattaché aux quatre fonctions du cadre NIST de gestion des risques (Govern, Map, Measure, Manage).
- Au regard du Règlement européen sur l’IA (RIA), ce risque émerge dans l’article 9 (système de gestion des risques), l’article 13 (transparence), l’article 15 (exactitude et robustesse), l’article 50 (étiquetage du contenu synthétique) ainsi que les articles 53 et 55 (obligations applicables aux modèles d’IA à usage général et à risque systémique).
- Un schéma de gouvernance opérationnel s’articule en quatre couches : évaluation pré-déploiement, ancrage par récupération de documents et seuils de confiance, médiation des sorties avec revue humaine sur les flux critiques, et surveillance post-déploiement assortie d’un dispositif de remontée d’incidents.
Le risque majeur : la production de contenu infidèle
S’il faut retenir une seule réponse à la question, c’est celle-ci : l’hallucination, la tendance d’un modèle génératif à produire un contenu qui sonne juste mais qui s’avère factuellement faux, fabriqué ou non étayé par les sources fournies au modèle. Le NIST emploie le terme de confabulation dans son profil dédié à l’IA générative, en partie pour souligner le caractère structurel et non accidentel du phénomène : le modèle ne ment pas, il échantillonne dans une distribution de probabilité qui assigne une masse non nulle à des énoncés faux (NIST AI 600-1).
Trois raisons font de ce risque le risque dominant en 2026.
La première tient à la fréquence d’occurrence en production. Les travaux académiques qui cartographient les incidents réels d’IA générative établissent que la sortie infidèle est le mode de défaillance le plus signalé dans les systèmes déployés, devant le biais, la fuite de données ou l’injection de prompt (arXiv 2505.22073). Plusieurs précédents servent désormais de jurisprudence implicite dans le raisonnement des responsables conformité : la décision Air Canada, dans laquelle un tribunal canadien a retenu la responsabilité de la compagnie pour une politique de remboursement inventée par son assistant conversationnel ; la sanction Mata v. Avianca, par laquelle un juge fédéral new-yorkais a sanctionné des avocats ayant déposé un mémoire citant six affaires intégralement fictives produites par ChatGPT ; et des décisions australiennes de 2024 et 2025 dans lesquelles des avocats ont été déférés à leurs ordres professionnels pour des citations hallucinées similaires.
La deuxième raison est l’effet de composition. Un incident de biais dans un système déterministe se manifeste comme un écart mesurable dans les résultats. Le même incident dans un modèle qui hallucine peut se dissimuler à l’intérieur d’un paragraphe fluide et apparemment autorisé. Il en va de même pour la confidentialité : un résumé infidèle d’un dossier médical peut inventer un diagnostic, mêlant exposition réelle de données et exposition fabriquée. L’hallucination est le mode de défaillance qui rend tous les autres modes de défaillance plus difficiles à auditer.
La troisième raison relève de la portée réglementaire. Le RIA n’emploie pas le mot hallucination mais impose aux fournisseurs de systèmes d’IA à haut risque de concevoir leurs systèmes pour qu’ils atteignent un niveau approprié d’exactitude, de robustesse et de cybersécurité, et maintiennent ces caractéristiques tout au long de leur cycle de vie (article 15). Ils doivent par ailleurs fournir des notices d’utilisation transparentes sur les performances et limites du système (article 13). Pour les modèles à usage général, les obligations s’intensifient sous l’article 53, et pour les modèles présentant un risque systémique, le Code de bonnes pratiques GPAI de l’Office européen de l’IA impose un cadre complet de sûreté et de sécurité (Code GPAI, juillet 2025).
Un risque dominant fait la une. Douze risques composent la structure sous-jacente.
La carte complète : la taxonomie en 12 catégories du NIST
Pourquoi le NIST AI 600-1 sert de référence
La plupart des articles concurrents énumèrent huit, dix ou douze risques sans colonne vertébrale commune, ce qui rend les listes difficiles à comparer et plus difficiles encore à opérationnaliser. Le NIST AI 600-1, publié le 26 juillet 2024, lève cette difficulté. Élaboré par un groupe de travail public de plus de 2 500 contributeurs, il identifie 12 risques propres à l’IA générative ou notablement aggravés par elle, chacun rattaché aux quatre fonctions du cadre NIST de gestion des risques 1.0 (Govern, Map, Measure, Manage), avec plus de 200 actions recommandées réparties entre elles.
Les 12 risques, cartographiés au RIA et au Top 10 LLM de l’OWASP
| Risque NIST AI 600-1 | Définition synthétique | Article RIA | Équivalent OWASP LLM Top 10 (2025) |
|---|---|---|---|
| CBRN | Abaissement du seuil d’accès à des capacités chimiques, biologiques, radiologiques ou nucléaires | Art. 51, 55 (GPAI à risque systémique) | (aucun) |
| Confabulation (hallucination) | Génération assurée mais infidèle de faits, citations ou code | Art. 13, 15 | LLM09 Désinformation |
| Contenus dangereux, violents ou haineux | Sorties qui incitent, instruisent ou normalisent un préjudice | Art. 5, 50 | LLM05 Traitement inapproprié des sorties |
| Protection des données | Mémorisation et divulgation de données personnelles ou sensibles | Art. 10, 26 et RGPD | LLM02 Divulgation d’informations sensibles |
| Impacts environnementaux | Empreinte énergétique, hydrique et carbone de l’entraînement et de l’inférence | Considérant 142, art. 53(1)(d) | (aucun) |
| Biais préjudiciable et homogénéisation | Écart systématique selon des attributs protégés | Art. 10, 15, 27 | (partiel, LLM09) |
| Configuration humain-IA | Niveaux d’automatisation mal calibrés et excès de confiance | Art. 14 (contrôle humain) | LLM06 Agence excessive |
| Intégrité de l’information | Contenus médiatiques fabriqués, hypertrucages, désinformation de synthèse à grande échelle | Art. 50 (marquage du contenu synthétique) | LLM09 Désinformation |
| Sécurité de l’information | Nouvelles surfaces d’attaque propres à l’IA, dont les attaques par prompt | Art. 15(5) cybersécurité | LLM01 Injection de prompt, LLM04 Empoisonnement des données |
| Propriété intellectuelle | Atteintes liées aux données d’entraînement et reproductions dans les sorties | Art. 53(1)(c) résumé des données d’entraînement | LLM03 Chaîne d’approvisionnement |
| Contenus obscènes, dégradants ou abusifs | CSAM, imagerie intime non consentie, contenu de maltraitance | Art. 5, règlement CSAM | LLM05 Traitement inapproprié des sorties |
| Chaîne de valeur et intégration de composants | Propagation des risques du fournisseur de modèle de fondation jusqu’au déployeur | Art. 25, 53 | LLM03 Chaîne d’approvisionnement |
La table remplit deux fonctions à la fois. Pour une équipe ancrée aux États-Unis, elle préserve le vocabulaire NIST déjà utilisé. Pour une équipe ancrée en Europe, elle montre quelle obligation du régulateur s’attache à chaque risque. La colonne OWASP fournit le pont vers les architectes sécurité, qui utilisent généralement le LLM Top 10 v2025 comme langage partagé.
Comment se servir de la table pour prioriser
La taxonomie n’est pas une liste à cocher. La priorisation, c’est le travail. Pour chaque risque, posez deux questions : quelle est la vraisemblance de cette défaillance compte tenu de votre architecture et de votre contexte de déploiement, et quelle est la gravité si elle survient. Un assistant de décision clinique priorise la confabulation, le biais préjudiciable et la configuration humain-IA. Un assistant de génération de code priorise la confabulation, la sécurité de l’information et la propriété intellectuelle. Un agent conversationnel grand public priorise les contenus dangereux, l’intégrité de l’information et la protection des données. La taxonomie permet à chaque équipe de partir du même vocabulaire pour aboutir à des ordres de priorité différents.
Ce qui rend le profil de risque de l’IA générative différent
Trois propriétés de l’IA générative invalident les hypothèses sur lesquelles repose la gestion des risques applicative classique.
Échelle et vitesse. Un seul prompt produit du contenu à l’échelle d’Internet. Un assistant client mal configuré peut publier des milliers d’engagements de remboursement incorrects avant qu’un humain ne s’en aperçoive, comme Air Canada en a fait l’expérience. Le rayon d’impact d’une mauvaise mise en service n’est plus borné par le volume d’utilisateurs, il est borné par le volume de génération.
Sorties stochastiques. Le logiciel classique dispose d’un oracle de test déterministe : à une entrée donnée correspond une sortie fixée et testable. Les modèles génératifs échantillonnent dans une distribution. Le même prompt produit des sorties différentes d’une exécution à l’autre, et le même modèle se comporte différemment après un simple ajustement. Cette propriété brise les tests unitaires, les tests de non-régression et la plupart des critères d’acceptation rédigés pour du logiciel déterministe. L’évaluation doit passer de « la sortie est-elle égale à X » à « la sortie reste-t-elle dans une distribution acceptable », question plus difficile à instrumenter.
Capacités émergentes et opacité de la chaîne de valeur. Des comportements absents des données d’entraînement peuvent apparaître à grande échelle, parfois sans préavis entre deux versions. Parallèlement, la responsabilité est stratifiée : un fournisseur de modèle de fondation entraîne le modèle, un intégrateur l’ajuste et l’encapsule, un déployeur le présente aux utilisateurs. Le RIA traite cette chaîne via les dispositions de l’article 25 et les obligations applicables aux fournisseurs GPAI de l’article 53, mais en pratique le déployeur reste propriétaire de l’échec visible par l’utilisateur. Le Code de bonnes pratiques GPAI trace une ligne supplémentaire au seuil systémique de 10^25 opérations en virgule flottante pour l’entraînement, au-delà duquel les fournisseurs doivent maintenir un cadre de sûreté et de sécurité comportant évaluations de modèle et exercices d’attaque en équipe rouge.
Gouverner le risque dominant : un schéma en quatre couches
Une posture de gouvernance défendable pour le risque dominant s’aligne sur les fonctions Measure et Manage du cadre NIST, et sur les articles 9, 14, 15, 17 et 72 du RIA.
Couche 1 : évaluation pré-déploiement
Avant qu’un système génératif n’atteigne les utilisateurs, il doit passer une suite d’évaluation documentée couvrant ses modes de défaillance attendus. Pour la confabulation, cela signifie des bancs d’essai dédiés (TruthfulQA, HaluEval, évaluations spécifiques au domaine construites sur votre propre vérité terrain), des prompts d’équipe rouge conçus pour provoquer des citations fabriquées et des tests adversariaux inspirés des techniques de MITRE ATLAS. Le NIST AI RMF Playbook décrit la fonction Measure en termes opérationnels ; l’article 15 du RIA formalise cette obligation, en exigeant que les systèmes à haut risque soient conçus et développés de manière à atteindre un niveau approprié d’exactitude, de robustesse et de cybersécurité (article 15).
Couche 2 : ancrage par récupération et seuils de confiance
Le schéma architectural qui réduit le plus fiablement l’hallucination à l’exécution est la génération augmentée par récupération avec ancrage strict. Le modèle est contraint de répondre à partir de documents récupérés, avec citation explicite, et de s’abstenir quand la confiance de récupération passe sous un seuil configuré. Le mode de défaillance bascule alors de « répondre faux » à « refuser de répondre », transition nettement moins coûteuse à opérer. Le seuil de confiance s’inscrit aussi dans le devoir de transparence de l’article 13, qui exige que la conception permette aux utilisateurs d’interpréter correctement la sortie du système.
Couche 3 : médiation des sorties
Pour les flux à forts enjeux, la récupération ne suffit pas. La médiation ajoute une couche de validation entre le modèle et l’utilisateur : un second modèle vérifie la sortie du premier, un validateur à base de règles impose des contraintes structurelles, ou un opérateur humain examine la sortie avant qu’elle ne soit exploitée. Le choix du point de médiation relève de l’impact. Décisions cliniques, juridiques et financières exigent un opérateur humain dans la boucle. Les sorties informationnelles peuvent ne demander que des contrôles automatisés. Ce choix matérialise l’article 14 (contrôle humain) : les fournisseurs doivent concevoir les systèmes à haut risque pour que des personnes physiques puissent effectivement les superviser et passer outre leurs sorties. En France, la CNIL a publié des recommandations pratiques sur l’intégration de l’humain dans les boucles d’IA décisionnelle qui complètent utilement le cadre européen.
Couche 4 : surveillance post-déploiement et signalement d’incidents
Rien dans les couches 1 à 3 ne capture la dérive qui n’émerge qu’après mise en production, lorsque les prompts s’écartent du jeu d’évaluation et que les utilisateurs découvrent des cas limites non anticipés. L’article 72 du RIA formalise la surveillance après mise sur le marché, et l’article 73 fixe les obligations de signalement des incidents graves. La définition de travail de l’OCDE des incidents d’IA fournit un vocabulaire partagé (OECD AI Paper No. 16), et la fonction Manage du cadre NIST liste les pratiques opérationnelles : évaluation continue contre des bancs glissants, boucles de retour utilisateurs, détection d’anomalies sur les distributions d’entrée et processus de réponse aux incidents porté par une fonction nommée dans l’organisation.
Questions fréquentes
Quels sont les quatre types de risque en IA ? La division en quatre la plus citée s’appuie sur les caractéristiques d’IA digne de confiance du cadre NIST. Les fonctions Govern, Map, Measure et Manage décrivent le cycle de vie, tandis que les caractéristiques de confiance regroupent les risques en quatre catégories pratiques : risques de sûreté et sécurité, risques d’équité et de biais, risques de transparence et de responsabilité, risques de protection des données et de gouvernance des données. D’autres taxonomies (OCDE, catégories de risque du RIA, ISO 23894) opèrent des découpages différents. Pour la prise de décision, la taxonomie plus fine du NIST AI 600-1 en 12 risques reste plus utile qu’un modèle à quatre seaux.
Quel est le principal souci d’usage de l’IA générative ? Le souci principal est la production de contenu infidèle : le modèle renvoie une réponse assurée qui est fausse, fabriquée ou non étayée par des preuves. Les conséquences concrètes comprennent l’engagement de la responsabilité lorsqu’un assistant déforme une politique d’entreprise, des sanctions professionnelles lorsque des citations fabriquées se retrouvent dans des écritures judiciaires, l’atteinte à la réputation lorsqu’un contenu synthétique est pris pour de l’information authentique, et des dommages cliniques ou financiers lorsqu’une recommandation hallucinée est suivie d’effet. Ce souci n’a rien de théorique : les précédents incluent désormais l’affaire Air Canada et la sanction Mata v. Avianca.
Quel est un souci propre à l’usage de l’IA générative dans le développement logiciel ? Le souci le plus aigu en développement logiciel est la génération de code non sûr. Les assistants de codage produisent volontiers des extraits qui importent des bibliothèques obsolètes, codent en dur des identifiants, omettent la validation des entrées ou reproduisent des motifs vulnérables mémorisés depuis les données d’entraînement. L’OWASP couvre la famille avec LLM05 Traitement inapproprié des sorties et LLM01 Injection de prompt, et le NIST SP 800-218A étend le cadre de développement logiciel sécurisé au développement assisté par IA. Les contrôles concrets passent par la revue obligatoire du code généré par IA, l’analyse de secrets, le filtrage de dépendances et des comportements de refus lorsqu’on demande à l’assistant de produire du code sensible côté sécurité.
Comment le RIA régule-t-il spécifiquement l’IA générative ? Le Règlement européen sur l’IA traite l’IA générative sur trois plans. L’article 50 fixe des obligations de transparence pour les contenus synthétiques (étiquetage des hypertrucages, marques lisibles par machine). L’article 53 fixe le socle d’obligations applicable aux fournisseurs de modèles d’IA à usage général : documentation technique, politique de droit d’auteur, résumé des données d’entraînement et assistance aux fournisseurs en aval. L’article 55 ajoute des devoirs propres aux modèles d’IA à usage général présentant un risque systémique : évaluations de modèle, tests adversariaux, signalement des incidents graves à l’Office de l’IA et cybersécurité. Le Code de bonnes pratiques GPAI opérationnalise les articles 53 et 55 pour les fournisseurs au-delà du seuil de 10^25 FLOPs d’entraînement.
Quelle différence entre biais et hallucination ? Le biais est un écart systématique des sorties selon des attributs protégés ou des groupes : le modèle a plus de chances de recommander un candidat masculin, plus de chances de mal reconnaître un visage à peau foncée, plus de chances de produire un stéréotype. L’hallucination est la génération infidèle : le modèle invente une citation, une politique de remboursement, une personne, une affaire. Les deux figurent au NIST AI 600-1 mais constituent des catégories distinctes et appellent des remédiations différentes : le biais se traite par la sélection des jeux de données, des évaluations d’équité et des audits de résultats ; l’hallucination se traite par l’ancrage par récupération, les seuils de confiance et la médiation des sorties.
Existe-t-il des cadres de gouvernance conçus spécifiquement pour l’IA générative ? Oui. Les quatre les plus opérationnels aujourd’hui sont le NIST AI 600-1 (US, juillet 2024), le Code de bonnes pratiques GPAI (UE, juillet 2025), le Top 10 OWASP pour les applications LLM (industrie, novembre 2024) et MITRE ATLAS (industrie, en évolution). Le NIST AI 600-1 est la taxonomie de risques canonique avec ses actions associées. Le Code GPAI opérationnalise le RIA pour les fournisseurs à usage général. L’OWASP fournit la liste de vulnérabilités côté développeur. MITRE ATLAS catalogue les techniques adversariales. Combinés, ils couvrent taxonomie, opérationnalisation réglementaire, sécurité applicative et modélisation des menaces.
Les modèles plus larges règleront-ils l’hallucination ? Probablement pas par la seule échelle. Les modèles plus larges réduisent certains types d’hallucination et en amplifient d’autres, notamment les affirmations assurées dans les domaines sous-représentés au moment de l’entraînement. La position académique sérieuse en 2025 considère que l’hallucination est intrinsèque à la génération autorégressive et qu’elle doit être gouvernée au niveau système, par l’ancrage, la médiation et la surveillance, plutôt qu’attendue au niveau modèle (arXiv 2504.08526).
Conclusion
S’il faut une réponse à emporter dans un examen, une réunion de direction ou un comité de vendeurs, la voici : le risque majeur des modèles d’IA générative est la sortie infidèle, encore appelée hallucination ou confabulation. S’il faut défendre cette réponse ou la rendre opérationnelle, le paysage sous-jacent comporte douze risques dans la taxonomie NIST AI 600-1, chacun rattaché à des articles précis du RIA, et chacun gouvernable par un petit nombre de schémas architecturaux éprouvés. L’erreur fréquente consiste à traiter les risques un par un. L’opportunité consiste à adopter une taxonomie, à la cartographier sur une bibliothèque de contrôles et à exécuter le schéma en quatre couches dans une boucle d’amélioration continue.
Chez AI Sigil, nous livrons un registre de risques pré-cartographié sur le NIST AI 600-1 et sur les obligations haut-risque et GPAI du RIA, avec contrôles par catégorie et collecte de preuves prête pour audit. Le risque, c’est une partie du travail. L’autre partie consiste à le maintenir sous gestion.