Contrôles Annexe A ISO 42001 : liste commentée

Comment l'Annexe A est organisée

Les clauses 4 à 10 de l'ISO/IEC 42001 définissent le système de management lui-même : contexte, leadership, planification, support, fonctionnement, évaluation des performances et amélioration^[6]. L'Annexe A se place à côté de ces clauses et fournit un catalogue de contrôles spécifiques à l'IA^[1].

Ce catalogue contient 38 contrôles répartis sous neuf objectifs de contrôle, numérotés de A.2 à A.10^[3]. La numérotation commence à A.2 parce que A.1 sert de clause introductive à l'annexe et ne constitue pas un groupe de contrôles^[1]. Chaque objectif formule un résultat attendu. Les contrôles qui lui sont rattachés décrivent les mesures concrètes pour atteindre ce résultat.

Point structurel à retenir : il s'agit d'un ensemble de référence, pas d'une liste obligatoire à appliquer de bout en bout. La clause 6.1.3 de la norme demande de déterminer les contrôles nécessaires au traitement des risques, puis de les comparer à l'Annexe A pour vérifier qu'aucun contrôle pertinent n'a été oublié^[1]. Le résultat de cette comparaison se consigne dans une déclaration d'applicabilité (SoA).

Si vous découvrez la norme, la page structure de la norme clause par clause donne le contexte nécessaire avant de parcourir l'Annexe A.

A.2 Politiques relatives à l'IA

Objectif

Fournir une orientation et un soutien de la direction pour les systèmes d'IA, en cohérence avec les exigences métier^[2].

Contrôles (3)

Contrôle 2.2 - Politique IA. L'organisation doit disposer d'une politique IA documentée, approuvée par la direction, qui exprime l'intention de développer et d'utiliser l'IA de manière responsable^[1]. Preuve attendue : le document de politique signé, un historique de versions et un registre de diffusion^[8].

Contrôle 2.3 - Alignement avec les autres politiques de l'organisation. La politique IA ne doit pas contredire les politiques existantes (sécurité de l'information, protection des données, qualité)^[1]. En pratique, un tableau de correspondance entre la politique IA et les politiques en vigueur suffit souvent pour démontrer la cohérence.

Contrôle 2.4 - Revue de la politique IA. La politique doit être réexaminée à des intervalles planifiés^[2]. L'auditeur cherchera un procès-verbal de revue de direction mentionnant la politique IA et, le cas échéant, les modifications décidées^[1].

Si votre organisation détient déjà une certification ISO 27001, la politique IA peut s'articuler comme un complément à la politique de sécurité de l'information. Consultez l'article sur l'intégration de l'ISO 42001 dans un SMSI ISO 27001 existant pour les détails pratiques.

A.3 Organisation interne

Objectif

Établir la redevabilité au sein de l'organisation pour maintenir une approche responsable de la mise en œuvre, de l'exploitation et du management des systèmes d'IA^[2].

Contrôles (2)

Contrôle 3.2 - Rôles et responsabilités IA. Des personnes nommées doivent assumer les rôles de propriétaire du système d'IA, de coordinateur du SMIA et de réviseur IA (supervision des décisions individuelles du système)^[8]. L'auditeur attend une matrice d'attribution ou un document RH équivalent. Des autorités verbales, sans trace écrite, ne résistent pas à l'audit^[8].

Contrôle 3.3 - Signalement des préoccupations. Un mécanisme doit permettre à toute personne de l'organisation de signaler des préoccupations liées à l'IA^[2]. Pour une PME romande qui déploie un chatbot interne, cela peut être aussi simple qu'une adresse e-mail dédiée, doublée d'un registre de signalements horodatés.

A.4 Ressources pour les systèmes d'IA

Objectif

S'assurer que l'organisation recense les ressources (composants et actifs) de chaque système d'IA afin de comprendre et traiter les risques et impacts associés^[2].

Contrôles (5)

Contrôle 4.2 - Documentation des ressources. Un inventaire documenté de toutes les ressources nécessaires au fonctionnement de chaque système d'IA^[2]. Cet inventaire est le point de départ de la cartographie des systèmes IA.

Contrôle 4.3 - Ressources en données. Identifier et documenter les jeux de données utilisés par chaque système^[2].

Contrôle 4.4 - Ressources en outillage. Recenser les outils logiciels, bibliothèques et frameworks mobilisés^[2].

Contrôle 4.5 - Ressources système et de calcul. Documenter l'infrastructure de calcul (serveurs, GPU, services cloud) sur laquelle repose le système d'IA^[2].

Contrôle 4.6 - Ressources humaines. Identifier les compétences humaines requises pour le développement, l'exploitation et la supervision du système^[2]. Ce contrôle rejoint la clause 7.2 (Compétence) du corps de la norme^[6].

Observation qualitative : dans les démarches observées, l'inventaire des ressources de calcul est souvent le parent pauvre. Les équipes documentent bien les données et les modèles, mais oublient de tracer les versions des environnements d'exécution, ce qui pose problème lors de la reproductibilité.

A.5 Évaluation des impacts des systèmes d'IA

Objectif

Définir le processus d'évaluation de l'impact des systèmes d'IA sur les individus, les groupes et la société^[1].

Contrôles

Ce groupe couvre l'analyse d'impact propre à l'IA. Il exige que l'organisation dispose d'un processus documenté pour évaluer les conséquences potentielles de chaque système d'IA avant son déploiement et à intervalles réguliers par la suite^[3]. L'évaluation d'impact IA est l'un des éléments qui distinguent le plus nettement l'ISO 42001 de l'ISO 27001^[3].

La clause 6.1.4 du corps de la norme prescrit cette évaluation d'impact. L'Annexe A.5 fournit les contrôles de référence pour la conduire^[2]. Pour une méthode détaillée, l'article sur l'analyse d'impact IA selon la norme développe les exigences concrètes.

Prenons un exemple concret. Une administration cantonale romande qui utilise un algorithme de tri des demandes de prestations sociales devrait évaluer l'impact sur les bénéficiaires (risque de discrimination, d'exclusion automatisée). Le registre d'impact documenterait les catégories de personnes affectées, la gravité potentielle et les mesures d'atténuation retenues.

A.6 Cycle de vie du système d'IA

Objectif

Assurer une conception, un développement, une vérification et un déploiement responsables des systèmes d'IA^[1].

Contrôles

Ce groupe est le plus volumineux de l'Annexe A. Il couvre l'ensemble du cycle de vie : de la définition des exigences à la mise hors service, en passant par la vérification, la validation et le suivi post-déploiement^[3]. Les contrôles y sont délibérément formulés à un niveau élevé et fondés sur des principes, pas sur des prescriptions techniques précises^[3].

Parmi les preuves attendues, on trouve typiquement : des spécifications de conception documentées, des rapports de tests de vérification et de validation, des critères d'acceptation définis avant le déploiement, et un plan de surveillance en exploitation^[1].

Un piège fréquent : traiter A.6 comme un processus purement technique confié à l'équipe de data science. Or les contrôles du cycle de vie intègrent des dimensions de gouvernance (approbation du déploiement, critères de retrait) qui relèvent de la direction. L'auditeur vérifiera que les décisions de passage en production sont tracées et approuvées par un rôle disposant de l'autorité nécessaire^[8].

A.7 Données pour les systèmes d'IA

Objectif

Gouverner les données utilisées par les systèmes d'IA en termes de qualité, de provenance et de préparation^[1].

Contrôles

Contrôle 7.1 (ou équivalent) - Données pour les systèmes d'IA. Documenter quelles données chaque système utilise : source, format, volume, catégories (personnelles, sensibles, non personnelles)^[8]. Preuve : un registre de données par système d'IA, relié à l'inventaire des systèmes.

Contrôle 7.2 (ou équivalent) - Qualité des données. Définir des critères de qualité pour les données d'entraînement et les données opérationnelles^[8]. Des critères de qualité non documentés constituent une lacune : l'auditeur demandera comment l'organisation sait que les données d'entraînement du modèle étaient appropriées^[8].

Contrôle 7.3 (ou équivalent) - Contrôle d'accès aux données. Restreindre et tracer les accès aux jeux de données utilisés par les systèmes d'IA^[8].

Pour une entreprise romande spécialisée en IA médicale, la provenance des données d'imagerie (consentement, anonymisation, représentativité géographique des cohortes) sera scrutée de près. Documenter la chaîne de provenance dès l'acquisition des données évite des reprises coûteuses au moment de l'audit.

A.8 Information des parties intéressées

Objectif

Assurer la transparence et la documentation à destination des utilisateurs et des personnes affectées par les systèmes d'IA^[1].

Contrôles

Ce groupe exige que l'organisation informe les parties intéressées de manière adaptée à leur contexte. Cela inclut la documentation technique pour les intégrateurs, les notices d'utilisation pour les opérateurs et, le cas échéant, une information accessible pour les personnes dont les décisions sont influencées par le système^[7].

La transparence au sens de l'ISO 42001 ne se limite pas à publier un document. Elle suppose que l'information soit compréhensible par son destinataire. Pour un système de scoring de crédit, par exemple, cela signifie expliquer au demandeur les facteurs principaux ayant influencé la décision, dans un langage non technique.

Ce groupe de contrôles présente un recouvrement direct avec les obligations de transparence du Règlement européen sur l'IA (AI Act). L'article sur le recouvrement entre ISO 42001 et AI Act détaille les correspondances.

A.9 Utilisation des systèmes d'IA

Objectif

Garantir une utilisation responsable et conforme à la destination prévue, avec un suivi en exploitation^[1].

Contrôles

Les contrôles A.9 portent sur la phase opérationnelle : utilisation conforme à l'usage prévu, surveillance continue des performances et des dérives du modèle, et capacité d'intervention humaine^[7]. L'idée directrice est qu'un système d'IA déployé n'est pas un système terminé. Il requiert un suivi actif.

Preuve typique : des tableaux de bord de surveillance avec des seuils d'alerte définis, des procédures de désactivation d'urgence documentées, et des journaux montrant que ces procédures ont été testées.

Observation qualitative : les organisations qui déploient des modèles de langage génératif sous-estiment souvent la surveillance post-déploiement. Un modèle dont les réponses dérivent (par changement de distribution des requêtes utilisateurs) relève directement de A.9. Pour cadrer ces situations, consultez l'article sur les risques de l'IA générative en entreprise.

A.10 Relations avec les tiers et les clients

Objectif

Répartir les responsabilités le long de la chaîne d'approvisionnement de l'IA^[1].

Contrôles

Ce dernier groupe traite des situations où l'organisation utilise des composants IA fournis par des tiers (API de modèles, jeux de données achetés, services d'annotation) ou fournit elle-même des composants à des clients^[7]. Les contrôles exigent une allocation claire des responsabilités : qui est responsable de la qualité des données, de la surveillance en exploitation, de la correction des biais détectés.

Exemple concret : une fintech genevoise qui intègre un modèle de détection de fraude fourni par un éditeur américain doit documenter dans un accord contractuel lequel des deux est responsable de la surveillance des performances du modèle en production, du retraining périodique et de la notification en cas de dérive. Sans cette allocation, l'auditeur constatera une lacune sur A.10.

Ce groupe de contrôles gagne en importance avec la montée des modèles « as a service ». Dès lors que vous consommez un modèle via une API, vous restez responsable de l'usage que vous en faites dans votre contexte. A.10 formalise cette responsabilité partagée.

Déclaration d'applicabilité et rôle de l'Annexe B

Après avoir parcouru les 38 contrôles, la question pratique est : lesquels retenir ? La réponse passe par la déclaration d'applicabilité (SoA). Ce document liste chacun des 38 contrôles de l'Annexe A, indique s'il est applicable ou non, et justifie chaque exclusion^[1][3].

La sélection n'est pas arbitraire. Elle découle des résultats de l'évaluation des risques IA (clause 6.1.2) et de l'évaluation d'impact (clause 6.1.4)^[1]. Un contrôle exclu sans justification liée aux risques constitue un constat d'audit potentiel^[8].

L'Annexe B de la norme fournit des indications de mise en œuvre pour chaque contrôle de l'Annexe A^[3][7]. Elle joue un rôle analogue à celui de l'ISO/IEC 27002 par rapport à l'Annexe A de l'ISO 27001^[3]. Les Annexes C et D complètent le dispositif : C propose des sources de risques IA et D offre des notes intersectorielles^[1][7].

La sélection des contrôles suit un enchaînement précis, prescrit par les clauses 6.1.2 à 6.1.4 de la norme^[2].

1Évaluation des risques IA (clause 6.1.2)

2Évaluation d'impact IA (clause 6.1.4)

3Détermination des contrôles nécessaires (clause 6.1.3)

4Comparaison avec l'Annexe A

5Rédaction de la SoA

Chaque exclusion de contrôle dans la SoA doit être justifiée par les résultats des étapes 1 et 2^[1].

Comparaison rapide avec l'Annexe A de l'ISO 27001

Si vous venez du monde ISO 27001, le mécanisme de l'Annexe A vous est familier. Les différences portent sur le périmètre et la granularité.

ISO 27001 Annexe A vs ISO 42001 Annexe A

Nombre de contrôles	93 (ISO 27001) contre 38 (ISO 42001)[3]
Regroupement	4 thèmes (ISO 27001) contre 9 objectifs de contrôle (ISO 42001)[3]
Focale	Confidentialité, intégrité, disponibilité (ISO 27001) contre biais, transparence, qualité des données, supervision humaine, impact sociétal (ISO 42001)[3]
Guide de mise en œuvre	ISO/IEC 27002 (ISO 27001) contre Annexe B intégrée (ISO 42001)[3]
Certifiable	Oui dans les deux cas[3]

Les organisations déjà certifiées ISO 27001 trouvent la mise en œuvre de l'ISO 42001 plus aisée, car les clauses du système de management (4 à 10) suivent la même Structure Harmonisée^[3]. Le delta réside dans l'Annexe A spécifique à l'IA et dans le processus d'évaluation d'impact^[3]. Pour approfondir les passerelles, consultez l'article ISO 42001 vs ISO 27001 : différences et passerelles.

Le piège le plus fréquent en audit

Le piège le plus courant, signalé de manière convergente par plusieurs sources spécialisées, est de traiter l'Annexe A comme une checklist à cocher intégralement^[1]. L'Annexe A n'est pas un référentiel d'exigences directes. C'est un catalogue de référence. L'exigence normative est de justifier vos choix, pas d'appliquer les 38 contrôles.

Selon un cabinet spécialisé, les déficiences les plus courantes lors du premier audit concernent les clauses 4 à 6 (contexte, périmètre, planification) et non l'Annexe A elle-même^[8]. L'écart typique : un périmètre du SMIA rédigé comme une copie du périmètre SMSI plutôt que comme un document spécifique à l'IA^[8]. Il est recommandé de recouper cette observation sur la base d'expériences d'audit directes.

Autre erreur récurrente : exclure un système d'IA du périmètre alors qu'il présente un risque manifeste. L'auditeur vérifiera que les exclusions de périmètre sont justifiées et qu'aucun système à risque n'a été commodément laissé de côté^[8].

Pour préparer efficacement votre première évaluation, la page sur l'analyse d'écart (gap analysis) offre une méthode structurée.

Questions fréquentes

À lire ensuite