Les mots de la norme,
et ce qu'ils engagent.

En France, l’autorité d’accréditation est le COFRAC ; aux États-Unis, l’ANAB ; au Royaume-Uni, l’UKAS. Pour ISO/IEC 42001, les exigences applicables aux organismes certificateurs sont fixées par ISO/IEC 42006, publiée en juillet 2025.

Un certificat délivré hors accréditation n’a pas la même valeur. Accrédité par qui, et pour quelle norme : c’est la première question à poser à un organisme.

Normative ne veut pas dire intégralement obligatoire. L’organisation compare les mesures issues de son traitement des risques à ce catalogue, pour vérifier qu’elle n’a rien omis, puis justifie chaque inclusion et chaque exclusion dans sa déclaration d’applicabilité.

La liste n’est pas exhaustive : l’organisation peut ajouter ses propres mesures.

On la dit souvent informative : c’est faux. Seules les Annexes C et D le sont.

Son statut normatif ne crée pas pour autant d’obligation nouvelle. L’auditeur ne vérifie pas chaque recommandation une à une ; il s’en sert pour juger si une mise en œuvre est raisonnable. C’est souvent la meilleure source pour savoir quelles preuves un contrôle réclame.

Le certificat vaut trois ans, avec des audits de surveillance annuels, puis un audit de renouvellement.

Il ne prouve ni qu’un modèle est fiable, ni qu’une réglementation est respectée : ISO/IEC 42001 ne confère aucune présomption de conformité à l’AI Act. Un « produit certifié ISO 42001 » est un abus de langage.

Contrairement aux contrôles de l’Annexe A, que la déclaration d’applicabilité permet d’écarter sur justification (6.1.3 f), elles ne se sélectionnent pas : la norme ne prévoit aucun moyen d’en retirer une. Leur portée se module en revanche. Plusieurs ne jouent que lorsque la situation s’y prête (7.2, 7.5.3, 9.1, 10.2 a)), et une note de 4.1 signale que les rôles tenus vis-à-vis des systèmes d’IA peuvent peser sur l’applicabilité des exigences comme sur son étendue. Elles s’adaptent aussi à la taille et au contexte de l’organisation : exiger une revue de direction ne dit ni sa forme, ni sa durée.

Les clauses 1 à 3 — domaine d’application, références normatives, termes et définitions — posent le cadre et le vocabulaire plus que des obligations de mise en œuvre. Deux nuances. La clause 2 donne valeur d’exigence au contenu d’ISO/IEC 22989 auquel la norme renvoie. Surtout, la note 2 de la définition 3.26, déclaration d’applicabilité, est rédigée en « shall » : elle attend que les risques identifiés soient documentés, et que la déclaration les fasse apparaître avec les contrôles retenus pour y répondre. Les définitions de la clause 3 s’imposent par ailleurs pour interpréter tout le reste.

L’Annexe A en propose 38, regroupés sous 10 objectifs de contrôle. Un objectif n’est pas un contrôle : dans le Tableau A.1, chaque domaine s’ouvre sur son objectif, énoncé sans numéro, et le premier contrôle porte le numéro .2 — A.2.2, A.3.2. C’est l’Annexe B qui numérote l’objectif en .1 (B.2.1). Le domaine A.6 en compte deux, un par sous-domaine.

Citer « le contrôle A.2.1 » est une erreur fréquente, y compris dans des documents d’acteurs spécialisés.

Elle relève de la clause 6.1.3 f), et non de la clause 6.3, qui traite de la planification des changements : la confusion circule largement.

C’est l’un des documents les plus examinés en audit, parce qu’il relie le catalogue de contrôles au registre des risques. Pour motiver une exclusion, la norme cite deux appuis, sans en faire une liste fermée : une appréciation des risques qui ne rend pas le contrôle nécessaire, et l’absence d’exigence externe applicable qui l’imposerait, ou l’exception que celle-ci prévoit. Une justification solide examine les deux ; un « non pertinent » sans autre motif ne tient pas.

ISO/IEC 42001 en est une, comme ISO 9001 pour la qualité ou ISO/IEC 27001 pour la sécurité de l’information. C’est pourquoi elle ne contient ni seuil technique, ni métrique imposée, ni méthode de risque obligatoire : elle exige que l’organisation définisse les siens, les applique et puisse le démontrer.

Seul « shall » crée un point de conformité : un écart est une non-conformité. Les clauses 4 à 10 sont rédigées en « shall », l’Annexe B en « should ». Les versions françaises rendent en général le premier par « doit » et le second par « il convient de ».

En principe, les notes et les exemples éclairent sans rien imposer : ils illustrent ou orientent, sans créer de point de conformité. La norme comporte une exception à connaître : la note 2 de la définition 3.26, déclaration d’applicabilité, est rédigée en « shall » ; à la lettre, elle attend que les risques identifiés soient documentés et que la déclaration les fasse apparaître avec les contrôles qui y répondent. Une note peut par ailleurs peser lourd en pratique : celle de la clause 4.1, qui cite les rôles possibles, signale que ces rôles peuvent influer sur l’applicabilité des exigences et des contrôles, et sur son étendue.

Longtemps désignée sous le nom d’Annexe SL, c’est elle qui permet d’intégrer ISO/IEC 42001 à un système ISO/IEC 27001 ou ISO 9001 existant : documentation, audit interne, revue de direction et traitement des non-conformités se mutualisent.

Elle aligne les contenants, pas les contenus. La clause 6 porte le même nom dans 27001 et dans 42001, mais on n’y apprécie pas le même risque.

La clause 10 ne compte que deux sous-clauses, 10.1 et 10.2. Les références à une « clause 10.3 » ou à une « clause 10.4 incidents » viennent de sources erronées : ces numéros n’existent pas.

Il n’impose pas de recourir à un prestataire : un collaborateur peut auditer, à condition de ne pas auditer son propre travail.

Le programme se pondère : les processus les plus importants, et ceux où les audits précédents ont trouvé des écarts, sont audités plus souvent. En pratique, les organismes certificateurs attendent qu’un audit interne ait été réalisé et ses constats traités avant l’audit de certification. C’est l’une des preuves que le système tourne déjà.

La clause 4.1 y ajoute une exigence propre à ISO/IEC 42001 : déterminer le ou les rôles que l’organisation tient vis-à-vis des systèmes d’IA. C’est cette détermination qui commande l’étendue de tout le reste.

La norme n’impose aucun outil : un wiki, un outil de tickets ou une gestion documentaire peuvent convenir, à condition d’y assurer ce que demande la clause 7.5. À la création comme à la mise à jour, trois points se vérifient : une relecture qui en valide la pertinence, un format et un support adaptés à l’usage, et de quoi l’identifier et la décrire. Ensuite, l’information doit être protégée comme il convient et se trouver là où l’on en a besoin, dans un état qui permette de s’en servir. Selon ce qui s’applique s’y ajoutent la façon dont elle circule — diffusion, droits d’accès, récupération, utilisation — et celle dont elle dure : un stockage qui en préserve la lisibilité, la maîtrise des modifications dont le versionnage, des règles de conservation et d’élimination. Les documents d’origine externe jugés nécessaires au système sont, eux aussi, repérés et maîtrisés.

L’écueil inverse de l’absence de preuve est l’inflation documentaire : des procédures que personne n’applique, et que l’auditeur confronte à la réalité.

Corriger l’écart ne suffit pas : la clause 10.2 fait examiner ce qui s’est passé, en déterminer les causes et chercher si des écarts semblables existent ou pourraient survenir, puis décider s’il faut agir sur ces causes — et vérifier ensuite l’efficacité de toute action corrective engagée.

En audit de certification, on distingue les non-conformités majeures, qui peuvent empêcher la certification, des mineures. Un incident lié à l’IA n’est pas, en soi, une non-conformité : la norme en aborde la prise en charge à propos de l’exploitation des systèmes (contrôle A.6.2.6, que l’Annexe B prolonge par des recommandations sur les réparations, le support et la remontée des incidents), et elle permet de l’intégrer à la gestion des incidents déjà en place. Elle en fait planifier l’annonce aux utilisateurs au contrôle A.8.4. La clause 10.2 n’entre en jeu que lorsque l’incident révèle une exigence non satisfaite.

Un objectif utile dit quoi, avec quels moyens, qui, quand, et comment on saura qu’il est atteint : ce sont les cinq points que la clause 6.2 fait déterminer pour planifier son atteinte. « Utiliser l’IA de façon responsable » est une intention ; « réaliser l’évaluation d’impact de chaque système avant sa mise en production » est un objectif.

L’Annexe C, informative, propose des familles d’objectifs dont s’inspirer : équité, transparence, robustesse, sécurité, entre autres.

La clause 4.2 demande d’identifier celles qui comptent pour le système de management, leurs attentes pertinentes, et celles de ces attentes que le système prendra en charge.

L’oubli le plus courant : les personnes soumises à l’IA. Elles ne contractent avec personne, et elles sont pourtant au cœur de l’évaluation d’impact.

Un périmètre trop large multiplie la charge ; un périmètre trop étroit produit un certificat que personne ne prend au sérieux.

L’exercice a un bénéfice immédiat : le construire oblige à inventorier les systèmes d’IA réellement utilisés, et beaucoup d’organisations y découvrent des usages que rien n’encadrait.

Elle est établie par la direction et documentée. Une politique qui énumère des valeurs sans offrir de cadre pour fixer les objectifs IA, ni engager l’organisation à respecter les exigences applicables et à améliorer son système de management, ne satisfait pas la clause 5.2. Prévoir sa revue périodique relève du contrôle A.2.4 ; en confier la charge à un rôle désigné est une recommandation de l’Annexe B.

Elle se lit aussi avec les autres politiques de l’organisation, sécurité de l’information ou données personnelles, avec lesquelles elle doit rester cohérente.

Ce qui s’audite n’est pas la tenue de la réunion, mais ce qui en sort : des décisions d’amélioration, des changements, des moyens alloués. Une revue de direction sans décision est un signal que l’auditeur relève.

Elle relève de la clause 7.3. La communication est la 7.4, la compétence la 7.2 — l’inversion de 7.3 et 7.4 est l’une des erreurs de citation les plus répandues.

Sensibiliser n’est pas former. La compétence porte sur la capacité à faire ; la sensibilisation, sur la conscience de ce qui est en jeu.

Un système de management n’est ni un logiciel, ni un classeur de procédures. C’est une manière de fonctionner qui doit être démontrable : des décisions tracées, des revues qui ont lieu, des écarts qui sont traités.

L’erreur fréquente consiste à produire les documents sans le fonctionnement. L’audit de certification le fait apparaître, parce qu’il cherche des traces d’exploitation et pas seulement des procédures.

Elle se définit en 6.1.2 et se réalise en 8.2, à intervalles planifiés et lors de changements importants.

On la présente souvent comme tournée vers la seule organisation : c’est inexact, puisqu’elle doit apprécier les conséquences des risques pour les individus et la société. Ce qui la distingue de l’évaluation d’impact, c’est son angle — le portefeuille de risques de l’organisation, à partir de ses objectifs —, là où l’évaluation d’impact part de chaque système. Les résultats de la seconde doivent alimenter la première.

Une organisation qui se contente d’élargir son registre de sécurité de l’information obtient un registre muet sur la discrimination ou les effets sociétaux.

Elle est obligatoire : la clause 6.1.4 en exige le processus, la clause 8.4 sa réalisation à intervalles planifiés et lorsqu’un changement significatif est envisagé. La présenter comme une bonne pratique facultative est une erreur répandue.

Ses contrôles associés sont ceux du domaine A.5, pas d’A.8. Elle ne se confond pas non plus avec l’analyse d’impact sur les droits fondamentaux de l’AI Act, qui a son propre périmètre et sa propre obligation de notification.

C’est au cours du traitement que l’organisation compare ses contrôles à l’Annexe A et établit sa déclaration d’applicabilité, en 6.1.3 f).

Accepter un risque est une réponse légitime, à condition que la décision soit approuvée : la norme fait valider par la direction désignée le plan de traitement des risques et l’acceptation des risques résiduels. La trace écrite se joue ailleurs — informations conservées sur le processus de traitement (6.1.3), puis sur les résultats obtenus (8.3).

La norme ne fixe ni seuil, ni métrique : elle attend que l’organisation surveille ses systèmes en exploitation et sache ce qui déclenche une action.

Une dérive ne se lit pas toujours dans les indicateurs techniques. Un changement d’usage peut dégrader les décisions sans qu’aucun score ne bouge.

Dans ISO/IEC 42001, l’enregistrement des journaux relève du contrôle A.6.2.8, qui peut être écarté avec justification. L’AI Act impose au contraire aux systèmes à haut risque une journalisation automatique et la conservation des journaux.

Une exclusion d’A.6.2.8 ne se joue donc pas sur le seul terrain de la norme : parmi les éléments qu’une justification d’exclusion peut comprendre, la norme cite le cas où aucune exigence externe applicable n’impose le contrôle, et l’Annexe B rappelle que certains systèmes portent des obligations de journalisation propres à leur juridiction. Pour un système à haut risque, la journalisation imposée par le règlement rend cette exclusion très difficile à justifier.

Elle relève du contrôle A.7.4, qui fait définir des exigences de qualité et s’assurer que les données servant à développer comme à exploiter le système y satisfont. Le domaine A.4 ne l’ignore pas pour autant : parmi ce qu’il faut documenter sur les données comme ressource, l’Annexe B cite leur qualité. Mais c’est A.7.4 qui porte l’exigence.

La norme n’exige pas des données parfaites, mais des critères écrits et vérifiés : un critère non écrit ne s’audite pas. Et la qualité se juge toujours au regard d’un usage — des données adaptées à l’entraînement d’un modèle peuvent ne pas l’être à son évaluation.

Les rôles se cumulent, et se déterminent système par système. Ils ne coïncident pas avec les catégories de l’AI Act : pour le règlement, le déployeur est celui qui utilise un système sous sa propre autorité, alors que dans la note de la clause 4.1, les déployeurs d’IA sont une sous-catégorie des producteurs.

La qualification au sens de la norme n’a aucun effet juridique.

ISO/IEC 42001 s’appuie pour ce terme sur le vocabulaire d’ISO/IEC 22989. L’AI Act a sa propre définition, à l’article 3, qui insiste sur l’autonomie du système et sur sa capacité à déduire de ses entrées comment produire ses résultats.

Les deux se recoupent largement sans être identiques. La qualification juridique suit la définition du règlement, précisée par les lignes directrices de la Commission publiées en février 2025.

Il n’a pas le même objet qu’ISO/IEC 42001 : le règlement vise chaque système d’IA et chaque modèle à usage général, la norme vise l’organisation.

Ses obligations s’appliquent par étapes. Celles des systèmes à haut risque ont été reportées par le règlement (UE) 2026/1744, publié en juillet 2026.

Elle concerne les organismes de droit public, les entités privées qui fournissent un service public, et les déployeurs de systèmes d’évaluation du crédit ou de tarification d’assurance vie et santé.

Elle ressemble à l’évaluation d’impact d’ISO/IEC 42001 sans s’y substituer : son contenu est fixé par le règlement, et sa notification à l’autorité est une obligation légale que la norme ne crée pas. ISO/IEC 42001 ignore d’autant moins ce type d’obligation qu’elle en fait, au contrôle A.8.5, un objet à recenser et à documenter ; l’Annexe B range d’ailleurs les résultats d’évaluations d’impact parmi les informations qu’une juridiction peut demander de transmettre aux autorités. Elle peut en revanche s’appuyer sur l’analyse d’impact relative à la protection des données déjà réalisée au titre du RGPD.

La qualification se fait système par système, et elle peut basculer : un déployeur qui appose sa marque sur un système à haut risque, le modifie substantiellement ou en change la destination en devient le fournisseur, au titre de l’article 25.

Ces catégories juridiques ne sont pas les rôles de la clause 4.1 d’ISO/IEC 42001.

ISO/IEC 42001 n’en est pas une, et sa reprise européenne, EN ISO/IEC 42001:2026, non plus.

La présomption de conformité à l’AI Act ne naît qu’avec la publication d’une référence au Journal officiel. Les normes européennes écrites pour le règlement, EN 18286 en tête, sont les candidates à ce statut.

L’annexe III vise notamment la biométrie, les infrastructures critiques, l’éducation, l’emploi, l’accès au crédit et aux services essentiels, la répression, les migrations et la justice.

Un système relevant de l’annexe III peut échapper à la qualification s’il ne présente pas de risque important — par exemple lorsqu’il accomplit une tâche procédurale étroite —, sauf s’il réalise un profilage de personnes. Le fournisseur qui s’en prévaut doit documenter son analyse.