Analyse d'impact IA : ce que la norme exige vraiment

Objet et définition de l'analyse d'impact IA

L'analyse d'impact des systèmes d'IA pose une question que la gestion des risques classique ne couvre pas : qui est affecté par ce système, et dans quelle mesure peut-il lui nuire ?^[2] Le sujet de l'évaluation, ce sont les personnes. Individus soumis à une décision automatisée, groupes traités différemment par le modèle, et société au sens large lorsque le système opère à grande échelle.^[2]

La norme ISO/IEC 42001:2023 traite cette exigence comme un exercice autonome, distinct du registre de risques organisationnel.^[2] ISO a par ailleurs publié la norme ISO/IEC 42005, dédiée spécifiquement à l'évaluation d'impact des systèmes d'IA, ce qui confirme l'importance accordée à cette activité dans la famille 42000.^[5]

Pour un responsable conformité ou un DPO, le parallèle avec l'analyse d'impact relative à la protection des données (AIPD) est tentant. Mais le périmètre est plus large : l'analyse d'impact IA couvre les effets éthiques, sociaux, environnementaux et opérationnels, pas seulement la protection des données personnelles.^[1] Un article dédié détaille les différences entre AIPD et analyse d'impact IA.

Positionnement dans la structure de la norme

La clause 6.1.4 demande à l'organisation de planifier l'approche d'évaluation d'impact. La clause 8.4 impose la réalisation opérationnelle de cette évaluation.^[4] L'annexe B.5 fournit des orientations de mise en œuvre, et les contrôles A.5 de l'annexe A contiennent les objectifs de contrôle dédiés à l'évaluation des impacts.^[2]

En pratique, la logique suit trois temps : planifier la méthode (clause 6.1.4), exécuter l'évaluation (clause 8.4), conserver les résultats comme information documentée au sens de la clause 7.5.^[2] Omettre l'un de ces trois volets transforme un bon travail d'analyse en constat de non-conformité lors de l'audit.

Pour situer ces clauses dans l'ensemble du référentiel, consultez la page sur la structure de la norme clause par clause.

Position de l'analyse d'impact dans les clauses opérationnelles

Clause	Objet
8.1	Planification et maîtrise opérationnelles
8.2	Appréciation des risques IA
8.3	Traitement des risques IA
8.4	Analyse d'impact des systèmes d'IA

Différence entre risk assessment et impact assessment

Ces deux exercices sont souvent confondus. La norme les sépare volontairement parce qu'ils répondent à des questions distinctes.^[2] Le risk assessment (clauses 6.1.2 et 8.2) adopte le point de vue de l'organisation : que pourrait-il se passer, quelle probabilité, quel coût pour nous ? L'impact assessment (clauses 6.1.4 et 8.4) adopte le point de vue des personnes affectées : qui pourrait être lésé, quelle gravité, les droits fondamentaux sont-ils en jeu ?^[4]

Un test simple proposé par un guide spécialisé : si vous pouvez rédiger l'intégralité du document sans nommer une seule catégorie de personne extérieure à votre organisation, vous avez produit un risk assessment, pas un impact assessment.^[2]

Les deux évaluations s'alimentent mutuellement. Un système identifié comme à haut risque devrait déclencher une analyse d'impact approfondie, et les résultats de l'impact assessment orientent la sélection des contrôles dans le plan de traitement.^[4] L'article consacré à la distinction entre risques et analyse d'impact approfondit ce point.

Qui est concerné par l'évaluation

L'analyse s'organise en trois cercles concentriques, du plus proche au plus large.^[2]

• Individus soumis au système. Le candidat filtré par un outil de recrutement, le client dont la demande de crédit est scorée, le patient dont l'imagerie est triée, l'employé dont la productivité est mesurée.
• Groupes susceptibles d'être affectés de manière inégale. Lorsqu'un système performe différemment selon les groupes, cette différence constitue l'impact. C'est ici que l'équité, l'accessibilité et la qualité des données d'entraînement cessent d'être abstraites.
• Société et environnement. Pertinent quand un système opère à grande échelle, influence ce que de nombreuses personnes voient, ou touche la sécurité, l'emploi ou les services publics.

Pour chaque cercle, les questions à documenter sont identiques : nature de l'impact, nombre de personnes touchées, gravité, réversibilité, et vulnérabilité éventuelle des personnes affectées.^[2]

Contenu attendu d'une analyse d'impact

La norme ne prescrit pas un formulaire unique, mais les sources convergent sur six éléments que l'auditeur s'attend à trouver.^[1][8]

Périmètre et contexte

Délimiter le système évalué, ses cas d'usage, le contexte géographique, culturel et juridique de déploiement, et les parties prenantes identifiées (utilisateurs finaux, développeurs, régulateurs, communautés potentiellement affectées).^[8]

Identification des impacts positifs et négatifs

L'évaluation couvre les dimensions éthique, opérationnelle, juridique, sociale et environnementale.^[1] Les impacts indirects comptent autant que les impacts directs. Par exemple, un modèle de prédiction de la demande énergétique peut influencer des décisions d'investissement à grande échelle.^[1]

Cotation de la gravité et de la vraisemblance

Une grille de scoring sévérité-vraisemblance permet de prioriser les actions.^[1] L'organisation définit ses propres échelles, mais doit les appliquer de manière cohérente à tous les systèmes dans le périmètre du SMIA.^[4]

Consultation des parties prenantes

La norme attend que des perspectives diverses soient intégrées : utilisateurs finaux, éthiciens, régulateurs, communautés impactées.^[1] Ce point est souvent négligé dans les démarches observées, alors qu'il constitue un critère d'audit explicite.

Mesures d'atténuation

Les résultats de l'analyse alimentent le plan de traitement des risques et les contrôles opérationnels.^[1] L'article sur le traitement du risque IA détaille cette articulation.

Documentation et traçabilité

L'organisation conserve les preuves de l'évaluation, des décisions prises et des actions d'atténuation engagées.^[1] Cette documentation est ce qui rend l'exercice auditable au sens de la clause 7.5.

Déclencheurs et périodicité

L'analyse d'impact n'est pas un document produit une fois pour l'audit puis classé. Selon un guide spécialisé, les déclencheurs de révision sont les suivants.^[2]

• Avant le déploiement. Une évaluation réalisée après que le système prend déjà des décisions a manqué son objectif.
• Changement d'usage prévu. Un modèle conçu pour la recherche documentaire interne et réorienté vers la communication client nécessite une réévaluation.
• Modification significative du système ou de son contexte. Réentraînement sur de nouvelles données, changement de population cible, évolution réglementaire.

La norme demande de revoir et mettre à jour l'évaluation lorsque des changements significatifs sont apportés au système ou à son contexte d'utilisation.^[1] L'itération est donc structurelle, pas optionnelle.

Ce caractère itératif distingue l'exercice d'un simple livrable de conformité. Il s'apparente davantage à un processus vivant, lié au cycle de vie du modèle.^[1]

Illustration : un éditeur RH en Suisse romande

Prenons un éditeur de logiciel basé à Lausanne qui commercialise un outil de présélection de candidatures utilisant un modèle de traitement du langage naturel. L'outil analyse les CV et attribue un score de correspondance au poste.

En appliquant les trois cercles de l'analyse d'impact, l'éditeur identifie :

• Individus : les candidats dont le dossier est scoré. Un faux négatif signifie une candidature écartée à tort.
• Groupes : si le corpus d'entraînement surreprésente des CV rédigés en français standard, les candidats francophones d'Afrique de l'Ouest ou du Maghreb pourraient être systématiquement sous-scorés.
• Société : à l'échelle du marché de l'emploi romand, un biais systématique dans un outil largement adopté pourrait renforcer des discriminations structurelles.

La cotation conduit l'éditeur à classer l'impact sur les groupes comme sévère (score élevé sur l'échelle gravité-vraisemblance), ce qui déclenche un contrôle renforcé : audit de biais trimestriel sur les données de production, avec seuils d'alerte documentés.

L'éditeur documente aussi la consultation des parties prenantes : entretiens avec trois entreprises clientes, un syndicat professionnel et un spécialiste de l'équité algorithmique. Ce type de trace est précisément ce qu'un auditeur cherchera dans le dossier.

Piège fréquent : confondre registre de risques et impact assessment

Les démarches observées révèlent un schéma récurrent : l'organisation rédige son registre de risques habituel, ajoute une colonne « impact sur les tiers » et considère l'exigence satisfaite. Or la norme traite explicitement l'analyse d'impact comme une exigence distincte, séparée du risk assessment.^[2]

Le problème n'est pas formel. Un registre de risques reste centré sur ce que l'organisation pourrait perdre (réputation, amendes, disponibilité). L'analyse d'impact demande de se placer du côté des personnes affectées et d'évaluer la gravité pour elles, pas pour vous.^[2]

Lors d'un audit de certification, un auditeur formé à ISO 42001 demandera à voir un document séparé, ou à tout le moins une section clairement identifiée qui répond aux questions propres à l'impact assessment : qui, quelle gravité pour cette personne, quelle vulnérabilité, quelle réversibilité.^[6] Si la réponse se limite à « risque moyen pour l'entreprise », c'est un constat de non-conformité probable.

Pour les organisations déjà certifiées ISO 27001, cette exigence est la plus déroutante car elle n'a pas d'équivalent dans le SMSI.^[6] L'article sur les différences entre ISO 42001 et ISO 27001 détaille les autres écarts structurels entre les deux référentiels.

Lien avec l'AI Act et la FRIA

L'AI Act européen impose aux déployeurs de systèmes d'IA à haut risque une évaluation des droits fondamentaux (Fundamental Rights Impact Assessment, FRIA). L'analyse d'impact ISO 42001 et la FRIA se recoupent largement, mais ne sont pas identiques.^[6] Un SMIA bien construit peut néanmoins structurer les processus et les preuves nécessaires à la conformité AI Act.^[6] Pour approfondir ce recouvrement, consultez la page ISO 42001 et AI Act européen.

Questions fréquentes

À lire ensuite