Double conformité NIST et AI Act : construire un pont

Deux cadres, même vocabulaire, obligations différentes

Un responsable conformité qui opère à la fois sur le marché américain et européen rencontre tôt ou tard la même friction : le NIST AI Risk Management Framework et le règlement européen sur l'IA (AI Act) parlent tous deux de risque, de transparence, de supervision humaine. Pourtant, ils ne débouchent pas sur les mêmes exigences concrètes.

Le NIST AI RMF est un cadre volontaire, structuré autour de quatre fonctions (Govern, Map, Measure, Manage), sans mécanisme de certification ni de sanction^[3]. L'AI Act, lui, est une loi contraignante dont les obligations varient selon la catégorie de risque du système, avec des échéances échelonnées : obligations GPAI applicables depuis le 2 août 2025, obligations pour les systèmes à haut risque depuis le 2 août 2026^[2].

La tentation est de traiter ces deux cadres comme interchangeables, puisqu'ils partagent un vocabulaire commun. C'est précisément là que le problème commence.

Où la concordance chiffrée pose problème

Une étude publiée en 2025 par Jameel Ahmed Siddiqui a mesuré la concordance entre l'AI Act, le NIST AI RMF et l'ISO/IEC 42001 sur un même échantillon de 45 systèmes d'IA. Le coefficient de concordance obtenu était de 0,609, en dessous du seuil de 0,667 généralement considéré comme le minimum pour tirer une conclusion fiable^[1].

Sous un second modèle d'évaluation, ce coefficient tombait à 0,521. Les trois cadres ne convergeaient sur le même verdict que pour 44,4 % des systèmes (40,0 % sous le second modèle)^[1]. Pour environ un couple de cadres sur six, l'écart atteignait deux niveaux d'obligation ou plus, soit la distance entre un système ne requérant rien et un système nécessitant une évaluation de conformité formelle^[1].

Ce désaccord a une direction. L'AI Act plaçait systématiquement les systèmes 0,58 à 0,91 niveaux en dessous du NIST et de l'ISO 42001, avec une significativité statistique (Wilcoxon p < 0,001)^[1]. Dit autrement : l'AI Act laissait 18 des 45 systèmes sans obligation spécifique, là où les deux cadres de processus n'en laissaient que 5 et 7 respectivement^[1].

Notons que cette étude repose sur un protocole automatisé (modèles Gemini flash-lite, 810 classifications). Elle offre un ordre de grandeur utile, mais ses résultats méritent d'être recoupés avec des évaluations humaines. Vérifier l'évolution de ces travaux depuis leur publication est recommandé.

AI Act : logique de périmètre. NIST : logique de processus

La divergence mesurée s'explique par une différence architecturale. L'AI Act fonctionne comme un instrument de périmètre : si un système d'IA ne tombe pas dans les catégories énumérées (haut risque, risque inacceptable, etc.), aucune obligation spécifique ne s'y attache^[1]. C'est un filtre binaire appliqué en amont.

Le NIST AI RMF, à l'inverse, pose une question de processus : quel niveau de gestion du risque les caractéristiques du système justifient-elles ? Avec cette approche, presque aucun système ne revient à zéro^[1]. La corrélation de rang entre les cadres reste correcte (0,62 à 0,85) : ils s'accordent sur quels systèmes sont plus risqués. Mais ils divergent sur ce qu'il faut faire^[1]. Or la réglementation opère sur le niveau, pas sur le rang.

Pour un responsable conformité, cette distinction change tout. Un système classé "risque limité" par l'AI Act peut très bien nécessiter un programme de gestion du risque substantiel selon le NIST. Inversement, un système à haut risque sous l'AI Act peut ne couvrir qu'une partie des fonctions NIST dans sa documentation. Comme le relève une analyse indépendante, les organisations qui gèrent bien cette tension sont celles qui traitent l'interopérabilité comme un problème de conception opérationnelle^[4].

ISO 42001 comme architecture commune

C'est ici qu'intervient l'ISO/IEC 42001. Cette norme internationale établit les exigences d'un système de management de l'IA (SMIA), structuré selon la méthodologie Plan-Do-Check-Act, avec des clauses 4 à 10 couvrant le contexte, le leadership, la planification, le support, les opérations, l'évaluation de performance et l'amélioration^[3].

Contrairement au NIST AI RMF, l'ISO 42001 est certifiable par un organisme accrédité^[7]. Contrairement à l'AI Act, elle n'est pas une loi mais un référentiel volontaire^[5]. Sa valeur dans une stratégie de double conformité tient à trois propriétés.

Premièrement, son Annexe A fournit 38 contrôles couvrant politique, rôles, gouvernance des données, développement, tiers, opérations et mise hors service^[3]. Ces contrôles recoupent une partie significative des attentes de l'AI Act pour les systèmes à haut risque (documentation technique, gestion des données, supervision humaine) et des fonctions NIST. Pour une analyse détaillée du recouvrement entre ISO 42001 et AI Act, un article dédié couvre ce sujet.

Deuxièmement, la norme suit la structure Annex SL, familière aux organisations déjà certifiées ISO 27001^[7]. Cela permet une intégration avec un SMSI existant sans repartir de zéro.

Troisièmement, un certificat ISO 42001 répond à une question d'approvisionnement sans conversation supplémentaire^[7]. Pour les marchés européens et les appels d'offres internationaux, c'est un artefact que les acheteurs peuvent classer dans un dossier.

Cartographier les recouvrements concrets

Plutôt que de gérer trois piles documentaires indépendantes, l'approche efficace consiste à identifier les contrôles partagés. Selon BD Emerson, si vous implémentez correctement les fonctions Map et Measure du NIST AI RMF, vous avez déjà produit une grande partie des preuves que les clauses 6 et 8 de l'ISO 42001 exigent^[7]. Le mapping n'est pas parfait, mais le travail sous-jacent est largement commun.

Correspondances entre fonctions NIST, clauses ISO 42001 et exigences AI Act

Fonction NIST AI RMF	Clauses ISO 42001 concernées	Exigences AI Act (haut risque)
Govern (culture, responsabilités)	Clause 5 (leadership), Clause 7 (support)	Système de gestion de la qualité, responsabilités désignées
Map (contexte, parties prenantes)	Clause 4 (contexte), Clause 6 (planification)	Description de l'usage prévu, analyse d'impact
Measure (évaluation, métriques)	Clause 9 (évaluation de performance)	Tests, validation, métriques de performance
Manage (traitement, réponse)	Clause 8 (opérations), Clause 10 (amélioration)	Surveillance post-marché, actions correctives

Ce tableau est une synthèse interprétative basée sur les descriptions des cadres dans les sources consultées^[3][7][2]. Il ne remplace pas un crosswalk formel. Pour un comparatif plus granulaire entre ISO 42001 et le NIST AI RMF, consultez l'article dédié au crosswalk officiel.

L'intérêt pratique est direct : une organisation qui documente ses systèmes d'IA selon la fonction Map du NIST produit simultanément une partie de l'inventaire requis par la clause 4 de l'ISO 42001 et de la documentation technique attendue par l'AI Act pour les systèmes à haut risque. Le travail n'est fait qu'une fois, mais sert trois finalités.

Séquence pratique pour une double conformité

La question n'est pas quel cadre choisir, mais dans quel ordre les déployer. Trois critères orientent la séquence^[7].

Quelqu'un vous demande-t-il une preuve ? Si des acheteurs européens, des obligations liées à l'AI Act ou un secteur régulé exigent un certificat, la certification ISO 42001 devient prioritaire. Si personne ne demande encore de preuve formelle, commencer par le NIST AI RMF est plus pragmatique.

Où en êtes-vous ? Sans inventaire de vos systèmes d'IA ni propriétaire désigné, les fonctions Govern et Map du NIST offrent un point d'entrée plus accessible qu'un projet de certification^[7]. La cartographie des systèmes IA est un prérequis commun aux deux démarches.

Quelle est votre géographie ? Le marché fédéral américain parle NIST. Les marchés européens et les appels d'offres internationaux demandent ISO^[7]. Une entreprise qui exporte vers les deux doit couvrir les deux.

Quatre étapes, de la pratique terrain à la preuve formelle.

1Inventaire et gouvernance (NIST Govern + Map)

2Évaluation et métriques (NIST Measure + Manage)

3Formalisation SMIA (ISO 42001, clauses 4 à 10)

4Couche réglementaire AI Act (obligations spécifiques par catégorie)

Les étapes 1-2 produisent les preuves réutilisées en étapes 3-4. La séquence est itérative^[7].

Cette séquence n'est pas la seule possible. Une organisation déjà certifiée ISO 27001 peut entrer directement par l'étape 3, en étendant son système de management existant. Mais pour une organisation partant de zéro, commencer par les pratiques NIST avant de formaliser en SMIA évite de certifier une coquille vide.

Piège fréquent : certifier un programme immature

BD Emerson formule cette mise en garde de façon directe : certifier un programme immature produit un certificat et beaucoup de théâtre^[7]. L'observation mérite qu'on s'y arrête.

La certification ISO 42001 requiert, selon Elevate Consult, entre 75 et 100 artefacts d'audit selon la taille et la complexité du système^[3]. L'audit de phase 2 porte sur 50 à 75 de ces artefacts et doit être reconduit annuellement^[3]. Si ces artefacts ont été produits pour passer l'audit plutôt que pour gouverner réellement vos systèmes, le coût de maintenance devient rapidement disproportionné.

Le piège est d'autant plus réel dans un contexte de double conformité. Une organisation qui obtient un certificat ISO 42001 sans avoir réellement intégré les fonctions NIST dans ses pratiques quotidiennes se retrouve avec un système de management formel déconnecté de la réalité opérationnelle. Quand l'AI Act exige ensuite des preuves de surveillance post-marché ou de gestion des données d'entraînement, les lacunes apparaissent.

Pour évaluer votre maturité avant de lancer un projet de certification, une analyse d'écart (gap analysis) reste le point de départ le plus fiable.

Exemple romand : éditeur logiciel exportant vers l'UE et les US

Prenons le cas fictif d'un éditeur de logiciel basé dans le canton de Vaud, qui développe un outil d'aide à la décision médicale intégrant de l'IA. Ses clients se trouvent en Suisse, en France, en Allemagne et aux États-Unis.

Côté européen, son système tombe probablement dans la catégorie "haut risque" de l'AI Act (dispositifs médicaux, annexe III). Les obligations de documentation technique, de gestion des données d'entraînement, de supervision humaine et de surveillance post-marché s'appliquent depuis août 2026^[2]. Côté américain, ses clients hospitaliers attendent une gestion du risque alignée sur le NIST AI RMF, cadre de référence dans le secteur de la santé^[2].

Sans architecture commune, cet éditeur maintient deux jeux de documentation parallèles, deux processus d'évaluation du risque, deux formats de preuve. Avec un SMIA ISO 42001 comme colonne vertébrale, il peut structurer un inventaire unique de ses systèmes (clause 4), une politique IA validée par la direction (clause 5), une évaluation des risques centralisée (clause 6), et des processus opérationnels documentés (clause 8). Les fonctions NIST alimentent ce SMIA en pratiques concrètes. Les exigences spécifiques de l'AI Act sont traitées comme une couche supplémentaire, ciblée sur les systèmes classés à haut risque.

Le gain n'est pas dans l'élimination de toute duplication, car certaines exigences de l'AI Act n'ont pas d'équivalent NIST et inversement. Il est dans la réduction du travail redondant et dans la cohérence de la documentation face à des audits multijuridictionnels. Comme le souligne AI Governance Desk, l'approche durable consiste à inventorier ses systèmes, les trier par risque et juridiction, identifier les contrôles communs, puis ajouter des couches ciblées là où les lois divergent réellement^[4].

Pour les entreprises suisses exportant vers l'UE, un guide spécifique détaille les points d'attention liés à l'extraterritorialité de l'AI Act.

Questions fréquentes

À lire ensuite