Sécurité IA : OWASP, MITRE et NIST, et dans quel ordre les utiliser
Trois grands frameworks de sécurité IA semblent rivaux. Ils ne le sont pas : chacun répond à une question différente, l'enjeu c'est par lequel commencer.
Toute entreprise qui construit quelque chose avec de l’IA aujourd’hui se cogne au même mur : un marché saturé de référentiels de sécurité qui ont l’air de faire tous la même chose. OWASP, MITRE, NIST. Trois noms respectés, trois ensembles de recommandations pour garder l’intelligence artificielle sous contrôle, et l’envie bien naturelle d’en choisir un puis de passer à autre chose. Cette envie, c’est le piège. Ces trois-là n’ont jamais été conçus pour se concurrencer, et vouloir trancher entre eux, c’est se tromper de question. Chacun répond à un besoin différent, et la seule décision qui compte vraiment, c’est l’ordre dans lequel on s’en sert.
Tous les trois s’occupent du même type de logiciel : les large language models, ou LLM, ces moteurs qui génèrent du texte derrière les chatbots et les assistants IA, ainsi que les applications bâties par-dessus. Passé ce sujet commun, ils n’ont plus rien à voir.
Trois questions différentes
La façon la plus nette de les distinguer, c’est de regarder à quelle question chacun répond.
OWASP répond à : qu’est-ce qui peut mal tourner dans mon application IA, et comment je le corrige. C’est une liste de contrôle pour les gens qui écrivent le code. MITRE ATLAS répond à : comment un vrai attaquant s’y prendrait-il concrètement pour pénétrer un système IA. C’est un catalogue des manœuvres d’attaque. NIST répond à : comment mon organisation garde-t-elle le risque IA sous contrôle sur la durée. C’est un manuel de pilotage pour ceux qui dirigent.
Une liste de contrôle, un mode d’emploi d’attaquant et un cadre de gouvernance ne sont pas trois versions de la même chose, pas plus qu’un correcteur orthographique ne remplace un exercice d’évacuation incendie. Ils se situent à des hauteurs différentes au-dessus du même système.
Il existe bien une poignée de problèmes sur lesquels ils se recoupent, et c’est précisément ce qui nourrit le réflexe « il suffit d’en prendre un ». Trois reviennent sans cesse. L’injection de prompt (prompt injection), c’est l’astuce qui consiste à glisser de nouvelles instructions dans le texte que l’IA lit, pour qu’elle ignore en douce ses propres règles. L’empoisonnement des données (data poisoning), c’est introduire de mauvais exemples dans les données dont un modèle apprend, pour qu’il en tire la mauvaise leçon. Le risque lié à la chaîne d’approvisionnement (supply chain) couvre les modèles, bibliothèques et jeux de données extérieurs qu’une équipe réutilise au lieu de les construire elle-même. Tout référentiel sérieux aborde ces trois sujets, parce que personne ne peut défendre une IA en les ignorant, mais chacun les traite à un niveau différent.
OWASP : la liste de contrôle du développeur
Le OWASP Top 10 for LLM Applications est exactement ce que son nom annonce : les dix façons les plus courantes dont une application IA déraille, chacune assortie d’un correctif qu’un ingénieur peut appliquer tout de suite. L’édition actuelle porte l’étiquette 2025 et a été publiée fin 2024 par l’OWASP GenAI Security Project, une communauté bénévole de professionnels de la sécurité. L’injection de prompt trône en tête de liste, parce qu’elle reste le moyen le plus fiable de faire dérailler une IA.
Le reste de la liste se lit comme le carnet d’inquiétudes d’un développeur. Deux des entrées les plus récentes montrent où les vrais systèmes lâchent. La première, c’est la fuite des instructions cachées d’une application, ce prompt système privé qui dicte à l’assistant comment se comporter. La seconde vise la base documentaire que beaucoup d’outils IA consultent avant de répondre : empoisonnez ces documents, et vous empoisonnez la réponse sans jamais toucher au modèle lui-même.
L’idée la plus utile de la liste, pour qui n’est pas ingénieur, est ce qu’OWASP appelle l’excessive agency, l’autonomie excessive. Elle met en garde contre le fait de donner à un assistant IA plus de pouvoir qu’il n’en a besoin : l’accès à vos fichiers, à votre base de données, la capacité d’envoyer des messages ou de lancer des commandes. Plus un assistant peut faire de choses, plus une seule manipulation réussie cause de dégâts. Réduisez ses pouvoirs au strict nécessaire, et vous rétrécissez la zone d’impact d’un incident. C’est la même logique du moindre privilège qui sous-tend l’architecture zero trust, appliquée à un outil qui improvise.
Steve Wilson, fondateur du projet et coprésident du GenAI Security Project, décrit la liste comme une ressource de terrain censée suivre le rythme des incidents réels, pas un tampon de conformité à agiter devant des auditeurs. C’est aussi sa limite. OWASP vous dit quoi corriger et grosso modo comment, mais pas comment une attaque complète enchaîne ces faiblesses entre elles, ni si votre direction devrait accepter le risque qui subsiste.
Le OWASP Top 10 for LLM Applications, la liste de contrôle des façons dont une application IA peut casser.
MITRE ATLAS : le mode d’emploi de l’attaquant
MITRE ATLAS est la version IA d’un catalogue bien plus ancien et bien plus connu, MITRE ATT&CK, que les équipes de sécurité utilisent pour étudier comment les intrus se déplacent dans des réseaux informatiques ordinaires. ATLAS fait la même chose pour l’IA : il déroule les étapes qu’un attaquant suit contre un système IA, du premier sondage jusqu’au vol ou à la corruption des données, le tout ancré dans des cas réels. Là où OWASP énumère ce qui peut mal tourner, ATLAS montre comment une attaque se déroule vraiment, étape par étape, dans le langage de l’attaquant.
Le catalogue ne cesse de s’étoffer à mesure que de nouvelles attaques apparaissent, et les ajouts récents portent sur les agents IA autonomes, ces assistants qui agissent par eux-mêmes en enchaînant plusieurs outils. Le décompte exact est une cible mouvante, et c’est précisément l’idée : ATLAS est un document vivant, pas une liste figée.
Sa valeur tient dans la mise à l’épreuve d’une défense. Une équipe de sécurité peut suivre le chemin de l’attaquant pas à pas et se demander, à chaque manœuvre : est-ce qu’on s’en apercevrait seulement. Prenez l’empoisonnement des données : les signaux d’alerte se logent dans la surveillance de la chaîne de traitement des données, pas dans les alarmes réseau qu’une entreprise fait déjà tourner. ATLAS fait remonter exactement ce genre d’angle mort. Il part du principe que le système existe déjà et qu’il est attaqué, et il tend au défenseur le vocabulaire de l’attaquant.
Deux confusions plombent la plupart des discussions sur ATLAS. La première, c’est de le mélanger avec ATT&CK : ATT&CK couvre l’informatique ordinaire, ATLAS en est l’extension IA, bâtie sur la même structure. La seconde, c’est de prendre ATLAS pour un outil de gouvernance. Il ne porte aucun processus d’acceptation du risque ni aucune règle pour piloter un programme, seulement des manœuvres d’attaquant et les cas qui les attestent.
MITRE ATLAS, le catalogue des manœuvres réelles d’attaquants contre les systèmes IA.
NIST : le manuel de pilotage
NIST AI RMF, formellement numéroté AI 100-1, est un cadre volontaire publié par l’agence de normalisation américaine en 2023 pour gérer le risque IA tout au long de la vie d’un système. Il opère au niveau de l’organisation, pas du code, et il ne nomme jamais le moindre bug ni la moindre attaque. Il repose plutôt sur quatre tâches : govern (définir qui est responsable et quelle est la culture), map (cerner le contexte et les risques), measure (les suivre) et manage (agir dessus). En dessous, il se ramifie en des dizaines de pratiques plus précises.
Il existe un document compagnon qu’il vaut la peine de connaître, parce que les comparaisons confondent souvent les deux. Le Generative AI Profile, numéroté AI 600-1 et publié en 2024, applique le même cadre spécifiquement à l’IA générative et y ajoute une douzaine de risques qui lui sont propres. Le profil prolonge le cadre principal, il ne le remplace pas : une équipe qui travaille avec de l’IA générative utilise les deux, avec AI 100-1 comme colonne vertébrale.
Le public visé ici, c’est la direction, le risque et la conformité, pas l’ingénieur en plein développement. NIST donne à une organisation une structure défendable et un vocabulaire commun que les auditeurs et les régulateurs attendent de plus en plus. Diana Kelley, dirigeante de longue date dans la sécurité et ancienne responsable cybersécurité chez Microsoft, soutient que les organisations qui réduisent réellement le risque IA sont celles qui adoptent ces cadres ensemble plutôt qu’isolément, parce qu’une liste de contrôle sans gouvernance dérive, et qu’une gouvernance sans liste de contrôle n’a rien de concret à gouverner. Ce que NIST ne vous donne pas, c’est une liste de bugs à corriger ou une carte de la façon dont un attaquant opère.
Le NIST AI Risk Management Framework, qui gouverne le programme via govern, map, measure et manage.
Côte à côte
| OWASP | MITRE ATLAS | NIST AI RMF | |
|---|---|---|---|
| Répond à | Quoi corriger | Comment l’attaque se déroule | Comment gouverner le risque |
| Écrit pour | Les ingénieurs qui construisent l’app | Les équipes qui la défendent | La direction et la conformité |
| Se lit comme | Une liste de contrôle | Un mode d’emploi d’attaquant | Un cadre de gouvernance |
| Bon moment | Pendant la construction | Une fois le système en service | À mesure que le programme grandit |
| Ne pas confondre avec | Le Top 10 web classique | MITRE ATT&CK | L’ancien cadre cyber du NIST |
L’ordre qui fonctionne vraiment
Comme chacun reprend là où le précédent s’arrête, ils s’empilent dans une séquence naturelle. Construisez d’abord proprement avec OWASP : parcourez la liste de contrôle, réduisez ce à quoi votre assistant IA peut toucher, nettoyez les données dont il se nourrit. Vous obtenez un système qui résiste aux faiblesses connues.
Ce système devient alors ce qu’ATLAS vous aide à défendre. Le même risque d’injection de prompt qu’OWASP vous a dit de corriger réapparaît dans ATLAS sous la forme d’une manœuvre d’attaquant, et vos défenseurs peuvent se demander s’ils la repéreraient vraiment en train de se produire. Les deux lisent le même risque par les deux bouts, celui du constructeur et celui de l’attaquant.
NIST enveloppe les deux. La gouvernance décide quelles fonctionnalités IA sortent tout court, fixe la politique qui impose la revue OWASP, et définit la dose de risque acceptable, ce qui indique en retour aux défenseurs sur quelles attaques d’ATLAS il vaut la peine d’investir. Le fil de la chaîne d’approvisionnement traverse les trois, et se comporte beaucoup comme le risque de propagation qu’on a vu dans les attaques sur la chaîne d’approvisionnement logicielle, où une seule dépendance empoisonnée porte bien au-delà de son point d’entrée.
Rien de tout cela n’oblige à adopter les trois à fond dès le premier jour. Une petite équipe peut vivre longtemps à l’intérieur de la liste de contrôle OWASP avant que le reste ne justifie son coût. Les cadres s’emboîtent au lieu de se concurrencer, si bien qu’adopter le suivant ne défait jamais le travail accompli sous le précédent. Inversez l’ordre, commencez par la gouvernance sans rien construire en dessous, et vous obtenez une politique qui ne protège rien. Construire d’abord, défendre ensuite, gouverner autour des deux.
Questions fréquentes
Faut-il choisir OWASP ou MITRE ATLAS pour la sécurité IA ?
Les deux, pour des rôles différents. OWASP est la liste de contrôle que vos ingénieurs parcourent pendant la construction, couvrant les faiblesses courantes comme l’injection de prompt avec des correctifs applicables sur le moment. MITRE ATLAS, c’est ce que vos défenseurs utilisent une fois le système en service, pour cartographier les vraies manœuvres d’attaquants face à ce qu’ils savent réellement détecter. Si vous êtes en train de construire et qu’il faut bien commencer quelque part, commencez par OWASP, parce qu’il se branche directement sur le code. Ajoutez ATLAS quand vous avez un système en marche qui vaut la peine d’être défendu.
Le framework IA du NIST est-il le même que l’ancien cadre cybersécurité du NIST ?
Non. Le NIST AI Risk Management Framework est un document distinct et plus récent, centré sur le risque propre à l’IA, organisé autour de quatre tâches : govern, map, measure et manage. Le célèbre NIST Cybersecurity Framework couvre la sécurité informatique en général et précède celui dédié à l’IA. Ils partagent un auteur et une forme voisine, mais ils traitent de terrains différents, et toute comparaison qui les présente comme interchangeables est tout aussi peu fiable sur le reste.
Quelle est la différence entre NIST AI 100-1 et AI 600-1 ?
AI 100-1 est le cadre principal, la colonne vertébrale de gouvernance à quatre tâches. AI 600-1 est le Generative AI Profile, un document compagnon publié en 2024 qui applique le même cadre à l’IA générative et y ajoute une douzaine de risques spécifiques. Le profil prolonge le cadre principal plutôt qu’il ne le remplace. Si vous travaillez avec de l’IA générative, vous utilisez les deux, avec AI 100-1 comme épine dorsale et AI 600-1 comme couche spécifique au génératif posée par-dessus.
Quelle est la taille de MITRE ATLAS ?
Il compte environ une quinzaine d’objectifs d’attaquants et des dizaines de techniques précises, ancrés dans des cas réels, et il grandit régulièrement à mesure que de nouveaux types d’attaques apparaissent. Les ajouts récents se sont concentrés sur les agents IA autonomes. Comme le décompte bouge à chaque version, la réponse honnête est d’aller consulter la matrice à jour sur le site de MITRE ATLAS plutôt que de se fier à un chiffre figé dans un article.
Une petite équipe peut-elle réalistement utiliser les trois frameworks ?
Pas à fond dès le premier jour, et ce n’est pas nécessaire. Une petite équipe qui déploie des fonctionnalités IA peut vivre longtemps à l’intérieur de la liste de contrôle OWASP et couvrir les risques qui font réellement tomber les systèmes. MITRE ATLAS gagne sa place une fois que vous avez un système déployé qui vaut la peine d’être défendu et des gens pour le défendre. Une gouvernance NIST formelle compte surtout quand arrivent l’échelle, la réglementation ou les audits. Comme les trois s’emboîtent, ajouter le suivant ne défait jamais le travail déjà fait.
