Clause 6 ISO 42001 : risques, impact et SoA

La clause 6 est la plus dense de la norme et celle sur laquelle se concentrent les écarts d’audit. Elle compte trois sous-clauses, dont la première se subdivise elle-même : les risques et opportunités à traiter, avec les critères de risque (6.1.1), l’appréciation du risque (6.1.2), son traitement (6.1.3) et l’évaluation d’impact (6.1.4) ; puis les objectifs (6.2) et la planification des changements (6.3). Les cinq premières portent chacune plusieurs exigences ; la dernière tient en une seule.

Deux points y sont décisifs et fréquemment mal rapportés, y compris par des organismes certificateurs. Le premier : la déclaration d’applicabilité relève de 6.1.3 f), et non de la clause 6.3, qui traite des changements. Le second : l’évaluation d’impact de 6.1.4 est une exigence, pas une bonne pratique facultative.

6.1.1 — Risques, opportunités et critères

Ce que dit la norme6.1.1

La sous-clause fait d’abord établir des critères de risque propres à l’IA, entretenus dans la durée, qui servent à la fois à apprécier les risques, à les traiter, à évaluer leurs impacts et à trancher entre risque acceptable et risque qui ne l’est pas. Elle fait ensuite déterminer les risques et opportunités à traiter. L’organisme les tire de ses enjeux (4.1) et des exigences des parties intéressées (4.2), et les examine à la lumière de l’usage auquel chaque système d’IA est destiné, de son domaine et de son contexte d’application, ainsi que du contexte interne et externe relevé en 4.1. Le but est triple : progresser en continu, prévenir ou limiter les effets indésirables, et s’assurer que le système de management peut produire les résultats attendus. Elle fait enfin planifier les actions qui répondent à ces risques et opportunités, la manière de les intégrer aux processus du système de management et de les y mettre en œuvre, et la manière d’en juger l’efficacité. Une information documentée sur les actions menées pour repérer et traiter ces risques et opportunités est conservée. Une note, informative, indique que lorsque plusieurs systèmes d’IA entrent dans le périmètre, cette détermination se mène par système ou par groupe de systèmes.

L’ordre importe. Des risques notés sans critères préalables ne sont pas comparables entre eux, et la décision d’acceptation devient une appréciation personnelle qu’aucun auditeur ne peut suivre. Le critère d’acceptation est la partie qu’on oublie : il dit à quel niveau un risque doit être traité plutôt que toléré.

6.1.2 — L’appréciation du risque, à partir de vos objectifs

Ce que dit la norme6.1.2

L’organisme se dote d’un processus d’appréciation du risque lié à l’IA, qu’il définit et met en place. Ce processus s’appuie sur la politique IA (5.2) et sur les objectifs IA (6.2), avec lesquels il reste aligné ; il est conçu pour que des appréciations répétées livrent des résultats comparables, cohérents et valides ; et il fait l’objet d’une information documentée conservée. À chaque appréciation, il repère les risques susceptibles de servir ou d’entraver les objectifs IA. Il les analyse ensuite : niveau de chaque risque, vraisemblance réaliste lorsque la notion s’applique, et conséquences potentielles si le risque se concrétisait, pour l’organisation comme pour les individus et les sociétés. Il les évalue enfin, en rapprochant cette analyse des critères de 6.1.1 pour fixer l’ordre de priorité du traitement. Une note, informative, permet de s’appuyer sur l’évaluation d’impact de 6.1.4 pour apprécier ces conséquences.

C’est ici que se joue la confusion la plus coûteuse de la norme, et elle court dans les deux sens. On lit souvent que l’appréciation de 6.1.2 ne regarde que l’organisation, et l’évaluation d’impact de 6.1.4 les personnes. C’est inexact : 6.1.2 demande déjà d’analyser les conséquences d’un risque pour les individus et les sociétés.

Ce qui distingue les deux processus, c’est leur angle. L’appréciation du risque part des objectifs que l’organisation s’est fixés en matière d’IA et construit un portefeuille de risques à hiérarchiser et à traiter. L’évaluation d’impact prend un système d’IA et examine ce qu’il peut produire sur des personnes, des groupes et les sociétés, qu’il soit utilisé comme prévu ou détourné de façon prévisible, dans le contexte technique et sociétal où il est déployé et selon les juridictions en cause. La norme les relie explicitement : les résultats de la seconde doivent être pris en compte dans la première, qui peut s’appuyer sur elle pour apprécier les conséquences.

6.1.3 — Le traitement, et la déclaration d’applicabilité

Ce que dit la norme6.1.3

Le processus de traitement du risque lié à l’IA est défini par l’organisme et part des résultats de l’appréciation. Il débouche sur deux livrables : un plan de traitement, et une déclaration d’applicabilité qui recense les contrôles nécessaires, qu’ils viennent de l’Annexe A ou d’ailleurs, en motivant aussi bien chaque inclusion que chaque exclusion. Pour y parvenir, il choisit des options de traitement appropriées et arrête l’ensemble des contrôles qu’elles appellent : il retient dans l’Annexe A ceux qui servent ces options, recherche ceux qu’il faut ajouter au-delà, puis rapproche le tout du catalogue de l’Annexe A pour s’assurer qu’aucun contrôle nécessaire ne manque ; pour leur mise en œuvre, il tient compte des lignes directrices de l’Annexe B. La direction désignée approuve le plan de traitement ainsi que l’acceptation des risques résiduels. Les contrôles nécessaires, eux, sont diffusés en interne, disponibles sous forme d’information documentée, accessibles selon le cas aux parties intéressées et cohérents avec les objectifs IA de 6.2. Le processus de traitement fait lui-même l’objet d’une information documentée conservée. Des notes, informatives, rappellent que l’Annexe A n’est pas exhaustive.

L’alinéa f) est le plus mal cité de la norme. C’est lui qui porte la déclaration d’applicabilité — et cela a une conséquence directe sur la nature de l’Annexe A. L’Annexe A est normative, mais cela ne rend pas ses 38 contrôles obligatoires : ce qui est exigé, c’est la comparaison avec le catalogue et la justification de chaque décision.

Pour les exclusions, le texte est plus ouvert qu’on ne le lit souvent. La déclaration contient tous les contrôles que les options de traitement retenues rendent nécessaires : un tel contrôle y figure donc forcément. Pour motiver une exclusion, la norme cite deux éléments qu’une justification peut comprendre, sans en faire une liste fermée : l’appréciation des risques ne rend pas le contrôle nécessaire, et aucune exigence externe applicable ne l’impose, ou elle prévoit une exception. Une justification solide examine les deux. Le coût et la difficulté ne figurent pas parmi ces éléments ; en pratique, une exclusion qui ne repose que sur eux se défend mal, car renoncer à traiter un risque revient à l’accepter, et cette acceptation doit être approuvée par la direction désignée.

Les preuves à préparer6.1.3

La déclaration d'applicabilité, contrôle par contrôle, avec justification des inclusions et des exclusionsInformation documentée exigée — 6.1.3
Le plan de traitement approuvé, avec responsables et échéances
Le lien explicite entre chaque risque et la mesure qui le traite, repris dans la déclaration d'applicabilitéInformation documentée exigée — 3.26, note 2
L'acceptation écrite des risques résiduels par la direction désignée
Le processus de traitement des risques, écritInformation documentée exigée — 6.1.3
La preuve que les contrôles retenus sont connus en interne, et accessibles aux parties intéressées lorsque c'est pertinent

Les autres éléments sont des pratiques que nous recommandons ; plusieurs rendent visible une activité que la norme exige sans en imposer la trace écrite.

6.1.4 — L’évaluation d’impact du système d’IA

C’est une exigence, formulée comme telle, et c’est probablement le point où la littérature commerciale égare le plus ses lecteurs. La clause 6.1.4 impose de définir le processus et de documenter les résultats ; la clause 8.4 impose de le mettre en œuvre à intervalles planifiés et lorsque des changements significatifs sont envisagés. Les contrôles A.5.2 à A.5.5 en fournissent le détail opérationnel.

L’évaluation d’impact n’est pas une analyse d’impact relative à la protection des données. Les deux peuvent se compléter — un système de tri de candidatures relève souvent des deux — mais leur objet diffère : l’une regarde le traitement de données personnelles, l’autre les conséquences du système, y compris quand aucune donnée personnelle n’est en jeu.

6.2 — Les objectifs relatifs à l’IA

Un objectif mesurable se suit plus facilement et se défend mieux en audit ; quand la mesure n’est pas possible, 6.2 impose tout de même de le suivre. « Améliorer l’éthique de nos systèmes » ne se mesure pas. « Disposer d’une évaluation d’impact à jour pour les systèmes en production avant la fin du semestre » se mesure, et se vérifie.

6.3 — La planification des changements

Sous-clause brève, et régulièrement confondue avec la déclaration d’applicabilité — qui n’est pas ici. Elle porte sur les changements du système de management lui-même : limites du périmètre, méthode d’appréciation, répartition des responsabilités, manière de choisir et de suivre les fournisseurs. Ce qui change dans les systèmes d’IA, ou dans ce que fournissent des tiers, relève d’abord de 8.1 ; s’il est jugé significatif, il appelle aussi une nouvelle appréciation des risques (8.2) et, lorsqu’il est envisagé, une nouvelle évaluation d’impact (8.4). L’arrivée d’un nouveau système d’IA passe par ces clauses ; elle ne touche la présente sous-clause que si elle modifie le système de management, par exemple en déplaçant les limites du périmètre : le parcours, étape par étape.

Ce que la clause 6 ne demande pas

Aucune méthode d’appréciation du risque n’est imposée. Une matrice, une approche par scénarios, une méthode dérivée d’ISO 31000 ou d’ISO/IEC 23894 : le choix vous appartient, à condition qu’il soit écrit et appliqué de façon constante.

La norme ne fixe aucun seuil, aucune métrique et aucune échelle : c’est à l’organisme de définir ses critères (6.1.1). Elle n’impose pas non plus de registre des risques sous une forme particulière. Elle exige en revanche de conserver une information documentée sur les actions menées face aux risques et opportunités (6.1.1), sur les processus d’appréciation (6.1.2) et de traitement (6.1.3), et sur les résultats de chaque appréciation (8.2) et de chaque traitement (8.3). Le registre n’est que la forme la plus courante pour tenir cette obligation et la rendre vérifiable.