MITRE ATLAS : le langage commun pour cartographier les attaques sur vos IA

Tant que votre RSSI, votre DSI et vos métiers nomment différemment les menaces qui pèsent sur vos IA, vous ne savez pas ce que vous couvrez ni ce que vous laissez ouvert : la taxonomie MITRE ATLAS vous donne le langage commun qui transforme des inquiétudes éparses en une carte partagée des attaques. Dans cet article, je vous montre comment utiliser ATLAS pas à pas pour bâtir un threat model d'IA que tout le monde comprend, et relier chaque scénario d'attaque à un contrôle que l'on peut vérifier.

Le problème : chacun décrit la menace dans sa propre langue

Le scénario que je vois revenir : le RSSI parle d'exfiltration de données, le métier craint que l'assistant raconte n'importe quoi à un client, la DSI s'inquiète d'un fournisseur de modèle mal maîtrisé. Trois inquiétudes légitimes, trois vocabulaires qui ne se recoupent pas. Résultat : personne ne sait si une menace citée par l'un est déjà couverte par un contrôle posé par l'autre, ni où sont les vrais trous.

Sans référentiel commun, un threat model d'IA devient une liste d'impressions qui dépend de la sensibilité de celui qui la rédige. Deux équipes qui regardent le même système produisent deux cartes différentes, et aucune n'est vérifiable. C'est exactement le flou qu'un attaquant exploite.

MITRE ATLAS, c'est quoi exactement ?

MITRE ATLAS est une base de connaissances des attaques réelles contre les systèmes d'IA, construite sur le même modèle que le référentiel ATT&CK bien connu des équipes cyber. Elle décrit les tactiques d'un attaquant, c'est à dire ses objectifs successifs (reconnaître le système, y accéder, l'empoisonner, exfiltrer), et pour chaque tactique les techniques concrètes déjà observées, comme l'empoisonnement d'une base RAG ou la porte dérobée glissée dans un agent.

Son intérêt n'est pas d'être exhaustif, mais d'offrir un vocabulaire partagé. Quand le RSSI, la DSI et le métier désignent une menace par le même nom de tactique, ils parlent enfin du même objet, et l'on peut vérifier, tactique par tactique, ce qui est couvert.

Ce langage prolonge celui que vous connaissez peut-être déjà côté risques applicatifs. Si les familles de risque des modèles de langage ne vous sont pas familières, commencez par le panorama que je détaille dans OWASP LLM Top 10: là où l'OWASP nomme les risques, ATLAS nomme les enchaînements d'attaque qui les exploitent.

Étape 1 : adopter le langage commun des tactiques

La première étape ne coûte presque rien et débloque tout le reste : réunir vos équipes autour du même vocabulaire. Vous parcourez les grandes tactiques d'ATLAS et vous les traduisez en une phrase que le métier comprend. L'objectif n'est pas de mémoriser la taxonomie, mais que chacun sache reconnaître de quelle tactique relève une menace qu'il évoque.

À la fin de cette étape, vous n'avez pas encore de contrôle, mais vous avez quelque chose de plus précieux : tout le monde nomme la même menace de la même façon.

Étape 2 : cartographier vos surfaces et vos scénarios

Le langage en main, vous l'appliquez à votresystème. Vous listez vos surfaces exposées, les entrées utilisateur, les données que le modèle peut atteindre, les outils qu'il peut déclencher, les modèles tiers dont vous dépendez, puis vous confrontez chacune aux tactiques d'ATLAS. Pour chaque croisement, une question simple : un attaquant pourrait-il jouer cette tactique ici, et comment ?

Vous obtenez une liste de scénarios d'attaque plausibles, chacun rattaché à une tactique nommée. Un scénario exploitable ressemble à « via la base documentaire, un attaquant empoisonne le contexte et fausse les réponses », pas à « le RAG est peut-être vulnérable ». C'est cette précision qui rend la suite vérifiable.

Cette cartographie ne remplace pas l'attaque réelle, elle la prépare. Une fois les scénarios prioritaires identifiés, vous les éprouvez pour de vrai, comme je le décris dans le red teaming d'un LLM. ATLAS vous dit quoi tester en priorité et pourquoi.

Étape 3 : relier chaque scénario à un contrôle vérifiable

Un scénario d'attaque sans contrôle en face n'est qu'une inquiétude documentée. La troisième étape est celle qui protège vraiment : à chaque scénario, vous associez un contrôle précis, et vous le formulez de façon vérifiable, c'est à dire que l'on peut le rejouer pour prouver qu'il tient.

La tactique d'empoisonnement mérite une attention particulière, car elle est silencieuse et durable. Je la détaille, avec ses contrôles de provenance et d'intégrité, dans l'empoisonnement des données et du modèle.

La bonne question n'est jamais « sommes-nous protégés ? » mais « pour cette tactique nommée, quel contrôle avons-nous, et pouvons-nous le rejouer ? ». La première n'a pas de réponse utile, la seconde se vérifie.

Étape 4 : partager le threat model et le faire vivre

Un threat model figé dans un document devient faux au premier changement de votre système. La dernière étape en fait un objet vivant, partagé et daté par version. Chaque nouveau modèle, chaque nouvelle donnée branchée, chaque outil rendu accessible rouvre potentiellement une tactique : vous rejouez alors la cartographie sur la partie concernée, et vous vérifiez que les contrôles associés tiennent toujours.

Parce qu'il repose sur un vocabulaire commun, ce threat model se relit en réunion sans traducteur. Le RSSI voit ses contrôles, la DSI voit ses surfaces, le métier voit les conséquences, et tous regardent la même carte. C'est ce partage qui transforme un exercice technique en décision d'entreprise.

Questions fréquentes

Faut-il être expert en cybersécurité pour utiliser MITRE ATLAS ?

Non. La force d'ATLAS est justement de donner un langage que le métier et la direction peuvent comprendre. Le travail technique de mapping peut être délégué, mais le rôle du dirigeant, du DPO ou du RSSI est de s'assurer que chaque tactique retenue débouche sur un contrôle vérifiable. C'est ce cadrage qui fait la valeur de la démarche.

En quoi ATLAS diffère-t-il de l'OWASP LLM Top 10 ?

Les deux sont complémentaires. L'OWASP LLM Top 10 est une liste des risques propres aux modèles de langage, utile comme checklist. ATLAS décrit les tactiques et enchaînements d'un attaquant sur un système d'IA complet, utile pour construire des scénarios réalistes. On commence souvent par l'OWASP pour nommer les risques, puis on passe à ATLAS pour les mettre en scène.

Cette cartographie remplace-t-elle un test de sécurité ?

Non, elle le prépare et le priorise. Le threat model dit où regarder et pourquoi ; le test offensif éprouve réellement si le système cède. Une cartographie sans test reste une hypothèse, et un test sans cartographie laisse forcément des angles morts. Les deux se nourrissent l'un l'autre.

À quelle fréquence faut-il mettre à jour le threat model ?

À chaque évolution qui change la surface d'attaque : nouveau modèle, nouvelles données branchées, nouvel outil accessible à un agent. Un threat model valable à un instant ne dit rien de la robustesse d'un système modifié depuis. C'est pour cela que la dernière étape en fait un objet vivant, et non un livrable qu'on archive.

C'est précisément l'objet de mon audit Sécurité & Conformité IA : je bâtis avec vos équipes ce threat model fondé sur ATLAS, puis je relie chaque scénario à un contrôle vérifiable. Pour situer votre usage le plus exposé, un premier échange suffit à identifier par où commencer.

Cet article a une visée pédagogique et ne constitue pas un conseil juridique. Chaque situation mérite une analyse au cas par cas.