Les mesures de l'annexe A de l'ISO 42001 en un coup d'œil

L'annexe A de l'ISO/IEC 42001:2023 est le catalogue normatif de 38 mesures de référence réparties en 9 domaines (A.2 à A.10), dans lequel les organisations retiennent, via la déclaration d'applicabilité (SoA) et selon une approche par les risques, celles qui les concernent. Les mesures couvrent tout l'éventail : du cadre de politique d'IA aux rôles, aux ressources, au cycle de vie et à la gouvernance des données, jusqu'à l'utilisation responsable et aux relations avec les tiers.

L'annexe A fonctionne comme l'annexe A de l'ISO/IEC 27001 combinée à l'ISO 27002 : chaque domaine a un objectif (« To … ») et une liste de mesures qui, ensemble, permettent de l'atteindre. Les recommandations de mise en œuvre correspondantes figurent dans l'annexe B, de nature informative.

Trois réponses rapides :

• Combien ? 9 domaines, 38 mesures. Les comptages divergents (39 ou 42 mesures ; 10 domaines) tiennent à des conventions de comptage ; le chiffre canonique est 9/38.
• Obligatoire ? Pas en bloc. La sélection se fait selon une approche par les risques via la SoA. Chaque mesure est marquée comme applicable ou non applicable, avec dans les deux cas une justification.
• Pourquoi est-ce important ? L'annexe A est le noyau opérationnel où la gouvernance de l'IA se concrétise dans la clause 8 (Fonctionnement). En audit, elle constitue la base centrale de l'échantillonnage.

Vue d'ensemble des 9 domaines

Le tableau suivant récapitule tous les domaines de l'annexe A avec leur objectif et un exemple de mise en œuvre typique.

A.2 à A.5 : pilotage, organisation, ressources et impact

A.2 (Policies related to AI) couvre la politique d'IA elle-même en tant qu'orientation approuvée par la direction (A.2.2), son alignement sur les autres politiques (A.2.3) et sa revue régulière (A.2.4). Pour un exploitant d'agents, la politique d'IA devrait traiter explicitement les niveaux d'autonomie (lecture seule / recommandation / action avec validation / action autonome), les limites d'utilisation des outils, les règles d'escalade et de human-in-the-loop, la diversité des fournisseurs de modèles et les cas d'usage interdits (par exemple, pas de conseil juridique autonome).

A.3 (Internal organisation) encadre les rôles et responsabilités liés à l'IA avec séparation des tâches (A.3.2) ainsi qu'un canal de signalement des préoccupations (A.3.3). L'ISO 42001 n'impose pas de titre fixe d'« AI Officer » ; dans les PME, le rôle de responsable de l'AIMS est souvent cumulé avec celui de RSSI ou de délégué à la protection des données.

A.4 (Resources for AI systems) exige la documentation des ressources (A.4.2), des ressources en données (A.4.3), en outils (A.4.4), en systèmes et en calcul (A.4.5) et en personnel (A.4.6). Pour les deployers d'agents, A.4.2 correspond au registre IA/agents, qui recense chaque agent en production avec sa finalité, son propriétaire, ses dépendances aux modèles, ses sources de données et sa classe de risque. C'est l'artefact le plus important pour l'échantillonnage d'audit.

A.5 (Assessing impacts of AI systems) définit le processus d'évaluation d'impact (A.5.2), sa documentation (A.5.3), ainsi que l'évaluation des impacts sur les individus et les groupes d'individus (A.5.4) et des impacts sociétaux (A.5.5). Ces quatre mesures sont le point d'ancrage opérationnel de la norme complémentaire ISO/IEC 42005:2025. Sur le plan fonctionnel, elles recoupent l'AIPD au titre de l'article 35 du RGPD et la FRIA au titre de l'article 27 du règlement européen sur l'IA, sans pour autant les remplacer.

A.6 à A.10 : cycle de vie, données, information, utilisation, tiers

A.6 (AI system lifecycle) est le domaine le plus vaste. Il couvre les objectifs du cycle de vie (A.6.1.2), la conception responsable (A.6.1.3), la spécification des exigences (A.6.2.2), la documentation de conception (A.6.2.3), la vérification et la validation (A.6.2.4), le déploiement (A.6.2.5), l'exploitation et la supervision (A.6.2.6), la documentation technique (A.6.2.7) et enfin la journalisation des événements (A.6.2.8). Cette dernière instaure une obligation explicite de journalisation qui va de pair, sur le plan fonctionnel, avec l'article 12 du règlement européen sur l'IA (journalisation pour l'IA à haut risque). A.6.2.8 est aussi la mesure dont les preuves sont le plus souvent insuffisantes dans les déploiements d'agents, car on n'y journalise généralement que les appels d'outils, et non les entrées du modèle, les traces de raisonnement ou les événements de reprise en main humaine.

A.7 (Data for AI systems) ancre la gouvernance des données : données pour le développement et l'amélioration (A.7.2), acquisition (A.7.3), qualité (A.7.4), provenance/origine (A.7.5) et préparation (A.7.6). A.7 sert de point d'ancrage au renvoi vers la série ISO/IEC 5259 et s'aligne conceptuellement sur l'article 10 du règlement européen sur l'IA. Point important : même si l'on utilise uniquement des modèles de fondation tiers, A.7 reste applicable. Le domaine couvre les données de retrieval/RAG, les templates de prompts et les jeux de données d'évaluation.

A.8 (Information for interested parties) couvre la documentation du système et les informations destinées aux utilisateurs, comme les model cards (A.8.2), le reporting externe (A.8.3), la communication sur les incidents (A.8.4) et l'information des parties prenantes (A.8.5). A.8.2 correspond étroitement à l'article 13 du règlement européen sur l'IA (transparence / notice d'utilisation), A.8.4 à l'article 73 (signalement des incidents graves) et aux obligations des deployers prévues à l'article 26.

A.9 (Use of AI systems) couvre les processus d'utilisation responsable (A.9.2), les objectifs correspondants (A.9.3) et l'utilisation prévue (A.9.4). A.9.4 est critique pour les deployers : si un agent est exploité en dehors de l'utilisation prévue déclarée par le fournisseur, le deployer (dans le règlement sur l'IA : déployeur) peut lui-même être considéré comme fournisseur en vertu de l'article 25, paragraphe 1, du règlement sur l'IA, par exemple lorsque la modification de la destination fait d'un système jusque-là non classé à haut risque un système d'IA à haut risque (point c). Un tel cas devrait déclencher automatiquement une nouvelle évaluation d'impact au titre de A.5.

A.10 (Third-party & customer relationships) encadre la répartition des responsabilités dans la chaîne de valeur (A.10.2), les fournisseurs (A.10.3) et les clients (A.10.4). Pour les deployers qui s'appuient sur des modèles de fondation ou des plateformes d'agents tiers, A.10.3 documente la répartition contractuelle et opérationnelle des rôles entre fournisseur et deployer, y compris la due diligence sur les certifications, la protection des données et la gestion des versions des modèles.

Comment l'annexe A s'intègre dans la SoA

L'annexe A ne s'applique pas en bloc : elle fait l'objet d'une sélection dans la déclaration d'applicabilité (SoA). La clause 6.1.3 impose la SoA, et lors d'un audit ISO 42001, c'est le document le plus examiné. Chaque mesure figure dans la SoA avec :

1. Référence et intitulé de la mesure (p. ex. A.6.2.8 Journalisation des événements)
2. Décision d'applicabilité (applicable / non applicable)
3. Justification (risque traité ou motif d'exclusion)
4. Statut de mise en œuvre (prévu / en cours / mis en œuvre / surveillé)
5. Renvoi aux preuves (politique, procédure, enregistrement, système)
6. Propriétaire

Le constat de non-conformité le plus fréquent dans la pratique d'audit 2024–2026 concerne les exclusions sans justification fondée sur les risques (un « n/a » assorti d'une ligne standard). Autres constats typiques : marquer une mesure comme applicable sans tenir à jour le document sous-jacent (par exemple A.4.2 « applicable » sans véritable registre des ressources), ou une SoA figée qui n'est pas mise à jour lors de l'arrivée de nouveaux agents ou d'un changement de modèle.

Exemple concret de mise en œuvre : agent de service client

Un deployer de taille moyenne (environ 800 salariés) exploite un agent de service client reposant sur un modèle de fondation tiers, connecté par RAG à la base de connaissances interne. Logique de la SoA pour les mesures critiques :

• A.4.2 applicable : entrée dans le registre IA/agents avec la finalité « support de premier niveau », propriétaire : le responsable du service client, dépendance aux modèles documentée, classe de risque « moyenne ».
• A.5.2–A.5.5 applicables : agent en contact avec les clients, ayant un effet sur des individus ; AISIA avec examen des droits fondamentaux et de la vie privée.
• A.6.2.8 applicable : journalisation du prompt et de l'instruction système, de l'identifiant et de la version du modèle, des appels d'outils, des requêtes de retrieval et des identifiants de documents, des sorties, ainsi que des événements de reprise en main humaine et d'escalade. Conservation : en règle générale, la plus longue des deux durées entre 6 mois et l'exigence sectorielle, avec justification dans la SoA.
• Mesures de développement de A.6 (p. ex. entraînement de modèles) : peuvent être partiellement exclues, faute de développement propre. Justification : « L'organisation ne développe pas de modèles d'IA ; tous les modèles proviennent de tiers, couverts par A.10.3. »
• Objectif mesurable (clause 6.2) : « ≥ 90 % de précision sur le jeu d'évaluation gold standard, mesure glissante sur 30 jours, reporting mensuel. »

Cette sélection tient en audit parce que chaque inclusion et chaque exclusion s'appuie sur une justification traçable fondée sur les risques, et parce que derrière chaque « applicable » se trouve un artefact réel.

Remarque : Cet article fournit une orientation technique et ne constitue pas un conseil juridique. Les correspondances avec le RGPD, le règlement européen sur l'IA et des numéros d'article précis (p. ex. art. 12, 13, 25, 35, 73) devraient être validées avec ton service juridique avant toute mise en œuvre contraignante.

Pour les agences et les décideurs B2B

Une organisation qui exploite des agents IA en production n'a pas besoin d'une « IA certifiée » : l'ISO 42001 certifie le système de management (AIMS/SMIA), pas le modèle individuel. Le chemin le plus rapide vers la préparation à l'audit passe par trois leviers : un registre IA/agents complet (A.4.2), une journalisation des événements fiable pour chaque agent (A.6.2.8) et une SoA tenue à jour, justifiée par les risques. Blck Alpaca aide les entreprises et les agences de toute l'Europe à mettre en place les mesures de l'annexe A de manière légère et solide en audit, en les intégrant aux systèmes ISO 27001/9001 existants et en les alignant sur les obligations du règlement européen sur l'IA qui les recoupent. Le catalogue de mesures devient ainsi un système de gouvernance pilotable plutôt qu'une collection de documents.