L'ISO/IEC 42005:2025 fournit des lignes directrices pour évaluer comment un système d'IA et ses usages prévisibles peuvent affecter des individus, des groupes et la société tout au long de son cycle de vie. Ce n'est pas une certification de produit et cela ne remplace ni l'analyse d'impact relative à la protection des données (AIPD) du RGPD, ni l'analyse d'impact sur les droits fondamentaux de l'AI Act. Elle permet de structurer une analyse large, traçable et reliée à des décisions réelles.
Ce qu'apporte l'ISO/IEC 42005
La norme encadre la planification, la réalisation, la documentation et la révision des évaluations d'impact des systèmes d'IA. Elle aide à identifier les bénéfices et les préjudices, les personnes concernées, les usages prévus et prévisibles, les défaillances, les mesures et le risque résiduel.
Sa valeur réside dans la création d'un langage commun entre métier, ingénierie, protection des données, sécurité, juridique et parties prenantes. L'évaluation ne doit pas devenir un rapport que l'on classe : elle doit influencer la conception, le déploiement, les limites d'usage et, le cas échéant, le retrait du système.
Différences avec les autres évaluations
| Instrument | Objet |
|---|---|
| ISO/IEC 42005 | Impacts larges du système d'IA sur les personnes, les groupes et la société |
| AIPD RGPD | Risque élevé lié au traitement de données personnelles |
| Droits fondamentaux (AI Act) | Droits fondamentaux dans les déploiements obligatoires |
| Évaluation de conformité | Respect des exigences des systèmes à haut risque |
| Risque de sécurité | Menaces sur la confidentialité, l'intégrité et la disponibilité |
Elles peuvent partager un inventaire, des personnes, des scénarios et des mesures, mais chacune conserve ses propres exigences. Une matrice de correspondance entre évaluations évite de dupliquer le travail tout en ne laissant aucune lacune.
Quand déclencher l'évaluation
L'organisation doit définir des déclencheurs imposant de lancer une évaluation d'impact :
- nouveau système ou cas d'usage ;
- décision concernant des personnes ;
- population vulnérable ;
- grande échelle ou catégories sensibles ;
- augmentation de l'autonomie ;
- nouvelle source de données ;
- changement de modèle ou de prestataire ;
- expansion vers un autre pays ou secteur ;
- incident ou réclamations ;
- indices de résultats inégaux.
On documente également les cas où l'évaluation n'est pas réalisée, et sur quel fondement.
Étape 1. Gouvernance et périmètre
Avant d'analyser les impacts, il convient de définir :
- le système, la version et le propriétaire ;
- l'organisation et le rôle ;
- la finalité et la décision ;
- la phase du cycle de vie couverte ;
- les localisations et la population ;
- l'équipe d'évaluation ;
- les personnes qui approuvent ;
- les sources et le niveau d'incertitude ;
- le calendrier et la révision.
Le périmètre n'est pas « le modèle ». Il inclut les données, l'interface, les outils, les personnes, la procédure et les actions en aval.
Étape 2. Décrire le système
La description doit permettre de comprendre :
- la fonction et les capacités ;
- les entrées et les sorties ;
- les modèles et algorithmes ;
- les données d'entraînement, de test et d'exploitation ;
- les dépendances et prestataires ;
- l'environnement de déploiement ;
- la supervision et l'autonomie ;
- les indicateurs et limites ;
- l'interaction avec d'autres systèmes.
Les versions sont consignées. L'évaluation d'un modèle antérieur ne couvre pas automatiquement une nouvelle intégration.
Étape 3. Finalité, usages et limites
Il convient de distinguer :
- l'usage prévu ;
- l'usage non prévu mais raisonnablement prévisible ;
- l'usage abusif ;
- l'usage restreint par une politique interne ;
- l'usage interdit par la loi ou en raison du risque.
Exemple : un assistant RH conçu pour répondre aux questions sur les politiques internes pourrait être utilisé pour déduire la performance d'une personne. Même si ce n'est pas la finalité prévue, si l'usage est prévisible, il doit être évalué et, le cas échéant, bloqué.
Étape 4. Parties concernées
Pas seulement les utilisateurs directs. L'évaluation peut concerner :
- les personnes visées par la décision ;
- les personnes dont les données entraînent le système ;
- les proches ou des tiers ;
- les groupes sous-représentés ;
- le personnel chargé de la supervision ;
- les clients et fournisseurs ;
- les communautés et la société.
L'impact différentiel est analysé. Une moyenne peut masquer un préjudice concentré sur un groupe précis.
Lorsque cela est pertinent, les personnes concernées ou leurs représentants sont consultés. En l'absence de consultation, cela est documenté, ainsi que la manière dont leur point de vue a été pris en compte par d'autres moyens.
Étape 5. Bénéfices et préjudices
L'évaluation doit considérer les deux aspects. Bénéfices possibles :
- accès aux services ;
- gain de temps ;
- cohérence ;
- détection des erreurs ;
- soutien à l'accessibilité ;
- meilleure allocation des ressources.
Préjudices possibles :
- exclusion ou discrimination ;
- perte d'autonomie ;
- surveillance ;
- erreur et difficulté de correction ;
- vie privée et sécurité ;
- manipulation ;
- impact sur l'emploi ;
- préjudice économique ou réputationnel ;
- impact environnemental ;
- dépendance technologique.
Le préjudice subi par un groupe n'est pas automatiquement compensé par des bénéfices agrégés. La distribution et la gravité de chaque impact doivent être évaluées séparément.
Étape 6. Scénarios d'impact
Un scénario clair suit une structure simple :
En raison de cause, le système peut événement, affectant personnes, et entraîner conséquence.
Exemple : en raison de données historiques incomplètes, un système peut moins bien noter les candidatures d'une région donnée, réduisant leur accès à l'emploi sans explication ni révision effective.
Pour chaque scénario, on consigne :
- la phase du cycle ;
- la cause et les preuves ;
- les personnes concernées ;
- la probabilité ;
- la gravité et la réversibilité ;
- les contrôles existants ;
- l'incertitude ;
- le risque initial.
Étape 7. Méthodes et preuves
Les preuves peuvent inclure :
- des tests quantitatifs ;
- une évaluation par groupes ;
- des exercices de red teaming ;
- des entretiens et ateliers ;
- la littérature et les incidents antérieurs ;
- des audits de données ;
- des tests d'utilisabilité ;
- une analyse juridique ;
- la documentation du prestataire.
La donnée observée est distinguée de l'hypothèse. Si le prestataire ne fournit pas d'informations suffisantes, l'incertitude augmente et peut justifier des limites supplémentaires à l'usage du système.
Étape 8. Mesures
Les mesures suivent une hiérarchie d'action :
- éviter l'usage ou la fonction ;
- réduire le périmètre ou l'autonomie ;
- modifier les données, le modèle ou le processus ;
- ajouter des contrôles techniques ;
- introduire une supervision et une réparation ;
- informer et surveiller.
Un avertissement ne compense pas une conception intrinsèquement néfaste.
Chaque mesure a un responsable, un délai, des preuves, un indicateur et une efficacité attendue. Le risque résiduel est réévalué après son application.
Supervision humaine et réparation
L'intervention humaine doit disposer d'informations, de compétences, de temps et d'autorité suffisants. On définit quelles décisions nécessitent une révision préalable, un échantillonnage ou une double approbation.
Les personnes concernées ont besoin de canaux pour :
- obtenir des informations ;
- corriger des données ;
- apporter du contexte ;
- contester la décision ;
- bénéficier d'une révision humaine ;
- obtenir réparation le cas échéant.
On mesure si le canal fonctionne réellement, pas seulement s'il existe sur le papier.
Décision et acceptation
L'issue de l'évaluation peut être :
- approuver ;
- approuver sous conditions ;
- limiter la population ou la fonction ;
- piloter en mode silencieux ;
- demander davantage de preuves ;
- reconcevoir ;
- ne pas déployer.
L'acceptation d'un impact élevé doit correspondre au niveau d'autorité défini. Elle n'est pas déléguée tacitement à l'équipe technique.
Surveillance et révision
Indicateurs de suivi :
- erreurs par groupe ;
- annulations humaines ;
- réclamations ;
- décisions sans explication ;
- accès indus ;
- changements de distribution ;
- incidents ;
- bénéfice réellement obtenu.
Déclencheurs de révision : changement de système, de population, de données, de prestataire, de loi, de contexte ou de risque. L'évaluation est versionnée comme tout autre document vivant.
Intégration avec l'ISO 42001
L'ISO/IEC 42001 établit le système de management ; l'ISO/IEC 42005 approfondit l'évaluation d'un système donné. L'inventaire du système de management de l'IA (AIMS) peut déclencher et stocker les évaluations 42005. Leurs résultats alimentent les risques, objectifs, contrôles, audit et revue de direction.
On ne crée pas de processus parallèle lorsqu'une gestion produit existe déjà. L'évaluation s'intègre comme un jalon de conception et de changement au sein du système existant.
Modèle minimal
| Champ | Contenu |
|---|---|
| Identification | Système, version, propriétaire et approbations |
| Finalité | Usage prévu et limites |
| Description | Données, modèle, outils et environnement |
| Parties concernées | Personnes, groupes et société |
| Impacts | Bénéfices, préjudices et distribution |
| Scénarios | Cause, événement et conséquence |
| Preuves | Tests, consultations et incertitude |
| Mesures | Responsable, délai et efficacité |
| Résiduel | Risque après contrôles |
| Décision | Approbation, conditions et révision |
Les annexes de la norme proposent des exemples de modèles ; il convient toujours d'utiliser l'édition acquise.
Plan sur 30 jours
Semaine 1
Périmètre, description du système, équipe d'évaluation et parties concernées.
Semaine 2
Usages, bénéfices, préjudices et scénarios.
Semaine 3
Tests, consultation, évaluation et mesures.
Semaine 4
Risque résiduel, décision, publication interne et surveillance.
Le délai varie selon la complexité du système et les preuves disponibles.
Erreurs fréquentes
- Évaluer uniquement le modèle.
- N'inclure que les utilisateurs directs.
- Lister des risques sans construire de scénarios.
- Ignorer les bénéfices et leur distribution.
- Traiter l'incertitude comme une absence de risque.
- Ajouter des avertissements plutôt que reconcevoir.
- Consulter une fois tout déjà décidé.
- Ne pas relier les mesures aux impacts.
- Ne pas définir de mécanisme de réparation.
- Ne pas revoir l'évaluation après un changement.
Checklist
- Périmètre et version définis.
- Finalité, usages prévisibles et interdits.
- Personnes directes et indirectes identifiées.
- Bénéfices et préjudices distribués.
- Scénarios étayés par des preuves.
- Probabilité, gravité et incertitude.
- Mesures avec responsable et preuve.
- Supervision et réparation effectives.
- Décision formelle et conditions.
- Surveillance et révision.
- Coordination avec l'AIPD et l'analyse des droits fondamentaux.
Questions fréquentes
L'ISO 42005 est-elle certifiable ?
C'est une norme d'orientation pour réaliser des évaluations. Elle ne doit pas être présentée comme une certification indépendante d'un système.
Remplace-t-elle l'AIPD ?
Non. Elle peut apporter structure et preuves, mais l'AIPD comporte ses propres exigences juridiques qu'elle doit respecter de façon indépendante.
Le rapport doit-il être publié ?
Cela dépend de l'obligation applicable, de la politique interne et du risque. Au minimum, une transparence adéquate et une documentation aux fins de reddition de comptes doivent exister.
Les bénéfices sont-ils également évalués ?
Oui, avec les préjudices et leur distribution. Un bénéfice agrégé n'efface pas un préjudice grave subi par un groupe précis.
Summum Calidad peut intégrer l'évaluation d'impact de l'IA dans un système de management de l'IA (AIMS) conforme à l'ISO/IEC 42001 et la coordonner avec la protection des données, la sécurité et l'AI Act.