26/10/2026

NIST AI 100-2 : la taxonomie des attaques contre l’IA

Le NIST AI 100-2 est la taxonomie de référence des attaques contre l’IA, autrement dit le lexique américain de l’apprentissage automatique antagoniste : qui attaque, à quelle étape du cycle de vie, avec quelles capacités et dans quel but. Pour une équipe européenne, c’est le vocabulaire le plus précis disponible pour les attaques que vise l’article 15 de l’AI Act. Nous montrons ici comment transformer cette taxonomie en preuves : registre des menaces, plan de tests et dossier technique.

Tiroir de spécimens en bois ouvert, aux compartiments étiquetés contenant de petites clés en laiton, une loupe fêlée et un sceau de cire brisé, image de la taxonomie NIST AI 100-2

L’essentiel

Le NIST AI 100-2 (édition <code>NIST AI 100-2e2025</code>, mars 2025) classe les attaques contre l’IA prédictive et générative ; il est volontaire et ne fixe aucune tolérance au risque.
L’édition 2025 introduit des identifiants stables <code>NISTAML</code> : nous comptons 5 catégories de violation et 25 identifiants d’attaque, une clé primaire idéale pour un registre des menaces.
Le document ne cite ni l’AI Act ni aucune norme ISO/IEC et laisse de côté la décision de risque que le règlement impose.
Notre table de correspondance relie chaque attaque nommée par l’article 15, paragraphe 5, aux identifiants du NIST et aux preuves à conserver.
Les normes européennes arrivent (ETSI EN 304 223, <code>ISO/IEC 27090</code>, <code>prEN 18282</code>) et le NIST affiche désormais « Super Intelligence » sans avoir modifié le document.

NIST AI 100-2 : ce que le document est, et ce qu’il n’est pas

Le titre complet est « Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations ». La version en vigueur, <code>NIST AI 100-2e2025</code>, a été approuvée par l’Editorial Review Board du NIST le 20 mars 2025, puis annoncée par le CSRC le 24 mars 2025. Elle succède à <code>NIST AI 100-2e2023</code>, publiée en janvier 2024 malgré son millésime. Les auteurs viennent de la recherche publique et de l’industrie : Apostol Vassilev (NIST), Alina Oprea (Northeastern University), Alie Fordyce et Hyrum Anderson (Cisco), Xander Davies (UK AI Security Institute) et Maia Hamin (US AI Safety Institute).

Selon notre décompte, le PDF de l’édition 2025 compte 127 pages et 449 références numérotées, contre 107 pages et 354 références pour l’édition précédente. Un glossaire fixe chaque terme, ce qui en fait un dictionnaire autant qu’une taxonomie. Le texte reprend les notions de sécurité, de résilience et de résistance du NIST AI RMF et complète, côté menaces, le profil IA générative NIST AI 600-1.

Ce n’est pas un référentiel de conformité. Une note de bas de page précise qu’il « does not establish any legal standard or any other legal requirement » et le résumé exécutif écarte toute recommandation sur la tolérance au risque. La page officielle de la publication le range d’ailleurs parmi les rapports, pas parmi les normes.

Ce qui a changé entre 2023 et 2025

Cinq évolutions comptent pour un praticien. Les identifiants <code>NISTAML</code> apparaissent : 30 codes, contre aucun en 2023. Le terme « abuse » devient « misuse » pour les violations propres à l’IA générative. Une section dédiée traite la chaîne d’approvisionnement de l’IA générative. Deux sections nouvelles portent sur la sécurité des agents et sur les bancs d’essai. Enfin, la bibliographie passe de 354 à 449 références.

Le renommage « Super Intelligence »

Le décret présidentiel américain du 29 septembre 2026, « Inaugurating the Era of Super Intelligence », impose aux agences fédérales d’écrire « Super Intelligence » au lieu d’« Artificial Intelligence » dans leurs communications officielles (fiche de la Maison-Blanche). Il ne crée aucune obligation pour les entreprises privées. La page du NCCoE s’intitule désormais « Super Intelligence: Adversarial Machine Learning » et, le 20 octobre 2026, les overlays COSAiS sont devenus COSIS, le NIST précisant que « Previously issued documents and publications have not been altered ». L’identifiant <code>NIST AI 100-2e2025</code> reste donc inchangé. Au 22 octobre 2026, nous n’avons trouvé ni édition 2026 ni projet public, alors que le NIST annonçait en mars 2025 une mise à jour annuelle.

Comment la taxonomie est construite

La taxonomie du NIST AI 100-2 croise cinq dimensions. Le type de système d’abord : IA prédictive ou IA générative. L’étape du cycle de vie ensuite : entraînement ou déploiement. Puis les objectifs de l’attaquant : disponibilité, intégrité, confidentialité, auxquels s’ajoute le mésusage pour l’IA générative. Viennent les capacités de l’attaquant : contrôle des données d’entraînement, contrôle du modèle, accès par requêtes, ou contrôle des ressources qu’interrogent un système RAG et ses outils. Enfin, sa connaissance du système : boîte blanche, boîte noire ou boîte grise.

Cette grille oblige à formuler une hypothèse de menace explicite. Un modèle exposé par API à des clients n’a pas le profil d’un modèle affiné en interne sur des données collectées sur le web : le premier subit surtout des requêtes, le second peut avoir été empoisonné avant même sa mise en service. Les deux relèvent pourtant de la même démarche de sécurité de l’IA.

Les cinq catégories de violation portent chacune un code : <code>NISTAML.01</code> disponibilité, <code>NISTAML.02</code> intégrité, <code>NISTAML.03</code> confidentialité, <code>NISTAML.04</code> mésusage, <code>NISTAML.05</code> chaîne d’approvisionnement. Les 25 identifiants d’attaque s’y rattachent, une même attaque pouvant figurer sous plusieurs catégories. Un index renvoie chaque code vers sa définition dans le texte.

C’est l’apport majeur de l’édition 2025 du NIST AI 100-2. Un identifiant stable survit aux changements d’outillage, se relie aux techniques de MITRE ATLAS et aux entrées de l’OWASP, et permet de comparer des systèmes entre eux. Nous recommandons de l’utiliser comme clé primaire du registre, puis d’y rattacher contrôles, tests et preuves. Un libellé change d’un outil à l’autre ; <code>NISTAML.015</code> désigne toujours l’injection indirecte de prompt.

Attaques contre l’IA prédictive : évasion, empoisonnement, confidentialité

Évasion. L’attaquant modifie une entrée au moment de l’inférence pour provoquer une erreur : c’est l’exemple adverse (<code>NISTAML.022</code>), décliné en boîte noire lorsque l’attaquant ne dispose que de requêtes (<code>NISTAML.025</code>). La transférabilité aggrave le problème : un exemple conçu sur un modèle de substitution trompe souvent le modèle cible. Les cas réels cités incluent des panneaux stop lus comme des limitations de vitesse.

Empoisonnement. Il vise l’entraînement. Côté disponibilité, le NIST distingue l’empoisonnement des données (<code>NISTAML.013</code>), l’empoisonnement de modèle (<code>NISTAML.011</code>) et l’empoisonnement à étiquettes propres (<code>NISTAML.012</code>), auxquels il ajoute les attaques énergie-latence (<code>NISTAML.014</code>), menées par simple accès aux requêtes. Côté intégrité : empoisonnement ciblé (<code>NISTAML.024</code>), porte dérobée (<code>NISTAML.023</code>), porte dérobée à étiquettes propres (<code>NISTAML.021</code>), empoisonnement de modèle (<code>NISTAML.026</code>) et sa variante par la chaîne d’approvisionnement (<code>NISTAML.051</code>).

Confidentialité. Quatre attaques : extraction de modèle (<code>NISTAML.031</code>), reconstruction de données (<code>NISTAML.032</code>), inférence d’appartenance (<code>NISTAML.033</code>), qui révèle si un enregistrement figurait dans le jeu d’entraînement, et inférence de propriétés (<code>NISTAML.034</code>) sur ce même jeu.

Le NIST AI 100-2 recense les parades connues : entraînement antagoniste, lissage aléatoire (randomized smoothing) et vérification formelle contre l’évasion ; assainissement des données et inspection du modèle contre l’empoisonnement ; confidentialité différentielle contre les attaques sur la vie privée. Il prévient aussi que ces mesures restent largement empiriques et qu’il n’existe aucune preuve de sécurité, au sens de la théorie de l’information, pour les algorithmes d’apprentissage couramment déployés.

Conséquence pratique : une mesure d’atténuation se documente avec ses résultats de test, jamais comme une garantie. Un plan de red teaming qui rejoue les mêmes attaques à chaque nouvelle version du modèle vaut davantage qu’une affirmation de conformité.

Attaques contre l’IA générative : chaîne d’approvisionnement, prompts, agents

L’IA générative hérite des attaques précédentes et en ajoute. Le NIST AI 100-2 consacre désormais une section à sa chaîne d’approvisionnement : modèles pré-entraînés et jeux de données tiers peuvent porter un empoisonnement invisible pour l’utilisateur, et les attaques pendant l’entraînement, pré-entraînement comme affinage, ont leur identifiant (<code>NISTAML.037</code>).

Injection directe. L’injection de prompt (<code>NISTAML.018</code>) couvre les jailbreaks, par lesquels un utilisateur contourne les garde-fous du modèle. Elle relève à la fois de l’intégrité et du mésusage.

Injection indirecte. Le texte malveillant arrive par un contenu récupéré, page web, document ou courriel (<code>NISTAML.015</code>). Il peut viser la disponibilité en imposant des tâches longues en arrière-plan (<code>NISTAML.017</code>), l’intégrité en produisant des sorties désalignées (<code>NISTAML.027</code>), ou la confidentialité : extraction du prompt système (<code>NISTAML.035</code>), fuite d’informations issues des interactions des utilisateurs (<code>NISTAML.036</code>), extraction de données (<code>NISTAML.038</code>) et compromission des ressources connectées (<code>NISTAML.039</code>), par exemple un assistant de messagerie amené à transférer des courriels à l’attaquant.

Agents. Le NIST AI 100-2 reconnaît, en section 3.5, que la recherche en sécurité propre aux agents « is still in its early stages ». Le risque change pourtant de nature : dès qu’un agent appelle des outils, une injection indirecte devient exécution de code ou exfiltration de données. Nous détaillons ce point dans notre article sur la sécurité de l’IA agentique, et la correspondance avec le Top 10 OWASP pour les LLM fait l’objet d’un guide distinct.

Bancs d’essai. Le document cite JailbreakBench, HarmBench et AgentDojo pour mesurer, Garak et PyRIT pour attaquer de façon outillée. Il rappelle aussi des travaux montrant que, tant qu’un modèle conserve une probabilité non nulle de comportement indésirable, un prompt bien choisi finira par le déclencher. D’où l’intérêt de campagnes répétées plutôt que d’un test ponctuel avant la mise en production.

Ce que NIST AI 100-2 laisse délibérément de côté

Notre décompte sur l’édition 2025 du NIST AI 100-2, réalisé par extraction pypdf, est sans appel : aucune mention de l’AI Act ni d’une norme ISO/IEC, ISO/IEC 42001 comprise ; le mot « compliance » apparaît une fois, « regulation » deux fois. Ce silence est assumé par les auteurs. La section 4.2.5 indique que la taxonomie « deliberately leaves aside » une question clé : comment les organisations doivent décider du développement et de l’usage de leurs systèmes d’IA au vu de la diversité croissante des attaques, de l’efficacité et des limites des parades disponibles.

Sont également hors champ les attaques de cybersécurité classiques contre la plateforme qui héberge le modèle, les défauts de conception non antagonistes et toute recommandation de tolérance au risque. Ce périmètre resserré fait la précision du document ; il oblige aussi à chercher ailleurs ce qui manque. Pour l’infrastructure, d’autres cadres prennent le relais, comme le NIST CSF ; pour le système de management, la norme ISO/IEC 42001.

C’est précisément le vide que comble l’AI Act. L’article 9 exige un système de gestion des risques qui couvre le mésusage raisonnablement prévisible et conduit à un risque résiduel jugé acceptable (article 9, paragraphe 5). L’annexe IV, point 2 h), exige que la documentation technique décrive les mesures de cybersécurité mises en place. Le NIST fournit les mots ; le règlement exige la décision et sa trace écrite. Une équipe qui se contente de citer le NIST AI 100-2 dans sa documentation n’a donc fait que la moitié du chemin vers un dossier défendable.

NIST AI 100-2 et l’article 15, paragraphe 5, de l’AI Act : la correspondance

L’article 15, paragraphe 5, du règlement (UE) 2024/1689 impose que les systèmes d’IA à haut risque résistent aux tentatives de tiers non autorisés de modifier leur utilisation, leurs sorties ou leur performance en exploitant leurs vulnérabilités. Les solutions techniques traitant les vulnérabilités propres à l’IA comprennent, au besoin, des mesures pour prévenir, détecter, contrer, résoudre et maîtriser les attaques visant le jeu de données d’entraînement (empoisonnement des données), les composants pré-entraînés (empoisonnement de modèle), les entrées conçues pour faire commettre une erreur au modèle (exemples adverses ou évasion de modèle), ainsi que les attaques contre la confidentialité et les défauts du modèle. Restitution fidèle, non citation : le texte exact est sur EUR-Lex et sur la page de l’article 15.

Le tableau ci-dessous, notre propre travail, relie chaque terme aux classes du NIST AI 100-2, puis aux preuves qu’une autorité de surveillance du marché ou un organisme notifié peut demander.

Terme de l’article 15, paragraphe 5	Classes et identifiants NIST AI 100-2	Preuves à conserver au dossier
Empoisonnement des données	<code>NISTAML.013</code>, <code>NISTAML.012</code>, <code>NISTAML.024</code>, portes dérobées <code>NISTAML.021</code> et <code>NISTAML.023</code>	Provenance et assainissement des données d’entraînement, tests d’empoisonnement, lien avec l’article 10 (gouvernance des données)
Empoisonnement de modèle (composants pré-entraînés)	<code>NISTAML.011</code>, <code>NISTAML.026</code>, chaîne d’approvisionnement <code>NISTAML.051</code>	Nomenclature IA (AI BOM), provenance du modèle et contrôle des empreintes, attestations des fournisseurs
Exemples adverses ou évasion de modèle	<code>NISTAML.022</code>, <code>NISTAML.025</code>, plus l’injection de prompt <code>NISTAML.018</code> et <code>NISTAML.015</code> pour les systèmes génératifs (notre lecture)	Plan et résultats des tests antagonistes, métriques de résistance dans la section essais de l’annexe IV
Attaques contre la confidentialité	<code>NISTAML.031</code> à <code>NISTAML.039</code> (extraction, inférence d’appartenance et de propriétés, extraction de prompt et de données)	Tests d’attaques sur la vie privée, limitation de débit et filtrage des sorties, lien avec l’analyse d’impact RGPD
Défauts du modèle	Largement hors du NIST AI 100-2 (défauts non antagonistes exclus)	Essais d’exactitude et de résistance au titre de l’article 15, paragraphes 1 à 4
Boucles de rétroaction (article 15, paragraphe 4)	Empoisonnement par rétroaction, <code>NISTAML.013</code> et <code>NISTAML.024</code>	Surveillance de la dérive et des données d’entrée, plan de surveillance après commercialisation (article 72)

Calendrier : depuis l’omnibus numérique (règlement (UE) 2026/1744), l’article 15 s’applique aux systèmes d’IA à haut risque de l’annexe III à partir du 2 décembre 2027, et à ceux de l’annexe I à partir du 2 août 2028. Pour les modèles d’IA à usage général présentant un risque systémique, l’article 55, paragraphe 1, points a) (évaluation incluant des tests antagonistes documentés) et d) (protection adéquate en cybersécurité), s’applique depuis le 2 août 2025, et la Commission peut sanctionner ces fournisseurs depuis le 2 août 2026. Le chapitre Sûreté et sécurité du code de bonnes pratiques GPAI du 10 juillet 2025 rend opérationnels évaluations, tests antagonistes et mesures de sécurité.

Les normes européennes qui porteront l’article 15

<code>prEN 18282</code>. Projet de norme européenne sur la cybersécurité des systèmes d’IA, préparé par le groupe de travail 5 du CEN-CENELEC JTC 21 pour soutenir l’article 15. L’enquête publique s’est tenue du 15 mai à la mi-juillet 2026 ; la publication est visée entre fin 2026 et début 2027. Il ne conférera une présomption de conformité qu’une fois cité au Journal officiel. Le projet étant confidentiel, nous n’en citons que le nom et le statut.

ETSI EN 304 223. Publiée le 14 janvier 2026 (communiqué de l’ETSI), elle pose 13 principes répartis sur cinq phases : conception sécurisée, développement, déploiement, maintenance, fin de vie. Elle prolonge l’ETSI TS 104 223, et l’ETSI annonce un TR 104 159 consacré à l’IA générative.

<code>ISO/IEC 27090:2026</code>. Première édition parue en octobre 2026, 56 pages, de nature indicative et non certifiable (présentation par heise). Elle couvre l’empoisonnement, la manipulation des poids, l’évasion, l’extraction, l’inférence d’appartenance, l’inversion de modèle et l’injection de prompt.

La voie du Cyber Resilience Act. Selon l’article 12 du règlement (UE) 2024/2847, un système d’IA à haut risque qui est aussi un produit comportant des éléments numériques est réputé satisfaire aux exigences de cybersécurité de l’article 15 s’il respecte l’annexe I du CRA et si le niveau de protection figure dans la déclaration UE de conformité CRA ; l’exactitude et la résistance restent régies par l’AI Act. Depuis le 11 septembre 2026, les obligations de signalement du CRA s’appliquent : alerte précoce sous 24 heures, notification sous 72 heures, rapport final sous 14 jours après la mise à disposition d’une mesure corrective pour une vulnérabilité activement exploitée, via la plateforme unique de l’ENISA. Enfin, l’article 42, paragraphe 2, de l’AI Act présume conformes les systèmes certifiés selon un schéma adopté au titre du règlement (UE) 2019/881, ce qui pèse sur la stratégie d’évaluation de la conformité.

Pour une équipe française, l’ANSSI, autorité nationale de cybersécurité, reste la référence naturelle : elle a publié en 2024 des recommandations de sécurité pour les systèmes d’IA générative. Le catalogue de l’ENISA sur la sécurisation des algorithmes d’apprentissage (2021) complète utilement ses menaces et contrôles.

Notre lecture : tous ces textes énumèrent les mêmes classes d’attaques que le NIST AI 100-2. Un registre indexé sur les identifiants <code>NISTAML</code> se ré-étiquette pour chaque norme au lieu d’être reconstruit à chaque publication.

Faire du NIST AI 100-2 un dossier de preuves, en sept étapes

Inventorier et classer. Recensez chaque système d’IA et qualifiez-le de prédictif, génératif ou agentique, puis de haut risque, de modèle à usage général ou d’autre. Cette double qualification détermine les identifiants pertinents et les articles applicables.
Modéliser les menaces. Confrontez chaque système aux identifiants <code>NISTAML</code> en notant les capacités réalistes de l’attaquant : accès par requêtes seulement, API d’affinage, ingestion RAG, accès à des outils. Écartez explicitement les identifiants non pertinents, avec une justification.
Relier aux contrôles. Associez chaque identifiant retenu à des contrôles, en descendant au niveau des techniques avec MITRE ATLAS et l’OWASP. Un même contrôle peut couvrir plusieurs identifiants : notez-le pour éviter les doublons.
Tester. Menez des tests antagonistes et du red teaming avec les outils que cite le NIST AI 100-2, comme Garak ou PyRIT. Consignez la méthode, le périmètre, la version du modèle et les résultats.
Décider et signer. Pour chaque identifiant, jugez si le risque résiduel est acceptable et faites signer la décision par son responsable. C’est la décision que le NIST laisse de côté et que l’article 9, paragraphe 5, impose.
Rédiger. Écrivez la section cybersécurité de l’annexe IV, point 2 h), et la partie article 15 de la déclaration en citant les identifiants. Un évaluateur suit alors le fil de la menace jusqu’à la preuve.
Surveiller et signaler. Intégrez les identifiants au plan de surveillance après commercialisation (article 72) et au signalement des incidents graves (article 73), sans oublier l’alerte précoce CRA sous 24 heures pour les vulnérabilités activement exploitées. Révisez le registre chaque année, au rythme de mise à jour annoncé par le NIST.

Pour tenir ce registre, ses contrôles et ses preuves au même endroit, voyez notre logiciel de gestion des risques IA.

Questions fréquentes

Le NIST AI 100-2 est-il obligatoire en Europe ?

Non. C’est une publication volontaire d’une agence fédérale américaine, et le document précise lui-même qu’il ne crée aucune exigence légale. Aucun texte européen ne le rend obligatoire. Il reste très utile comme vocabulaire commun : les attaques qu’il décrit recouvrent celles que nomme l’article 15 de l’AI Act, et les normes européennes en préparation traitent les mêmes classes. L’utiliser pour structurer un registre des menaces ne dispense pas de démontrer la conformité au règlement, mais facilite le dialogue avec un auditeur ou une autorité.

Qu’est-ce qui a changé entre les éditions 2023 et 2025 du NIST AI 100-2 ?

L’édition 2025 introduit 30 codes <code>NISTAML</code> (5 catégories et 25 identifiants d’attaque), remplace « abuse » par « misuse », ajoute une section sur la chaîne d’approvisionnement de l’IA générative ainsi que de nouvelles sections sur la sécurité des agents et sur les bancs d’essai. Selon notre décompte, elle passe de 107 à 127 pages et de 354 à 449 références. Pour un registre construit sur l’édition 2023, l’effort principal consiste à rattacher chaque menace à son identifiant.

Le NIST AI 100-2 couvre-t-il les agents d’IA ?

Oui, avec prudence. L’édition 2025 ajoute une section sur la sécurité des agents tout en reconnaissant que la recherche dédiée n’en est qu’à ses débuts. Les identifiants existants s’appliquent : l’injection indirecte (<code>NISTAML.015</code>) et la compromission des ressources connectées (<code>NISTAML.039</code>) deviennent critiques dès qu’un agent appelle des outils. Le document cite AgentDojo pour mesurer ces attaques. Pour les contrôles propres aux agents, il faut compléter avec des sources plus opérationnelles.

Quel lien avec MITRE ATLAS et le Top 10 OWASP pour les applications LLM ?

Ils sont complémentaires. Le NIST AI 100-2 fournit la taxonomie et les définitions, MITRE ATLAS décrit les tactiques et techniques observées, et le Top 10 OWASP hiérarchise les risques applicatifs des LLM. En pratique, l’identifiant <code>NISTAML</code> sert de clé du registre, et les entrées ATLAS et OWASP précisent les techniques et les contrôles. Nos guides sur MITRE ATLAS et sur le Top 10 OWASP pour les LLM détaillent ces correspondances.

Suivre le NIST AI 100-2 suffit-il pour l’article 15 de l’AI Act ?

Non. Le NIST AI 100-2 nomme et décrit les attaques, mais ne dit ni quel risque résiduel accepter, ni comment documenter la décision. L’AI Act exige une gestion des risques (article 9), une description des mesures de cybersécurité dans la documentation technique (annexe IV, point 2 h), des essais d’exactitude et de résistance, puis une surveillance après commercialisation. La taxonomie structure l’analyse des menaces ; les normes harmonisées à venir et vos décisions signées complètent le dossier.

Pourquoi les pages du NIST parlent-elles désormais de « Super Intelligence » ?

Un décret présidentiel du 29 septembre 2026 impose aux agences fédérales américaines le terme « Super Intelligence » à la place d’« Artificial Intelligence » dans leurs communications officielles. Le NIST a donc renommé des pages et des projets, comme les overlays COSIS le 20 octobre 2026, en précisant que les documents déjà publiés n’ont pas été modifiés. L’identifiant <code>NIST AI 100-2e2025</code> reste valable et aucune obligation nouvelle ne pèse sur les entreprises privées. Dans vos registres, conservez l’identifiant d’origine.

Conclusion

Le NIST AI 100-2 est le meilleur dictionnaire disponible pour les attaques contre l’IA, et ses identifiants <code>NISTAML</code> en font, depuis 2025, une clé de registre exploitable. Il s’arrête pourtant volontairement là où commence le travail d’une équipe européenne : décider quel risque résiduel accepter, le prouver et le tenir à jour. L’AI Act, le CRA et les normes européennes arrivées en 2026 attendent précisément ces décisions documentées. La méthode la plus économique consiste à indexer menaces, contrôles, tests et preuves sur les identifiants du NIST, puis à les ré-étiqueter pour chaque référentiel. Commencez par vos systèmes à haut risque et par vos modèles génératifs exposés à des contenus externes : ce sont eux qui recevront les premières questions des autorités. Pour outiller ce registre, notre logiciel de gestion des risques IA peut vous y aider.

Mathieu Lefebvre