Évaluation d'impact et appréciation des risques : ne pas confondre
Deux processus distincts, décrits dans deux clauses différentes. La confusion entre les deux revient souvent, et elle coûte cher : ce que l'un établit ne tient pas lieu de l'autre.
La différence ne tient pas là où on la place d’habitude.
On lit partout que l’appréciation du risque de la clause 6.1.2 regarde l’organisation, et que l’évaluation d’impact de la clause 6.1.4 regarde les personnes. C’est une simplification, et elle égare : la clause 6.1.2 demande déjà d’analyser les conséquences d’un risque pour les individus et les sociétés, et pas seulement pour l’organisation.
Ce qui distingue vraiment les deux processus, c’est leur angle. L’appréciation du risque part des objectifs de l’organisation 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 faire à des personnes et à la société, dans son contexte réel d’usage.
Les deux sont exigées. Elles ne se remplacent pas, et fournir l’une à la place de l’autre est un écart classique sur le domaine A.5.
Deux processus, deux angles
| Appréciation du risque | Évaluation d’impact | |
|---|---|---|
| Clause de définition | 6.1.2 | 6.1.4 |
| Clause d’exécution | 8.2 | 8.4 |
| Point de départ | Les objectifs IA et les critères de risque de l’organisation | Un système d’IA : son déploiement, son usage prévu, ses mésusages prévisibles |
| Ce qui est examiné | Les risques qui favorisent ou compromettent l’atteinte des objectifs, et leurs conséquences pour l’organisation, les individus et les sociétés | Les conséquences pour les individus, les groupes et les sociétés, dans le contexte technique, sociétal et juridique du système |
| Niveau | Le portefeuille de risques de l’organisation | Chaque système du périmètre |
| Débouché | Hiérarchisation, traitement et déclaration d’applicabilité (6.1.3) | Une évaluation documentée, prise en compte dans l’appréciation du risque |
| Contrôles associés | L’Annexe A, sélectionnée par le traitement | A.5.2 à A.5.5 |
Le chaînage entre les deux
La norme ne se contente pas de juxtaposer les deux processus : elle les relie dans les deux sens. Les résultats de l’évaluation d’impact doivent être pris en compte dans l’appréciation du risque. Et pour apprécier les conséquences d’un risque, l’organisation peut s’appuyer sur l’évaluation d’impact.
Concrètement, un impact identifié sur des personnes — un taux de refus plus élevé pour un groupe, une décision inexplicable — entre dans le registre des risques avec ses conséquences pour ces personnes et pour l’organisation : contestation, sanction, perte de confiance. Il y est hiérarchisé et traité comme les autres.
C’est pour cette raison que l’ordre compte. Une organisation qui ne conduit que l’appréciation du risque, sans évaluation d’impact par système, apprécie des conséquences pour les personnes qu’elle n’a jamais examinées de près : elle ne voit que ce qu’elle sait déjà craindre.
L’évaluation d’impact est une exigence, pas une bonne pratique
Le point mérite d’être appuyé, parce que beaucoup de documentation commerciale le présente comme optionnel.
La clause 6.1.4 impose de définir le processus et de documenter les résultats. La clause 8.4 impose de le réaliser à intervalles planifiés et lorsqu’un changement significatif est envisagé. Les contrôles A.5.2 à A.5.5 en détaillent la mise en œuvre.
Une organisation qui arrive en audit sans aucune évaluation d’impact documentée n’a pas un point d’amélioration : elle a un écart.
Ce n’est pas non plus une analyse d’impact relative à la protection des données
La confusion avec l’AIPD du règlement général sur la protection des données est fréquente, et compréhensible : les deux exercices se ressemblent et portent souvent sur le même système.
Ils ne se confondent pas. L’AIPD examine un traitement de données à caractère personnel. L’évaluation d’impact de la norme examine les conséquences d’un système d’IA — y compris lorsqu’il ne traite aucune donnée personnelle. La norme invite d’ailleurs à vérifier si une analyse spécialisée déjà conduite, comme l’AIPD, prend assez en compte les enjeux propres à l’IA pour couvrir le volet vie privée de l’évaluation d’impact ; elle n’en couvre pas le reste. Un modèle de détection de défauts sur une chaîne de production n’appelle pas d’AIPD ; il peut appeler une évaluation d’impact si son erreur affecte la sécurité de quelqu’un.
Les deux peuvent se compléter, et pour un système de tri de candidatures il faut probablement les deux. Fournir l’une pour l’autre ne satisfait ni l’une ni l’autre.
Ce que contient une évaluation d’impact utilisable
Une à deux pages suffisent si elles sont réellement instruites :
- Le système et son usage prévu — ce qu’il fait, pour quelle décision, avec quel degré d’automatisation.
- Les mésusages prévisibles — ce qu’on fera du système en dehors de ce qui était prévu.
- Le contexte — technique, sociétal, et les juridictions dans lesquelles le système est employé.
- Les personnes et groupes affectés, et les effets sur la société — nommément, pas « les utilisateurs ».
- Les catégories de conséquences examinées — droits, équité, sécurité, vie privée, accès au service.
- La gravité et la vraisemblance de chacune.
- Les mesures d’atténuation retenues, et celles écartées.
- Les déclencheurs de réévaluation — c’est la partie qu’on oublie systématiquement.
- Le renvoi vers le registre des risques, où les résultats doivent être repris.
Le déclencheur qu’on manque toujours
La mise à jour du modèle par votre fournisseur. Le comportement du système change sans qu’une ligne de votre code ait bougé, et votre évaluation d’impact décrit alors une version qui n’est plus en production.
C’est un changement que vous ne décidez pas, et vous seul pouvez dire s’il est significatif — ce sont vos critères qui en décident. La parade consiste à traiter la politique de version de votre fournisseur comme un paramètre de votre dispositif, et non comme un aléa extérieur.
Ce qu’il faut retenir
Deux processus, deux clauses, deux angles. L’appréciation du risque, en 6.1.2 et 8.2, part des objectifs de l’organisation et apprécie les conséquences pour tous. L’évaluation d’impact, en 6.1.4 et 8.4, part de chaque système et regarde les personnes et la société. Les deux sont des exigences, et la seconde nourrit la première.
Si vous n’en avez qu’une aujourd’hui, c’est presque toujours la première — souvent héritée d’un système de sécurité qui ne regardait que l’information.