ISO/IEC 42001:2023 n’est pas une norme de performance algorithmique. Elle ne fixe ni seuil universel d’exactitude, ni architecture de référence, ni méthode unique d’entraînement. Son objet est le système de management par lequel une organisation encadre le développement, la fourniture ou l’utilisation de systèmes d’intelligence artificielle.
Cette distinction déplace immédiatement la difficulté. Un modèle peut être correctement évalué sur un jeu de test et demeurer insuffisamment gouverné. À l’inverse, un corpus documentaire abondant peut donner l’apparence d’un système de management sans établir que les responsabilités sont exercées, que les changements sont autorisés ou que les incidents modifient effectivement les mesures de maîtrise.
La question centrale d’ISO 42001 n’est donc pas seulement : « le système d’IA fonctionne-t-il ? ». Elle est aussi : « quelle organisation décide de sa finalité, de ses conditions d’emploi, de ses limites, de son acceptation et de son retrait, et sur quelles preuves ? »
La lecture croisée des clauses 4 à 10, des annexes A à D et des dispositions pertinentes de l’AI Act montre que les premiers obstacles se situent dans l’architecture de responsabilité, la qualification juridique des rôles, la gestion des interfaces et la continuité de la preuve.
ISO 42001 ne certifie pas un algorithme : elle évalue un système de management
ISO 42001 reprend la structure harmonisée des normes de système de management. Les clauses 4 à 10 portent respectivement sur le contexte de l’organisation, le leadership, la planification, les fonctions de support, les opérations, l’évaluation des performances et l’amélioration.
Cette structure a une conséquence méthodologique importante : le SMIA ne peut pas être construit à partir de la seule annexe A. Avant de sélectionner des mesures, l’organisation doit déterminer son contexte, ses parties intéressées, son périmètre, ses objectifs et ses critères de risque. Elle doit ensuite mettre en œuvre les processus nécessaires, mesurer leur efficacité, conduire des audits internes, organiser la revue de direction et traiter les non-conformités.
L’annexe A constitue un référentiel de contrôles relatifs à l’IA. Elle n’est pas une liste uniforme à appliquer mécaniquement. La clause 6 conduit l’organisation à déterminer les mesures nécessaires au traitement des risques, à les comparer au référentiel de l’annexe A afin de vérifier qu’aucun contrôle nécessaire n’a été omis, puis à formaliser leur applicabilité. La déclaration d’applicabilité devient ainsi une pièce d’architecture du SMIA : elle relie les risques, les décisions de traitement, les contrôles retenus et la justification des exclusions.
Cette logique distingue ISO 42001 d’un audit limité à un produit. L’objet audité comprend les mécanismes organisationnels qui entourent les systèmes d’IA : politique, responsabilités, ressources, cycle de vie, données, information des parties intéressées, conditions d’utilisation, relations avec les fournisseurs, surveillance et amélioration.
Ce que les annexes A à D révèlent sur la difficulté réelle d’ISO 42001
Les quatre annexes n’ont pas la même fonction. Les confondre conduit fréquemment à transformer la mise en œuvre en exercice documentaire.
| Annexe | Fonction dans ISO 42001 | Difficulté organisationnelle révélée |
|---|---|---|
| Annexe A | Référentiel d’objectifs de contrôle et de contrôles relatifs à l’IA | Déterminer les contrôles nécessaires selon les risques et justifier leur applicabilité, plutôt que recopier une liste générique |
| Annexe B | Recommandations de mise en œuvre associées aux contrôles de l’annexe A | Traduire un objectif de gouvernance en processus, responsabilité, fréquence, seuil et enregistrement vérifiable |
| Annexe C | Exemples d’objectifs organisationnels et de sources de risque liés à l’IA | Définir ce que signifient, dans un contexte déterminé, l’équité, la robustesse, la sécurité, l’explicabilité, la responsabilité ou la protection de la vie privée |
| Annexe D | Utilisation du SMIA dans différents domaines et articulation avec d’autres systèmes de management | Intégrer le SMIA aux dispositifs existants sans diluer les risques propres à l’IA ni dupliquer les instances et les preuves |
L’annexe A est organisée autour de neuf domaines : politiques relatives à l’IA ; organisation interne ; ressources nécessaires aux systèmes d’IA ; évaluation de leurs impacts ; cycle de vie ; données ; information des parties intéressées ; utilisation des systèmes ; relations avec les tiers et les clients.
Cette architecture explique pourquoi la première difficulté n’est pas exclusivement technique.
A.2 et A.3 — Politique et organisation interne. Une politique IA n’a de portée que si elle est reliée à une autorité de décision, à des rôles définis et à un mécanisme de signalement des préoccupations. Le problème n’est pas de rédiger des principes généraux, mais de déterminer qui peut autoriser un cas d’usage, accepter un risque, imposer une mesure compensatoire ou interrompre le système.
A.4 — Ressources. La notion de ressource dépasse l’infrastructure. Elle comprend les données, les outils, les capacités de calcul, les composants, mais également les compétences humaines nécessaires. Il faut donc relier chaque système à ses dépendances techniques et organisationnelles, avec des propriétaires identifiés.
A.5 — Évaluation des impacts. L’analyse ne peut pas être absorbée dans un registre de cybersécurité. Elle porte sur les effets que le système peut produire sur des individus, des groupes ou la société. Elle suppose l’identification des populations concernées, des mécanismes d’impact, des mesures de prévention et des circonstances imposant une réévaluation.
A.6 et A.7 — Cycle de vie et données. Les exigences de conception, de vérification, de validation, de déploiement, d’exploitation, de surveillance et de retrait doivent être intégrées aux chaînes de développement et d’achat. La gouvernance des données doit, quant à elle, couvrir leur origine, leur qualité, leur préparation et leur aptitude à la finalité retenue. Une documentation séparée du MLOps, du DevSecOps ou du processus fournisseur ne produit qu’une conformité de façade.
A.8 et A.9 — Information et utilisation. Les informations destinées aux utilisateurs et aux autres parties intéressées doivent être cohérentes avec l’usage réel, les limites observées et les conditions de supervision. Une fiche système périmée, une instruction d’utilisation générique ou un avertissement qui ne correspond pas au contexte métier rompt la chaîne de maîtrise.
A.10 — Tiers et clients. Le recours à une API, à un modèle généraliste ou à une solution SaaS ne transfère pas automatiquement la responsabilité. Les responsabilités respectives doivent être distribuées dans les procédures, les contrats, les engagements de service et les dispositifs de notification des changements ou incidents.
L’annexe C ajoute une autre profondeur. Les objectifs de responsabilité, d’expertise, de qualité des données, d’équité, de protection de la vie privée, de robustesse, de sûreté, de sécurité, de transparence ou d’explicabilité ne possèdent pas de métrique universelle. L’organisation doit les contextualiser. « Être explicable » n’a pas le même contenu pour un outil d’aide à la rédaction, un dispositif de détection de fraude et un système influençant l’accès à un service essentiel.
L’annexe D rappelle enfin qu’un SMIA n’est pas destiné à fonctionner en vase clos. Les mécanismes déjà présents dans un SMSI, un système qualité ou un système de protection des données peuvent être mutualisés, mais leur périmètre doit être étendu aux actifs et aux impacts propres à l’IA. DEVFORMA analyse cette articulation dans son comparatif ISO 42001 et ISO 27001 ainsi que dans son étude sur l’intégration de l’IA au périmètre du SMSI.
AI Act et ISO 42001 : une correspondance de gouvernance, pas une équivalence juridique
L’AI Act et ISO 42001 ne possèdent ni le même statut, ni le même objet, ni le même mécanisme d’application.
Le règlement européen distribue les obligations selon la qualification du système et le rôle de l’opérateur : fournisseur, déployeur, importateur, distributeur, fabricant de produit ou fournisseur de modèle d’IA à usage général. ISO 42001 demande à l’organisation de définir le périmètre de son système de management et d’y appliquer des processus cohérents avec son contexte.
Une organisation certifiée ISO 42001 ne peut donc pas en déduire automatiquement sa conformité à l’AI Act. Elle doit construire une matrice distincte indiquant, pour chaque système : sa qualification, le rôle juridique exercé, les articles applicables, le responsable de l’obligation et la preuve attendue.
La lecture article par article fait néanmoins apparaître des interfaces précises.
| Article de l’AI Act | Exigence structurante | Question organisationnelle à résoudre | Interface possible avec ISO 42001 |
|---|---|---|---|
| Article 4 — mesures de maîtrise de l’IA | Développement des compétences adaptées aux connaissances, à l’expérience et au contexte d’utilisation | Quels niveaux de compétence sont requis pour concevoir, acheter, superviser, utiliser ou auditer chaque système ? | Clause 7 sur les compétences et la sensibilisation ; A.3, A.4 et A.9 |
| Article 9 — management des risques | Pour les systèmes à haut risque concernés, processus continu et itératif couvrant le cycle de vie, l’usage prévu et le mésusage raisonnablement prévisible | Qui fixe les critères d’acceptation, qui accepte le risque résiduel et quels changements déclenchent une nouvelle analyse ? | Clause 6 ; A.5 sur les impacts ; A.6 sur le cycle de vie |
| Article 10 — données et gouvernance des données | Pratiques relatives à la collecte, l’origine, la préparation, les hypothèses, la représentativité, les biais et les lacunes des jeux de données | Qui possède la donnée, qui atteste sa provenance et qui juge son aptitude statistique et contextuelle à la finalité ? | A.4 sur les ressources et A.7 sur les données |
| Article 11 et annexe IV — documentation technique | Documentation établie avant la mise sur le marché ou en service, tenue à jour et permettant l’évaluation de conformité | Comment synchroniser versions du modèle, architecture, données, tests, métriques, changements, mesures de supervision et documentation ? | Clause 7.5 sur l’information documentée ; A.6 sur le cycle de vie et la documentation du système |
| Article 12 — enregistrement des événements | Capacité de journalisation automatique permettant la traçabilité, le suivi et l’identification de certaines situations à risque | Quels événements journaliser, pendant combien de temps, avec quels contrôles d’intégrité et quels droits d’accès ? | A.6 pour la traçabilité du cycle de vie ; A.9 pour la surveillance de l’utilisation |
| Article 13 — information des déployeurs | Instructions exactes et compréhensibles sur la finalité, les capacités, les limites, les métriques, les risques et la supervision | Qui valide que les instructions reflètent la version effectivement déployée et les limites constatées en exploitation ? | A.8 sur l’information des parties intéressées ; A.10 sur les relations fournisseurs-clients |
| Article 14 — contrôle humain | Supervision proportionnée permettant de comprendre, surveiller, interpréter, ignorer, inverser ou interrompre le système selon le cas | La personne désignée possède-t-elle la compétence, l’autorité, le temps et les moyens techniques d’intervenir réellement ? | A.3 sur les responsabilités ; A.6 sur la conception et l’exploitation ; A.9 sur l’usage |
| Article 15 — exactitude, robustesse et cybersécurité | Niveaux appropriés sur le cycle de vie, résilience aux erreurs, incohérences, boucles de rétroaction et attaques propres à l’IA | Qui définit les métriques, seuils et scénarios d’essai, et qui arbitre lorsqu’un seuil métier, de sécurité ou d’équité n’est pas atteint ? | A.6 et A.7, complétés par les processus de sécurité de l’information |
| Article 17 — système de management de la qualité | Pour les fournisseurs de systèmes à haut risque concernés, politiques et procédures couvrant conformité, conception, validation, données, risques, surveillance et incidents | Comment intégrer les exigences réglementaires dans un système piloté, proportionné et maintenu, plutôt que dans un dossier ponctuel ? | Forte proximité structurelle avec les clauses 4 à 10 d’ISO 42001, sans identité entre les deux référentiels |
| Article 25 — chaîne de valeur | Répartition des responsabilités et possibilité de changement de qualification lorsque certaines modifications sont réalisées | Qui devient fournisseur lorsqu’un système est renommé, substantiellement modifié ou utilisé hors de sa finalité initiale ? | A.10 sur l’allocation des responsabilités avec les tiers et les clients |
| Article 26 — obligations des déployeurs | Utilisation conforme aux instructions, supervision par des personnes compétentes et autorisées, contrôle des données d’entrée, surveillance et conservation de certains journaux | Comment intégrer les instructions du fournisseur aux procédures opérationnelles du métier et remonter les anomalies ? | A.8, A.9 et A.10 ; clauses 7 et 8 |
| Article 27 — analyse d’impact sur les droits fondamentaux | Analyse exigée pour certains déployeurs et certains systèmes à haut risque avant la première utilisation, avec actualisation lorsque les faits évoluent | Comment distinguer l’analyse juridique exigée par le règlement de l’évaluation plus générale des impacts du SMIA ? | A.5 peut fournir un processus et des éléments de preuve, mais ne remplace pas l’analyse exigée par l’article 27 |
| Article 50 — transparence de certains systèmes | Information sur l’interaction avec une IA et obligations de marquage ou de divulgation pour certains contenus ou usages | Qui qualifie le contenu, choisit le mécanisme d’information, vérifie son maintien et gère les exceptions ? | A.8 sur l’information des parties intéressées et A.9 sur l’utilisation |
| Article 72 — surveillance après commercialisation | Pour les fournisseurs concernés, collecte et analyse systématiques des données de performance et de conformité pendant le cycle de vie | Quels indicateurs, sources de retour, seuils d’alerte et circuits de décision alimentent la réévaluation du système ? | Clause 9 sur l’évaluation des performances ; A.6 sur l’exploitation et la surveillance |
| Article 73 — incidents graves | Notification des incidents graves selon les conditions et délais réglementaires applicables | Qui qualifie la gravité, préserve les éléments, établit le lien causal et coordonne notification, enquête et correction ? | A.8 pour la communication ; clauses 8, 9 et 10 pour le traitement opérationnel et l’amélioration |
Ce tableau ne constitue pas une table de conformité. Il met en évidence les interfaces de gouvernance. Une preuve produite dans le SMIA ne répond à une obligation de l’AI Act que si elle couvre le bon système, le bon rôle, la bonne version, le bon périmètre et le contenu précisément exigé par le règlement.
Les difficultés organisationnelles que fait apparaître cette lecture croisée
1. Le périmètre n’est pas un simple inventaire d’outils
Un registre recensant « Copilot », « ChatGPT » ou un moteur de scoring ne décrit pas encore le périmètre du SMIA. Un même service peut soutenir plusieurs finalités, traiter différentes catégories de données et placer l’organisation dans des rôles juridiques distincts. L’unité de gouvernance pertinente est donc le cas d’usage contextualisé : système ou composant concerné, version, finalité, processus métier, population affectée, entrées, sorties, niveau d’autonomie, fournisseur, utilisateurs, environnement d’exploitation et rôle juridique de l’organisation.
Sans cette granularité, l’analyse de risque demeure générique, l’évaluation des impacts ne peut pas identifier les personnes affectées et la documentation ne permet pas de démontrer quel système a effectivement été validé.
2. La responsabilité doit être traduite en droits de décision
Une matrice RACI est insuffisante lorsqu’elle indique seulement qui doit être consulté ou informé. Un SMIA doit expliciter l’autorité associée aux décisions sensibles : autorisation d’expérimenter, validation des données, approbation de la mise en production, acceptation du risque résiduel, modification de la finalité, dérogation, suspension et retrait.
L’article 14 de l’AI Act illustre cette exigence. La supervision humaine n’est pas satisfaite par la présence abstraite d’un opérateur. Celui-ci doit disposer des compétences et de l’autorité permettant de ne pas utiliser le système, d’ignorer ou d’inverser son résultat, voire d’interrompre son fonctionnement lorsque le contexte l’exige.
La difficulté est institutionnelle : dans de nombreuses organisations, le propriétaire métier possède l’autorité budgétaire, l’équipe data maîtrise le fonctionnement, la conformité qualifie l’obligation et la sécurité contrôle l’environnement. Le processus doit préciser où se situe la décision finale et comment sont arbitrés les désaccords.
3. Le risque, l’impact et la conformité sont trois objets distincts
Le registre de risques ne doit pas absorber indistinctement tous les travaux.
Le management des risques évalue les événements incertains susceptibles d’affecter les objectifs. L’évaluation des impacts examine les conséquences du système sur les individus, les groupes et, selon le contexte, la société. L’analyse de conformité détermine les exigences juridiques applicables en fonction de la qualification du système et du rôle de l’opérateur.
Ces objets sont reliés, mais leurs critères, leurs responsables et leurs conclusions peuvent différer. Une mesure de cybersécurité peut réduire le risque d’empoisonnement des données sans répondre à une question de discrimination. Une analyse d’impact ISO 42001 peut identifier des effets pertinents sans contenir tous les éléments requis par une analyse d’impact sur les droits fondamentaux au titre de l’article 27.
Pour approfondir la distinction entre risques liés à l’IA et risques de sécurité de l’information, voir l’analyse DEVFORMA ISO/IEC 23894 et ISO/IEC 27005.
4. La preuve doit suivre la configuration réelle du système
La documentation devient probante seulement si elle est reliée à une configuration identifiable. La fiche du système, les données, le modèle, les prompts structurants, les composants tiers, les résultats de validation, les instructions d’utilisation et la décision de déploiement doivent converger vers la même version.
Cette continuité est difficile lorsque les modèles sont mis à jour par un fournisseur, que les prompts évoluent hors du processus de changement, que les bases de connaissances sont renouvelées en continu ou qu’un composant RAG modifie les informations accessibles au système sans modification du modèle lui-même.
La gouvernance ISO 42001 doit alors s’articuler avec la gestion de configuration, la traçabilité des données, les pipelines de déploiement et la gestion des changements. Un document daté ne suffit pas s’il est impossible d’établir à quelle configuration il se rapporte.
5. La supervision humaine doit être conçue comme un contrôle opérationnel
L’expression « human in the loop » est trop imprécise pour constituer une mesure. Une supervision effective exige au minimum : un objet de contrôle défini, une information accessible, un seuil ou un événement déclencheur, une personne compétente, un pouvoir d’intervention, une procédure d’escalade et une trace de l’action.
Elle suppose également de traiter le biais d’automatisation. Lorsque l’opérateur reçoit des centaines de recommandations, ne dispose que de quelques secondes pour statuer ou ne peut pas comprendre les limites du système, le contrôle humain existe formellement mais perd sa fonction matérielle.
Le choix de l’interface, la charge de travail, la séparation des tâches et l’autorité hiérarchique deviennent alors des paramètres de conformité et de maîtrise du risque, au même titre que la fonctionnalité permettant d’annuler une décision.
6. La chaîne de valeur doit devenir une chaîne de responsabilités
Les systèmes contemporains combinent fréquemment modèle de fondation, couche applicative, hébergement, données internes, mécanisme de recherche documentaire et outils connectés. Aucun acteur ne possède seul toute l’information nécessaire.
L’annexe A.10 d’ISO 42001 et les articles 13, 25 et 26 de l’AI Act obligent à examiner les interfaces. Le fournisseur doit transmettre certaines informations ; le déployeur doit respecter les instructions et surveiller l’usage ; une modification substantielle ou un changement de finalité peut modifier la répartition des obligations.
La due diligence doit donc être convertie en exigences contractuelles et opérationnelles : notification des changements, accès aux informations de validation, métriques et limites, journalisation, assistance en cas d’incident, réversibilité, sous-traitance, conservation des preuves et coopération réglementaire.
7. Le SMIA doit survivre à la phase projet
La conformité ne s’arrête pas à la mise en production. Les articles 9, 12, 72 et 73 organisent une boucle entre risque, journalisation, surveillance, incident et correction. Les clauses 9 et 10 d’ISO 42001 imposent de leur côté l’évaluation des performances, l’audit interne, la revue de direction, le traitement des non-conformités et l’amélioration continue.
Le point de fragilité réside dans le passage entre les équipes. Une alerte technique n’est pas encore un incident qualifié. Un incident qualifié n’entraîne pas automatiquement la réévaluation des impacts. Une action corrective clôturée administrativement ne démontre pas que le contrôle est devenu efficace.
Le SMIA doit définir ces transitions : critères de déclenchement, destinataires, délais internes, décision attendue, enregistrement produit et vérification de l’efficacité.
Quel corpus de preuves pour un SMIA techniquement auditable ?
Il n’existe pas de dossier documentaire universel. Le corpus dépend du rôle de l’organisation, de son périmètre et de ses risques. Une architecture minimale peut néanmoins relier les objets suivants :
| Objet de preuve | Contenu attendu | Point de vigilance |
|---|---|---|
| Périmètre du SMIA | Entités, activités, sites, produits, processus et interfaces couverts | Éviter un périmètre nominal qui exclut les dépendances déterminantes |
| Registre des cas d’usage | Finalité, version, métier, population, données, fournisseur, autonomie et rôle juridique | Recenser les usages intégrés aux logiciels et les composants tiers, pas uniquement les projets data |
| Note de qualification | Catégorie du système et rôle de l’organisation au regard des textes applicables | Réexaminer la qualification en cas de changement de finalité ou de modification substantielle |
| Matrice d’autorité | Propriétaires et droits de décision à chaque étape du cycle de vie | Distinguer responsabilité opérationnelle, avis spécialisé et autorité d’acceptation |
| Méthode et registre de risques | Critères, scénarios, mésusages prévisibles, risques résiduels, traitements et propriétaires | Relier chaque risque à une décision et à une mesure effectivement suivie |
| Évaluation des impacts | Populations affectées, mécanismes d’impact, gravité, mesures et déclencheurs de révision | Ne pas la confondre avec le seul risque cyber ni avec une analyse juridique particulière |
| Déclaration d’applicabilité | Contrôles nécessaires, statut, justification et lien avec les risques | Éviter les justifications génériques ou les exclusions non reliées au contexte |
| Dossier de données | Origine, droits, préparation, qualité, représentativité, biais, lacunes et transformations | Assurer la traçabilité entre la donnée décrite et la version utilisée |
| Dossier de validation | Métriques, seuils, jeux d’essai, résultats, limites, scénarios adverses et approbations | Distinguer performance moyenne, performance par sous-population et limites contextuelles |
| Plan de supervision humaine | Rôle, compétence, informations disponibles, pouvoirs d’intervention et escalade | Vérifier l’effectivité sous contrainte réelle de temps et de charge |
| Dossier fournisseur | Due diligence, responsabilités, engagements, changements, incidents et réversibilité | Ne pas considérer l’attestation du fournisseur comme une preuve suffisante pour l’usage propre |
| Plan de surveillance | Indicateurs, journaux, dérives, seuils, fréquence, sources de retour et responsables | Relier les alertes à la réévaluation des risques et impacts |
| Dossier de changement | Nature du changement, analyse d’impact, tests, approbation et version déployée | Couvrir modèles, données, prompts, outils, règles métier et finalité |
| Dossier d’incident | Qualification, chronologie, causalité, notifications, correction et retour d’expérience | Préserver les preuves et distinguer incident technique, impact et incident grave réglementaire |
Ce corpus n’a de valeur que si les documents se référencent mutuellement. Le registre doit pointer vers la qualification et le propriétaire ; le risque vers le contrôle ; le contrôle vers la preuve ; la preuve vers la version ; le changement vers la nouvelle validation ; l’incident vers la réévaluation et l’action corrective.
Ce que doit maîtriser un ISO 42001 Lead Implementer
La fonction d’implémentation ne consiste pas à transposer des clauses dans une série de modèles. Elle requiert la capacité de construire un système cohérent entre gouvernance, ingénierie, droit, risque et auditabilité.
Un professionnel chargé d’une mise en œuvre ISO 42001 doit notamment savoir :
- délimiter le SMIA à partir du contexte et des interfaces réelles ;
- conduire une analyse d’écart sans confondre absence de document et absence de contrôle ;
- formaliser une méthodologie de risque et d’impact adaptée aux systèmes d’IA ;
- sélectionner les contrôles nécessaires et construire la déclaration d’applicabilité ;
- intégrer les exigences dans le cycle de vie, les achats, le MLOps et la gestion des changements ;
- définir les indicateurs permettant d’évaluer l’efficacité du système de management ;
- préparer un audit interne et une revue de direction à partir de preuves d’exécution.
La formation PECB ISO/IEC 42001 Lead Implementer se situe à ce niveau : planifier, mettre en œuvre, maintenir et améliorer un SMIA. Elle doit être distinguée de la certification du système de management de l’organisation, délivrée à l’issue d’un audit réalisé par un organisme de certification.
Pour une première lecture structurée du référentiel, la formation ISO/IEC 42001 Foundation porte sur les concepts et exigences fondamentales. Le parcours ISO/IEC 42001 Lead Auditor adopte l’autre perspective : planifier et conduire l’évaluation du SMIA, apprécier les preuves et formuler les constats d’audit.
Conclusion
Les difficultés initiales d’ISO 42001 ne sont pas réductibles à un manque de maturité technique. Elles proviennent de l’écart entre la transversalité des systèmes d’IA et la fragmentation habituelle des responsabilités.
La méthode prescrite par la norme conduit à relier les contrôles aux risques et à en justifier l’applicabilité. L’annexe B fournit les indications permettant de traduire ces contrôles en pratiques. L’annexe C offre une base pour contextualiser les objectifs et les sources de risque, tandis que l’annexe D éclaire l’intégration du SMIA aux autres systèmes de management. L’AI Act ajoute une couche distincte : qualification des rôles, exigences propres à certaines catégories de systèmes et preuves juridiquement déterminées.
La robustesse du dispositif dépend alors d’une propriété simple à énoncer, mais exigeante à maintenir : pour chaque système, l’organisation doit pouvoir reconstruire la chaîne qui relie la finalité, la version, la responsabilité, le risque, l’impact, le contrôle, la décision et la preuve.
Ce n’est qu’à cette condition qu’ISO 42001 cesse d’être un corpus documentaire pour devenir un véritable système de management de l’intelligence artificielle.
FAQ — ISO 42001, annexes et AI Act
L’annexe A d’ISO 42001 est-elle une checklist de contrôles obligatoires ?
Non. L’organisation détermine les contrôles nécessaires en fonction de ses risques, vérifie son choix par comparaison avec l’annexe A et formalise l’applicabilité des contrôles. Une exclusion doit être justifiée ; un contrôle nécessaire ne peut pas être écarté au seul motif qu’il est difficile à mettre en œuvre.
Une certification ISO 42001 démontre-t-elle la conformité à l’AI Act ?
Non. La certification porte sur le SMIA dans le périmètre défini. La conformité à l’AI Act dépend notamment de la catégorie du système, du rôle juridique de l’organisation et du respect de chaque obligation applicable. Les preuves ISO 42001 peuvent contribuer au dossier, mais une analyse juridique et technique distincte reste nécessaire.
Quelle différence entre l’évaluation des impacts d’ISO 42001 et l’analyse de l’article 27 ?
ISO 42001 demande d’organiser l’évaluation des impacts des systèmes d’IA dans le cadre du SMIA. L’article 27 définit une analyse d’impact sur les droits fondamentaux applicable à certains déployeurs et systèmes à haut risque. Les deux travaux peuvent être articulés, mais leurs périmètres et leurs exigences ne sont pas identiques.
ISO 42001 est-elle uniquement organisationnelle ?
Non. Plusieurs contrôles touchent directement aux ressources techniques, aux données, à la vérification, à la validation, à la journalisation, à l’exploitation et à la surveillance. La norme est dite organisationnelle parce qu’elle exige que ces activités techniques soient gouvernées, attribuées, documentées et évaluées dans un système de management cohérent.
