Impacts IA sur les individus : décrypter le contrôle B.5.4

B.5.4 dans l'architecture de l'Annexe A

L'Annexe A de l'ISO/IEC 42001 regroupe neuf catégories de contrôles et 38 contrôles individuels que les organisations peuvent appliquer pour traiter les risques liés à leurs systèmes d'IA^[4]. La catégorie A.5, intitulée « Assessing Impacts of AI system », contient quatre contrôles complémentaires : le processus d'évaluation d'impact (A.5.2), sa documentation (A.5.3), l'évaluation de l'impact sur les individus ou groupes d'individus (A.5.4) et l'évaluation des impacts sociétaux (A.5.5)^[4].

Le contrôle B.5.4 (la guidance correspondante à A.5.4) se concentre sur les personnes directement ou indirectement touchées par un système d'IA. La norme cite explicitement quatre axes : l'équité (fairness), la vie privée (privacy), la sûreté (safety) et la sécurité (security)^[4]. Pour un responsable conformité ou un DPO, ce contrôle représente le point de convergence entre la gouvernance IA et la protection des droits individuels. Il ne s'agit pas d'un exercice théorique : la déclaration d'applicabilité (SoA) doit justifier l'inclusion ou l'exclusion de chaque contrôle de l'Annexe A^[4].

Contrairement à A.5.5, qui porte sur les effets à l'échelle de la société (emploi, confiance publique, dynamiques sociales)^[4], B.5.4 vise les conséquences concrètes sur des personnes identifiables ou des groupes définis. Cette distinction est déterminante pour calibrer la granularité de l'analyse.

Quatre dimensions d'impact sur les individus

La norme structure l'évaluation autour de quatre axes. Chacun appelle un regard différent et, souvent, des compétences distinctes au sein de l'organisation.

Équité et non-discrimination

Un système d'IA peut produire des résultats biaisés qui désavantagent certains groupes de manière disproportionnée. L'ISO 42001 demande d'identifier ces risques de discrimination algorithmique et de les traiter^[6]. Pour un DPO, cette dimension rejoint les obligations de la nLPD suisse en matière de décisions automatisées affectant significativement une personne.

L'évaluation de l'équité ne se limite pas à vérifier un indicateur statistique. Elle suppose de comprendre quels attributs protégés (genre, origine, âge, handicap) pourraient être corrélés aux variables d'entrée du modèle, même indirectement.

Vie privée et protection des données

La collecte excessive de données et l'atteinte à la vie privée figurent parmi les abus potentiels que la norme vise à limiter^[6]. Pour le DPO, B.5.4 constitue un complément structurel à l'analyse d'impact relative à la protection des données (AIPD). Les deux exercices partagent des préoccupations communes, mais l'AIPD et l'analyse d'impact IA diffèrent sur le périmètre : l'AIPD se concentre sur les données personnelles, tandis que B.5.4 couvre aussi la sûreté physique et l'équité.

En pratique, les observations de terrain montrent que les organisations qui mènent déjà des AIPD disposent d'une base méthodologique réutilisable. Le registre des traitements et la cartographie des flux de données constituent un point de départ naturel.

Sûreté (safety)

La sûreté concerne les dommages physiques ou psychologiques qu'un système d'IA pourrait causer. Un outil de diagnostic médical assisté par IA, par exemple, peut engendrer un risque direct pour la santé en cas de recommandation erronée^[4]. L'évaluation doit tenir compte de la finalité du système, de sa complexité et de la sensibilité des données traitées^[4].

Pour les systèmes à faible risque physique (recommandation de contenu, chatbot interne), la sûreté reste pertinente sous l'angle psychologique : désinformation, stress lié à des décisions automatisées, perte de contrôle perçue par l'utilisateur.

Sécurité (security)

La sécurité recouvre les vulnérabilités techniques du système d'IA : attaques adversariales, empoisonnement des données d'entraînement, extraction de modèle. L'ISO 42001 s'articule avec l'ISO 27001 sur ce volet^[3]. Les organisations déjà certifiées ISO 27001 peuvent intégrer les exigences IA à leur SMSI existant, ce qui rationalise l'effort de sécurité.

L'évaluation de la sécurité au titre de B.5.4 se distingue toutefois de l'analyse de risques classique : elle se focalise sur les conséquences pour les individus (fuite de données personnelles, décision faussée par une attaque) plutôt que sur l'impact organisationnel.

Méthodologie d'évaluation d'impact

Le contrôle A.5.2 exige un processus clair et structuré pour évaluer l'impact du système d'IA tout au long de son cycle de vie, en tenant compte de sa finalité, de sa complexité et de la sensibilité des données^[4]. B.5.4 s'inscrit dans ce processus comme l'étape spécifique aux individus.

Le processus suit une logique itérative, à reprendre à chaque évolution significative du système.

1Identifier les individus ou groupes affectés

2Caractériser les effets sur les 4 axes (équité, vie privée, sûreté, sécurité)

3Évaluer la gravité et la vraisemblance

4Définir les mesures de traitement

5Documenter et réévaluer périodiquement

L'évaluation doit couvrir l'ensemble du cycle de vie du système d'IA, de la conception au retrait^[4].

La norme ne prescrit pas de méthode unique. Selon le cabinet Schellman, spécialisé en audits ISO, l'évaluation des risques et des impacts constitue l'un des volets les plus exigeants de la démarche ISO 42001^[7]. L'approche NIST AI RMF peut servir de référence méthodologique complémentaire, car elle propose un cadre structuré de gestion des risques liés à l'IA^[6].

Le point de départ concret : dresser la liste des personnes ou catégories de personnes en contact avec le système (utilisateurs directs, personnes concernées par les décisions, tiers affectés indirectement). Pour chaque catégorie, documenter les effets possibles sur chacun des quatre axes. Cette cartographie initiale conditionne la qualité de toute l'évaluation.

Documentation et traçabilité

Le contrôle A.5.3 impose de documenter les résultats de l'évaluation d'impact^[4]. Pour B.5.4, cela signifie conserver une trace écrite des impacts identifiés sur les individus, des critères de gravité retenus, des mesures de traitement décidées et de leur suivi.

Cette documentation sert plusieurs objectifs. D'abord, elle alimente la démarche d'évaluation des risques IA prévue par la clause 6.1. Ensuite, elle constitue une preuve d'audit lors de la certification. Enfin, elle permet la traçabilité des décisions, un principe que la norme partage avec le cadre réglementaire européen^[6].

Un registre d'évaluation d'impact par système d'IA, versionné et horodaté, représente la forme la plus courante. Les organisations qui utilisent déjà un outil GRC peuvent y centraliser politiques, risques et contrôles de l'Annexe A dans une seule plateforme^[1].

Articulation entre risques IA et impact

L'une des confusions fréquentes concerne la frontière entre l'analyse de risques et l'analyse d'impact dans l'ISO 42001. La clause 6.1 traite de l'appréciation des risques au niveau du SMIA, tandis que les contrôles A.5 portent sur l'impact des systèmes d'IA eux-mêmes^[4].

En pratique, les deux exercices se nourrissent mutuellement. Un impact élevé sur les individus (par exemple, un biais systématique dans un système de scoring) constitue aussi un risque pour l'organisation (risque réputationnel, risque juridique). L'évaluation B.5.4 fournit donc des données d'entrée pour l'appréciation des risques organisationnels, et inversement.

L'ISO 42001 suit un cycle PDCA (Plan-Do-Check-Act) qui impose une amélioration continue^[3]. L'évaluation d'impact sur les individus n'est pas un exercice ponctuel : elle doit être reprise à chaque modification significative du système, changement de périmètre d'utilisation ou évolution du contexte réglementaire.

Exemple concret : tri de candidatures en Suisse romande

Prenons le cas fictif d'une régie immobilière genevoise qui déploie un outil d'IA pour présélectionner les dossiers de candidature locative. Le système analyse les pièces fournies (attestation de salaire, extrait de poursuites, références) et attribue un score de solvabilité.

L'évaluation B.5.4 porterait sur les quatre axes :

• Équité : le modèle risque-t-il de désavantager certaines nationalités ou tranches d'âge si les données d'entraînement reflètent des pratiques discriminatoires passées ?
• Vie privée : quelles données personnelles sont collectées et conservées ? Le candidat est-il informé du traitement automatisé, conformément à la nLPD ?
• Sûreté : un refus injustifié peut avoir des conséquences graves pour une personne en recherche urgente de logement (stress, précarité).
• Sécurité : les dossiers contiennent des données sensibles (revenus, poursuites). Une faille de sécurité exposerait les candidats à un risque d'usurpation d'identité.

La documentation de cette évaluation devrait inclure les critères de scoring, les tests de biais réalisés, les mesures correctives (par exemple, une revue humaine systématique des refus) et le calendrier de réévaluation. Ce type de dossier répond simultanément aux exigences de B.5.4 et aux attentes d'une autorité de protection des données.

Pièges fréquents lors de l'évaluation B.5.4

Confondre impact sociétal et impact individuel

Le contrôle A.5.5 couvre les impacts sociétaux (emploi, économie, environnement, confiance publique)^[4]. B.5.4 se limite aux individus et groupes d'individus identifiables. Mélanger les deux dans un seul document dilue l'analyse et complique l'audit. Les observations de terrain montrent que séparer clairement les deux évaluations, même si elles partagent un socle méthodologique commun, facilite la revue par l'auditeur.

Réaliser l'évaluation une seule fois

L'approche PDCA de la norme implique que l'évaluation d'impact n'est pas un livrable figé^[3]. Un système d'IA évolue (nouvelles données, réentraînement, extension du périmètre). Chaque changement significatif doit déclencher une réévaluation. Les organisations qui traitent B.5.4 comme une case à cocher initiale s'exposent à une non-conformité lors de l'audit de surveillance.

Omettre les individus indirectement affectés

L'évaluation doit couvrir non seulement les utilisateurs du système, mais aussi les personnes sur lesquelles porte la décision algorithmique. Dans l'exemple du tri locatif, les candidats refusés ne sont pas utilisateurs du système, mais en subissent les conséquences. Cette catégorie est souvent oubliée dans les premières versions de l'évaluation.

Négliger l'articulation avec la protection des données

Pour les organisations soumises à la nLPD ou au RGPD, l'évaluation B.5.4 et l'AIPD portent sur des périmètres qui se chevauchent partiellement. Ne pas articuler les deux exercices crée des doublons, des incohérences et un surcroît de travail inutile. La comparaison entre AIPD nLPD et analyse d'impact ISO 42001 permet de clarifier les recouvrements et les spécificités de chaque cadre.

Sous-estimer la dimension sûreté pour les systèmes « à faible risque »

Même un chatbot de service client peut générer un impact sur les individus : réponses erronées en matière de santé, de droits ou de procédures administratives. La qualification « faible risque » ne dispense pas d'une évaluation B.5.4, elle en réduit simplement la profondeur attendue. L'ISO 42001 s'applique à toute organisation impliquée dans le développement, la fourniture ou l'utilisation de produits ou services basés sur l'IA^[3].

Questions fréquentes

À lire ensuite