L'analyse d'impact des systèmes d'IA (clause 6.1.4)

Ce que la norme appelle une analyse d'impact

La norme définit l'analyse d'impact d'un système d'IA comme un processus formel et documenté par lequel les impacts sur des individus, des groupes d'individus, ou les deux, et sur les sociétés sont identifiés, évalués et traités par l'organisation qui développe, fournit ou utilise des produits ou services recourant à l'intelligence artificielle.^[1] Trois mots méritent l'attention : le processus est formel, il est documenté, et son objet n'est pas l'organisation mais les personnes et la société.

Cette orientation vers l'extérieur est le trait qui caractérise l'exercice. Là où la plupart des démarches de management regardent ce que l'organisation peut perdre, l'analyse d'impact regarde ce que les personnes peuvent subir.^[5] Le point de vue change de camp, et c'est volontaire.

La notion n'est pas une simple recommandation. Elle figure parmi les termes définis de la norme, et la clause 6.1.4 lui donne un contenu d'obligation que nous détaillons plus bas. Comprendre la définition, c'est déjà comprendre pourquoi cet exercice ne se confond avec aucun autre.

Ce que la clause 6.1.4 exige précisément

La clause 6.1.4 demande à l'organisation de définir un processus pour apprécier les conséquences potentielles, pour les individus ou groupes d'individus et pour les sociétés, qui peuvent résulter du développement, de la fourniture ou de l'usage de systèmes d'IA.^[2] L'exigence porte d'abord sur l'existence d'un processus, pas sur un document isolé.

Ce processus doit déterminer les conséquences que le déploiement d'un système, son usage prévu et son mésusage prévisible ont sur les individus, les groupes et les sociétés.^[2] Le mot mésusage est important : la norme ne se contente pas de l'usage idéal, elle demande d'anticiper l'usage dévoyé, raisonnablement prévisible, du système.

L'analyse doit prendre en compte le contexte technique et sociétal spécifique du déploiement, ainsi que les juridictions applicables.^[2] Un même modèle déployé dans deux contextes différents n'a pas le même impact, et la norme refuse l'analyse hors-sol. Le résultat de l'analyse doit être documenté, et lorsque c'est approprié, il peut être mis à la disposition des parties intéressées pertinentes que l'organisation a définies.^[2]

Enfin, l'organisation doit considérer les résultats de l'analyse d'impact dans son appréciation des risques, et la norme renvoie au contrôle A.5 de la Table A.1 pour des contrôles dédiés à l'appréciation des impacts des systèmes d'IA.^[2] Une note ajoute que dans certains contextes, par exemple des systèmes critiques pour la sûreté ou la vie privée, l'organisation peut exiger des analyses d'impact spécifiques à une discipline, sûreté, vie privée ou sécurité.^[2]

Ces exigences se lisent comme une chaîne et non comme une liste à cocher. Un processus défini produit un résultat documenté, ce résultat tient compte d'un contexte réel, il peut être partagé avec les parties intéressées concernées, puis il remonte vers l'appréciation des risques où il pèse sur les décisions. Une étape manquante fragilise les autres. Une analyse menée mais jamais reliée aux risques, ou un résultat produit sans considération du contexte de déploiement, ne répond pas à ce que la clause demande.

La distinction nette avec l'appréciation des risques

La confusion la plus fréquente consiste à fondre l'analyse d'impact dans l'appréciation des risques. Les deux exercices se ressemblent, ils mobilisent des compétences voisines, mais ils ne répondent pas à la même question. L'appréciation des risques de la clause 6.1.2 analyse les risques de l'IA pour apprécier les conséquences potentielles, pour l'organisation, les individus et les sociétés, qui résulteraient de la matérialisation des risques identifiés.^[3]

Le détail décisif tient dans la cible. L'appréciation des risques identifie aussi les risques qui aident ou empêchent l'organisation d'atteindre ses objectifs d'IA.^[3] Elle regarde donc, parmi d'autres choses, les risques pour l'organisation elle-même. L'analyse d'impact, elle, ne regarde pas l'organisation : elle se concentre sur les conséquences subies par les individus, les groupes et les sociétés.^[2]

Les sources spécialisées formulent la même opposition. L'appréciation des risques évalue les risques métier et techniques pour l'organisation, tandis que l'analyse d'impact se concentre sur les conséquences externes et les préjudices pour les individus, les groupes et les sociétés.^[4] Une lecture raisonnable de la norme est donc la suivante : un même danger peut être lu deux fois, une fois comme risque pour vous, une fois comme impact sur autrui, et les deux lectures sont attendues.

Deux exercices, deux questions, deux clauses

Critère	Appréciation des risques (6.1.2)	Analyse d'impact (6.1.4)
Question posée	Quels risques pèsent sur l'atteinte des objectifs et sur l'organisation, les individus et les sociétés ?	Quelles conséquences le système fait-il subir aux individus, groupes et sociétés ?
Point de vue	Inclut l'organisation	Tourné vers les personnes et la société
Prend en compte	Probabilité et niveau de risque	Déploiement, usage prévu, mésusage prévisible, contexte et juridictions
Exécution périodique	Clause 8.2	Clause 8.4

Tableau reformulé à partir des clauses 6.1.2, 6.1.4, 8.2 et 8.4. Le texte de la norme n'est pas reproduit.

Comment les deux exercices s'articulent

Distinguer ne veut pas dire séparer. La norme relie explicitement les deux démarches. Une note de la clause 6.1.2 indique que, lorsqu'elle apprécie les conséquences au titre de l'analyse des risques, l'organisation peut utiliser une analyse d'impact telle qu'indiquée en 6.1.4.^[3] Autrement dit, l'analyse d'impact fournit la matière qui éclaire une partie de l'appréciation des risques.

Le lien fonctionne aussi dans l'autre sens. La clause 6.1.4 demande de considérer les résultats de l'analyse d'impact dans l'appréciation des risques.^[2] L'analyse d'impact n'est donc pas un livrable qui dort dans un classeur. Ses conclusions doivent remonter dans la chaîne de décision, là où l'organisation choisit ce qu'elle traite et comment.

Cette boucle est ce qui donne du sens à l'exercice. Identifier qu'un système peut désavantager un groupe de personnes ne sert à rien si ce constat ne devient pas un risque suivi, doté d'un propriétaire et d'un traitement. Les guides de mise en œuvre insistent sur ce point : les conséquences identifiées doivent être considérées dans l'appréciation des risques, qui pilote ensuite la sélection des contrôles.^[4]

Quand la mener : planifiée en clause 6, exécutée en 8.4

La structure de la norme répartit l'analyse d'impact entre deux clauses, et cette répartition se lit comme une distinction entre planifier et faire. La clause 6 appartient à la planification : c'est là que l'organisation définit le processus d'analyse d'impact, ses critères et sa place dans le dispositif.^[2]

L'exécution relève de la clause 8, consacrée au fonctionnement. La clause 8.1 demande de réaliser et de maîtriser les processus nécessaires et de concrétiser les actions déterminées en clause 6.^[6] La clause 8.4 précise le rythme propre à l'analyse d'impact : l'organisation réalise les analyses d'impact des systèmes d'IA conformément à 6.1.4, à intervalles planifiés ou lorsque des changements importants sont proposés.^[6]

Ce double déclencheur, l'intervalle planifié et le changement important, vaut la peine d'être retenu. Une analyse d'impact n'est pas un acte unique réalisé une fois pour toutes. Elle se refait quand le système évolue de façon notable, change d'usage ou d'environnement. La clause 8.2 prévoit la même logique pour l'appréciation des risques, à conduire elle aussi à intervalles planifiés ou en cas de changements importants.^[6] Les deux exercices vivent donc au même rythme, en parallèle.

L'analyse d'impact traverse deux clauses. La clause 6 la définit, la clause 8 la réalise et en conserve la trace.

6.1.4Définir le processus d'analyse d'impact et sa place

8.4Réaliser les analyses à intervalles planifiés ou lors de changements importants

6.1.2Considérer les résultats dans l'appréciation des risques

8.4Conserver une information documentée des résultats

Schéma reformulé à partir des clauses 6.1.2, 6.1.4 et 8.4. Le texte de la norme n'est pas reproduit.

Ce qu'elle documente et ce qu'un auditeur attend

La norme demande que le résultat de l'analyse d'impact soit documenté.^[2] La clause 8.4 ajoute que l'organisation conserve une information documentée des résultats de toutes les analyses d'impact des systèmes d'IA.^[6] Le mot toutes est à prendre au sérieux : il ne suffit pas d'avoir mené une analyse exemplaire sur un système, il faut la trace de chacune.

Ce que documente concrètement une analyse découle des exigences de la clause 6.1.4 : la finalité et l'usage prévu du système, ses mésusages prévisibles, le contexte technique et sociétal de son déploiement, les juridictions applicables, et les conséquences identifiées sur les individus, les groupes et les sociétés.^[2] Les sources de terrain ajoutent les dimensions souvent examinées : la vie privée, l'équité et les biais, la transparence, l'autonomie des personnes, dans des secteurs sensibles comme le recrutement, la santé, le crédit ou la justice.^[5]

Un auditeur, lors d'un audit, ne cherche pas une belle prose. Il cherche des preuves. Il attend un processus défini, un résultat documenté pour chaque système concerné, la démonstration d'une exécution à intervalles planifiés et lors de changements importants, et la trace que ces résultats ont été considérés dans l'appréciation des risques.^[4] Cette dernière trace est souvent le point faible des dossiers : l'analyse existe, mais rien ne montre qu'elle a alimenté les décisions de risque.

La norme rattache la notion d'information documentée à un terme défini : une information qui doit être maîtrisée et tenue à jour, sur n'importe quel support.^[1] Cela vaut pour les résultats d'analyse d'impact. La maîtrise porte sur l'accès, le stockage, le contrôle des versions et la conservation. En pratique, un dossier d'analyse d'impact daté, versionné et relié au système concerné vaut mieux qu'un document élégant mais isolé, parce qu'il rend visible la régularité de la démarche.

Les guides de mise en œuvre convergent sur les éléments de preuve attendus : un rapport d'analyse d'impact, une procédure qui décrit le processus, et le rapport d'appréciation des risques qui en reçoit les conclusions.^[4] Ce triptyque résume bien ce qu'une organisation gagne à préparer : non pas un livrable unique, mais une mécanique qui se rejoue et laisse une trace à chaque tour.

Le rapprochement prudent avec l'analyse d'impact des données

Beaucoup d'organisations connaissent déjà une analyse d'impact, celle relative à la protection des données, l'AIPD prévue par le RGPD, ou une démarche analogue conduite sous la nLPD suisse. La tentation est grande de considérer que l'analyse d'impact de la clause 6.1.4 en serait une simple variante. Ce rapprochement est utile, mais il doit rester prudent.

La parenté est réelle au plan de la logique : dans les deux cas, on examine les conséquences possibles sur des personnes avant ou pendant le déploiement, et on documente. La norme reconnaît elle-même cette proximité, puisqu'elle envisage des analyses d'impact vie privée spécifiques selon le contexte.^[2] Une analyse d'impact relative aux données peut donc nourrir l'analyse d'impact du système d'IA, et inversement.

La différence d'objet reste entière. L'analyse d'impact relative à la protection des données vise les risques pour les droits des personnes liés à un traitement de données personnelles. L'analyse d'impact de la clause 6.1.4 vise les conséquences d'un système d'IA sur les individus et les sociétés, qu'il y ait ou non traitement de données personnelles, et inclut des dimensions comme l'équité algorithmique ou l'autonomie qui dépassent la seule protection des données.^[5] Les deux outils se recoupent sans se confondre, et il serait imprudent de remplacer l'un par l'autre. La cartographie entre l'ISO 42001 et les autres cadres aide à situer ces recoupements sans les surinterpréter.

Un cas concret : une commune romande qui déploie un outil de tri

Prenons, à titre d'illustration et sans aucune entité réelle, une commune romande qui déploie un outil d'IA pour pré-trier les demandes d'aide sociale qu'elle reçoit. L'outil ne décide pas seul, mais il ordonne les dossiers et signale ceux à examiner en priorité. L'objet de l'analyse d'impact n'est pas le risque pour le service, c'est la conséquence pour les administrés.^[2]

L'analyse d'impact examine d'abord l'usage prévu et le mésusage prévisible : que se passe-t-il si l'outil tend à reléguer systématiquement certains profils en bas de pile, par exemple les dossiers atypiques ou ceux rédigés dans un français approximatif ? Elle considère le contexte technique et sociétal du déploiement et les juridictions applicables, en l'occurrence le droit suisse et le droit cantonal de l'aide sociale.^[2] Elle identifie des conséquences possibles : tri défavorable, biais à l'encontre d'un groupe, opacité de la décision pour la personne concernée, perte de confiance dans l'institution.^[5]

Le résultat est documenté, puis considéré dans l'appréciation des risques de la commune, qui décide alors des contrôles : un contrôle humain sur les dossiers signalés, un suivi des écarts de traitement entre groupes, une information claire aux administrés.^[2] Lorsque l'outil change de version ou d'usage, l'analyse se refait, conformément au rythme de la clause 8.4.^[6] C'est exactement ce que la norme attend : un regard tourné vers les personnes, documenté, et relié aux décisions de risque.

Questions fréquentes

À lire ensuite