Évaluation d’impact sur les droits fondamentaux de l’IA : déterminer si elle s’applique et quoi documenter

Périmètre et précautions : une évaluation pour décider avant l’utilisation

L’évaluation d’impact sur les droits fondamentaux prévue à l’article 27 du règlement sur l’intelligence artificielle, appelé AI Act, est une analyse préalable que certains déployeurs doivent réaliser avant d’utiliser certains systèmes d’IA à haut risque. En pratique, son objectif est d’examiner comment l’utilisation prévue pourrait affecter des personnes ou des groupes dans un contexte donné, puis de définir les mesures, les responsables et les mécanismes de réponse nécessaires avant d’autoriser cette utilisation.

Il ne s’agit ni d’une certification du système, ni d’une garantie qu’aucun préjudice ne surviendra, ni d’une évaluation générale de toutes les activités d’une organisation. Elle ne remplace pas non plus automatiquement une analyse d’impact relative à la protection des données (AIPD). Ce guide a un objet plus restreint : aider à déterminer si l’obligation s’applique au cas considéré et à organiser le travail nécessaire pour assurer la traçabilité de la décision de déploiement.

La législation applicable peut évoluer. Les sources officielles fournies font état d’une modification de 2026 qui porte notamment sur le traitement des éléments de l’AIPD et sur le questionnaire que doit élaborer le Bureau de l’IA. Avant d’appliquer ce guide, consultez donc le texte consolidé en vigueur, les formulaires officiels et le calendrier applicable. Ce guide organise l’analyse ; il ne constitue pas un conseil juridique.

Arbre d’applicabilité : qui doit évaluer et quelle utilisation examiner

L’obligation prévue à l’article 27 ne s’applique pas indistinctement à toute organisation qui utilise l’IA. Il faut, de manière générale, vérifier si le système relève de la catégorie de systèmes à haut risque concernée et si la personne ou l’entité qui le déploie appartient à l’une des catégories visées par la norme. L’article mentionne notamment les organismes de droit public, les entités privées fournissant des services publics et les déployeurs de certains systèmes à haut risque dans les domaines du crédit et de l’assurance vie ou santé.

L’évaluation est liée à l’utilisation réellement prévue, et non seulement au nom commercial du produit ou à une classification générale fournie par le fournisseur. Il faut recenser la finalité, les fonctions activées, le processus organisationnel auquel elles s’intègrent et les personnes concernées. Si un outil sert à plusieurs usages, il est préférable d’examiner chaque cas d’utilisation séparément : l’obligation et les risques peuvent varier d’un cas à l’autre.

L’article 27 exclut de cette obligation spécifique les systèmes à haut risque visés au point 2 de l’annexe III. Cette exclusion ne doit pas être étendue à tout système qui semble présenter un risque limité et ne règle pas, à elle seule, les autres obligations découlant de l’AI Act, de la protection des données ou des règles sectorielles. Si la classification dépend d’une exception, d’une modification de l’utilisation ou d’une interprétation de la finalité, consignez le fondement de cette conclusion et demandez un examen juridique.

La décision peut se résumer par les questions suivantes : l’entité est-elle un déployeur visé ? Le système et le cas d’utilisation relèvent-ils du champ pertinent ? Une exception s’applique-t-elle ? Une évaluation déjà réalisée reste-t-elle valable pour cette utilisation ? S’il manque des informations pour répondre, la conclusion responsable n’est pas de supposer que l’obligation ne s’applique pas. Il faut préciser l’information manquante, désigner la personne chargée de l’obtenir et indiquer la condition qui empêche de finaliser l’approbation.

Calendrier, responsabilités et communication avec l’autorité

L’évaluation doit être achevée avant le déploiement concerné, et non après la survenue de préjudices ou le démarrage d’une activité habituelle. En pratique, le point de contrôle devrait se situer avant d’autoriser l’accès des utilisateurs, d’intégrer le système à un processus décisionnel ou de permettre à ses résultats d’influer sur des décisions concernant des personnes.

Les responsabilités au sein de l’organisation doivent être attribuées explicitement. L’équipe à l’origine du cas d’utilisation décrit le processus et les décisions que le système doit soutenir ; les fonctions de conformité, de protection des données, de droits fondamentaux, de sécurité et d’exploitation examinent leurs domaines respectifs ; enfin, une instance disposant de l’autorité suffisante décide si l’utilisation peut être approuvée, doit être modifiée ou doit être suspendue. La collaboration ne doit pas rendre floue la responsabilité de réaliser et de tenir à jour l’évaluation.

La norme prévoit que l’évaluation soit communiquée à l’autorité de surveillance du marché compétente une fois réalisée. Pour déterminer quelle autorité est compétente, ainsi que le canal et le format applicables, il faut vérifier la juridiction, l’organisation institutionnelle nationale et les consignes officielles en vigueur. Il ne convient pas d’inventer un destinataire ou une formalité à partir d’un modèle interne.

Il faut également définir à quel moment l’évaluation sera actualisée. Une modification de la finalité, de la population concernée, des données d’entrée, de la fréquence d’utilisation, du niveau d’automatisation, des mesures de contrôle humain ou des conditions de fonctionnement peut changer l’analyse. Consignez les changements qui imposent de rouvrir la décision, la personne chargée de les détecter et celle qui peut suspendre l’utilisation pendant le réexamen.

Que documenter : de la finalité aux personnes concernées

L’article 27 définit un socle d’informations permettant de relier le système à son contexte d’utilisation. L’évaluation doit décrire les processus dans lesquels le système sera utilisé conformément à sa finalité prévue ; la durée et la fréquence de son utilisation ; les catégories de personnes et de groupes susceptibles d’être concernés ; les risques spécifiques de préjudice dans ce contexte, compte tenu des informations pertinentes fournies par le fournisseur ; la mise en œuvre de mesures de contrôle humain ; et les mesures à prendre si les risques se matérialisent, y compris les dispositifs de gouvernance interne et les mécanismes de réclamation.

Pour que ces rubriques éclairent réellement une décision, évitez les formulations vagues comme « un biais est possible » ou « un contrôle humain sera maintenu ». Expliquez qui pourrait subir un préjudice, à quelle étape du processus, quelle conséquence est plausible et quels éléments permettraient de la détecter. Si l’impact dépend de circonstances inconnues — par exemple la taille d’un groupe concerné ou la qualité de certaines données —, consignez cette incertitude au lieu de la transformer en affirmation.

Les informations fournies par le fournisseur peuvent aider à comprendre les capacités, les limites et les risques connus du système, mais elles ne remplacent pas l’analyse du déployeur. Un même système peut avoir des conséquences différentes selon les critères d’admission, la manière dont le personnel interprète ses résultats, la possibilité de corriger les données et les moyens dont dispose une personne pour contester une décision. L’évaluation doit refléter ces conditions concrètes.

La consultation des personnes concernées, de leurs représentants ou de spécialistes peut apporter des informations absentes de la documentation technique. Il faut distinguer les obligations légales des bonnes pratiques éditoriales ou organisationnelles : si la norme ne prescrit pas de méthode de consultation précise, consignez la consultation comme une mesure choisie pour améliorer l’analyse, et non comme une exigence textuelle attribuée à l’article.

Des risques aux décisions : mesures, éléments probants et limites

Une liste de risques ne suffit pas. Chaque risque pertinent doit être relié à une mesure vérifiable, à un responsable, à un délai et à un élément permettant de vérifier l’efficacité de la mesure. Si une mesure dépend d’une autre équipe, d’une fonctionnalité qui n’est pas encore mise en œuvre ou d’une validation en attente, ne la présentez pas comme déjà opérationnelle. Traitez-la comme une condition préalable au déploiement.

Les mesures peuvent consister à limiter la finalité ou les personnes admissibles, réduire la fréquence d’utilisation, améliorer la qualité des données, définir des seuils de réexamen, tester les résultats afin de détecter des différences pertinentes, exiger un examen humain avant une décision défavorable, permettre la correction et les réclamations, ou arrêter le système si des signes de préjudice apparaissent. Ces possibilités doivent être justifiées dans le contexte considéré ; elles ne constituent pas une liste exhaustive et ne garantissent pas, à elles seules, la conformité.

Le contrôle humain doit être concret et réalisable. Précisez qui effectue l’examen, quelles informations cette personne reçoit, quelle formation lui est nécessaire, quelle marge de manœuvre elle a pour s’écarter du résultat et comment sa décision est consignée. Une personne qui confirme automatiquement les résultats, sans disposer du temps, des informations ou de l’autorité nécessaires pour intervenir, ne constitue pas une mesure efficace simplement parce qu’elle est mentionnée dans une procédure.

L’autorisation peut être assortie de conditions. Par exemple, un projet pilote limité peut être autorisé uniquement après la réalisation des tests, la validation du canal de réclamation et l’attribution des ressources nécessaires au contrôle. La décision doit définir des critères de suspension ou de modification, tels que des erreurs dépassant un seuil fixé à l’avance, des réclamations révélant une tendance, des changements non approuvés du système ou l’impossibilité d’assurer le contrôle promis. Les seuils précis doivent découler de l’évaluation ; ils ne doivent pas être présentés comme des valeurs universelles.

Lien avec l’AIPD : coordonner sans confondre

Une AIPD, ou analyse d’impact relative à la protection des données, est réalisée conformément au régime de protection des données lorsque le traitement envisagé est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes. Elle porte sur le traitement de données à caractère personnel et sur les obligations relatives à la protection des données ; l’évaluation prévue à l’article 27 porte sur les impacts de l’utilisation du système d’IA sur les droits fondamentaux, dans le champ défini par l’AI Act. Les deux analyses peuvent se recouper, mais leurs objectifs et leurs périmètres ne sont pas identiques.

L’article 27 établit un lien avec les évaluations de protection des données. En outre, les sources officielles fournies indiquent qu’une modification de 2026 concerne la réutilisation des éléments de l’AIPD et le questionnaire que doit élaborer le Bureau de l’IA. Il ne faut donc pas appliquer automatiquement une formulation antérieure sur la nécessité de compléter, réutiliser ou citer une AIPD : consultez la version consolidée en vigueur et les consignes officielles pour connaître les conditions actuelles.

Comme méthode de travail, conservez une cartographie des correspondances. Indiquez quelles analyses de l’AIPD éclairent également les personnes, les données ou les risques pertinents pour l’évaluation des droits fondamentaux ; quels éléments nécessitent une analyse complémentaire ; et quelles questions ne sont pas couvertes par une évaluation poursuivant l’autre objectif. Les renvois entre documents évitent les doublons, mais doivent permettre à une personne chargée du contrôle de retrouver les éléments probants et de comprendre pourquoi ils répondent à la rubrique concernée.

Si aucune AIPD n’est requise dans le cas considéré, cela ne démontre pas que l’évaluation prévue à l’article 27 ne s’applique pas non plus. Inversement, l’existence d’une AIPD ne prouve pas à elle seule que les risques dépassant le cadre du traitement des données ont été couverts. L’entité doit documenter la conclusion applicable au cas, la norme en vigueur sur laquelle elle s’appuie et les lacunes qui restent à traiter.

Cas pratique : évaluation de demandes de crédit

Supposons qu’une entité utilise un système à haut risque pour contribuer à l’évaluation de demandes de crédit. Cet exemple est hypothétique : il n’affirme ni qu’un système précis existe, ni qu’une entité donnée est soumise à l’obligation, ni que des préjudices se sont produits. Avant de l’appliquer, l’organisation devrait confirmer la classification, son rôle, l’utilisation prévue et les conditions juridiques du cas.

Il faut d’abord représenter le processus : quelles informations le système reçoit, quel résultat il produit, qui le consulte et si ce résultat recommande, ordonne ou détermine une décision. La fréquence et la durée d’utilisation doivent aussi être décrites. Une analyse qui se contente d’indiquer que « le modèle évalue le crédit » ne précise pas si le personnel peut s’écarter de la recommandation, si le résultat provoque un refus automatique ou s’il existe un second examen.

Il faut ensuite identifier les personnes concernées — par exemple les demandeurs et les personnes dont les données influent indirectement sur l’évaluation — puis formuler des hypothèses de préjudice que l’entité devra valider. Il pourrait être utile d’examiner la possibilité de décisions défavorables liées à des données incomplètes, d’effets disproportionnés sur certains groupes, d’erreurs difficiles à corriger ou d’obstacles à la compréhension et à la contestation d’une décision. Il ne s’agit pas de conclusions sur un modèle réel : elles nécessitent des données, des tests et une analyse du contexte.

Les mesures doivent répondre aux hypothèses formulées. L’entité pourrait vérifier la provenance et la qualité des données, tester les résultats et les différences pertinentes, empêcher qu’un score constitue le seul fondement de décisions défavorables lorsque l’analyse indique qu’un examen est nécessaire, former le personnel, consigner les raisons de s’écarter d’une recommandation et proposer un mécanisme accessible de correction des informations ou de réclamation. Il faut préciser qui effectue chaque contrôle et quel résultat conduirait à juger la mesure insuffisante.

Avant l’approbation, l’instance responsable devrait vérifier que les mesures existent et que le contrôle humain est assorti d’une autorité effective. S’il manque des résultats de tests, si aucun canal de réclamation n’est opérationnel ou s’il est impossible d’expliquer quelles informations fondent une décision, la réponse prudente peut être de reporter, de restreindre ou de ne pas autoriser le déploiement tant que le problème n’est pas résolu. Cette conclusion relève de l’entité et doit s’appuyer sur ses propres éléments probants ; l’exemple ne remplace pas son analyse.

Liste de contrôle avant d’approuver l’utilisation

Une liste de contrôle est utile si elle débouche sur une décision et ne devient pas une simple formalité à cocher. Chaque réponse doit être associée à une source, à un responsable et, le cas échéant, à une action en attente. Distinguez les exigences juridiques identifiées dans le texte en vigueur des pratiques internes ajoutées par l’organisation pour renforcer l’analyse.

Avant de conclure, vérifiez que le document identifie précisément le système, sa version, sa finalité, les processus concernés, le calendrier et la fréquence d’utilisation. Assurez-vous que les personnes et les groupes concernés sont décrits de façon suffisamment concrète, que chaque risque est relié à un préjudice possible dans ce contexte et que les limites du système ainsi que les informations pertinentes du fournisseur ont été prises en compte.

Confirmez également que le contrôle humain existe dans la pratique, que les mesures ont des responsables et des éléments probants, et que les risques résiduels sont connus. Vérifiez les mécanismes de détection des problèmes, de réception des réclamations et de réponse aux incidents. Si des personnes concernées ou des spécialistes ont été consultés, consignez ce que cette consultation a apporté et les décisions qu’elle a influencées. Si aucune consultation n’a eu lieu, indiquez si cette absence limite l’analyse.

Enfin, vérifiez la communication à l’autorité compétente, les renvois à l’AIPD lorsqu’ils sont pertinents, la date de réexamen et les conditions qui imposent de rouvrir l’évaluation. L’approbation devrait préciser la version de la documentation examinée, les conditions assorties à l’utilisation et la personne habilitée à l’interrompre.

Points à vérifier avant d’utiliser ce guide

L’évaluation doit s’appuyer sur la version consolidée de l’AI Act en vigueur à la date pertinente, et non uniquement sur des résumés, des projets ou des versions antérieures. Les sources fournies recensent une modification législative de 2026 et une consolidation datée de juillet 2026 ; elles indiquent également que la Commission européenne a actualisé ses questions fréquentes en août 2026. Comme les règles et les dates peuvent évoluer, vérifiez que ces versions correspondent à la période et au cas d’utilisation que vous examinez.

Vérifiez dans le texte officiel le périmètre exact des déployeurs soumis à l’obligation, les catégories de systèmes concernées, l’exception, les rubriques requises, la communication à l’autorité et l’effet des modifications sur l’AIPD. Vérifiez aussi si des formulaires officiels définitifs ont été publiés et comment effectuer la notification dans l’État membre concerné. Une foire aux questions peut aider à s’orienter, mais elle ne prévaut pas sur l’acte législatif.

Le calendrier d’application doit faire l’objet d’une vérification distincte : la date pertinente dépend des dispositions en vigueur et de la catégorie de système concernée. Ne déduisez pas une date générale d’une actualité ou d’une version antérieure du règlement. En cas de doute sur le champ d’application, l’autorité compétente ou l’interaction avec d’autres règles, demandez un conseil juridique avant d’autoriser l’utilisation.

Pour élargir l’analyse, reliez cette évaluation aux procédures internes de sécurité et de gestion des risques de l’entité, à son processus de comparaison des systèmes et à l’évaluation des solutions possibles avant de choisir un outil. Ces examens complètent la décision, mais ne remplacent pas l’évaluation juridique lorsqu’elle est obligatoire.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.