ISO/IEC 42001 : Gouvernance et Management de l'IA
Paysage normatif tel que référencé — à vérifier auprès de l'ISO et de l'AI Act Service Desk avant de s'appuyer sur un numéro de clause pour un audit1. Structure de la norme : dix clauses, quatre annexes
La norme ISO/IEC 42001:2023 repose sur la même structure harmonisée (Harmonized Structure) que toute la famille des normes de management ISO (ISO 9001, ISO 27001, ISO 22301). C'est précisément ce qui explique qu'une organisation disposant déjà d'un Système de Management de la Sécurité de l'Information ISO 27001 mette en œuvre plus rapidement un Système de Management de l'IA (SMIA) : les clauses 4 à 10 — Contexte de l'organisation, Leadership, Planification, Support, Fonctionnement, Évaluation des performances, Amélioration — se superposent presque exactement aux contrôles qu'elle maintient déjà. L'écart se situe ailleurs : dans tout ce qui est spécifique à l'IA.
Cet écart se trouve dans l'Annexe A, le cœur normatif du texte : 38 contrôles répartis en 9 objectifs de contrôle (A.2 à A.10), couvrant la politique IA, l'organisation interne, les ressources, l'évaluation d'impact des systèmes d'IA, la gestion du cycle de vie des systèmes d'IA, les données utilisées par l'IA, l'information des parties intéressées, l'usage responsable de l'IA, et les relations avec les tiers/fournisseurs. L'Annexe B fournit les lignes directrices de mise en œuvre pour chaque contrôle. L'Annexe C recense les sources de risque typiques liées à l'IA — amplification des biais, opacité, dérive des données (« data drift »), comportements émergents dans les systèmes à apprentissage continu — ainsi que les objectifs organisationnels associés. L'Annexe D établit la correspondance avec ISO 9001, ISO/IEC 27001, ISO 31000 et ISO 37301, ce qui permet à une organisation multi-normes de faire fonctionner un système de management intégré plutôt que quatre bureaucraties parallèles.
Deux normes terminologiques sous-tendent tout l'édifice et valent d'être citées : l'ISO/IEC 22989 fournit le vocabulaire IA sur lequel s'appuie le reste de la famille (ce que signifient réellement, dans ce contexte, « système d'IA », « système de management de l'IA » ou « partie intéressée »), et l'ISO/IEC 23053 définit le cadre générique d'apprentissage automatique auquel renvoie la 42001 chaque fois qu'elle évoque les étapes du cycle de vie d'un modèle.
2. Alignement avec l'EU AI Act — et là où ça s'arrête vraiment
C'est le point sur lequel la quasi-totalité des contenus de conformité se trompent par excès de simplification — il vaut donc la peine d'être précis. La « présomption de conformité » de l'Article 40 du Règlement européen sur l'IA ne s'applique pas à l'ISO/IEC 42001 elle-même. Elle s'applique aux normes harmonisées — des spécifications techniques élaborées par les organismes européens de normalisation (le CEN et le CENELEC, via leur comité technique conjoint JTC 21, créé en juin 2021 sous mandat de normalisation M/593 de la Commission) et formellement citées au Journal officiel de l'Union européenne (JOUE). Tant qu'une norme n'a pas franchi cette barre précise, la suivre relève de la bonne pratique, pas de la présomption légale.
Le JTC 21 a déjà adopté et adapté certains livrables de l'ISO/IEC SC 42 plutôt que de repartir de zéro — par exemple en intégrant au catalogue européen l'ISO/IEC TR 24027:2023 (sur les biais dans les systèmes d'IA) et l'ISO/IEC 23894:2023 (lignes directrices sur la gestion des risques IA). Mais ce sont l'une et l'autre des rapports techniques ou des documents de lignes directrices, donc informatifs et non normatifs — ce qui les rend, à eux seuls, insuffisants pour conférer une présomption de conformité. L'ISO/IEC 42001 devait initialement faire l'objet d'un vote d'adoption en norme européenne (EN) par le CEN-CENELEC en 2024 ; les analyses juridiques indépendantes suivant le programme de travail du JTC 21 indiquent que ce vote ne semble pas avoir eu lieu à ce jour, d'après les dernières informations disponibles. Le JTC 21 rédige à la place des normes européennes sur mesure — notamment la prEN 18286, une norme de Système de Management de la Qualité pour la conformité à l'AI Act, parvenue au stade d'enquête publique fin 2025 — qui s'appuient sur la logique de la 42001 tout en ajoutant des exigences que la norme d'origine ne couvre pas complètement.
L'écart qui compte vraiment : le Centre commun de recherche (JRC) de la Commission européenne a lui-même relevé que l'ISO/IEC 42001 n'offre qu'une couverture limitée de la journalisation et de la conservation des enregistrements (« logging » et « recordkeeping »), les traitant comme des contrôles de risque optionnels plutôt que comme des exigences de base obligatoires. Or l'Article 12 (conservation des enregistrements) et l'Article 11 (documentation technique) de l'AI Act ne sont pas optionnels pour les systèmes à haut risque. Une organisation certifiée ISO 42001 qui considère que cela règle ses obligations au titre de l'Article 12 commet une erreur de catégorie : certification et conformité à une norme harmonisée sont deux choses juridiquement distinctes, même si elles partagent une grande partie du vocabulaire.
Pour le dire sans détour : la certification ISO/IEC 42001, délivrée par un organisme de certification accrédité, démontre qu'une organisation fait fonctionner un processus de management de l'IA structuré et auditable. C'est une preuve solide de maturité de gouvernance, et régulateurs, clients et assureurs la traitent de plus en plus comme telle. Ce n'est pas, en soi, un substitut à une évaluation de conformité documentée au titre de l'Article 40 vis-à-vis d'une norme citée au JOUE — et à ce jour, aucune version de la 42001 ne porte ce statut précis.
3. Supervision humaine obligatoire — l'Article 14 décortiqué paragraphe par paragraphe
L'Article 14 de l'AI Act est l'ancrage juridique de la supervision humaine, et il est plus précis que ne le laisse penser l'expression « humain dans la boucle ». Il distingue trois capacités bien distinctes que le déployeur doit pouvoir exercer sur un système à haut risque : la capacité à comprendre le système, la capacité à intervenir sur une décision donnée, et la capacité à arrêter le système dans son ensemble. Ces trois capacités ne sont pas interchangeables, et un audit qui n'en vérifie qu'une seule passera à côté de vraies failles.
14(4)(a) et (c) — Comprendre et surveiller
La personne chargée de la supervision doit pouvoir véritablement saisir les capacités et limites du système et détecter les anomalies ou les performances inattendues, et doit pouvoir interpréter correctement ses résultats. En pratique, cela se traduit par des scores de confiance attachés aux sorties, des résumés d'attribution des caractéristiques (souvent fondés sur SHAP ou LIME) expliquant les principales variables d'entrée ayant influencé le résultat, des alertes en cas de données d'entrée hors distribution, et des tableaux de bord de performance en temps réel comparés aux niveaux de précision attendus.
14(4)(b) — Conscience du biais d'automatisation
Les personnes chargées de la supervision doivent rester conscientes de la tendance à se fier excessivement aux résultats de l'IA — une exigence qui vise directement le schéma bien documenté où une étape de « relecture » se transforme, une fois le système jugé fiable, en simple tampon d'approbation. Le suivi du taux de contournement (« override rate ») comme indicateur clé est l'un des rares signaux concrets que les auditeurs recherchent ici : un taux de contournement proche de zéro est au moins aussi susceptible de traduire un biais d'automatisation qu'un modèle parfait.
14(4)(d) et (e) — Contourner et arrêter
La personne en charge de la supervision a besoin à la fois de l'autorité légale et de la capacité pratique, sans friction excessive, d'écarter un résultat donné dans une situation précise, et, séparément, de la capacité d'arrêter complètement le fonctionnement du système. Ce sont des mécanismes architecturalement différents : un bouton de contournement qui rejette une seule recommandation n'est pas le même mécanisme qu'une capacité d'arrêt, qui devrait relever de personnes désignées et nommément identifiées comme responsables de la supervision — pas simplement de quiconque dispose d'un accès administrateur système — avec une autorité documentée en amont, et non improvisée pendant un incident.
14(5) — Le cas renforcé
Pour certains systèmes d'identification biométrique à distance (Annexe III, point 1(a)), le Règlement va plus loin : aucune action ne peut être engagée sur la base du résultat d'identification du système sans une vérification distincte par au moins deux personnes compétentes, formées et autorisées — avec une dérogation étroite pour certains usages relevant des services répressifs, de la migration, du contrôle des frontières ou de l'asile, lorsque le droit national ou de l'Union considère cette exigence de double vérification comme disproportionnée.
L'Article 14 se conjugue avec l'Article 26, paragraphe 2, qui impose aux déployeurs — et non aux seuls fournisseurs — de confier ce rôle de supervision à des personnes disposant réellement de la compétence, de la formation et de l'autorité organisationnelle nécessaires pour l'exercer. Et il existe ici une subtilité facile à manquer : au titre de l'Article 25, un déployeur qui modifie substantiellement un système, y compris son architecture de supervision, peut être requalifié en fournisseur — héritant du même coup des obligations de conception qui incombent à ce dernier.
Pourquoi cela dépasse l'ISO 42001 à elle seule : la 42001 exige qu'une organisation définisse où se situe la supervision humaine dans le cycle de vie de l'IA et qu'elle le documente. L'Article 14 exige que cette supervision soit opérationnellement réelle au moment de l'audit — des personnes nommément identifiées, des mécanismes de contournement et d'arrêt qui fonctionnent réellement, des journaux d'intervention infalsifiables avec identifiant de l'opérateur et horodatage. Un certificat de système de management prouve que la politique existe. Il ne produit pas, en lui-même, le journal d'intervention en direct qu'un régulateur — ou l'avocat de la partie adverse — réclamera en premier.
4. Qui audite les auditeurs : l'ISO/IEC 42006 et la 42007
Un certificat n'a de crédibilité que celle de l'organisme qui l'a délivré. L'ISO/IEC 42006 fixe les exigences que doivent respecter les organismes de certification eux-mêmes pour auditer la mise en œuvre d'un SMIA — compétence des auditeurs, contrôle des conflits d'intérêts, calcul de la durée d'audit — en étendant le cadre existant de l'ISO/IEC 17021 (applicable aux organismes de certification des systèmes de management) au domaine spécifique de l'IA. L'ISO/IEC 42007 définit les schémas d'évaluation de la conformité construits sur cette base, c'est-à-dire les procédures concrètes que suit un auditeur lors d'un audit de certification 42001. Ensemble, ces deux normes expliquent pourquoi un certificat 42001 délivré par un organisme accrédité a un poids différent d'un simple label « IA responsable » auto-décerné par un éditeur : il existe une chaîne de compétence définie derrière le tampon — même si, comme indiqué à la section 2, ce tampon ne constitue toujours pas une déclaration de conformité à une norme harmonisée.
C'est aussi à ce niveau que l'adoption réelle devient visible : plusieurs grands fournisseurs d'infrastructure cloud et d'IA ont déjà fait passer des produits spécifiques par des audits 42001 tiers accrédités, avec certificats et périmètres d'audit publiés à des fins de diligence raisonnable pour leurs clients — un bon réflexe de vérification pour savoir si l'affirmation « conforme ISO 42001 » d'un fournisseur renvoie à un certificat réel ou à une paraphrase marketing de celui-ci.
5. La limite documentée : certifier un processus n'est pas certifier un résultat
C'est la réserve honnête qui doit figurer sur toute page se voulant une référence sur ce sujet, car c'est la conclusion à laquelle aboutit réellement la recherche sous-jacente. Des chercheurs étudiant les voies d'auto-certification pour les systèmes d'IA à haut risque ont explicitement relevé que l'obtention de la certification ISO/IEC 42001 n'établit pas, en soi, qu'un système d'IA donné respecte les exigences substantielles de l'AI Act — parce que la 42001 certifie l'existence et le fonctionnement d'un système de management, pas les propriétés techniques d'un modèle en particulier.
Les analyses de conformité côté industrie convergent vers le même constat sous un angle différent : la 42001 cartographie les rôles, formalise l'évaluation des risques et fait de l'amélioration continue une attente de niveau conseil d'administration — et, en pratique, de nombreuses mises en œuvre s'arrêtent précisément là, au niveau du management, laissant la preuve opérationnelle — les journaux en direct, les intervenants nommés, le bouton d'arrêt qui fonctionne réellement — non démontrée jusqu'à ce qu'un audit, ou un incident, ne force la question.
Rien de tout cela ne rend la norme inutile. Cela en fait un échafaudage nécessaire et bien construit plutôt qu'un bâtiment achevé. Une organisation qui considère la certification 42001 comme l'aboutissement de son travail de gouvernance de l'IA n'a, par définition, pas encore accompli la partie du travail que l'AI Act sanctionne réellement.