Blog
•
16 min de lecture
Pour une entreprise multi-entités, le parcours ISO/IEC 42001 part d’une décision de périmètre au titre de l’article 4.3, passe par l’analyse d’écarts, la conception de l’AIMS, la mise en œuvre des contrôles et l’audit interne, et aboutit à un audit de certification en deux étapes, puis à un cycle de trois ans avec surveillance annuelle. À l’échelle d’un groupe, cette séquence prend 12 à 24 mois, et la décision de périmètre en détermine l’essentiel.
Où commence le parcours ISO 42001 pour une entreprise multi-entités ?
Il commence par le périmètre, pas par une analyse d’écarts. L’ISO/IEC 42001:2023, publiée le 18 décembre 2023, impose à l’organisme de déterminer les limites de son système de management de l’IA à l’article 4.3, « Détermination du domaine d’application du système de management de l’IA », après avoir pris en compte son contexte (article 4.1) et les besoins des parties intéressées (article 4.2). Tout ce qui suit, de la déclaration d’applicabilité au nombre de jours d’audit, est chiffré sur cette base.
Les certificats publics montrent à quel point les plus grands fournisseurs d’IA le définissent de façon restreinte. Le certificat d’Anthropic, annoncé le 13 janvier 2025, couvre « notre système de management de l’IA ». Celui d’IBM, annoncé le 1er octobre 2025, couvre « le système de management de l’IA (AIMS) d’IBM Granite », soit une seule famille de modèles. Celui de Microsoft énumère neuf services nommément désignés. Aucun n’a certifié « l’entreprise ».
Un groupe présent dans plusieurs juridictions doit tracer une seconde limite. Selon l’IAF MD 1:2023, un certificat multisite exige « un système de management unique comprenant une fonction centrale identifiée » qui « contrôle le système de management de manière centralisée ». Tous les sites doivent relever du programme d’audit interne de l’organisme et d’une revue de direction centralisée et, lorsque les sites peuvent faire l’objet d’un échantillonnage, l’audit initial porte sur un nombre de sites égal à la racine carrée du nombre total de sites, arrondie à l’entier supérieur. Un groupe incapable de désigner la fonction centrale de son AIMS ne dispose pas encore d’un périmètre certifiable.
Avec des centaines de modèles, comment décider de ce qui entre dans le périmètre de l’AIMS ?
L’organisme décide-t-il de la manière dont le système est construit ou utilisé, ou se contente-t-il d’en consommer un résultat ? Les résultats du système atteignent-ils les parties intéressées identifiées au titre de l’article 4.2 ? L’organisme peut-il produire des preuves pour les mesures de l’annexe A qu’il déclarera applicables ? Un système qui ne passe pas le premier test relève généralement d’une relation fournisseur, et non d’un système d’IA inclus dans le périmètre ; celui qui ne passe pas le troisième est dans le périmètre, mais pas encore prêt.
La distinction entre un système d’IA inclus dans le périmètre et une partie intéressée est celle sur laquelle les grands parcs de modèles se trompent le plus souvent. Un modèle de fondation consommé via l’API d’un éditeur n’est pas un système que l’entreprise peut auditer. L’éditeur est une partie intéressée et un fournisseur ; l’application que l’entreprise a construite dessus, avec ses prompts, ses garde-fous et sa supervision humaine, est le système d’IA inclus dans le périmètre. L’inventaire IA doit contenir les deux fiches et le lien qui les relie, car l’auditeur demandera ce qui change lorsque l’éditeur modifie le modèle de base.
Catégorie | Exemple | Décision de périmètre en première vague | Ce que l’auditeur examinera |
|---|---|---|---|
Modèles que le groupe développe et exploite dans un circuit de décision | Modèles de crédit, de souscription, de sinistres et de tarification | Dans le périmètre, système par système | Responsable, dossiers de cycle de vie, évaluations des risques et d’impact, surveillance |
Applications construites sur le modèle de fondation d’un éditeur | Assistant interne avec recherche dans les documents de politique interne | Dans le périmètre en tant que système de l’entreprise ; éditeur enregistré comme fournisseur | Contrôles des fournisseurs, notification des changements, évaluation par rapport à la version du modèle de base |
IA intégrée dans des SaaS sous licence | Scoring de leads dans le CRM, comptes rendus de réunion dans les outils collaboratifs | Dans l’inventaire, hors du périmètre certifié, sauf si elle détermine une décision concernant des personnes | Justification documentée de l’exclusion, évaluation du fournisseur, usage acceptable |
IA que le groupe vend à ses clients ou intègre dans ses offres | Modèle d’éditeur revendu dans un produit destiné aux clients | Dans le périmètre ; le groupe est le fournisseur | Transparence envers les clients, information des parties intéressées, gestion des incidents |
Expérimentations et notebooks hors production | Bacs à sable de data science | Hors périmètre, avec un point de contrôle du cycle de vie qui intègre les systèmes lors de leur déploiement | Preuve que le point de contrôle existe et se déclenche |
Modèles statistiques historiques relevant de la gestion du risque de modèle | Modèles de capital, de liquidité et de stress test | Point de décision : exclure avec une frontière documentée vis-à-vis du MRM, ou inclure et reprendre les preuves du MRM | Une frontière écrite cohérente avec l’inventaire de gestion du risque de modèle |
Agents disposant d’un accès à des outils | Agent qui lit et écrit dans un système d’enregistrement | Dans le périmètre lorsqu’il agit sur un système inclus dans le périmètre | Gestion des habilitations, déclencheurs de supervision humaine, mécanisme d’arrêt |
Entités dans d’autres juridictions | Une filiale disposant de sa propre équipe IA | Périmètre par entité juridique et par site ; la première vague couvre les entités que la fonction centrale contrôle | Autorité de la fonction centrale, couverture de chaque site par l’audit interne |
Ce tableau est une position de départ, pas une règle de la norme. Chaque exclusion doit reposer sur une justification écrite qui tiendrait si on la lisait à voix haute devant un régulateur, et l’inventaire doit consigner les systèmes exclus comme les systèmes inclus, afin que l’exclusion soit visible à chaque audit de surveillance.
À quoi ressemble le parcours, de l’analyse d’écarts à la surveillance, et combien de temps dure chaque étape ?
L’ISO/IEC 17021-1, la norme à laquelle les organismes d’accréditation soumettent les organismes de certification, en fixe la mécanique. L’étape 1 examine la documentation et l’état de préparation ; l’étape 2 évalue « la mise en œuvre, y compris l’efficacité, du système de management du client ». Les audits de surveillance ont lieu « au moins une fois par année civile, sauf les années de renouvellement de la certification », et « le premier cycle de certification de trois ans commence avec la décision de certification ».
Les durées ci-dessous sont des fourchettes de planification pour un groupe comptant plusieurs entités juridiques et des centaines de modèles, et non des chiffres issus de la norme ; un organisme déjà certifié ISO/IEC 27001 se situera dans le bas de la plupart des fourchettes. Le guide de mise en œuvre de la norme ISO 42001 d’Enzai détaille le contenu de chaque étape ; ce tableau en présente l’enchaînement et la durée.
Étape | Ce qui se passe | Fourchette de planification (grande entreprise) |
|---|---|---|
Décision de périmètre | Entités, sites, fonction centrale et systèmes d’IA désignés ; exclusions rédigées ; rôles consignés pour chaque système | 6 à 12 semaines |
Analyse d’écarts | Articles 4 à 10 et mesures de l’annexe A applicables comparés aux pratiques actuelles, entité par entité | 6 à 10 semaines |
Conception de l’AIMS | Politique IA, méthodes d’évaluation des risques et d’impact, rôles, déclaration d’applicabilité, plan de compétences | 2 à 4 mois |
Mise en œuvre des contrôles et preuves | Contrôles opérationnels sur chaque système du périmètre ; preuves rattachées au système et à la version | 4 à 9 mois |
Audit interne et revue de direction | Audit indépendant de chaque site du périmètre ; non-conformités corrigées ; revue par la direction | 6 à 10 semaines |
Audit d’étape 1 | Examen de la documentation et de l’état de préparation ; constats traités avant l’étape 2 | 1 à 3 jours sur site, 4 à 8 semaines pour clore les constats |
Audit d’étape 2 | Audit de la mise en œuvre sur les sites échantillonnés ; décision de certification ensuite | 1 à 3 semaines de jours d’audit, décision 4 à 8 semaines plus tard |
Surveillance | Audit annuel ; le premier dans les 12 mois suivant la décision de certification | Récurrent |
Renouvellement de la certification | Audit complet avant l’expiration du certificat au bout de trois ans | Année 3 |
Au total, une première vague prend 12 à 24 mois, et la variable qui pèse le plus n’est pas le nombre de modèles, mais le nombre d’entités dont les preuves doivent atteindre le même niveau d’exigence.
Qui peut certifier un AIMS, et l’accréditation compte-t-elle ?
L’ISO/IEC 42006:2025, publiée en juillet 2025, fixe les exigences applicables aux organismes qui auditent et certifient les systèmes de management de l’IA, en complément de l’ISO/IEC 17021-1. L’ANAB indique qu’elle « accrédite les organismes de certification qui délivrent des certifications ISO/IEC 42001 » et fait référence à la 42006 dans son programme ; le certificat d’Anthropic de janvier 2025 a été délivré par un organisme accrédité par l’ANAB, l’accréditation ANAB est donc antérieure à la 42006. L’UKAS a accordé sa première accréditation AIMS au BSI, annoncée en janvier 2026 ; le communiqué du BSI lui-même, daté du 17 novembre 2025, mentionne également une accréditation par l’organisme néerlandais RvA.
Un certificat ne vaut que ce que vaut l’organisme qui l’a délivré. Un acheteur, ou un client qui évalue cet acheteur, doit demander quel organisme d’accréditation figure sur le certificat, si cette accréditation mentionne explicitement l’ISO/IEC 42001 et ce que couvre la déclaration de périmètre.
Combien de temps avant que l’ISO 42001 devienne une attente du marché ?
Il n’existe aucun décompte des certificats qui fasse autorité ; l’ISO Survey ne suit pas l’ISO/IEC 42001. La réponse honnête repose sur quatre indicateurs observables qui vont dans des directions différentes.
Les annonces publiques se concentrent du côté de l’offre. Anthropic, IBM et Microsoft ont fait certifier leurs propres produits d’IA, et un nombre croissant d’éditeurs technologiques ont suivi. Une entreprise qui achète de l’IA devra vérifier des certificats avant qu’on lui demande d’en détenir un.
Les questionnaires de sécurité comportent déjà des questions calquées sur l’ISO 42001. L’AI Controls Matrix de la Cloud Security Alliance, publiée le 9 juillet 2025, compte 243 objectifs de contrôle mis en correspondance avec l’ISO 42001, le NIST AI RMF et l’EU AI Act, accompagnés d’un questionnaire que les clients peuvent adresser à leurs fournisseurs. Une entreprise qui vend des services intégrant de l’IA doit dès maintenant s’attendre à retrouver ces questions dans les évaluations que lui soumettent ses clients.
Les marchés publics ne l’ont pas rendue obligatoire. Le Department for Science, Innovation and Technology britannique a mené une consultation sur un outil, AI Management Essentials, fondé sur l’ISO/IEC 42001, puis a déclaré dans sa réponse de décembre 2025 qu’il « ne publiera pas AIME et n’en fera donc pas une exigence du processus de marchés publics ».
La réglementation ne l’exige pas non plus. L’EU AI Act ne mentionne pas l’ISO 42001, et aucune des autorités de supervision présentées dans l’entrée du glossaire d’Enzai consacrée à la gouvernance de l’IA dans les services financiers ne l’impose. Pour un déployeur réglementé, un AIMS certifié est une forme de preuve au regard des attentes en matière de gouvernance, pas une obligation.
La mesure utile est interne. Comptez chaque trimestre les appels d’offres, revues de sécurité et demandes des régulateurs qui portent sur l’ISO 42001 ; lorsque ce nombre augmente, l’attente est là.
La certification ISO 42001 permet-elle de satisfaire à l’EU AI Act ?
Non. La présomption de conformité prévue à l’article 40 du règlement sur l’IA s’attache aux normes harmonisées dont les références sont publiées au Journal officiel de l’Union européenne, et l’ISO/IEC 42001 n’en fait pas partie. Les travaux sont menés par le CEN-CENELEC JTC 21 dans le cadre de la demande de normalisation M/593 et de sa modification M/613 ; en octobre 2025, le CEN et le CENELEC ont adopté des mesures d’accélération visant à disposer des normes clés d’ici le quatrième trimestre 2026.
Le premier livrable est arrivé, et ce n’est pas l’ISO 42001. L’EN 18286:2026, « Quality Management System for EU AI Act Regulatory Purposes », a été publiée en juillet 2026 pour couvrir le système de gestion de la qualité prévu à l’article 17 pour les fournisseurs de systèmes d’IA à haut risque. Il s’agit d’une norme européenne conçue à cet effet et, à la date de rédaction, aucun livrable du JTC 21 n’a été cité au Journal officiel : aucun ne confère donc encore de présomption de conformité. La gestion des risques (prEN 18228), la journalisation (prEN 18229-1) et la cybersécurité (prEN 18282) étaient encore au stade de l’enquête en juillet 2026.
Les échéances n’attendent plus les normes. Le règlement (UE) 2026/1744, l’omnibus numérique sur l’IA, est entré en vigueur le 27 juillet 2026 ; la page de la Commission consacrée au règlement sur l’IA indique désormais le 2 décembre 2027 pour les systèmes à haut risque de l’annexe III et le 2 août 2028 pour les systèmes de l’annexe I, que des normes harmonisées soient disponibles ou non. Le guide de conformité à l’EU AI Act d’Enzai présente le calendrier complet des échéances. Un AIMS certifié atteste d’un système de management ; la conformité d’un système d’IA à haut risque se démontre obligation par obligation, un travail que la page solution EU AI Act traite séparément.
Où les preuves ISO 42001 recoupent-elles l’EU AI Act et le NIST AI RMF, et où ne les recoupent-elles pas ?
Le recoupement se situe au niveau du système de management, et la table de correspondance du NIST entre l’AI RMF et l’ISO/IEC 42001 (établie sur le projet final) fait par exemple correspondre le périmètre de l’article 4.3 à MAP 3.3, « le périmètre d’application ciblé est spécifié et documenté ». Une entreprise qui structure son programme à l’aide des profils NIST peut réutiliser l’essentiel de ses preuves GOVERN pour les articles 5 et 7.
Élément de preuve | ISO/IEC 42001 | EU AI Act | NIST AI RMF |
|---|---|---|---|
Politique IA, rôles, engagement de la direction | Article 5 | Alimente le système de gestion de la qualité de l’article 17 pour les fournisseurs | GOVERN |
Évaluation et traitement des risques liés à l’IA | Articles 6.1.2, 6.1.3, 8.2, 8.3 | Gestion des risques de l’article 9, par système à haut risque | MAP, MEASURE, MANAGE |
Évaluation de l’impact du système d’IA | Articles 6.1.4, 8.4 | Analyse d’impact sur les droits fondamentaux de l’article 27, uniquement pour certains déployeurs | MAP |
Contrôles des fournisseurs et des clients | Mesures de l’annexe A relatives aux tiers et aux clients | Obligations des fournisseurs et des déployeurs tout au long de la chaîne de valeur | GOVERN, MANAGE |
Documentation technique conforme à l’annexe IV, évaluation de la conformité, marquage CE, enregistrement dans la base de données de l’UE | Non couvert | Requis pour les systèmes d’IA à haut risque | Non couvert |
Obligations de transparence de l’article 50, obligations relatives aux modèles d’IA à usage général | Non couvert | Requis quel que soit le statut de l’AIMS | Partiellement, via le Generative AI Profile |
C’est là où il n’y a pas de recoupement que se situe le coût. L’ISO 42001 demande si un processus documenté et efficace existe ; le règlement sur l’IA exige un livrable précis pour un système précis, selon un modèle précis, à une date précise. Une évaluation d’impact qui satisfait un auditeur AIMS n’est pas forcément l’analyse de l’article 27 qu’un déployeur relevant de l’annexe III doit réaliser. La correspondance qui fait gagner du temps se situe au niveau des preuves : une évaluation des biais menée sur une version de modèle identifiée constitue un seul livrable qui sert à la fois l’article 8 de l’ISO 42001, l’article 9 du règlement et MEASURE. Le module Cadres de conformité d’Enzai repose sur ce principe, avec des preuves « collectées une fois, utilisées pour tous les audits » et un score de conformité par système et par référentiel.
Que faut-il préparer avant de déployer une plateforme de gouvernance pour l’ISO 42001 ?
La question du déploiement est en réalité une question de périmètre : une plateforme ne peut cartographier que ce qu’on lui fournit.
La liste des entités juridiques et des sites de la première vague, avec la fonction centrale désignée.
Un export de l’inventaire indiquant, pour chaque système, le responsable, la finalité, la référence du modèle ou de l’éditeur, l’étape du cycle de vie, la juridiction et le degré d’autonomie. L’inventaire IA d’Enzai combine la détection de l’IA, les imports depuis les plateformes et les demandes de cas d’usage, et classe les systèmes par niveau selon le cas d’usage, l’autonomie, la sensibilité des données et l’exposition aux clients, ce qui renseigne la plupart de ces champs pour les systèmes que personne n’a déclarés.
Le rôle que joue l’entreprise pour chaque système : concepteur, client d’un système d’éditeur ou fournisseur auprès de ses propres clients.
Les livrables ISO/IEC 27001 réutilisables, l’inventaire de gestion du risque de modèle et la frontière MRM formalisée par écrit.
Les contrats avec les fournisseurs d’IA, en ayant repéré les clauses relatives à la notification des changements de modèle et aux sous-traitants ultérieurs.
Une entreprise qui dispose de ces éléments se situe au niveau du modèle de maturité de la gouvernance où la certification n’est plus qu’un exercice de formalisation. Celle qui en est dépourvue a son premier constat avant même le début de l’analyse d’écarts.
Ce que cela implique sur le plan opérationnel
Désignez la fonction centrale et les entités de la première vague avant de commander une analyse d’écarts. Consignez, pour chaque système d’IA de l’inventaire, s’il est dans le périmètre certifié, exclu avec justification, ou s’il relève d’une relation fournisseur.
Consignez le rôle de l’entreprise pour chaque système et reliez chaque application fondée sur un modèle d’éditeur à la fiche de l’éditeur.
Rattachez les preuves aux systèmes et aux versions, et non aux articles, et faites correspondre chaque livrable à tous les référentiels qu’il satisfait, afin que rien ne soit produit deux fois pour l’EU AI Act ou le NIST AI RMF.
Choisissez l’organisme de certification en fonction du périmètre de son accréditation et vérifiez la formulation du certificat ; les clients lisent la déclaration de périmètre plus attentivement que le logo.
Suivez chaque trimestre la demande entrante pour le certificat, et menez les travaux liés à l’annexe III de l’EU AI Act en visant le 2 décembre 2027, comme un chantier distinct que l’AIMS soutient sans le remplacer.
Pour découvrir comment Enzai structure le périmètre, les preuves et la correspondance entre référentiels d’un programme ISO 42001, commencez par la page solution ISO 42001 ou échangez avec l’équipe Enzai.
Certifié ISO 27001 depuis 2023, audité chaque année par NQA
Traitement des données aligné sur le RGPD
Données clients hébergées sur AWS dans plusieurs régions
Utilisez votre propre modèle d’IA via une connexion privée
Identifiez l’IA utilisée par vos équipes, examinez-la avant sa mise en service, évaluez-la au regard des règles applicables et contrôlez ce que les agents peuvent faire. Conçu pour les organisations réglementées.