MITRE ATLAS : des techniques d’attaque de l’IA aux contrôles de conformité

L’essentiel

• MITRE ATLAS est une base de connaissances ouverte et vivante qui décrit comment les systèmes d’IA sont réellement attaqués : 16 tactiques et 84 techniques issues d’incidents avérés et de travaux de red team.
• Le cadre prolonge la logique de MITRE ATT&CK vers la surface d’attaque propre au machine learning : empoisonnement des données, évasion de modèle, injection de requête, autant de menaces que les référentiels de sécurité classiques ne nommaient pas.
• ATLAS, l’OWASP LLM Top 10 et le NIST AI RMF forment des couches complémentaires (menaces, vulnérabilités applicatives, gouvernance), et non des standards concurrents.
• Les classes d’attaque cataloguées par ATLAS sont précisément celles que le règlement européen sur l’IA impose de contrer pour les systèmes à haut risque, ce qui fait d’ATLAS une source de preuves de conformité.
• Le gain concret tient en une chaîne : relier chaque technique ATLAS à un contrôle et à une preuve d’audit dans votre dispositif de gouvernance de l’IA.

Qu’est-ce que MITRE ATLAS ?

MITRE ATLAS est l’acronyme d’Adversarial Threat Landscape for Artificial-Intelligence Systems. MITRE le présente comme une base de connaissances mondiale et vivante des tactiques et techniques adverses visant les systèmes fondés sur l’IA, construite à partir d’observations d’attaques réelles et de démonstrations menées par des équipes de red team spécialisées. Autrement dit, c’est une cartographie structurée de la manière dont on attaque l’IA, nourrie par des incidents qui ont eu lieu plutôt que par des craintes théoriques. Dans sa version 5.4.0 (février 2026), la matrice ATLAS compte 16 tactiques, 84 techniques, 56 sous-techniques, 32 mesures d’atténuation et 42 études de cas documentées. Ces cas sont tangibles : contournement de vérification d’identité par hypertrucage (deepfake), évasion de modèle de machine learning, agents d’IA dotés de portes dérobées, ou détournement de transactions financières via des assistants d’IA. Si ce référentiel existe, c’est parce que l’IA ajoute une surface d’attaque que les modèles de sécurité traditionnels n’ont jamais été conçus pour décrire. Un modèle peut être corrompu pendant l’entraînement, trompé au moment de l’inférence, ou interrogé jusqu’à ce qu’il divulgue les données dont il a appris. ATLAS donne aux équipes de sécurité et de gouvernance un vocabulaire commun pour ces modes de défaillance : une découverte de red team, un responsable de contrôle et un auditeur peuvent désigner la même technique et parler de la même chose. Pour une organisation régulée, ce langage partagé est le premier pas vers une sécurité de l’IA traitée comme une discipline de gouvernance, et non comme un projet ponctuel. C’est aussi la raison pour laquelle AI Sigil place ATLAS comme couche de référence sous son modèle de risques et de contrôles.

MITRE ATLAS face à MITRE ATT&CK

Qui a déjà travaillé en centre opérationnel de sécurité retrouvera ses repères dans ATLAS, et ce n’est pas un hasard. Le cadre s’inspire directement de la méthode MITRE ATT&CK : la même articulation entre tactiques (l’objectif de l’attaquant à chaque étape) et techniques (la façon dont il l’atteint), présentée sous forme de matrice que l’on lit de gauche à droite, au fil du cycle d’attaque. La différence tient à la cible. ATT&CK décrit les attaques contre l’informatique classique : postes de travail, réseaux, identités. ATLAS décrit les attaques contre l’IA elle-même : le modèle, ses données d’entraînement, sa chaîne d’inférence et les agents bâtis par-dessus. Plusieurs tactiques sont communes aux deux (reconnaissance, accès initial, exfiltration, impact), car un attaquant continue d’hameçonner, de se déplacer latéralement, de voler des identifiants. Ce qu’ajoute ATLAS, c’est le cœur propre à l’IA : obtenir l’accès à un modèle, empoisonner ses données, fabriquer des entrées qui le trompent, ou l’extraire dans son intégralité. Pour une équipe de gouvernance, la conclusion n’est pas de choisir entre les deux. ATT&CK couvre l’infrastructure autour du modèle ; ATLAS couvre le modèle. Une attaque sérieuse contre l’IA emprunte généralement les deux chemins.

Dans la matrice MITRE ATLAS : les 16 tactiques

La matrice se lit comme un cycle de vie. L’adversaire débute par la reconnaissance (il étudie votre modèle, son API, sa documentation publique), passe par le développement de ressources et l’accès initial, puis atteint les étapes spécifiques à l’IA : accès au modèle, préparation de l’attaque, exécution, persistance, exfiltration et impact. Chaque tactique regroupe des techniques qui décrivent un geste précis. Quatre familles de techniques comptent particulièrement pour la gouvernance, car elles recoupent des risques nommés par la réglementation :

• Empoisonnement des données. Manipuler les données d’entraînement pour que le modèle apprenne la mauvaise chose, qu’il s’agisse d’une porte dérobée dissimulée ou d’une dégradation générale de l’exactitude.
• Évasion de modèle (exemples contradictoires). Concevoir des entrées destinées à faire commettre une erreur à un modèle en production, par exemple une image subtilement altérée ou une requête de contournement qui déjoue un filtre de sécurité.
• Extraction et inversion de modèle. Interroger un modèle jusqu’à pouvoir le reconstituer ou récupérer les données confidentielles sur lesquelles il a été entraîné : une atteinte à la confidentialité.
• Injection de requête et contournements. Détourner un modèle de langage ou un agent d’IA au moyen d’instructions piégées dissimulées dans le contenu qu’il traite.

Ces familles s’alignent nettement sur la taxonomie officielle des États-Unis. Le NIST AI 100-2 E2025, taxonomie fédérale de l’apprentissage automatique adverse, classe les attaques contre l’IA prédictive en évasion, empoisonnement et atteintes à la vie privée, et les attaques contre l’IA générative en injection de requête, contournements et compromission de la chaîne d’approvisionnement. ATLAS fournit les techniques éprouvées sur le terrain ; le NIST fournit la terminologie formelle. Les employer ensemble donne le quoi et le comment.

ATLAS, l’OWASP LLM Top 10 et le NIST AI RMF

Une question revient sans cesse : comment ATLAS se situe-t-il par rapport aux autres référentiels de sécurité et de gouvernance de l’IA ? La réponse tient en une phrase : ils opèrent à des altitudes différentes et ont été pensés pour fonctionner ensemble.

• MITRE ATLAS est un modèle d’adversaire. Il répond à la question « comment attaquerait-on ce système ? » et sert à la modélisation des menaces, au red teaming et à l’ingénierie de détection.
• L’OWASP LLM Top 10 est un modèle de vulnérabilités. Il répond à « qu’est-ce qui cloche habituellement dans une application LLM ? » (injection de requête, traitement non sécurisé des sorties, empoisonnement des données d’entraînement) et sert au développement sécurisé et à la revue de code.
• Le NIST AI RMF est un modèle de gouvernance. Ses quatre fonctions (Gouverner, Cartographier, Mesurer, Gérer) répondent à « comment notre organisation supervise-t-elle le risque IA ? » et s’adressent aux responsables des risques et de la conformité.

Ce sont des couches, non des alternatives : la menace (ATLAS), la faiblesse qu’elle exploite (OWASP), et la supervision qui décide quoi en faire (NIST). L’intérêt pratique est budgétaire. Selon l’analyse de la matrice publiée par Vectra, près de 70 % des mesures d’atténuation d’ATLAS correspondent à des contrôles de sécurité déjà en place. Vous partez rarement de zéro : vous reliez une menace IA à un contrôle que vous possédez déjà, puis vous prouvez le lien. Les ressources de gouvernance d’AI Sigil abordent ces trois référentiels comme une pile cohérente plutôt que comme des listes rivales.

Pourquoi MITRE ATLAS compte pour la conformité, pas seulement pour la sécurité

Voici le point que la plupart des présentations d’ATLAS passent sous silence. On le présente d’ordinaire comme un outil pour le centre opérationnel de sécurité. Pour une organisation régulée, c’est aussi un instrument de conformité, car les attaques qu’il catalogue sont celles que la loi nomme désormais. L’article 15 du règlement européen sur l’IA exige que les systèmes d’IA à haut risque atteignent « un niveau approprié d’exactitude, de robustesse et de cybersécurité ». Il va plus loin au paragraphe 5 : ces systèmes « sont résilients face aux tentatives de tiers non autorisés de modifier leur utilisation, leurs sorties ou leurs performances en exploitant les vulnérabilités du système ». Le même paragraphe nomme ensuite les menaces par catégorie. Les solutions techniques doivent, au besoin, traiter les « attaques visant à manipuler le jeu de données d’entraînement (empoisonnement des données), ou les composants préentraînés utilisés lors de l’entraînement (empoisonnement de modèle), les entrées conçues pour amener le modèle d’IA à commettre une erreur (exemples contradictoires ou évasion de modèle), les attaques portant atteinte à la confidentialité ou les défauts du modèle ». Relisez cette liste à la lumière des familles de techniques ATLAS ci-dessus : ce sont les mêmes menaces. Le règlement énonce l’obligation ; ATLAS fournit le catalogue opérationnel qui permet de démontrer comment vous y répondez. Quand un évaluateur demande comment vous traitez les exemples contradictoires ou l’empoisonnement des données, « nous avons relié les techniques ATLAS pertinentes à des contrôles, puis nous les avons testés » pèse bien plus lourd qu’une déclaration de principe. La même logique vaut en amont : le code de bonnes pratiques pour les modèles d’IA à usage général attend un test contradictoire pour les modèles présentant un risque systémique, et ATLAS est une source naturelle de cas de test. En France, cette exigence prolonge des réflexes que la CNIL et l’ANSSI promeuvent déjà sur la robustesse et la sécurité des systèmes. C’est ce recadrage qui fait la différence. ATLAS n’est pas seulement un moyen de détecter les attaques : c’est un moyen de prouver que vous les aviez anticipées.

Faire vivre ATLAS dans un dispositif de gouvernance de l’IA

Faire passer ATLAS de l’affiche de référence à un rouage opérationnel de la gouvernance se résume à une chaîne : menace, contrôle, preuve. Menace. Pour chaque système d’IA de votre inventaire, sélectionnez les techniques ATLAS réellement applicables. Un assistant LLM exposé au public affronte l’injection de requête et les contournements ; un modèle antifraude entraîné sur des données de tiers affronte l’empoisonnement ; un modèle accessible via une API affronte l’extraction. Vous n’avez pas besoin des 84 techniques, seulement de celles que votre architecture appelle. Contrôle. Reliez chaque technique retenue à un contrôle de système. Comme la plupart des mesures d’ATLAS recoupent des contrôles de sécurité existants, il s’agit le plus souvent de rattacher une menace IA à la gestion des accès, à la validation des entrées, à la supervision, aux vérifications de la chaîne d’approvisionnement ou aux tests de red team que vous pouvez déjà présenter. Là où subsiste un véritable écart, vous venez d’identifier un contrôle à construire. Preuve. Joignez la démonstration que le contrôle fonctionne : un rapport de red team contre la technique, le résultat d’un test de détection d’empoisonnement, un journal d’accès, une validation signée. C’est ce qui transforme un contrôle déclaré en artefact d’audit. Cette chaîne est exactement ce que demandent les fonctions Mesurer et Gérer du NIST AI RMF, et elle s’accorde avec les contrôles de l’annexe A de la norme ISO 42001, le standard certifiable de système de management de l’IA. Elle clarifie aussi les responsabilités : au titre du règlement IA, le fournisseur répond de la robustesse intégrée au modèle, tandis que le déployeur répond des conditions d’usage ; une même technique ATLAS peut donc engendrer des obligations pour les deux parties. Une plateforme comme AI Sigil sert précisément à conserver cette cartographie (menaces, contrôles, preuves et obligations) en un seul endroit, afin que la chaîne reste auditable au lieu d’être reconstruite de mémoire le jour de l’évaluation.

Comment démarrer avec MITRE ATLAS

Inutile d’un programme considérable pour commencer. Une première passe ressemble à ceci :

1. Inventoriez vos systèmes d’IA et notez, pour chacun, le type de modèle, les sources de données et le mode d’exposition.
2. Pour chaque système, présélectionnez les techniques ATLAS plausibles compte tenu de cette architecture.
3. Évaluez votre couverture de contrôle actuelle face à cette présélection et consignez vos points forts et vos points exposés.
4. Priorisez les écarts par impact, en commençant par les systèmes à haut risque au sens du règlement IA ou critiques pour l’activité.
5. Documentez les preuves des contrôles qui fonctionnent déjà, pour ne rien perdre avant le prochain audit.
6. Réexaminez chaque trimestre, car ATLAS est un cadre vivant et votre parc de modèles évolue.

Pour les équipes régulées, ajoutez une colonne à cet exercice : l’obligation que chaque technique aide à satisfaire. Ce simple lien, de la technique ATLAS au devoir réglementaire, est ce qui transforme une liste de sécurité en gouvernance.

Questions fréquentes

Qu’est-ce que MITRE ATLAS ? MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) est une base de connaissances ouverte et vivante des tactiques et techniques employées par les attaquants contre les systèmes d’IA, fondée sur des observations réelles et des démonstrations de red team. La matrice actuelle compte 16 tactiques et 84 techniques, organisées à la manière de MITRE ATT&CK mais centrées sur le machine learning. Quelle différence entre MITRE ATLAS et MITRE ATT&CK ? ATT&CK décrit les attaques contre l’informatique classique (postes, réseaux, identités). ATLAS décrit les attaques contre les systèmes d’IA eux-mêmes : le modèle, ses données d’entraînement et sa chaîne d’inférence. ATLAS réutilise la structure d’ATT&CK et partage certaines tactiques, mais ajoute des techniques propres à l’IA comme l’empoisonnement des données, l’évasion de modèle et l’extraction de modèle. Quelle différence entre MITRE ATLAS et l’OWASP LLM Top 10 ? Ils répondent à des problèmes distincts. ATLAS est un modèle d’adversaire utilisé pour la modélisation des menaces et le red teaming. L’OWASP LLM Top 10 est une liste des vulnérabilités les plus fréquentes des applications LLM, utilisée pour le développement sécurisé. ATLAS dit comment vous pourriez être attaqué ; l’OWASP dit où se trouvent habituellement les faiblesses. Les deux sont complémentaires. Combien de tactiques compte MITRE ATLAS ? Dans sa version 5.4.0 (février 2026), la matrice ATLAS compte 16 tactiques, ainsi que 84 techniques, 56 sous-techniques, 32 mesures d’atténuation et 42 études de cas. Les références citant 14 tactiques sont antérieures aux mises à jour récentes : vérifiez toujours la matrice à jour sur atlas.mitre.org. MITRE ATLAS est-il exigé par le règlement européen sur l’IA ? Le règlement ne nomme pas ATLAS, qui n’est donc pas obligatoire. En revanche, l’article 15 impose aux systèmes à haut risque d’être résilients face à l’empoisonnement des données, à l’empoisonnement de modèle, aux exemples contradictoires et aux atteintes à la confidentialité, soit exactement les menaces qu’ATLAS catalogue. ATLAS est un moyen pratique d’organiser et de prouver les solutions techniques attendues. Quel est le lien entre MITRE ATLAS et le NIST AI RMF ? Ils agissent à des niveaux différents. ATLAS est un catalogue de menaces ; le NIST AI RMF est un cadre de gouvernance articulé autour de Gouverner, Cartographier, Mesurer et Gérer. En pratique, ATLAS alimente les fonctions Mesurer et Gérer : il fournit les menaces concrètes que vous évaluez et traitez, tandis que le RMF fournit la structure de supervision autour d’elles.

Conclusion

La plupart des équipes découvrent MITRE ATLAS comme un artefact de sécurité, une matrice d’attaques que la red team étudie. La vue est juste, mais incomplète. Pour toute organisation qui exploite de l’IA sous contrainte réglementaire, ATLAS est le pont entre deux mondes qui s’ignorent souvent : l’équipe de sécurité qui sait comment l’IA est attaquée, et l’équipe de conformité qui doit prouver que le système est robuste. Ses techniques sont les menaces nommées par le règlement IA rendues concrètes, et les relier à des contrôles et à des preuves est précisément ce qu’un audit cherche à voir. Commencez petit, avec un système et ses techniques plausibles, puis étendez la cartographie. Pour que cette cartographie vive en un seul endroit auditable, découvrez comment AI Sigil relie menaces, contrôles et obligations de l’IA.