Évaluation d'impact et appréciation des risques : ne pas confondre
Deux processus distincts, décrits dans deux clauses différentes. C'est la confusion la plus coûteuse du référentiel, et la non-conformité la plus régulièrement relevée.
La différence tient en une question : qui subit la conséquence ?
L’appréciation du risque de la clause 6.1.2 regarde ce que le système peut faire subir à votre organisation. L’évaluation d’impact de la clause 6.1.4 regarde ce qu’il peut faire subir aux personnes, aux groupes et aux sociétés.
Les deux sont exigées. Elles ne se remplacent pas, et fournir l’une à la place de l’autre est l’écart le plus fréquemment constaté sur le domaine A.5.
Deux objets, deux clauses
| 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 |
| Objet de la conséquence | l’organisation | individus, groupes, sociétés |
| Exemples | indisponibilité, sanction, perte financière, atteinte à la réputation | discrimination, atteinte à la vie privée, perte d’accès à un service, effet sur un groupe |
| Contrôles associés | l’ensemble des domaines A.2 à A.10 | A.5.2 à A.5.5 |
Le chaînage entre les deux
Ce n’est pas une redondance administrative : les deux processus s’alimentent.
Un impact identifié sur des personnes — un taux de refus plus élevé pour un groupe, une décision inexplicable — devient une source de risque pour l’organisation : contestation, sanction, perte de clients. L’évaluation d’impact nourrit donc l’appréciation du risque.
C’est pour cette raison que l’ordre compte. Une organisation qui ne conduit que l’appréciation du risque part avec une vision tronquée : 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 lors de changements significatifs. 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 recouvrent 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. 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 personnes et groupes affectés — 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 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 le changement le plus significatif et le seul sur lequel vous n’avez pas la main. 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 objets. L’appréciation du risque en 6.1.2 et 8.2, l’évaluation d’impact en 6.1.4 et 8.4. Les deux sont des exigences.
Et si vous n’en avez qu’un aujourd’hui, c’est presque toujours le premier — parce qu’il est celui que votre système de management de la sécurité savait déjà faire.