SoA ISO 42001 : préparer la déclaration d'applicabilité

Le rôle de la SoA dans la clause 6.1.3

La clause 6.1.3 d'ISO/IEC 42001 demande à l'organisation de définir un processus de traitement des risques liés à l'IA, de sélectionner les contrôles nécessaires, de les comparer à l'Annexe A pour ne rien oublier, puis de produire une déclaration d'applicabilité approuvée par la direction^[2]. La SoA n'est donc pas une formalité administrative, c'est la pièce qui relie l'analyse de risque aux contrôles effectivement déployés.

Pour le SMIA, la SoA joue le même rôle structurant que dans ISO/IEC 27001 : elle liste les contrôles de référence, indique lesquels s'appliquent, et justifie chaque exclusion^[8]. La différence tient au contenu de l'Annexe A, centré sur les enjeux propres à l'IA, gouvernance, données, transparence, supervision humaine, incidents.

Un point souvent mal compris : la SoA ne se substitue ni au plan de traitement des risques, ni au registre des risques. Les trois documents coexistent et se référencent. Le plan de traitement décrit qui fait quoi et quand, la SoA fige l'état des contrôles à un instant donné avec leurs justifications^[2].

Entrées nécessaires avant de rédiger

Aborder la SoA sans préparation conduit à un document indéfendable. Trois entrées doivent être stabilisées en amont, sans quoi l'exercice tourne au remplissage de cases.

D'abord, un périmètre du SMIA clarifié : quels systèmes d'IA, quelles unités, quels processus sont couverts^[8]. Une SoA dont le périmètre est flou produit des contrôles flottants, applicables ou non selon la lecture. L'auditeur le détecte vite.

Ensuite, une analyse de risque IA documentée, prolongée par une analyse d'impact des systèmes concernés. Cette analyse fournit la matière première qui justifie pourquoi tel contrôle de l'Annexe A est retenu et pourquoi tel autre ne l'est pas^[8]. ISO/IEC 42001 est explicitement risk-driven, la sélection découle des risques, jamais l'inverse.

Enfin, une cartographie des politiques, procédures et preuves existantes. Une organisation déjà certifiée ISO/IEC 27001 réutilise une partie des contrôles d'accès, gestion des fournisseurs, gestion du changement, et ajoute les volets propres à l'IA, qualité des jeux de données, équité, supervision, suivi post-déploiement^[7]. La SoA matérialise ce recouvrement, à condition que les liens soient tracés.

Exemple romand

Pour une caisse de pension vaudoise qui utilise un modèle d'aide à la décision sur les rentes invalidité, le périmètre du SMIA peut se limiter à ce cas d'usage, à l'équipe métier qui l'opère et au prestataire qui héberge le modèle. La SoA reflétera ce périmètre étroit, avec une justification claire pour les contrôles non retenus, par exemple ceux liés au développement interne si le modèle est intégralement fourni par un tiers.

Structure d'une SoA défendable

Aucune mise en page n'est imposée. Les pratiques convergentes recommandent un tableau structuré, souvent un tableur, qui couvre les champs suivants^[8].

Structure recommandée pour rendre la SoA exploitable en audit comme en interne.

1Référence et libellé du contrôle Annexe A

2Applicable oui ou non

3Justification basée sur le risque

4Statut d'implémentation

5Politiques, procédures et preuves liées

Source : pratique documentée par les guides de mise en oeuvre^[8].

Cette structure paraît évidente. Elle ne l'est pas dans la pratique observée : beaucoup de SoA s'arrêtent à la colonne 3, sans statut réel, sans pointeur vers les preuves. L'auditeur ne peut alors pas tester l'implémentation, il signale l'écart.

Une bonne SoA ajoute parfois deux colonnes utiles, le propriétaire du contrôle et la date de dernière revue. Cela évite les contrôles orphelins et facilite l'audit interne prévu par la clause 9.2^[1].

Justifier inclusions et exclusions

La justification est le coeur de la SoA. ISO/IEC 42001 n'impose pas l'ensemble de l'Annexe A, mais exige une explication pour chaque décision^[8]. Deux pièges à éviter.

Premier piège, la justification d'inclusion réduite à une formule générique du type contrôle requis pour la gouvernance. L'auditeur attend un lien explicite vers un risque identifié dans le registre, ou vers une attente d'une partie intéressée, ou vers une obligation réglementaire applicable.

Second piège, l'exclusion mal argumentée. Exclure un contrôle parce qu'il est jugé non pertinent ne suffit pas. La justification doit montrer soit que le risque adressé n'existe pas dans le périmètre, soit qu'il est traité par un autre dispositif déjà en place^[2]. Certains contrôles, comme l'existence d'une politique IA, sont en pratique difficiles à exclure parce que les clauses principales les exigent sous une forme ou une autre^[8].

Interprétation : pour les organisations qui développent peu d'IA en interne et consomment surtout des services tiers, les contrôles liés au cycle de développement peuvent être partiellement transférés au fournisseur. La SoA doit alors expliciter ce transfert, et le plan de traitement renvoyer aux clauses contractuelles correspondantes. Sinon, l'exclusion ressemble à un évitement.

Lier contrôles, politiques et preuves

Une SoA isolée ne vaut rien. Sa valeur tient à ses renvois. Chaque contrôle retenu doit pointer vers une politique, une procédure ou un enregistrement qui prouve son existence et son fonctionnement^[3].

Les preuves typiques observées dans les démarches IA incluent : politique de gouvernance IA, politique de gestion des risques IA, procédure d'évaluation des systèmes, fiches de modèle, résultats de tests d'équité et de robustesse, journaux d'incidents, registres d'approbation des modèles, revues de fournisseurs^[7]. La liste varie selon le périmètre, l'esprit reste le même : la SoA est un index navigable, pas un document terminal.

Une pratique utile consiste à étiqueter les contrôles par système ou par cas d'usage, pour qu'une équipe produit sache exactement ce qui s'applique à son périmètre^[3]. Cela évite le défaut classique d'une SoA d'entreprise qui décrit des contrôles génériques sans rattachement opérationnel.

Quand l'organisation opère aussi sous ISO/IEC 27001, RGPD ou s'aligne sur le règlement européen sur l'IA, la même SoA peut servir de point d'ancrage pour signaler les recoupements, à condition de ne pas dupliquer la gouvernance^[3]. C'est un gain réel d'efficacité, à manier avec rigueur pour ne pas mélanger les périmètres.

Ce que l'auditeur regarde réellement

La certification ISO/IEC 42001 est attribuée par un organisme tiers accrédité, qui audite le SMIA pour vérifier sa conformité aux exigences de la norme^[1]. Le cycle suit le modèle classique des normes ISO de management : audit initial, audits de surveillance annuels, renouvellement à trois ans^[1].

Sur la SoA, trois questions reviennent en audit.

• La SoA couvre-t-elle tous les contrôles de l'Annexe A, sans omission silencieuse.
• Chaque inclusion et chaque exclusion est-elle justifiée par référence à l'analyse de risque et à l'analyse d'impact.
• Les preuves citées existent-elles, sont-elles à jour, et reflètent-elles ce que l'organisation fait réellement.

Une SoA qui répond non sur l'un de ces trois points produit une non-conformité majeure ou un cluster d'observations qui bloque la recommandation de certification. Selon la pratique documentée par les certificateurs, un audit de référence préalable, ou audit à blanc, sert souvent à dégrossir ces écarts avant l'audit officiel^[4].

Interprétation : pour un Lead Implementer, la SoA est aussi un outil de pilotage. Les contrôles marqués partiellement en place avec une date cible permettent de montrer à l'auditeur que l'amélioration continue est réelle, pas cosmétique. Une SoA où tout est implémenté à 100 % du premier coup éveille au contraire la méfiance.

Pièges fréquents et angles morts

Plusieurs angles morts reviennent dans les démarches observées et les retours de praticiens.

Premier angle mort, la SoA traitée comme une formalité, copiée d'un modèle générique et déconnectée du registre des risques^[3]. Le test simple : prendre un contrôle au hasard et demander quel risque il traite. Si personne ne sait répondre en interne, la SoA ne survivra pas à l'audit.

Deuxième angle mort, l'absence de signature ou d'approbation formelle par la direction. La clause 6.1.3 exige une approbation par le management désigné^[2]. Une SoA en version brouillon, sans validation tracée, est une non-conformité immédiate.

Troisième angle mort, la confusion entre SoA ISO/IEC 27001 et SoA ISO/IEC 42001. Les deux coexistent, elles ne fusionnent pas. Même quand le SMIA s'appuie sur un SMSI existant, la certification 42001 exige son propre périmètre et son propre audit^[7].

Quatrième angle mort, l'oubli des risques propres à l'IA, biais, qualité des données, dérive du modèle, hallucinations, supervision humaine, explicabilité^[7]. Une SoA qui recycle un contenu sécurité de l'information sans aborder ces sujets ne reflète pas un SMIA, elle reflète un SMSI déguisé.

Cinquième angle mort, la SoA figée. La norme attend un document vivant, mis à jour quand les systèmes, les risques ou la réglementation évoluent^[8]. Une SoA datée d'un an sans aucune trace de revue est un signal négatif.

Maintenir la SoA vivante

La SoA ne vit que si elle est intégrée aux routines du SMIA. Trois mécanismes simples y contribuent.

La revue de direction prévue par la clause 9.3 examine périodiquement l'efficacité du SMIA, ce qui inclut la pertinence des contrôles retenus^[1]. Inscrire la SoA à l'ordre du jour évite qu'elle ne dérive du réel.

L'audit interne prévu par la clause 9.2 teste un échantillon de contrôles à chaque cycle. Documenter les écarts trouvés dans une colonne de la SoA, avec date de correction, donne à l'auditeur externe une lecture immédiate de la maturité du système^[1].

La gestion des changements prévue par la clause 6.3 déclenche une révision de la SoA quand un nouveau système d'IA entre dans le périmètre, quand un fournisseur change, ou quand un cadre réglementaire évolue^[1]. Selon la pratique documentée par plusieurs guides en 2025 et 2026, l'arrivée du règlement européen sur l'IA et l'évolution des cadres nationaux justifient à elles seules une revue annuelle minimale, à vérifier au regard de la situation à la date de lecture^[5].

Pour un consultant ou un futur Lead Implementer, l'enjeu pratique tient en une phrase. La SoA n'est pas le livrable final du projet de certification, c'est son tableau de bord permanent. Si elle est construite ainsi, l'audit ne sera pas une épreuve, juste une lecture.

Questions fréquentes

À lire ensuite