FRIA : l'analyse d'impact droits fondamentaux (Art. 27)

La FRIA n’est pas une AIPD RGPD rebaptisée. C’est une obligation autonome de l’article 27 de l’AI Act, qui pèse sur le déployeur — pas sur le fournisseur — et qui ne concerne qu’une poignée d’acteurs bien précis. Beaucoup d’entreprises s’inquiètent à tort d’y être soumises ; d’autres, réellement concernées, ne l’ont pas encore identifiée. Voici comment trancher, et comment construire l’analyse.

Qu’est-ce qu’une FRIA (analyse d’impact sur les droits fondamentaux) ?

FRIA est l’acronyme de Fundamental Rights Impact Assessment, que le règlement (UE) 2024/1689 (AI Act) traduit par « analyse d’impact des systèmes d’IA à haut risque sur les droits fondamentaux ». Elle est régie par l’article 27 du règlement.

L’idée est simple : avant de déployer certains systèmes d’IA à haut risque, l’organisation qui les utilise doit évaluer l’effet concret que ce système peut produire sur les droits et libertés des personnes — non-discrimination, dignité, vie privée, accès à un service, droit à un recours. Là où l’analyse de conformité technique (à la charge du fournisseur) vérifie que le système est bien construit, la FRIA regarde ce qui se passe en aval : dans mon contexte d’usage, sur mes publics, avec mes processus, quels dommages ce système peut-il causer ?

C’est une logique que je connais bien pour l’avoir pratiquée côté protection des données depuis des années : on ne raisonne pas sur l’outil dans l’absolu, mais sur l’usage réel qu’on en fait. La FRIA transpose cette approche au terrain des droits fondamentaux.

Qui doit réaliser une FRIA ? (la question qui tranche tout)

C’est le point le plus mal compris. L’article 27(1) limite l’obligation à trois catégories de déployeurs de systèmes d’IA à haut risque au sens de l’article 6(2) :

1. Les organismes de droit public (administrations, collectivités, établissements publics) ;
2. Les entités privées fournissant des services publics (par exemple un délégataire de service public, un opérateur privé de transport, d’éducation, de santé ou d’aide sociale) ;
3. Tout déployeur — public ou privé — d’un système à haut risque relevant des points 5 b) et 5 c) de l’annexe III, c’est-à-dire l’évaluation de la solvabilité et le scoring de crédit des personnes physiques, et l’évaluation des risques et la tarification en assurance vie et santé.

Autrement dit : si vous êtes une PME privée qui déploie un outil d’IA de tri de CV (annexe III, point 4) ou de vidéosurveillance augmentée, vous êtes soumis aux obligations du déployeur de l’article 26, mais pas à la FRIA de l’article 27 — sauf à basculer dans l’une des trois catégories ci-dessus. En revanche, une banque qui utilise un modèle de scoring de crédit, ou un assureur qui tarifie un contrat santé au moyen d’un algorithme, y sont soumis quel que soit leur statut.

L’article 27(1) prévoit par ailleurs une exception : les systèmes à haut risque destinés à être utilisés dans le domaine visé au point 2 de l’annexe III (gestion et exploitation des infrastructures critiques) sont exclus de l’obligation de FRIA.

Bien identifier son rôle dans la chaîne de valeur est donc un préalable. Si vous n’êtes pas au clair sur la frontière entre fournisseur et déployeur, commencez par la distinction fournisseur / déployeur de l’AI Act, puis vérifiez le classement de votre système avec le guide IA à haut risque : liste et obligations.

Les 6 éléments obligatoires de la FRIA

L’article 27(1) énumère limitativement le contenu de l’analyse. Une FRIA conforme doit comporter les six éléments suivants — ni plus courte, ni éludée :

a) La description des processus du déployeur dans lesquels le système à haut risque sera utilisé, conformément à sa destination. Il s’agit de décrire le processus métier réel : à quelle étape l’IA intervient, sur quelle décision elle pèse, quelle est sa place dans la chaîne humaine.

b) La période et la fréquence d’utilisation prévues pour chaque système. Un usage ponctuel et un usage massif quotidien n’emportent pas le même niveau de risque : ce paramètre doit être documenté.

c) Les catégories de personnes physiques et de groupes susceptibles d’être affectés dans le contexte d’usage spécifique. C’est ici qu’on identifie les publics vulnérables (mineurs, demandeurs d’emploi, allocataires, patients) et les groupes exposés à un risque de traitement différencié.

d) Les risques spécifiques de préjudice susceptibles d’affecter ces personnes ou groupes, en tenant compte des informations communiquées par le fournisseur au titre de l’article 13 (transparence). On raisonne par droit : discrimination, atteinte à la vie privée, exclusion de l’accès à un service, erreur non détectée.

e) La description des mesures de surveillance humaine mises en œuvre, conformément à la notice d’utilisation. C’est le lien direct avec l’article 14 : qui contrôle, à quel moment, avec quelle capacité réelle de s’écarter de la recommandation de la machine (contre l’automation bias).

f) Les mesures à prendre en cas de matérialisation des risques, y compris les modalités de gouvernance interne et les mécanismes de réclamation. Une FRIA n’est pas un diagnostic : elle doit prévoir le plan d’action et la voie de recours ouverte aux personnes.

Ce dernier point est celui que les organisations sous-estiment le plus. Dans mon expérience de conseil, un dispositif de traitement des réclamations réellement accessible pèse plus lourd, en cas de contrôle, qu’une analyse de risque abondante mais sans suite opérationnelle.

FRIA et AIPD : deux analyses distinctes qui se complètent

C’est la confusion la plus fréquente, et elle est légitime : les deux exercices se ressemblent. Il faut pourtant les distinguer nettement.

L’AIPD (analyse d’impact relative à la protection des données) découle de l’article 35 du RGPD. Elle porte sur les risques que le traitement de données personnelles fait peser sur les droits et libertés des personnes. La FRIA, elle, porte sur l’impact du système d’IA sur l’ensemble des droits fondamentaux — dont, mais pas seulement, la protection des données.

L’article 27(4) organise leur articulation : lorsqu’une obligation de la FRIA est déjà satisfaite par l’AIPD réalisée au titre de l’article 35 du RGPD (ou de l’article 27 de la directive « police-justice » 2016/680), la FRIA vient compléter cette AIPD. Vous ne refaites pas deux fois le même travail : vous capitalisez sur l’AIPD existante et vous ajoutez les volets que le RGPD ne couvre pas (surveillance humaine, mécanismes de réclamation propres à l’usage de l’IA, droits fondamentaux autres que la protection des données).

En pratique, la bonne séquence pour un système à haut risque qui traite des données personnelles consiste à mener d’abord l’AIPD, puis à l’étendre. Si vous partez de zéro, les guides AIPD pour l’IA : quand et comment la réaliser et l’AIPD en 7 étapes avec modèle donnent la méthode sur le volet données, sur laquelle la FRIA vient se greffer.

Quand et comment notifier l’autorité de surveillance du marché

L’article 27(2) précise que l’obligation s’applique au premier usage du système. Le déployeur peut, pour des cas d’usage similaires, s’appuyer sur une FRIA déjà réalisée ou sur les analyses existantes du fournisseur. Mais dès qu’un élément listé au paragraphe 1 évolue ou n’est plus à jour, il doit actualiser l’analyse : la FRIA est un document vivant, pas un livrable qu’on archive.

Une fois l’analyse réalisée, l’article 27(3) impose une étape que l’AIPD ne connaît pas : notifier les résultats à l’autorité de surveillance du marché, en transmettant un modèle de questionnaire rempli. L’article 27(5) prévoit que le Bureau européen de l’IA (AI Office) élabore ce modèle, y compris sous forme d’outil automatisé, pour simplifier la démarche. Les déployeurs bénéficiant de la dérogation de l’article 46(1) peuvent être exemptés de cette notification.

Concrètement, tant que le modèle officiel n’est pas publié, il est prudent de structurer dès à présent votre FRIA selon les six rubriques de l’article 27(1), de manière à pouvoir alimenter le questionnaire sans reprendre l’analyse.

Calendrier : l’article 27 et l’incertitude du « digital omnibus »

L’article 27 entre en application le 2 août 2026, en même temps que l’essentiel des obligations relatives aux systèmes à haut risque de l’annexe III (article 113 du règlement).

Un point d’actualité doit toutefois être signalé, car il évolue vite. Un accord politique provisoire sur le paquet dit « digital omnibus » a été trouvé le 7 mai 2026 : il prévoit de reporter au 2 décembre 2027 l’application des obligations relatives aux systèmes à haut risque autonomes de l’annexe III — ce qui inclurait la FRIA. À la date de rédaction (juillet 2026), ce report n’a pas encore été formellement adopté ni publié au Journal officiel de l’Union européenne. Tant que ce n’est pas le cas, la date juridiquement contraignante reste le 2 août 2026.

Ma recommandation est de ne pas jouer sur ce délai. Le report éventuel n’efface pas l’obligation ; il déplace une échéance. Les organisations concernées — administrations, opérateurs de services publics, banques et assureurs — ont tout intérêt à cartographier dès maintenant leurs systèmes à haut risque et à préparer leurs FRIA. Pour suivre l’ensemble des échéances, voir le calendrier d’application de l’AI Act.

Ce que risque un déployeur qui ignore l’article 27

La FRIA fait partie des obligations du chapitre III du règlement. Son non-respect relève du régime de sanctions de l’article 99(4) : une amende administrative pouvant atteindre 15 millions d’euros ou 3 % du chiffre d’affaires annuel mondial de l’exercice précédent, le montant le plus élevé étant retenu.

Au-delà du montant, l’enjeu est probatoire. Une FRIA correctement documentée est, pour un déployeur public ou un établissement financier, le principal élément qui démontre la maîtrise du système en cas de contrôle ou de réclamation d’une personne. Son absence, à l’inverse, fragilise toute la défense. Le détail des paliers d’amende est présenté dans notre guide Amendes AI Act : le régime de sanctions (Art. 99).

Pour les acteurs du crédit et de l’assurance, spécifiquement visés par les points 5 b) et 5 c) de l’annexe III, l’analyse sectorielle IA en banque et assurance : conformité AI Act complète utilement cet article.

Structurer une FRIA, croiser l’annexe III avec votre parc de systèmes, articuler l’analyse avec l’AIPD existante et tenir le tout à jour est un travail méthodique et récurrent. C’est précisément ce type de cartographie et de documentation continue que Legiscope aide à industrialiser, plutôt que de le traiter comme un projet ponctuel.

Ce qu’il faut retenir

• La FRIA (article 27 AI Act) est une obligation autonome du déployeur, distincte de l’AIPD RGPD : elle évalue l’impact d’un système d’IA à haut risque sur l’ensemble des droits fondamentaux.
• Elle ne concerne que trois catégories : organismes de droit public, entités privées fournissant des services publics, et déployeurs de systèmes de scoring de crédit ou de tarification en assurance vie et santé (annexe III, points 5 b) et 5 c)).
• Le contenu est limitativement fixé : processus, fréquence, publics affectés, risques de préjudice, surveillance humaine, mesures et voies de recours.
• La FRIA complète l’AIPD lorsque celle-ci existe (art. 27(4)) et doit être notifiée à l’autorité de surveillance du marché (art. 27(3)).
• Entrée en application prévue le 2 août 2026 ; un report au 2 décembre 2027 est en discussion (« digital omnibus ») mais non encore adopté. Sanction : jusqu’à 15 M€ ou 3 % du CA mondial.

FAQ

La FRIA remplace-t-elle l’AIPD RGPD ?

Non. Ce sont deux analyses distinctes avec des objets différents : l’AIPD porte sur le traitement de données personnelles, la FRIA sur l’impact du système d’IA sur l’ensemble des droits fondamentaux. L’article 27(4) prévoit que la FRIA complète l’AIPD lorsque celle-ci a déjà couvert certains éléments, ce qui évite de refaire deux fois le même travail.

Une PME privée doit-elle réaliser une FRIA ?

En principe non, sauf si elle relève de l’une des trois catégories de l’article 27(1) : entité fournissant un service public, ou déployeur d’un système de scoring de crédit ou de tarification en assurance vie et santé. Une PME privée qui déploie un autre système à haut risque (tri de CV, par exemple) reste soumise aux obligations du déployeur de l’article 26, mais pas à la FRIA.

À quelle autorité faut-il transmettre la FRIA ?

Le déployeur doit notifier les résultats de son analyse à l’autorité de surveillance du marché compétente, en utilisant le modèle de questionnaire élaboré par le Bureau européen de l’IA (art. 27(3) et 27(5)). Une exemption de notification est prévue pour les déployeurs relevant de la dérogation de l’article 46(1).

Faut-il refaire une FRIA à chaque utilisation du système ?

Non. L’obligation vise le premier usage. Pour des cas d’usage similaires, le déployeur peut réutiliser une FRIA existante ou les analyses du fournisseur. Il doit en revanche l’actualiser dès qu’un des éléments de l’analyse évolue ou n’est plus à jour (art. 27(2)).

L’obligation de FRIA est-elle bien applicable au 2 août 2026 ?

À la date de rédaction, oui : c’est la date d’entrée en application fixée par l’article 113. Un report au 2 décembre 2027 est prévu par l’accord provisoire du « digital omnibus » du 7 mai 2026, mais il n’est pas encore formellement adopté ni publié au Journal officiel. Tant que ce n’est pas le cas, le 2 août 2026 demeure juridiquement contraignant.