A.5 — Évaluation des impacts des systèmes d'IA
C'est le domaine le plus spécifique à cette norme, et celui où les écarts sont les plus fréquents. Un seul point suffit à les expliquer : la dimension sociétale est presque toujours absente.
Le domaine A.5 compte quatre contrôles : A.5.2 sur le processus d’évaluation d’impact, A.5.3 sur sa documentation, A.5.4 sur les impacts pour les individus et les groupes, A.5.5 sur les impacts sociétaux.
C’est ici que se trouve ce qui distingue ISO/IEC 42001 d’une norme de management générique, et c’est ici que se concentrent les écarts.
Un rappel de localisation, parce qu’il est souvent faux : les évaluations d’impact relèvent du domaine A.5, et non du domaine A.8 qui traite de l’information des parties intéressées. L’erreur est courante et fait chercher les preuves au mauvais endroit.
Ce que l’auditeur regarde
D’abord que le processus existe — c’est A.5.2, et c’est le pendant de la clause 6.1.4. Ensuite que des évaluations aient été réellement conduites et documentées — A.5.3, le pendant de la clause 8.4.
Puis il lit une évaluation, et il cherche deux choses : les individus et groupes affectés (A.5.4), et les conséquences sociétales (A.5.5).
La non-conformité la plus fréquente
L’absence de dimension sociétale. C’est le constat que rapportent de façon convergente plusieurs sources de terrain, et il s’explique bien : une organisation qui aborde l’évaluation d’impact depuis sa pratique de protection des données examine naturellement l’individu — c’est l’objet du droit applicable — et s’arrête là.
Or A.5.5 porte précisément sur ce qui dépasse l’individu : l’effet d’un système de tri sur l’accès à l’emploi d’une catégorie de candidats, l’effet d’un système de scoring sur l’accès au crédit d’un territoire, l’effet d’un outil de génération sur un métier.
Une évaluation qui conclut « aucun impact » sans avoir examiné les groupes affectés n’est pas une évaluation.
Trois niveaux de mise en œuvre
Minimal crédible. Une fiche d’une à deux pages par système, avant déploiement : le système et son usage prévu, les personnes et groupes affectés nommément, les catégories de conséquences examinées, la gravité et la vraisemblance, les mesures retenues, et les événements qui déclencheront une réévaluation. Ce dernier point est celui qu’on oublie systématiquement.
Mature. L’évaluation s’insère dans le cycle de projet, dès l’expression du besoin. Une grille commune est utilisée, chaque conséquence identifiée est qualifiée et assortie d’un plan d’action, et un regard extérieur au projet — juridique, conformité, métier — intervient sur les systèmes à enjeu. Les résultats alimentent l’appréciation du risque, ce qui est tout l’intérêt du chaînage.
À éviter. Le rapport de trente pages pour un prototype, la consultation d’un comité externe pour un assistant interne, la double validation par deux experts et deux directeurs. La charge devient dissuasive, et l’effet observable est que les évaluations cessent d’être faites pour les systèmes qui en auraient besoin.
Ce que le domaine ne demande pas
Aucune méthode imposée, aucune grille type, aucun seuil de gravité. La taxonomie de l’Annexe C peut servir de point de départ, elle n’est pas obligatoire.
Il ne demande pas non plus une évaluation par version : il demande une réévaluation lors des changements significatifs, et c’est à vous de définir ce qui en est un.