Annexe A de l'ISO 42001 : les 9 catégories de contrôles

Le rôle de l'Annexe A dans le SMIA

L'Annexe A de l'ISO/IEC 42001:2023 est un référentiel normatif de contrôles. Elle énumère des objectifs et des contrôles que l'organisation passe en revue lors du traitement du risque, à la croisée de la clause 6.1.3 et de la déclaration d'applicabilité^[2].

Le texte n'impose pas de tout retenir. Il invite à comparer les contrôles choisis avec ceux de l'Annexe pour vérifier qu'aucun sujet pertinent n'a été oublié, puis à justifier inclusions et exclusions^[2]. La logique est celle d'un menu raisonné, pas d'une liste prescriptive.

La structure officielle compte neuf domaines, de A.2 à A.10^[6][4]. Certaines publications commerciales en présentent huit en fusionnant des sections, ce qui complique la lecture^[2]. Nous suivons ici le découpage normatif à neuf domaines.

Vue d'ensemble des catégories de contrôles, dans l'ordre de la norme.

A.2Politiques IA

A.3Organisation interne

A.4Ressources

A.5Évaluation d'impacts

A.6Cycle de vie

A.7Données

A.8Information aux parties

A.9Usage

A.10Tiers

Numérotation issue du sommaire de la norme^[4][6].

A.2 Politiques relatives à l'IA

Ce premier domaine vise une direction de gestion claire pour les systèmes d'IA, alignée sur les besoins métier^[4]. Il comprend trois contrôles, A.2.2 sur la politique d'IA elle-même, A.2.3 sur son alignement avec les autres politiques internes, et A.2.4 sur sa revue régulière^[6].

Le piège fréquent observé dans les démarches en cours est la politique d'IA dupliquée de la politique de sécurité, sans articulation avec les volets RH, qualité ou protection des données. L'alignement demandé par A.2.3 n'est alors qu'apparent et le premier audit interne le relève.

Exemple romand. Une caisse de pension qui pilote un moteur d'aide à la décision pour ses placements peut produire une charte IA brève, validée par le conseil de fondation, qui renvoie explicitement à la politique de sécurité, au règlement interne et au cadre nLPD. La revue annuelle est inscrite au calendrier de gouvernance.

A.3 Organisation interne

A.3 traduit la politique en responsabilités nommées. L'objectif est d'établir une responsabilité interne pour soutenir l'approche d'IA responsable^[4]. Deux contrôles principaux, A.3.2 sur les rôles et responsabilités IA, et A.3.3 sur le signalement de préoccupations^[6].

La matrice RACI n'est pas exigée par la norme, mais elle reste l'outil le plus lisible pour démontrer la traçabilité décisionnelle. Selon Glocert, en janvier 2026, un comité de gouvernance avec représentation exécutive et un point d'escalade pour les décisions sensibles font partie des pratiques courantes^[2], à recouper avec les exigences formelles du texte.

Le canal de signalement A.3.3 n'est pas un gadget. Dans une PME industrielle vaudoise qui exploite un modèle de maintenance prédictive, l'opérateur de ligne doit pouvoir remonter une dérive sans passer par le fournisseur du modèle. Le canal doit être documenté, accessible et protégé.

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

A.4 demande d'identifier et de documenter les ressources nécessaires à chaque étape du cycle de vie^[6]. La norme distingue plusieurs catégories, dont les données, les outils, le système et l'infrastructure de calcul, et les ressources humaines^[6][4].

L'exigence centrale, c'est la documentation, contrôle A.4.2^[4]. Sans inventaire, aucune analyse de risque sérieuse n'est possible. Une bonne pratique consiste à coupler le registre des systèmes d'IA, exigé en amont par la clause 6, avec un registre des ressources qui pointe vers les jeux de données, les modèles, les environnements et les compétences mobilisées.

Piège fréquent. Les compétences sont souvent listées en termes de profils théoriques, sans preuve de formation effective. Or A.4 sur les ressources humaines n'a de valeur que si elle s'articule à la clause 7.2 Compétence, avec dossiers de formation et évaluation des acquis. À défaut, l'auditeur consigne une non-conformité mineure.

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

A.5 porte sur l'évaluation des impacts des systèmes d'IA sur les individus, les groupes et la société, tout au long du cycle de vie^[6]. C'est le cœur de la diligence raisonnée propre à l'IA. Les contrôles couvrent le processus d'évaluation, sa documentation, ainsi que la prise en compte des impacts sur les personnes, les groupes et la société^[6].

L'analyse d'impact exigée ici n'est pas l'AIPD au sens des règles de protection des données. Elle l'englobe parfois, mais son périmètre va au-delà, jusqu'aux effets sociétaux et aux droits fondamentaux^[6]. La confusion entre les deux est l'erreur la plus répandue dans les démarches observées.

Exemple romand. Une commune qui déploierait un outil d'aide à l'attribution de prestations sociales doit documenter une évaluation distincte de l'AIPD, traitant des effets sur les groupes vulnérables, des biais possibles et des recours offerts aux administrés.

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

A.6 traite la chaîne de conception, développement, vérification, validation, déploiement, exploitation, surveillance et retrait. Selon Glocert, en janvier 2026, les contrôles attendus couvrent les revues de conception, la gestion de version des modèles, les tests de biais, la validation contre des seuils d'équité et les procédures de déploiement contrôlé^[2], à recouper avec le texte officiel.

Interprétation. Le principal apport de A.6 n'est pas d'ajouter des étapes à un cycle de développement existant, mais d'imposer des points d'arrêt de gouvernance, où des décisions sont prises et tracées. Sans ces jalons, la conformité à la clause 8 Opération reste fragile.

Exemple romand. Une fintech genevoise qui exploite un modèle de scoring de crédit peut s'appuyer sur ses revues de code et ses tests fonctionnels existants, en ajoutant un jalon explicite d'approbation de modèle avant mise en production, avec une fiche modèle documentant l'usage prévu et les limites connues^[2].

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

A.7 cible les données utilisées tout au long du cycle de vie, de l'acquisition à la qualité, en passant par la provenance et la préparation. C'est le domaine où l'articulation avec la nLPD et le RGPD est la plus serrée, sans s'y réduire. La qualité des données, leur représentativité et leur traçabilité y sont traitées comme des sujets d'ingénierie autant que de gouvernance.

Piège fréquent. Les équipes traitent A.7 comme un sous-ensemble du registre de traitement RGPD. C'est insuffisant. La provenance, la qualité statistique et les biais d'échantillonnage relèvent d'une logique différente de la base légale et de la finalité.

Exemple romand. Un hôpital universitaire qui entraîne un modèle d'aide au diagnostic à partir de cohortes locales doit documenter la composition démographique des jeux d'entraînement, les méthodes d'anonymisation et les jeux de validation indépendants, en plus du registre des traitements.

A.8 Information aux parties intéressées

A.8 organise l'information mise à disposition des parties prenantes, internes et externes, sur le système d'IA. Il s'agit de transparence opérationnelle, pas de communication marketing. Documentation technique, fiches modèles, notices d'usage, mécanismes de contestation entrent dans ce périmètre.

Selon Glocert, en janvier 2026, les fiches modèles précisant l'usage prévu et les limites, ainsi qu'une documentation d'architecture traitant des préoccupations propres à l'IA, font partie des éléments attendus^[2]. À recouper avec les obligations de transparence introduites par l'AI Act européen pour les organisations exposées au marché de l'Union.

Interprétation. La granularité d'information varie selon le destinataire. Un utilisateur final n'a pas besoin du même niveau de détail qu'un auditeur interne ou qu'un régulateur. A.8 demande de réfléchir cette segmentation, pas de tout publier.

A.9 Usage des systèmes d'IA

A.9 traite l'usage effectif des systèmes par l'organisation, qu'ils soient développés en interne ou acquis. Le sujet récurrent y est la dérive d'usage, lorsque le système est utilisé hors de son périmètre de conception. La norme demande de documenter l'usage prévu, de former les utilisateurs et de surveiller l'écart entre usage prévu et usage réel.

Piège fréquent. L'organisation déploie un assistant génératif pour la rédaction interne, puis tolère son usage pour des décisions affectant des personnes. Le périmètre d'usage glisse sans qu'aucune revue formelle ne soit déclenchée. C'est typiquement ce que A.9, lié à la clause 8, doit prévenir.

Exemple romand. Une administration cantonale qui généralise un assistant conversationnel à ses agents doit documenter les cas d'usage autorisés, ceux qui sont proscrits, et la conduite à tenir en cas de doute. Une formation initiale et un rappel annuel constituent le minimum opérationnel.

A.10 Relations avec les tiers et les clients

A.10 traite les relations avec les fournisseurs, sous-traitants, partenaires et clients qui interviennent dans le cycle de vie du système d'IA. La chaîne d'approvisionnement IA est rarement maîtrisée de bout en bout, ce qui rend ce domaine particulièrement sensible.

Selon ISMS.online, en 2025-2026, les contrôles couvrent l'allocation des responsabilités entre parties, l'évaluation des risques liés aux fournisseurs et les exigences contractuelles^[3]. À recouper avec le texte de la norme^[1], qui reste la source de référence pour la formulation exacte des contrôles.

Exemple romand. Une PME qui consomme un modèle de langage en API doit cartographier ce qui relève de sa responsabilité, traitement des données envoyées, validation des sorties, conservation des journaux, et ce qui reste chez le fournisseur, entraînement, mises à jour, gestion des incidents. Sans ce partage explicite, A.10 est inopérant.

Articuler Annexe A et déclaration d'applicabilité

L'Annexe A n'a de sens qu'articulée à la clause 6.1.3 Traitement du risque. Elle sert de filet de sécurité pour vérifier qu'aucune dimension importante n'a été oubliée^[2]. La déclaration d'applicabilité formalise les choix d'inclusion et d'exclusion, contrôle par contrôle, avec justification.

Repères de structure des neuf domaines

Domaine	Intitulé
A.2	Politiques relatives à l'IA[6]
A.3	Organisation interne[6]
A.4	Ressources pour les systèmes d'IA[6]
A.5	Évaluation des impacts[6]
A.6	Cycle de vie du système d'IA[4]
A.7	Données pour les systèmes d'IA[4]
A.8	Information aux parties intéressées[4]
A.9	Usage des systèmes d'IA[4]
A.10	Relations avec les tiers et les clients[4]

Conseil pratique pour le futur Lead Implementer. Construisez la déclaration d'applicabilité en deux temps. Première passe, vous inscrivez chaque contrôle de A.2 à A.10 et sa décision d'applicabilité, avec une phrase de justification. Seconde passe, vous reliez chaque contrôle retenu à au moins une preuve documentée, politique, registre, procès-verbal ou indicateur de surveillance.

Dernier point d'attention. La numérotation A.5 désigne l'évaluation d'impact dans la norme et le cycle de vie dans certaines présentations commerciales^[2][6]. En cas de doute, le texte officiel ISO/IEC 42001:2023^[1] tranche et c'est lui qu'un auditeur vérifiera.

Questions fréquentes

À lire ensuite