Évaluation des impacts

Pourquoi ce chapitre est le plus utile

ISO/IEC 42001 n'impose pas de formulaire type pour évaluer les impacts d'un système d'IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire, mais elle exige — via les clauses relatives à l'appréciation des risques (6.1.2) et aux impacts sur les parties prenantes (6.1.4) — que l'organisme dispose d'une méthode reproductible pour le faire. Dans la pratique, cette méthode porte un nom emprunté à la littérature réglementaire : l'évaluation d'impact algorithmique, ou AIA (Algorithmic Impact Assessment).

Ce chapitre n'est pas un exercice de conformité abstrait. C'est le filtre qui détermine si un système peut être déployé tel quel, doit être corrigé, ou doit être refusé. Sans seuils explicites, la décision de déployer repose sur l'intuition de la dernière personne consultée — ce qui ne survit ni à un audit ni à un incident.

Une AIA mal calibrée produit deux échecs symétriques : trop stricte, elle bloque des usages à faible risque et pousse les équipes à la contourner ; trop permissive, elle laisse passer des systèmes à fort impact sans garde-fou. L'objectif n'est pas la sévérité mais la proportionnalité documentée.

L'évaluation d'impact algorithmique : principe et origine

L'AIA est une démarche structurée qui consiste à examiner, avant la mise en production d'un système d'IA, les effets qu'il peut produire sur les personnes, les groupes et l'organisation elle-même — au-delà de la seule performance technique. Elle est apparue dans les administrations publiques (Canada, puis Union européenne avec le AI ActAI ActConformitéRèglement européen sur l'intelligence artificielle, adopté en 2024. Il classe les systèmes en quatre niveaux de risque selon leur usage — jamais selon leur technologie.Voir dans le glossaire) avant d'être reprise comme bonne pratique dans les référentiels de management, dont ISO/IEC 42001.

La logique est proche de celle d'une étude d'impact environnemental : on n'évalue pas seulement si le système « fonctionne », on évalue ce qu'il produit comme effets sur son environnement humain et organisationnel — discrimination, perte d'autonomie décisionnelle, erreurs à conséquences irréversibles, atteinte à la réputation, dépendance opérationnelle excessive.

Une AIA répond à quatre questions, dans cet ordre : qui est affecté, comment, avec quelle gravité potentielle, et avec quelle probabilité. Ce sont ces réponses qui alimentent la grille présentée plus loin.

AIA et DPIA : deux évaluations complémentaires, pas interchangeables

La confusion la plus fréquente en entreprise consiste à croire qu'une DPIA (Data Protection Impact Assessment, ou analyse d'impactAIPDConformitéAnalyse d'impact relative à la protection des données, obligatoire dès qu'un traitement est susceptible d'engendrer un risque élevé — ce qui couvre la plupart des systèmes de profilage.Voir dans le glossaire relative à la protection des donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire au sens du RGPDRGPDConformitéRèglement européen sur la protection des données personnelles. Il s'applique dès qu'un système d'IA traite de telles données, et se cumule avec l'AI Act.Voir dans le glossaire) couvre déjà le sujet dès lors qu'un système d'IA traite des données personnelles. Ce n'est vrai qu'en partie.

Un système de scoring interne qui n'utilise aucune donnée à caractère personnel (par exemple un modèle de maintenance prédictive sur des capteurs machine) peut échapper totalement à l'obligation de DPIA tout en justifiant pleinement une AIA — s'il conditionne des décisions d'arrêt de production ou de sécurité. Ne pas confondre absence de donnée personnelle et absence de risque.

Lorsque les deux évaluations sont requises, il est recommandé de les mener en parallèle avec des points de synchronisation, plutôt que de faire de la DPIA un sous-produit de l'AIA ou l'inverse : les deux ont des finalités différentes et des porteurs souvent différents.

Cartographier les parties prenantes

La première étape opérationnelle d'une AIA consiste à lister, de façon exhaustive et non seulement intuitive, l'ensemble des parties affectées par le système. L'erreur la plus commune est de s'arrêter à l'utilisateur direct de l'outil.

Une cartographie sérieuse distingue au minimum quatre catégories :

• Sujets directs — les personnes sur lesquelles porte une décision ou une prédiction du système (candidat évalué, patient, client, salarié noté).
• Utilisateurs opérationnels — celles et ceux qui interagissent avec le système au quotidien pour produire un résultat (agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire, analyste, soignant, recruteur).
• Décideurs en aval — celles et ceux qui s'appuient sur la sortie du système sans le manipuler directement (responsable hiérarchique validant une recommandation).
• Tiers indirectement affectés — personnes ou groupes qui subissent des effets de second ordre sans jamais interagir avec le système (candidats non retenus par effet de comparaison, riverains d'un site optimisé par IA, collègues d'une personne mal notée).

Un système de tri de CV touche le candidat évalué (sujet direct), le recruteur qui utilise l'outil (utilisateur opérationnel), le manager qui valide l'embauche sur la base du score (décideur en aval), et l'ensemble des candidats non présélectionnés dont le dossier n'a jamais été examiné par un humain (tiers indirectement affectés). Omettre cette dernière catégorie est l'angle mort le plus fréquent des AIA menées trop vite.

Pour chaque catégorie, l'évaluation documente le type d'impact possible (financier, psychologique, professionnel, sur la santé, sur la réputation), son caractère réversible ou non, et l'existence ou non d'un recours effectif en cas d'erreur.

Déterminer les seuils de criticité

Une fois les parties prenantes et les impacts potentiels identifiés, l'évaluation se formalise sur une grille à deux axes : la gravité de l'impact s'il se produit, et la probabilité qu'il se produise compte tenu de la maturité du système et de son contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire d'usage. C'est cette grille qui est représentée dans le schéma ci-dessus.

Le croisement des deux axes définit des zones de risque auxquelles sont associées des obligations différenciées :

Fixez les seuils avant d'évaluer un système précis, en atelier avec la gouvernance IA, et documentez les critères de passage d'une zone à l'autre. Si les seuils sont ajustés a posteriori pour faire rentrer un projet déjà engagé dans une zone plus favorable, l'AIA perd toute valeur probante en cas de contrôle.

La gravité s'apprécie sur plusieurs dimensions cumulatives : nombre de personnes concernées, caractère réversible ou non de la conséquence, existence d'un recours, sensibilité de la catégorie de personnes affectées (mineurs, personnes vulnérables, salariés en position de dépendance). La probabilité s'apprécie à partir de données concrètes — taux d'erreur mesuré en test, historique d'incidents sur des systèmes comparables, robustesse démontrée sur des populations sous-représentées dans les données d'entraînement — et non à partir d'une estimation qualitative non étayée.

Construire la grille d'évaluation : méthode pas à pas

1. Décrire le système en langage non technique — fonction, données en entrée, type de sortie, degré d'autonomie de la décision (assistance, recommandation, décision automatisée).
2. Lister les parties prenantes selon les quatre catégories vues plus haut, sans se limiter à l'utilisateur direct.
3. Identifier les scénarios d'impact négatif pour chaque catégorie — un scénario par risque plausible, pas un fourre-tout générique du type « risque de biais ».
4. Coter chaque scénario en gravité et en probabilité, en s'appuyant sur des éléments factuels (résultats de tests, retours d'expérience, littérature du domaine).
5. Positionner le scénario le plus défavorable sur la grille — c'est lui, et non la moyenne des scénarios, qui détermine la zone de risque du système.
6. Documenter les mesures d'atténuation déjà en place et celles à ajouter pour espérer redescendre d'une zone.
7. Faire valider la cotation par une personne extérieure à l'équipe projet — l'auto-évaluation par les concepteurs du système sous-estime systématiquement la probabilité des scénarios défavorables.

Le point 7 n'est pas une formalité bureaucratique : les études sur l'évaluation de risque montrent une sous-estimation récurrente des probabilités d'échec par les équipes qui ont conçu le système évalué, un biais bien documenté sous le nom d'optimisme de conception.

Le cycle de vie de l'évaluation

Une AIA n'est pas un document figé produit une fois avant mise en production. ISO/IEC 42001 attend une réévaluation à chaque changement significatif du système ou de son contexte d'usage :

• changement de périmètre fonctionnel ou de population cible ;
• réentraînement du modèle sur un nouveau jeu de données ;
• changement de fournisseur ou de version d'un modèle tiers intégré au système ;
• incident ou quasi-incident détecté en production ;
• évolution du cadre réglementaire applicable.

En dehors de ces déclencheurs, une cadence de revue minimale doit être fixée en fonction de la zone de risque initiale — plus la zone est critique, plus la fréquence de revue est élevée, comme indiqué dans le tableau des seuils. Chaque réévaluation est tracée dans le registre des risques IA, avec la date, la cotation obtenue et les mesures ajustées.

Pièges fréquents

Les évaluations d'impact échouent rarement par absence de méthode formelle. Elles échouent par des raccourcis pris dans leur application :

• Évaluer le système en théorie, pas en usage réel — un système conçu pour assister une décision humaine peut, en pratique, être suivi aveuglément par les opérateurs faute de temps ; l'AIA doit intégrer ce risque d'automatisation de fait, pas seulement l'intention de conception.
• Confondre absence de plainte et absence d'impact — l'absence de recours effectif pour les personnes affectées masque souvent un impact réel non remonté, en particulier pour les tiers indirectement affectés.
• Traiter l'AIA comme un jalon projet unique — remplie une fois en phase de cadrage, puis jamais mise à jour malgré des évolutions substantielles du modèle.
• Sous-traiter la cotation à l'éditeur de la solution — un fournisseur externe n'a ni la visibilité sur le contexte d'usage réel, ni l'intérêt à coter son propre produit en zone élevée.

Checklist opérationnelle

• Le système est décrit en langage non technique, accessible à un comité de gouvernance non spécialiste.
• Les quatre catégories de parties prenantes ont été examinées, y compris les tiers indirectement affectés.
• Chaque scénario d'impact négatif est coté sur des données factuelles, pas sur une impression.
• Le scénario le plus défavorable détermine la zone de risque retenue.
• Les seuils de criticité appliqués ont été fixés avant l'évaluation du projet concerné.
• La cotation a été validée par une personne extérieure à l'équipe projet.
• Une DPIA distincte a été engagée si des données personnelles sont traitées.
• Une cadence de réévaluation est fixée et inscrite au registre des risques IA.
• Les déclencheurs de réévaluation (réentraînement, changement de fournisseur, incident) sont connus de l'équipe produit.

Cette checklist ne remplace pas le jugement du comité de gouvernance : elle garantit seulement qu'aucune étape structurante n'a été oubliée avant que ce jugement ne s'exerce.