Déclaration d'applicabilité IA : SoA ISO 42001 décodée

Définition et place dans la norme

La déclaration d'applicabilité, souvent abrégée SoA pour Statement of Applicability, est le document qui formalise quels contrôles une organisation retient pour traiter ses risques liés à l'IA, et lesquels elle écarte. Elle est exigée par la clause 6.1.3 de la norme ISO/IEC 42001:2023, consacrée au traitement des risques liés à l'IA^[3].

Concrètement, la clause 6.1.3 demande à l'organisation de définir un processus de traitement des risques qui produit une SoA contenant les contrôles nécessaires et la justification de l'inclusion comme de l'exclusion de chaque contrôle^[3]. La justification d'exclusion peut s'appuyer sur le fait qu'un contrôle n'est pas jugé nécessaire par l'évaluation des risques, ou qu'il n'est pas requis, voire exclu, par les exigences externes applicables^[3].

La SoA s'inscrit dans la logique d'un SMIA structuré selon le cycle Planifier, Faire, Vérifier, Agir, comme les autres normes de systèmes de management ISO^[5]. Elle se positionne à la sortie de la planification : sans elle, le passage à l'opérationnel n'a pas de référentiel de contrôles assumé par la direction.

Contenu attendu d'une SoA conforme

Une SoA conforme à la clause 6.1.3 contient trois blocs d'information indissociables. D'abord, la liste des contrôles retenus pour traiter les risques identifiés. Ensuite, la justification de leur inclusion, c'est-à-dire le lien avec un risque, une exigence externe ou une attente de partie intéressée. Enfin, la justification des contrôles écartés, avec le motif de l'exclusion^[3].

La norme précise par une note que les justifications d'exclusion peuvent porter sur des objectifs de contrôle généraux ou sur des systèmes d'IA spécifiques, qu'il s'agisse de contrôles listés à l'Annexe A ou de contrôles définis par l'organisation elle-même^[3]. Autrement dit, la SoA n'est pas réservée aux contrôles de l'annexe. Elle peut consigner des contrôles propres si l'organisation en a créé.

En pratique, la majorité des SoA examinées sont organisées en tableau avec, par contrôle, son identifiant, son intitulé, son statut d'applicabilité, la justification, l'état de mise en place, le propriétaire et le renvoi à la documentation. Ce format n'est pas imposé par la norme, mais il facilite la lecture par l'auditeur^[3].

La clause 6.1.3 fixe un noyau dur ; tout le reste est de la mise en forme.

1Contrôles retenus

2Justification d'inclusion

3Justification d'exclusion

Source : ISO/IEC 42001:2023, clause 6.1.3, reformulée^[3].

Articulation avec l'Annexe A et les contrôles propres

La norme ISO/IEC 42001 publie en Annexe A un référentiel de contrôles de référence couvrant des thèmes comme la gouvernance des données, l'atténuation des biais, la réponse aux incidents ou la transparence^[5]. L'Annexe B fournit, elle, des lignes directrices de mise en œuvre^[5].

L'Annexe A joue donc le rôle de catalogue de référence : à chaque contrôle, l'organisation se positionne dans la SoA. Cette logique est familière à quiconque a travaillé sur ISO 27001, où la SoA est, depuis longtemps, la pièce centrale de l'analyse et de la décision de couverture des risques^[2].

Un point qui mérite d'être martelé : la SoA n'est pas une simple reproduction de l'Annexe A avec des cases cochées. Une organisation peut, et parfois doit, ajouter des contrôles spécifiques que l'annexe ne couvre pas, par exemple pour répondre à une exigence sectorielle ou à une obligation issue de l'AI Act^[3]. La note de la clause 6.1.3 ouvre explicitement la porte à ces contrôles établis par l'organisation^[3].

Justifier inclusions et exclusions

La qualité d'une SoA se lit dans ses justifications. Une inclusion bien justifiée renvoie à un risque évalué, à un système d'IA précis, ou à une exigence externe identifiée. Une exclusion solide explique pourquoi le contrôle est sans objet, et non pourquoi il est gênant à déployer.

La norme accepte deux grandes familles d'exclusion : l'évaluation des risques ne justifie pas le contrôle, ou des exigences externes applicables ne l'exigent pas, voire en dispensent^[3]. Concrètement, écarter un contrôle d'explicabilité au seul motif qu'il est coûteux est rarement défendable. L'écarter parce que les systèmes d'IA du périmètre sont uniquement des outils internes de pré-tri, sans décision affectant des personnes, est défendable, à condition que l'évaluation des risques l'établisse.

Cas concret romand. Une PME industrielle vaudoise déploie un assistant interne basé sur un modèle de langage tiers, exclusivement pour aider à la rédaction de notes techniques internes. Dans sa SoA, elle peut écarter certains contrôles liés aux interactions directes avec des personnes concernées par la décision d'un système d'IA, en justifiant l'absence de décision automatisée affectant des personnes externes. Elle conservera en revanche les contrôles relatifs à la qualité des données et à la responsabilité, attendus par la norme pour tout système d'IA en exploitation^[3]. Cette justification doit être tracée et datée, et elle est revue à chaque évolution du périmètre.

Construire la SoA, étape par étape

La SoA n'est pas un livrable de début de projet. Elle est l'aboutissement d'un enchaînement, et c'est ce qui en fait, pour un futur Lead Implementer, un excellent indicateur de maturité d'un SMIA.

• Définir le périmètre du SMIA et identifier les systèmes d'IA concernés.
• Identifier les parties intéressées et les exigences externes applicables, dont l'AI Act le cas échéant^[8].
• Conduire l'évaluation des risques liés à l'IA prévue par la clause 6.1.2.
• Définir le processus de traitement des risques, en s'appuyant sur l'Annexe A et sur des contrôles propres si nécessaire^[3].
• Rédiger la déclaration d'applicabilité : contrôles retenus, justifications d'inclusion et d'exclusion^[3].
• Faire valider la SoA par la direction, puis l'intégrer aux revues périodiques.

Une SoA produite avant l'évaluation des risques est, par construction, une SoA sans fondations. Les démarches observées montrent que l'inversion de cet ordre est l'un des écarts les plus fréquemment relevés lors des audits blancs réalisés par les organismes de certification accrédités^[1].

Un document vivant, pas une pièce d'archive

La SoA n'a de valeur que si elle reflète la situation réelle au moment où on la lit. Une publication de cabinet décrit la SoA comme un document vivant qui consigne les décisions sur les contrôles nécessaires et écartés à partir d'une évaluation des risques approfondie^[3]. C'est exactement cela : un cliché à jour, pas une photo d'archive.

Trois événements doivent déclencher une revue de la SoA. D'abord, toute évolution du périmètre, par exemple l'arrivée d'un nouveau système d'IA ou la mise hors service d'un autre. Ensuite, toute évolution réglementaire pertinente, l'AI Act et ses échéances en étant l'illustration la plus visible^[8]. Enfin, toute évolution significative du profil de risque, par exemple après un incident ou une modification de modèle.

À noter, à la date de publication de cet article, juin 2026, le marché de la certification ISO/IEC 42001 s'organise rapidement, avec des organismes qui structurent leurs offres d'audit et d'accompagnement en deux étapes^[5]. Cette dynamique renforce l'attention portée à la SoA pendant l'audit initial, mais aussi lors des audits de surveillance, où la cohérence entre SoA, registre des risques et preuves de mise en place est systématiquement examinée^[1].

Pièges fréquents observés

Premier piège : confondre la SoA et le plan de traitement des risques. Le plan décrit qui fait quoi, à quelle échéance, pour traiter chaque risque. La SoA, elle, fige le référentiel de contrôles applicables et leur justification. Les deux documents se complètent, ils ne se substituent pas.

Deuxième piège : recopier intégralement l'Annexe A en mettant tous les contrôles à applicable, sans véritable analyse. Cette approche cosmétique se détecte rapidement en audit, car les justifications d'inclusion deviennent génériques et déconnectées des risques évalués. Elle expose à un écart majeur sur la clause 6.1.3^[3].

Troisième piège : oublier les contrôles applicables aux tiers. Selon un éditeur GRC, la norme étend la gestion des risques aux pratiques de gouvernance de l'IA des fournisseurs, à la transparence, à l'explicabilité et aux mises à jour de modèles^[8]. À recouper avec le texte de la norme, mais l'angle est juste : une SoA qui ignore la chaîne d'approvisionnement IA passe à côté d'une partie du risque réel.

Quatrième piège, propre à la transition depuis ISO 27001 : penser que la SoA 27001 suffit. Le périmètre, les risques et les contrôles diffèrent. ISO/IEC 42001 cible les enjeux propres à l'IA, dont les biais, l'équité, l'impact sur les personnes concernées et la traçabilité des décisions^[5]. Une SoA dédiée s'impose, même si la structure du système de management est partagée avec un SMSI existant.

SoA ISO/IEC 42001 et SoA ISO/IEC 27001, ce qui change

Périmètre	Systèmes d'IA (cycle de vie complet) vs actifs et traitements d'information[5]
Référentiel de contrôles	Annexe A de la 42001 vs Annexe A de la 27001[3]
Risques couverts	Biais, équité, explicabilité, impact sociétal en plus de la sécurité[5]
Articulation externe	AI Act, NIST AI RMF, ISO 23894 pour la 42001[8]

Cinquième piège : ne pas dater la SoA et ne pas tracer ses versions. Sans historique, il devient difficile de démontrer en audit que les contrôles ont été revus à la suite d'un changement de périmètre ou d'un incident. La traçabilité est elle-même un contrôle, et la SoA en est le réceptacle naturel.

Questions fréquentes

À lire ensuite