Statement of Applicability ISO 42001 : 38 contrôles expliqués pour les PME

L'essentiel en 30 secondes

  • Le Statement of Applicability (SoA) est le document central de la norme ISO/IEC 42001:2023 : il liste les contrôles retenus, ceux exclus, et les justifications associées.
  • L'Annexe A de l'ISO 42001 contient 38 contrôles répartis en 9 objectifs, couvrant la gouvernance, les ressources, la conception, l'exploitation et l'évaluation des systèmes d'IA.
  • Sans SoA, aucune certification ISO 42001 n'est délivrable : c'est le pivot de l'audit de stade 2 mené par l'organisme certificateur.
  • Le SoA doit être révisé au minimum une fois par an et à chaque changement majeur (nouveau cas d'usage IA, modification du périmètre, évolution réglementaire).
  • Pour les PME concernées par les systèmes d'IA à haut risque au sens du Règlement (UE) 2024/1689, le SoA s'articule directement avec les obligations des Articles 9, 10, 14 et 17 de l'AI Act.
  • Un SoA mal documenté peut entraîner un refus de certification et fragiliser la défense en cas de contrôle CNIL ou d'enquête de l'autorité de surveillance du marché.

1. Introduction au Statement of Applicability (SoA) ISO 42001

Le Statement of Applicability — déclaration d'applicabilité en français — est exigé par la clause 6.1.3 d) de la norme ISO/IEC 42001:2023. C'est un livrable contractuel pour toute organisation qui vise la certification de son système de management de l'intelligence artificielle (AIMS).

Le SoA ne se résume pas à une simple checklist. Il documente trois choses : les contrôles retenus parmi les 38 listés en Annexe A, les contrôles exclus, et la justification de chaque décision. Cette traçabilité est ce que l'auditeur certificateur examinera en priorité lors du stade 2.

Pour une PME française de 10 à 250 salariés qui exploite un ou plusieurs systèmes d'IA — recommandation produit, scoring RH, automatisation documentaire — le SoA structure la démarche de conformité. Il rend explicite ce que l'organisation fait et ne fait pas, et pourquoi.

L'obligation légale n'est pas directe : aucun texte français n'impose l'ISO 42001. Mais la certification devient un actif concurrentiel et un élément de preuve pour démontrer la conformité au Règlement (UE) 2024/1689 (l'AI Act), notamment pour les fournisseurs de systèmes à haut risque visés à l'Article 17 du Règlement.

Le SoA est au système IA ce que le registre des traitements est au RGPD : un document vivant, opposable, et la première chose qu'un auditeur ouvrira.

2. Les 38 contrôles clés de l'ISO 42001 (Annexe A)

L'Annexe A normative de l'ISO/IEC 42001:2023 organise les 38 contrôles en 9 objectifs (A.2 à A.10). Voici la cartographie synthétique.

Domaine Référence Annexe A Nombre de contrôles Finalité
Politiques relatives à l'IA A.2 2 Définir et approuver une politique IA
Organisation interne A.3 3 Rôles, responsabilités, reporting
Ressources pour les systèmes d'IA A.4 6 Données, compétences, infrastructures
Évaluation d'impact A.5 4 AI Impact Assessment, processus, documentation
Cycle de vie du système d'IA A.6 10 Conception, développement, vérification, déploiement
Données pour les systèmes d'IA A.7 4 Qualité, traçabilité, gestion des données
Information pour les parties intéressées A.8 4 Documentation, transparence utilisateur
Utilisation des systèmes d'IA A.9 2 Procédures d'usage responsable
Tiers et clients A.10 3 Allocation des responsabilités, fournisseurs

Soit un total de 38 contrôles. Chacun porte une référence du type A.6.2.4 (politique de développement) et un objectif explicite. Le SoA doit traiter chaque ligne sans exception.

2.1 Contrôles de gouvernance (A.2 et A.3)

Les cinq contrôles de gouvernance fixent le cadre : approbation d'une politique IA par la direction (A.2.2), allocation claire des rôles (A.3.2), reporting des préoccupations IA (A.3.3). Pour une PME, ces contrôles sont rarement exclus — ils constituent le socle minimal exigé par l'auditeur.

2.2 Contrôles de ressources (A.4)

Six contrôles couvrent les données, les outils, le calcul, les ressources humaines, les ressources système et le cycle de vie matériel. C'est ici que la PME documente ses pipelines de données, les compétences IA en interne, et l'infrastructure (cloud, on-premise).

2.3 Contrôles de cycle de vie (A.6)

Le bloc le plus dense, avec 10 contrôles : objectifs du système, exigences, conception, vérification, validation, déploiement, exploitation, surveillance, journalisation, gestion des incidents. Il recouvre largement les exigences des Articles 9 (gestion des risques) et 17 (système de management de la qualité) de l'AI Act.

2.4 Contrôles de données (A.7)

Quatre contrôles dédiés à la donnée d'entraînement, de test, de production : qualité, provenance, gestion. Articulation directe avec l'Article 10 du Règlement (UE) 2024/1689 et les obligations RGPD documentées dans les fiches pratiques IA de la CNIL.

3. Étape 1 : Identifier les contrôles applicables

L'identification des contrôles applicables s'effectue par croisement de trois inputs : l'analyse de risque IA, le périmètre du système de management, et les obligations légales applicables.

  1. Cartographier les systèmes d'IA exploités — interne, externe, fournisseur tiers, sous-traitant. Chaque système est qualifié au regard de l'AI Act (interdit, haut risque, risque limité, risque minimal).
  2. Conduire l'AI Impact Assessment prévu au contrôle A.5.2. Cette évaluation identifie les risques (biais, sécurité, atteinte aux droits fondamentaux) et les mesures de traitement.
  3. Recenser les exigences légales : Règlement (UE) 2024/1689, RGPD, sectorielles (ACPR, ANSM, ARCEP selon l'activité).
  4. Sélectionner les contrôles qui répondent aux risques identifiés et aux exigences légales.

Pour une PME qui développe ou met sur le marché un système d'IA classé à haut risque, aucun contrôle ne peut être exclu sans justification renforcée : l'auditeur considérera par défaut l'ensemble de l'Annexe A applicable.

Type de PME Profil typique Contrôles probablement applicables
PME utilisatrice (déployeur) Utilise un SaaS d'IA générative pour automatiser le support A.2 à A.5, A.8, A.9, A.10
PME développeur (fournisseur) Conçoit un modèle de scoring vendu en marque blanche Les 38 contrôles de l'Annexe A
PME intégrateur Combine plusieurs API d'IA dans un produit propriétaire A.2 à A.10 selon les composants intégrés

Besoin d'un SoA prêt à auditer ?

Nos modèles de Statement of Applicability ISO 42001 sont préremplis avec les 38 contrôles, leurs justifications types et l'articulation avec les obligations de l'AI Act. Adaptés aux PME françaises de 10 à 250 salariés.

Demander un échantillon de pack ISO 42001

4. Étape 2 : Justifier l'absence de contrôles

Lorsqu'un contrôle de l'Annexe A est exclu, la justification doit être documentée dans le SoA. Une exclusion non motivée est le motif de non-conformité majeure le plus fréquent en audit ISO 42001.

Une justification recevable répond à trois critères :

  • Factuelle : elle s'appuie sur le périmètre, la nature de l'activité ou la qualification du système. Exemple : « Le contrôle A.10.4 (responsabilité des clients) est exclu : l'organisation n'agit pas comme fournisseur, elle n'a pas de clients utilisateurs de systèmes d'IA. »
  • Tracée : elle renvoie à la cartographie des systèmes et à l'analyse de risque.
  • Proportionnée au risque résiduel : elle démontre que l'exclusion ne crée pas de risque inacceptable pour les parties prenantes.
Type de justification Exemple recevable Exemple non recevable
Périmètre « Pas de développement interne, uniquement déploiement de SaaS tiers » « Trop complexe à mettre en œuvre »
Nature du système « Aucun système d'IA classé haut risque selon l'Annexe III du Règlement (UE) 2024/1689 » « Pas concerné » (sans précision)
Substitution équivalente « Contrôle couvert par les exigences ISO 27001 déjà certifiées » « Pas le temps cette année »

La règle pratique : si la justification tient en moins de 30 mots, elle est probablement insuffisante.

5. Étape 3 : Mettre en œuvre les contrôles

La mise en œuvre transforme la sélection théorique en pratique opérationnelle. Trois chantiers s'enchaînent.

5.1 Définir les responsabilités

Le contrôle A.3.2 exige une matrice RACI claire. Pour une PME, les rôles classiques sont :

  • Direction générale : approbation politique IA, allocation budget, validation SoA.
  • DPO : articulation RGPD/IA, AI Impact Assessment, registre des traitements.
  • IA Lead ou CTO : conception, déploiement, surveillance technique.
  • RSSI : sécurité des modèles et des données, gestion des incidents.
  • Métier (utilisateur final) : remontée des dérives, contrôle humain (Art. 14 du Règlement).

5.2 Planifier les ressources

Pour une PME de 50 salariés, l'effort initial de mise en œuvre des 38 contrôles est typiquement de 30 à 60 jours-homme répartis sur 6 à 9 mois. Le coût de certification (audit stade 1 + stade 2) varie selon les organismes mais reste un poste à isoler dans le budget initial [à vérifier auprès de l'organisme certificateur retenu].

5.3 Implémenter les processus

Chaque contrôle se traduit par un livrable : politique, procédure, registre, modèle, journal, rapport. Le SoA renvoie à ces livrables — c'est ce qui rend la déclaration auditable.

Contrôle Livrable type Responsable
A.2.2 — Politique IA Politique IA signée par la direction Direction générale
A.5.2 — AI Impact Assessment Rapport AIIA par système DPO + IA Lead
A.6.2.6 — Vérification et validation Plan de tests, rapports de validation IA Lead
A.6.2.8 — Surveillance opérationnelle Tableau de bord, logs RSSI / IA Lead
A.7.4 — Gestion de la qualité des données Procédure data quality, jeu de tests DPO + Data Manager

6. Étape 4 : Vérifier et valider le SoA

La vérification du SoA passe par un audit interne (clause 9.2 de l'ISO 42001) avant l'audit externe de certification.

L'auditeur interne — qui doit être indépendant du périmètre audité — examine trois éléments :

  1. Complétude : les 38 contrôles sont-ils traités, retenus ou exclus avec justification ?
  2. Cohérence : la sélection des contrôles est-elle alignée avec l'analyse de risque et les obligations légales ?
  3. Preuves : pour chaque contrôle retenu, existe-t-il une preuve de mise en œuvre datée et accessible ?

En pratique, un audit interne ISO 42001 dure 2 à 5 jours pour une PME, selon la complexité des systèmes d'IA et la maturité du système de management.

Les preuves attendues sont des artefacts datés : politiques signées, comptes rendus de comité IA, rapports d'AI Impact Assessment, journaux d'incidents, rapports de surveillance, plans de formation. La règle : si un contrôle ne génère pas de preuve, il n'est pas réellement mis en œuvre.

7. Étape 5 : Maintenir et mettre à jour le SoA

Le SoA est un document vivant. La clause 10.1 de l'ISO 42001 impose une amélioration continue, et la clause 9.3 prévoit une revue de direction au minimum annuelle.

Trois déclencheurs imposent une révision du SoA hors calendrier annuel :

  • Changement de périmètre : nouveau cas d'usage IA, acquisition d'une activité, ouverture d'un nouveau marché.
  • Changement réglementaire : nouvelle obligation issue de l'AI Act (par exemple, l'entrée en application progressive du Règlement (UE) 2024/1689 entre 2025 et 2027), évolution des lignes directrices CNIL, nouvelles normes harmonisées.
  • Incident significatif : biais détecté, fuite de données d'entraînement, atteinte aux droits fondamentaux.

Chaque révision donne lieu à une nouvelle version du SoA, datée et approuvée par la direction. La traçabilité des versions est elle-même contrôlée (A.4.6 — gestion documentaire du cycle de vie).

8. Exemples de SoA pour PME

8.1 PME de 50 salariés — système d'IA interne

Contexte : éditeur SaaS B2B, 50 salariés, utilise un modèle de classification d'emails de support entraîné en interne sur ses propres données.

Domaine Annexe A Décision Justification
A.2 Politique IA Retenu Système développé en interne, gouvernance requise
A.5 Évaluation d'impact Retenu Traitement de données clients, RGPD applicable
A.6 Cycle de vie complet Retenu (10 contrôles) Rôle de fournisseur au sens AI Act
A.10.4 Responsabilités client Exclu Modèle non commercialisé en marque blanche

Total : 37 contrôles retenus, 1 exclu avec justification.

8.2 PME de 150 salariés — système d'IA externe

Contexte : cabinet de conseil RH, 150 salariés, utilise un outil tiers de scoring de CV sous licence SaaS.

Domaine Annexe A Décision Justification
A.2 et A.3 Gouvernance Retenu Déployeur d'un système classé haut risque (Annexe III, point 4 du Règlement)
A.6 Cycle de vie Retenu partiel (5/10) L'organisation est déployeur, pas fournisseur
A.7 Données Retenu Données candidats sensibles
A.10 Tiers Retenu intégral Contractualisation avec le fournisseur du système

Total : environ 30 contrôles retenus, 8 exclus avec justification documentée du rôle de déployeur.

8.3 Conseils pour simplifier le SoA

  • Adopter un format tableur unique : référence du contrôle, libellé, statut (retenu/exclu), justification, livrable, responsable, date de revue.
  • Mutualiser les preuves avec d'autres référentiels : un contrôle d'accès ISO 27001 peut couvrir partiellement un contrôle ISO 42001.
  • Limiter la prose : l'auditeur valorise la précision, pas la longueur.
  • Tenir une matrice de correspondance avec les Articles de l'AI Act pour démontrer la double conformité.

9. Liens avec l'AI Act et le RGPD

Le SoA ISO 42001 n'est pas isolé. Il s'articule avec deux corpus juridiques majeurs.

9.1 Articulation avec l'AI Act

Le Règlement (UE) 2024/1689 impose, à l'Article 17, un système de management de la qualité pour les fournisseurs de systèmes d'IA à haut risque. La certification ISO 42001 est l'un des moyens reconnus pour démontrer la conformité à cette exigence, dans l'attente des normes harmonisées en cours de développement par le CEN-CENELEC JTC 21.

Article AI Act Obligation Contrôle ISO 42001 correspondant
Art. 9 Système de gestion des risques A.5.2, A.5.3, A.5.4
Art. 10 Gouvernance des données A.7.2, A.7.3, A.7.4, A.7.5
Art. 13 Transparence et information aux déployeurs A.8.2, A.8.3, A.8.4
Art. 14 Contrôle humain A.9.2, A.9.3
Art. 15 Exactitude, robustesse, cybersécurité A.6.2.6, A.6.2.7, A.6.2.8
Art. 17 Système de management de la qualité L'ensemble du SoA
Art. 72 Surveillance après commercialisation A.6.2.8, A.6.2.9

Le SoA devient ainsi une preuve mobilisable face à l'autorité de surveillance du marché. Les sanctions prévues à l'Article 99 du Règlement — détaillées dans notre article sanctions AI Act pour les PME — peuvent atteindre 7% du chiffre d'affaires mondial pour les violations les plus graves.

9.2 Articulation avec le RGPD

Plusieurs contrôles de l'Annexe A recoupent directement le RGPD :

  • A.5.2 (AI Impact Assessment) complète mais ne remplace pas l'analyse d'impact relative à la protection des données (AIPD) prévue à l'Article 35 du RGPD.
  • A.7.2 à A.7.5 (gestion des données) s'articulent avec les principes de licéité, minimisation et exactitude (Art. 5 RGPD).
  • A.8.4 (information aux utilisateurs) s'articule avec les Articles 12 à 14 du RGPD.

La CNIL recommande, dans ses fiches pratiques IA, d'articuler explicitement les deux démarches — c'est un point de vigilance fort en audit.

Pack ISO 42001 + AI Act pour PME

SoA préremplis, AI Impact Assessment, matrice de correspondance avec les Articles 9 à 17 du Règlement (UE) 2024/1689, registres types : nos modèles documentaires couvrent l'intégralité des 38 contrôles, prêts à être adaptés à votre activité.

Recevoir un devis personnalisé

10. FAQ sur le SoA ISO 42001

Qu'est-ce qu'un Statement of Applicability (SoA) ?

Le SoA est le document, exigé par la clause 6.1.3 d) de l'ISO/IEC 42001:2023, qui identifie les contrôles de l'Annexe A applicables à votre organisation et justifie l'absence des contrôles exclus. Il est essentiel pour la certification.

Combien de contrôles l'ISO 42001 comporte-t-il ?

L'ISO/IEC 42001:2023 comporte 38 contrôles répartis sur 9 objectifs en Annexe A : politiques (A.2), organisation interne (A.3), ressources (A.4), évaluation d'impact (A.5), cycle de vie (A.6), données (A.7), information aux parties intéressées (A.8), usage (A.9), tiers et clients (A.10). Chaque contrôle doit être évalué pour sa pertinence.

Dois-je mettre à jour mon SoA régulièrement ?

Oui. La revue est annuelle au minimum, et déclenchée à chaque changement majeur : nouveau système d'IA, modification du périmètre, évolution de l'AI Act ou du RGPD, incident significatif. Cela garantit la pertinence et l'opposabilité du document.

Quelles sont les conséquences d'un SoA incorrect ?

En audit ISO 42001, un SoA incomplet ou mal justifié est un motif de non-conformité majeure qui suspend la certification. Au-delà, en cas de contrôle de l'autorité de surveillance du marché, l'absence de SoA documenté affaiblit la défense de l'organisation et expose aux sanctions de l'Article 99 du Règlement (UE) 2024/1689.

Comment l'AI Act influence-t-il le SoA ?

Le Règlement (UE) 2024/1689 impose des exigences spécifiques pour les systèmes d'IA à haut risque (Articles 9 à 17). Le SoA doit donc traiter ces obligations en retenant les contrôles correspondants — typiquement A.5, A.6, A.7 et A.8 dans leur intégralité. La matrice de correspondance entre Articles AI Act et contrôles Annexe A est attendue par l'auditeur.

11. Sources officielles

Pour aller plus loin, consultez notre pillar AI Act pour les PME françaises, notre analyse des sanctions et amendes prévues par l'Article 99, notre glossaire juridique IA et la liste complète de nos sources officielles.


Disclaimer — Cet article fournit des informations générales sur l'EU AI Act et l'ISO/IEC 42001:2023 applicables aux PME françaises. Il ne constitue pas un conseil juridique. Pour toute décision opérationnelle, faites valider votre démarche par votre DPO ou conseil juridique. regulia décline toute responsabilité quant à l'usage qui peut être fait de ces informations.