Cadres de sécurité de l'IA en 2026 : Lesquels s'appliquent et où chacun s'arrête

En 2026, les équipes de sécurité des entreprises disposent de plus de cadres de sécurité de l'IA que jamais auparavant. NIST, OWASP, MITRE ATLAS, Google SAIF, ISO 42001 et CSA MAESTRO abordent chacun différents aspects du problème global de la sécurité de l'IA, et aucun d'entre eux n'est complet à lui seul.

Une fois que les organisations ont déterminé quels cadres adopter, elles doivent comprendre quel problème chaque cadre de sécurité de l'IA a été conçu pour résoudre et, plus important encore, où chacun s'arrête.

Ce guide compare les principaux cadres de sécurité de l'IA en fonction de leur portée, de leur public cible et de leur couverture pratique, et montre ce qui reste non couvert une fois le travail du cadre terminé.

Que cherchent à résoudre les cadres de sécurité de l'IA ?

Les cadres de cybersécurité traditionnels ont été développés spécifiquement pour les applications déterministes. Les systèmes d'IA fonctionnent de manière comportementale et probabiliste, apprennent des données d'entraînement, utilisent le traitement du langage naturel pour exécuter des instructions et sont de plus en plus capables de fonctionner de manière autonome. Ces caractéristiques comportementales présentent des risques uniques qu'aucun cadre de cybersécurité précédent n'a été conçu pour aborder.

Les cadres de sécurité de l'IA tentent de combler cette lacune en offrant des lignes directrices structurées pour l'identification des risques liés à l'IA, la gouvernance des systèmes d'IA tout au long de leur cycle de vie, et la construction de défenses fiables contre les défaillances ou les exploitations de l'IA.

Les équipes de sécurité des entreprises sont confrontées à un véritable défi car les différents cadres couvrent des aspects différents d'un même problème complexe et multicouche. Une dépendance exclusive à l'égard d'un cadre de sécurité de l'IA donné sans tenir compte de l'ensemble de ses lacunes créera des faiblesses identifiables dans la posture de sécurité globale de l'entreprise.

Les principaux cadres de sécurité de l'IA

Examinons les principaux cadres de sécurité de l'IA :

Cadre de gestion des risques liés à l'IA du NIST 

Le NIST AI RMF, publié par le National Institute of Standards and Technology, comporte quatre composantes principales : Gouverner, Cartographier, Mesurer et Gérer. « Gouverner » implique l'établissement de politiques et la définition des rôles et responsabilités. « Cartographier » consiste à identifier où l'IA est utilisée et les risques liés à l'IA associés à sa mise en œuvre. « Mesurer » définit les critères d'évaluation de ces risques. « Gérer » établit un plan pour la mise en œuvre de stratégies d'atténuation des risques une fois les risques évalués identifiés.

En ce qui concerne les industries réglementées, le Cadre de gestion des risques liés à l'IA du NIST est l'ancrage de gouvernance par défaut. Il est directement aligné sur les niveaux de risque définis dans la loi européenne sur l'IA, et les industries réglementées, y compris les services financiers, la santé et les infrastructures critiques, font explicitement référence au NIST AI RMF dans leurs directives de gouvernance de l'IA.

La Limite : Le NIST AI RMF fournit des structures de gouvernance, et non des contrôles techniques. Il définit les structures de responsabilité qui devraient exister et les catégories de risques liés à l'IA qui devraient être surveillées, mais il ne fournit pas de directives sur la manière de prévenir une attaque par injection de prompt lors de l'exécution. Le AI RMF n'aborde pas la manière de garantir que les agents ne peuvent invoquer que les outils auxquels leurs utilisateurs sont autorisés à accéder. Il présume qu'une entité en aval se chargera de l'application. Les équipes qui considèrent la conformité au NIST AI RMF comme exhaustive auront des politiques détaillées mais aucune application réelle lors des opérations en direct.

OWASP LLM Top 10 et Agentic Top 10

Le LLM Top 10, produit par l'OWASP, décrit les risques de sécurité de plus haut niveau pour les applications de grands modèles linguistiques (LLM), y compris l'injection de prompt, la gestion des sorties non sécurisée, l'empoisonnement des données, les attaques par déni de service sur le modèle et la compromission de la chaîne d'approvisionnement. L'Agentic Top 10 étend ces risques en identifiant les risques uniques posés par les agents autonomes, y compris l'utilisation d'outils non sécurisée, les privilèges excessifs, la violation des limites de confiance inter-agents et la consommation incontrôlée de ressources.

Ces deux documents aident à convertir la recherche sur les attaques en contrôles d'ingénierie sur lesquels les équipes de développement peuvent agir directement. Ceci est particulièrement précieux pour les équipes qui développent des applications LLM, car l'OWASP offre le meilleur point de départ pour comprendre la surface d'attaque introduite par leur développement d'IA.

La Limite: OWASP est un document de sensibilisation aux menaces, identifiant ce qu'il faut aborder plutôt que de prescrire une approche programmatique pour une application continue. Bien que l'injection de prompt soit clairement le risque de sécurité IA le plus élevé, l'identifier dans un document ne l'intercepte pas en production. Si rien dans la pile opérationnelle ne peut bloquer l'injection de prompt à l'exécution, la seule sensibilisation à OWASP n'offre aucune mesure de sécurité contre elle.

MITRE ATLAS

MITRE ATLAS est un catalogue de tactiques et techniques adverses réelles employées contre les solutions basées sur l'IA. Structuré comme une matrice similaire à MITRE ATT&CK, il s'aligne directement avec les équipes SOC utilisant déjà des outils de sécurité basés sur ATT&CK. Les techniques incluent l'évasion de modèle, l'empoisonnement de données, les attaques par porte dérobée et l'extraction de modèle, toutes basées sur des recherches publiées et des données de réponse aux incidents confirmées plutôt que sur une modélisation des menaces estimée.

Pour les équipes rouges (red teams), ATLAS offre un moyen structuré de tester les comportements adverses réalistes des systèmes d'IA. Pour les équipes bleues (blue teams), ATLAS fournit le vocabulaire nécessaire pour écrire des règles de détection pour les schémas d'attaque spécifiques à l'IA et pour intégrer le risque lié à l'IA dans les flux de travail SIEM existants.

La Limite : ATLAS décrit comment les attaques se produisent et permet de les tester, ce qui est réellement précieux. Cependant, MITRE ATLAS ne fournit pas de contrôles d'exécution pour les charges de travail d'IA en production. Une équipe de sécurité peut élaborer un modèle de menace complet basé sur ATLAS, mener un exercice d'équipe rouge contre chaque technique ATLAS, et ne trouver toujours aucune défense d'exécution protégeant ces voies d'attaque en production. ATLAS offre une visibilité sur les lacunes mais nécessite des outils distincts pour les combler.

Google SAIF

Le Cadre de Sécurité de l'IA (SAIF) développé par Google a identifié six grands domaines d'intervention : 

1) Établir des bases de sécurité solides à travers l'écosystème de l'IA ; 

2) Étendre les capacités de détection et de réponse au pipeline d'IA ; 

3) Automatiser les mesures défensives pour anticiper les risques accrus par l'IA ;

4) Standardiser les contrôles au niveau de la plateforme afin qu'ils soient régis par une politique globale unique ;

5) Ajuster les contrôles si nécessaire en fonction du contexte du système d'IA ; 

6) Évaluer le risque lié à l'IA par rapport aux modèles de menace existants. 

SAIF offre aux organisations développant des applications d'IA sur Google Cloud ou utilisant les normes d'ingénierie de Google une excellente compréhension des approches efficaces en matière de sécurité de l'IA, depuis les premières phases de développement de modèles jusqu'au développement et au déploiement de l'IA.

La Limite : SAIF est utile en tant que bonnes pratiques de haut niveau, mais ne prescrit pas de contrôles spécifiques ni la manière de les appliquer une fois qu'une application d'IA est en production. SAIF fournit des orientations substantielles sur l'intégrité des données, la sécurité des modèles et la sécurité de la chaîne d'approvisionnement pendant la phase d'entraînement des modèles, mais n'offre qu'un point de départ pour l'application des contrôles sur les agents de production après le déploiement.

ISO 42001 

ISO 42001 est une norme internationale de système de management pour l'IA. Elle décrit comment établir, mettre en œuvre, maintenir et améliorer un système de management de l'IA, en utilisant la même structure de haut niveau que l'ISO 27001 (sécurité de l'information) et l'ISO 9001 (management de la qualité). Les organisations utilisant déjà des cadres de gouvernance ISO peuvent étendre leur programme existant à l'IA en utilisant l'ISO 42001 comme langage commun.

La principale raison pour laquelle les organisations adoptent l'ISO 42001 est qu'elle offre une voie de certification pour répondre aux exigences de certification en matière de gouvernance de l'IA, de plus en plus imposées par les processus d'approvisionnement des entreprises. L'ISO 42001 est le cadre le plus crédible disponible à cette fin.

La limitation: L'ISO 42001 se concentre sur la certification des systèmes de management, et non sur les contrôles techniques ou les mesures de sécurité opérationnelle. Elle fournit la preuve qu'une organisation a élaboré sa politique de gouvernance de l'IA, établi des responsabilités et mis en œuvre des processus d'examen. 

Cependant, l'ISO 42001 ne traite pas du comportement d'IA agentique, de l'injection de prompt ou de l'application des politiques à l'exécution au niveau de l'infrastructure. Avoir un système de management certifié ISO 42001 ne signifie pas que les systèmes de l'organisation filtrent ou enregistrent les requêtes individuelles qui les traversent. La certification atteste du système de management de la gouvernance, et non de la sécurité des données ou de l'application des politiques sur le trafic en direct.

Comment utiliser plusieurs cadres ensemble ?

Ces cadres de sécurité de l'IA ont été créés à des fins différentes, et les utiliser ensemble compense les faiblesses de chacun.

Le NIST AI RMF fournit le modèle de gouvernance. L'OWASP LLM Top 10 et l'Agentic Top 10 servent de référence pour les développeurs et les ingénieurs afin d'évaluer les vulnérabilités de sécurité. MITRE ATLAS soutient la modélisation des menaces et le red teaming contre les techniques d'attaque spécifiques à l'IA. L'ISO 42001 gère la vérification externe et la conformité réglementaire. Google SAIF fournit des conseils sur l'intégration de la sécurité dans le développement et l'entraînement des modèles.

Combiner ces cadres de sécurité de l'IA offre une assurance supplémentaire que toutes les couches du système d'IA sont prises en compte. Le NIST AI RMF fournit des conseils sur ce qu'il faut gouverner. OWASP fournit des conseils sur ce qu'il faut surveiller. ATLAS fournit des conseils sur la manière dont les attaques sont exécutées. L'ISO 42001 fournit la preuve de la conformité aux exigences réglementaires. SAIF fournit des conseils sur la manière de développer des modèles d'IA sécurisés.

Cependant, une lacune critique demeure. Aucun de ces cadres de sécurité de l'IA ne traite du plan de contrôle par lequel chaque requête d'IA, action d'agent et invocation d'outil nécessite l'application d'une politique avant l'exécution.

Quels cadres de sécurité de l'IA laissent sans réponse ?

Tous les cadres de sécurité de l'IA examinés ici appliquent des actions à l'un des trois niveaux suivants : politique, documentation ou modélisation des menaces. Aucun d'entre eux n'applique directement des contrôles sur le trafic d'inférence en direct.

L'utilisation du NIST AI RMF n'empêche pas un agent sur-privilégié d'exécuter une action via un outil restreint ; il s'appuie sur un élément en aval pour gérer correctement l'application des politiques.

OWASP identifie l'injection de prompt comme la vulnérabilité de sécurité IA numéro un, mais la reconnaître dans un document n'empêche pas les instructions injectées d'atteindre un modèle d'IA en production.

MITRE ATLAS fournit un modèle expliquant comment un attaquant exploite les capacités d'un agent, mais n'empêche pas cette exploitation dans un déploiement en direct. L'équipe rouge identifie la vulnérabilité. Une couche technique distincte doit combler cette lacune.

La certification ISO 42001 indique qu'un système de management est en place, mais ne garantit pas que toutes les requêtes traitées par ce système sont enregistrées ou filtrées en temps réel.

Cette lacune est structurelle. Les cadres de sécurité de l'IA ont été conçus pour la planification, la documentation et les environnements de test. Combler cette lacune nécessite un plan de contrôle fonctionnant au niveau de l'infrastructure, où les systèmes d'IA s'exécutent en temps réel, et où la politique est appliquée avant que les requêtes n'atteignent les modèles et les outils.

Comment TrueFoundry opérationnalise les cadres de sécurité de l'IA au niveau de l'infrastructure ?

TrueFoundry repose sur une prémisse importante. La couche d'infrastructure devrait appliquer les cadres de contrôle tels que décrits précédemment, et ne pas laisser leur application aux équipes de développement individuelles ni les documenter dans les artefacts de gouvernance. 

La plateforme TrueFoundry se déploie dans le compte AWS / GCP / Azure du client et applique la politique au niveau de la passerelle avant qu'un modèle/outil ne reçoive des requêtes.

• Aborder l'utilisation d'outils non sécurisés d'OWASP: L'injection d'identité OAuth 2.0 lie chaque action d'agent à la portée des permissions de l'utilisateur authentifié. Un agent ne peut pas invoquer un outil à moins que l'utilisateur demandeur ne soit autorisé à y accéder, mettant directement en œuvre le principe du moindre privilège que les cadres de sécurité de l'IA décrivent mais ne peuvent pas appliquer eux-mêmes.
• Alignement avec les normes de gouvernance du NIST AI RMF: Le mécanisme de contrôle d'accès par modèle et par outil établit la responsabilité de la gestion des risques liés à l'IA au niveau du système, plutôt que de la laisser à des documents de politique que les équipes de développement peuvent ou non appliquer de manière cohérente.
• Traitement de l'injection de prompt OWASP LLM01: Le filtrage des injections de prompt est appliqué au niveau de l'infrastructure avant que les instructions n'atteignent le contexte du modèle d'IA. La rédaction des informations personnelles identifiables (PII) traite la divulgation d'informations sensibles OWASP LLM06 en interceptant les données personnelles et les données sensibles avant qu'elles n'entrent dans le modèle, satisfaisant ainsi les exigences de protection des données spécifiées par les cadres de sécurité de l'IA.
• Production de traces auditables: Des traces d'audit immuables satisfont aux exigences indiquées dans le NIST AI RMF, l'ISO 42001 et l'EU AI Act sans nécessiter d'infrastructure de journalisation distincte pour chaque équipe ou application.
• Traitement des exigences en matière de confidentialité et de résidence des données: Le déploiement natif VPC est conforme aux exigences de souveraineté et de résidence que tous les cadres de sécurité de l'IA indiquent mais qu'aucun d'entre eux n'applique seul.
• Combler le fossé entre les directives des cadres et la réalité organisationnelle: Au niveau de l'infrastructure, chaque politique est appliquée à chaque requête d'exécution, plutôt que d'être documentée dans un classeur de gouvernance et appliquée de manière incohérente entre les équipes.