L’essentiel
- ISO/IEC 42001:2023 est la première norme internationale certifiable consacrée à un Système de Management de l’Intelligence Artificielle (SMIA), publiée conjointement par l’ISO et la CEI en décembre 2023.
- Elle certifie l’organisation, pas un système d’IA isolé. Le certificat atteste que l’entreprise gouverne son IA par un système maîtrisé, sans valider un modèle particulier.
- Le standard articule une colonne vertébrale de management (Chapitres 4 à 10) avec un jeu de mesures spécifiques à l’IA en Annexe A, couvrant politiques, cycle de vie, données, transparence et chaîne d’approvisionnement.
- La certification suit un audit en deux étapes et un cycle de trois ans avec audits de surveillance annuels. La préparation réaliste tient entre 6 et 12 mois pour une organisation partant d’un socle faible ou moyen.
- ISO 42001 est une charpente de gouvernance, pas une réponse à la conformité au Règlement IA. Elle ne délivre pas, à elle seule, l’évaluation de conformité, le filtrage des pratiques interdites, la transparence vis-à-vis des utilisateurs, ni le signalement des incidents graves.
Ce qu’est précisément ISO/IEC 42001
ISO/IEC 42001:2023 spécifie les exigences applicables à « l’établissement, la mise en œuvre, la maintenance et l’amélioration continue d’un système de management de l’IA au sein des organisations ». L’énoncé officiel se trouve sur la fiche du catalogue ISO. Le texte a été élaboré par le sous-comité technique conjoint ISO/CEI SC 42, qui produit également les autres normes de la famille IA (biais, robustesse, cycle de vie, gestion des risques). ISO 42001 est la première de cette famille face à laquelle toute organisation peut être certifiée par un tiers accrédité.
L’objet de la certification est le Système de Management de l’IA (SMIA), non l’IA elle-même. Un SMIA réunit politiques, rôles, procédures, mesures et enregistrements qui régissent la manière dont une organisation conçoit, achète, déploie et retire ses systèmes d’IA. Le parallèle avec ISO 9001 (qualité) et ISO 27001 (sécurité de l’information) est immédiat : la norme certifie la discipline de l’entreprise, pas le produit.
Le cycle Plan-Do-Check-Act commun à toute la famille de normes ISO à Structure Harmonisée se retrouve ici, adapté aux spécificités de l’IA. Le « Do » englobe l’entraînement, le déploiement et la surveillance avec contrôle de dérive. Le « Check » comprend les objectifs d’équité, de robustesse et d’explicabilité, en plus des non-conformités classiques. L’« Act » couvre les déclencheurs de réentraînement et les chemins de rappel pour les systèmes déjà en production.
Deux conséquences pratiques en découlent. D’une part, le certificat est délivré à une organisation pour un périmètre défini (une unité d’affaires, une ligne de produits, l’entité juridique entière), si bien qu’un « SMIA-de-1 » constitue un périmètre tout à fait acceptable lorsqu’une PME exploite un seul système d’IA. D’autre part, la norme reste volontaire : aucun régulateur ne l’impose. Sa force vient des appels d’offres, de la due diligence des investisseurs et de la valeur de preuve qu’elle apporte sous des régimes comme le Règlement IA.
À qui s’adresse la norme
ISO 42001 est neutre quant à la juridiction, mais sa lecture épouse naturellement les rôles définis aux articles 3(3) et 3(4) du Règlement IA. Les fournisseurs conçoivent ou font concevoir un système d’IA et le mettent sur le marché sous leur nom. Les déployeurs exploitent un système d’IA sous leur propre autorité. Les chapitres du SMIA s’appliquent indifféremment, mais l’évidence opérationnelle diffère : les fournisseurs investissent davantage sur la traçabilité des données d’entraînement et la documentation des modèles ; les déployeurs concentrent l’effort sur les déclarations d’usage prévu, les notices d’utilisation et la formation des opérateurs.
Les fournisseurs de modèles d’IA à usage général (GPAI), y compris les éditeurs de grands modèles de fondation, peuvent eux aussi se faire certifier ISO 42001. La norme n’a pas d’annexe dédiée au GPAI, mais les familles de mesures de l’Annexe A relatives aux données, au cycle de vie, à la chaîne d’approvisionnement et aux politiques cartographient sans peine les obligations que les textes réglementaires posent en aval.
L’IA à usage interne suit les mêmes règles que l’IA destinée au marché. Une banque utilisant un modèle de scoring uniquement pour ses propres clients reste dans le périmètre, parce que le SMIA couvre tout système d’IA conçu, exploité ou utilisé par l’organisation. Le certificat ne dit rien de la commercialisation ; il atteste la gouvernance.
Corollaire utile : le « SMIA-de-1 », c’est-à-dire une petite organisation avec un unique système d’IA en production. La plupart des mesures ISO 42001 se réduisent à l’échelle d’une équipe restreinte (une politique IA tenue par une seule personne, une déclaration d’applicabilité unique, une seule évaluation des risques). Les mesures de l’Annexe A demeurent identiques, mais l’évidence d’audit se contracte d’autant. Les auditeurs sont habitués aux périmètres réduits à un système nommé et ne pénalisent pas la sobriété.
La structure des chapitres : comment la norme est bâtie
Chapitres 4 à 10
Le corps de la norme suit la Structure de Haut Niveau (HLS) partagée avec ISO 9001, ISO 27001 et le reste de la famille à Structure Harmonisée. Les chapitres 1 à 3 fixent le domaine, les références normatives et les termes ; les exigences opérationnelles vivent dans les chapitres 4 à 10.
Chapitre 4 (Contexte) demande à l’organisation de cartographier son contexte interne et externe pour l’IA, d’identifier les parties intéressées (régulateurs, clients, salariés, populations concernées) et de définir le périmètre du SMIA. Chapitre 5 (Leadership) exige un responsable IA désigné, une politique IA approuvée au plus haut niveau et un engagement démontrable de la direction. Chapitre 6 (Planification) accueille l’évaluation des risques IA et l’évaluation d’impact IA, ainsi que la Déclaration d’Applicabilité qui relie l’ensemble aux mesures de l’Annexe A. Chapitre 7 (Support) couvre ressources, compétences, sensibilisation, communication et information documentée. Chapitre 8 (Réalisation) étend la planification opérationnelle à tout le cycle de vie de l’IA (conception, données, entraînement, évaluation, déploiement, surveillance, retrait). Chapitre 9 (Évaluation des performances) impose surveillance, audit interne et revue de direction. Chapitre 10 (Amélioration) referme la boucle avec non-conformité, action corrective et amélioration continue.
Annexe A : les neuf domaines de mesures, brièvement
L’Annexe A est le jeu de mesures spécifiques à l’IA. Elle reprend la forme de l’Annexe A d’ISO 27001 tout en restant à un niveau d’abstraction supérieur : des objectifs de mesure, non des implémentations prescrites. Neuf domaines, de A.2 à A.10 :
A.2Politiques pour l’IAA.3Organisation interneA.4Ressources pour les systèmes d’IAA.5Évaluation des impacts des systèmes d’IAA.6Cycle de vie des systèmes d’IAA.7Données pour les systèmes d’IAA.8Information des parties intéresséesA.9Utilisation des systèmes d’IAA.10Relations tiers et clients
Chaque domaine porte une poignée d’objectifs de mesure. La norme ne dit pas comment les satisfaire ; l’organisation choisit ses mesures lors de la planification et justifie ses choix dans la Déclaration d’Applicabilité.
Annexes B, C et D
L’Annexe B est un guide d’implémentation informatif qui rattache chaque objectif de mesure à des pratiques suggérées. L’Annexe C recense les sources de risque propres à l’IA : biais des données d’entraînement, biais d’automatisation, opacité, fragilités de robustesse, vulnérabilités de sécurité, empreinte environnementale. L’Annexe D parcourt des considérations sectorielles (santé, secteur public, emploi, défense). Ces trois annexes ne sont pas des exigences, mais les auditeurs les lisent ; tout écart par rapport à l’Annexe B doit être justifié par écrit.
L’Annexe A en termes opérationnels
Le piège le plus fréquent consiste à traiter l’Annexe A comme une liste de politiques à cocher. Les auditeurs recherchent des artefacts attestant que les mesures vivent au quotidien, pas des classeurs. Voici chaque domaine vu comme un rythme opérationnel, avec un exemple concret d’artefact qui décroche la coche.
A.2 Politiques pour l’IA
La politique IA et ses sous-politiques (usage acceptable, développement de modèles, IA tierce) sont revues à une cadence définie. Artefact opérationnel : le registre daté des politiques avec historique des versions et un procès-verbal de comité de direction approuvant la version en vigueur.
A.3 Organisation interne
Rôles et responsabilités liés à l’IA sont documentés sans ambiguïté. Artefact opérationnel : une matrice RACI nommant le responsable IA, les propriétaires de modèle par système, le data steward et la fonction risques en deuxième ligne, contresignée par les RH ou la direction de l’organisation.
A.4 Ressources pour les systèmes d’IA
L’organisation sait quelles données, quels outils, quelle puissance de calcul et quels profils humains ses systèmes d’IA consomment. Artefact opérationnel : une revue d’inventaire mensuelle du feature store, du registre des prompts, du registre des modèles et des dépenses cloud, dont les écarts remontent au responsable IA.
A.5 Évaluation des impacts des systèmes d’IA
Pour chaque système d’IA, une évaluation d’impact recense les effets sur les individus, les groupes et la société. Artefact opérationnel : une évaluation d’impact IA par système, rafraîchie à chaque changement majeur ou tous les douze mois, le premier des deux prévalant.
A.6 Cycle de vie du système d’IA
Le cycle de vie, de l’idéation au retrait, est piloté : revue de conception, revue des données, revue du modèle, validation de déploiement, surveillance, retrait. Artefact opérationnel : les enregistrements de portes décisionnelles montrant qui a approuvé chaque transition et sur quelle preuve.
A.7 Données pour les systèmes d’IA
Les données d’entraînement et d’inférence sont documentées, adaptées à l’usage et soumises à un management de la qualité. Artefact opérationnel : une fiche dataset par jeu d’entraînement, indiquant provenance, base légale, contrôles de représentativité et lacunes connues.
A.8 Information des parties intéressées
Utilisateurs, opérateurs et parties affectées reçoivent une information appropriée sur le système d’IA. Artefact opérationnel : la note de transparence ou la fiche modèle du système, plus les divulgations affichées aux utilisateurs en production, captures d’écran à l’appui.
A.9 Utilisation des systèmes d’IA
L’usage prévu, les limites opérationnelles et la supervision humaine sont définis et appliqués. Artefact opérationnel : un document « usage prévu » par système, accompagné d’un livret de prise en main pour les opérateurs ou d’une attestation de formation.
A.10 Relations tiers et clients
Fournisseurs (éditeurs de modèles de fondation, fournisseurs de données, plateformes MLOps) et clients (lorsque l’organisation joue le rôle de fournisseur) sont gouvernés par contrat et par assurance. Artefact opérationnel : un registre des fournisseurs d’IA avec leur rôle, les clauses contractuelles IA en vigueur et la dernière preuve d’assurance disponible (rapport d’audit, attestation, SBOM, fiche modèle).
Test rapide : un mardi matin, demandez-vous quel artefact vous avez touché aujourd’hui pour quelle mesure de l’Annexe A. Si la réponse est « aucun depuis des semaines », le SMIA n’existe que sur le papier.
Évaluation des risques, évaluation d’impact et Déclaration d’Applicabilité
Évaluation des risques IA contre évaluation d’impact IA
ISO 42001 sépare deux activités au vocabulaire trop souvent confondu. L’évaluation des risques IA (chapitre 6.1.2) est tournée vers l’organisation : qu’est-ce qui pourrait mal tourner avec ce système, pour l’entreprise, et avec quelle probabilité et quelle gravité ? L’évaluation d’impact IA (chapitre 6.1.4) regarde vers l’extérieur : quels effets ce système d’IA produit-il sur les personnes, les groupes ou la société, droits fondamentaux compris ?
Les confondre dans un document unique tue le dispositif. L’évaluation des risques pilote la sélection des mesures de l’Annexe A. L’évaluation d’impact pilote les obligations de transparence, les mécanismes de recours et la décision même de déploiement. Le billet AWS Security détaille la méthode de gestion du risque sur le cycle de vie et montre comment les deux alimentent la Déclaration d’Applicabilité.
Comment la Déclaration d’Applicabilité diffère de celle d’ISO 27001
Sous ISO 27001, la Déclaration d’Applicabilité (DdA) liste chaque mesure de l’Annexe A et indique si elle s’applique, avec justification. Sous ISO 42001 la logique est identique, mais la DdA acquiert un second axe : les cas d’usage IA. Une mesure peut être applicable en général tout en présentant une implémentation différente selon le cas d’usage (un agent conversationnel, un modèle de détection de fraude, un trieur de CV). Les DdA les plus lisibles prennent la forme d’une matrice : lignes pour les mesures, colonnes pour les cas d’usage IA, cellules renvoyant à l’implémentation concrète.
Quelles preuves les auditeurs acceptent
Les auditeurs déprécient les PDF de politiques sans trafic réel. Ils acceptent les enregistrements qui montrent que la politique a servi : comptes-rendus de revue, signatures d’approbation, commentaires de tickets, feuilles d’émargement de formation, captures d’écran de notices in-app, fiches dataset, fiches modèle, tableaux de bord de dérive, rétrospectives d’incident. Règle de pouce : pour chaque mesure de l’Annexe A, repérez un artefact échantillonnable, une cadence de rafraîchissement et un propriétaire nommé. Trois items par mesure sur neuf domaines : un backlog tenable.
Le parcours de certification, du coup d’envoi à la surveillance
Analyse d’écarts et cadrage du SMIA (mois 1 à 2)
Les six à huit premières semaines fixent le périmètre de certification (quelle entité juridique, quelle unité, quels systèmes d’IA), conduisent l’analyse d’écarts contre les chapitres 4 à 10 et l’Annexe A, et constituent le backlog initial des politiques, procédures et artefacts à produire. La plupart des organisations profitent de cette phase pour choisir un organisme de certification accrédité. Les délais d’audit pour les premières certifications oscillaient entre deux et six mois en 2025 ; la réservation anticipée se justifie.
Audit Stage 1
Le Stage 1 est l’audit de documentation et de préparation. L’organisme certificateur passe en revue le périmètre du SMIA, la politique IA, les évaluations de risques et d’impact, la DdA et les procès-verbaux de revue de direction. D’après la synthèse Cloud Security Alliance sur le parcours de certification, le Stage 1 tient en un à deux jours pour une petite structure. Toute non-conformité majeure doit être levée avant le Stage 2.
Audit Stage 2
Le Stage 2 est l’audit d’efficacité opérationnelle. Les auditeurs échantillonnent les preuves par mesure de l’Annexe A, interrogent le responsable IA et les propriétaires de modèle, et vérifient que le SMIA fonctionne tel que documenté. La durée dépend de la taille et de la complexité : généralement une à trois semaines pour une structure de taille moyenne disposant de plusieurs systèmes d’IA. Le résultat est le certificat (en cas de succès) accompagné d’une liste de non-conformités mineures et d’observations.
Surveillance et recertification triennale
Le certificat est valable trois ans, avec des audits de surveillance annuels représentant environ un tiers de la durée de l’audit initial. La quatrième année déclenche un audit complet de recertification. Le retour d’expérience CSA sur les audits note que les constats les plus fréquents en surveillance portent sur des évaluations d’impact obsolètes et des procédures de retrait de modèles non appliquées.
Échéances réalistes
CSA et la plupart des organismes certificateurs convergent vers 6 à 12 mois de préparation pour une organisation au socle faible ou moyen, davantage si le périmètre est large ou si aucune autre certification de système de management (ISO 27001, ISO 9001) n’existe. Les structures déjà certifiées ISO 27001 divisent généralement par deux l’effort de rédaction de politiques, puisque les politiques, le programme d’audit interne et la revue de direction se réutilisent.
ISO 42001 dans le paysage réglementaire : ce qu’elle couvre et ce qu’elle ne couvre pas
Là où ISO 42001 recouvre le Règlement IA
Le recouvrement entre les chapitres d’ISO 42001 et les obligations « fournisseur » et « déployeur » du Règlement IA est important : gestion des risques, gouvernance des données, documentation technique, surveillance post-marché et supervision humaine. Plusieurs cartographies indépendantes placent ce recouvrement autour de 40 à 50 % des exigences substantielles du Règlement. Les normes européennes harmonisées en préparation sous mandat M/593 (la famille prEN 18228 du CEN-CENELEC) constituent le pont formel entre exigences essentielles du Règlement et présomption de conformité ; tant qu’elles ne sont pas publiées, ISO 42001 reste la charpente la plus mûre.
Les cinq écarts qui comptent
Un SMIA certifié, à lui seul, ne fournit pas :
- L’évaluation de conformité des systèmes à haut risque prévue à l’article 43 (contrôle interne ou évaluation par un organisme notifié selon le cas d’usage).
- Le filtrage des pratiques interdites prévu à l’article 5 (notation sociale, moisson non ciblée d’images faciales, certaines reconnaissances d’émotions).
- La transparence vis-à-vis des utilisateurs finaux prévue à l’article 50 (information lorsqu’une personne interagit avec une IA ou observe un contenu généré par IA).
- Le signalement des incidents graves à l’article 73, dans les délais imposés à l’autorité de surveillance du marché compétente.
- L’évaluation d’impact sur les droits fondamentaux prévue à l’article 27 pour les déployeurs de systèmes à haut risque, lorsqu’il s’agit d’organismes publics ou d’acteurs privés assurant un service d’intérêt général.
Une organisation peut détenir un certificat ISO 42001 valide tout en étant en infraction sur l’un de ces axes. La valeur du certificat est de faciliter la démonstration du reste ; il ne constitue pas une défense.
Cartographie avec NIST AI RMF
Le NIST AI Risk Management Framework 1.0 et ISO 42001 sont conçus pour interopérer. Les quatre fonctions cœur du NIST cartographient proprement : Govern s’aligne sur le chapitre 5 et une partie du chapitre 6 ; Map s’aligne sur les chapitres 4 et 6.1 ; Measure s’aligne sur les chapitres 8 et 9 ; Manage s’aligne sur les chapitres 8 et 10. Une organisation ayant sérieusement travaillé l’AI RMF récupère la plupart des artefacts ; le manque concerne en général l’énoncé formel de périmètre du SMIA, la DdA et la cadence auditable de revue de direction.
Pourquoi le certificat ne tient pas lieu de défense
Les autorités de surveillance du marché instituées par le Règlement IA n’acceptent pas « nous sommes certifiés ISO 42001 » en remplacement des obligations spécifiques du texte. Elles peuvent retenir le certificat comme indice d’une posture de gouvernance mûre, ce qui atténue la sanction lorsqu’une non-conformité mineure est constatée, mais les obligations légales restent testables une à une. Image à garder : ISO 42001 est une charpente qui facilite tout le reste ; pas une ligne d’arrivée.
Questions fréquentes
ISO 42001 est-elle obligatoire ? Non. ISO 42001 est une norme internationale volontaire. Aucune juridiction n’en impose la certification à ce jour. La demande vient des achats (grands comptes la réclamant à leurs fournisseurs), de la due diligence des investisseurs et de la valeur de preuve qu’elle offre sous des régimes comme le Règlement IA. Certains secteurs (banque, santé) pourraient l’ajouter à leurs questionnaires fournisseurs dans les dix-huit prochains mois, ce qui en ferait une exigence de facto pour les éditeurs.
Combien de temps prend une certification ISO 42001 ? Une préparation réaliste s’étend sur 6 à 12 mois pour une organisation partant d’un socle faible ou moyen, moins si vous détenez déjà ISO 27001 et pouvez réutiliser politiques, programme d’audit interne et cadence de revue de direction. L’audit lui-même tient en Stage 1 (un à deux jours) puis Stage 2 (une à trois semaines selon la taille). Du coup d’envoi au certificat, comptez généralement entre huit et quatorze mois.
Une organisation certifiée ISO 27001 peut-elle étendre son périmètre au SMIA ? Oui, et c’est la voie d’entrée la plus courante. Les deux normes partagent la Structure de Haut Niveau ; politiques, maîtrise documentaire, audit interne et revue de direction se réutilisent directement. Le travail à ajouter porte sur l’évaluation des risques et de l’impact IA, le jeu de mesures de l’Annexe A (notamment A.5, A.6, A.7) et les portes de cycle de vie des modèles. On voit régulièrement des systèmes de management intégrés couvrant ISO 27001 et ISO 42001 avec une revue de direction commune.
ISO 42001 couvre-t-elle spécifiquement l’IA générative ? La norme est technologiquement neutre, mais l’Annexe C énumère explicitement des risques propres à l’IA générative (hallucination, vulnérabilités d’injection de prompt, provenance des données d’entraînement, enjeux de propriété intellectuelle). L’Annexe D inclut des cas d’usage génératifs. Les organisations qui développent ou déploient de l’IA générative doivent s’attendre à une attention accrue des auditeurs sur A.7 (données) et A.8 (information des parties intéressées), où les obligations de transparence de l’IA générative pèsent le plus lourd.
ISO 42001 suffit-elle pour le Règlement IA ? Non. ISO 42001 couvre environ 40 à 50 % des exigences substantielles du Règlement et offre une solide charpente de gouvernance, mais elle ne fournit ni évaluation de conformité, ni filtrage des pratiques interdites, ni transparence pour l’utilisateur final, ni signalement des incidents graves, ni évaluation d’impact sur les droits fondamentaux. Les normes européennes harmonisées en préparation sous mandat M/593 seront le pont formel vers la conformité au Règlement. En attendant, traitez ISO 42001 comme la fondation, le Règlement comme l’obligation contraignante, et les EN harmonisées comme l’horizon d’alignement.
Qui peut auditer et certifier un SMIA ? Seuls les organismes de certification accrédités ISO 42001 par un organisme d’accréditation national reconnu (COFRAC en France, UKAS au Royaume-Uni, ANAB aux États-Unis, DAkkS en Allemagne, ACCREDIA en Italie, ENAC en Espagne, IPAC au Portugal). La liste des organismes accrédités s’est étoffée tout au long de 2025. Vérifiez que l’accréditation de l’organisme couvre explicitement ISO/IEC 42001, et pas seulement ISO/IEC 27001 ; tous n’ont pas encore étendu leur portée.
Conclusion
ISO 42001 est la première brique d’infrastructure de gouvernance de l’IA face à laquelle les organisations peuvent réellement être certifiées, et elle s’impose vite comme la langue commune de l’assurance IA. Traitée comme une charpente, elle organise toutes les autres obligations IA : elle offre au Règlement IA un point d’amarrage, absorbe le NIST AI RMF sans tension et oblige l’entreprise à nommer son IA. Traitée comme une ligne d’arrivée, elle déçoit, parce que le certificat ne se substitue jamais au travail de conformité légale qui doit se mener en parallèle.
Chez AI Sigil, nous traitons le SMIA comme un objet d’exploitation : un système vivant que la plateforme aide à faire tourner, pas un classeur que les auditeurs ouvrent une fois par an. Si vous cartographiez la place d’ISO 42001 par rapport au Règlement IA dans votre pile, l’article connexe ISO 42001 ne couvre pas l’AI Act : la vraie boîte à outils de conformité détaille le pont. Pour voir comment la plateforme AI Sigil opérationnalise le SMIA au quotidien, la visite de la plateforme est l’étape suivante.