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 — avec une échéance désormais fixée au 2 décembre 2027 par le règlement (UE) 2026/1744.

Article publié le 23 juillet 2026 et mis à jour le 14 septembre 2026 : le report de l’article 27, encore à l’état d’accord provisoire lors de la rédaction, a été adopté et publié.

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. 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 : c’est lui qui prouve que l’analyse a été traduite en organisation.

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). Le règlement (UE) 2026/1744 a précisé cette articulation à l’article 27(4) et (5) : la FRIA peut renvoyer aux sections pertinentes de l’AIPD ou en incorporer des parties, et le modèle de questionnaire du Bureau de l’IA doit permettre ces renvois (voir notre analyse de l’omnibus IA).

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.

Critère	AIPD (art. 35 RGPD)	FRIA (art. 27 AI Act)
Objet	Traitement de données personnelles	Système d’IA à haut risque
Périmètre des droits	Droits et libertés liés aux données	Ensemble des droits fondamentaux
Débiteur	Responsable de traitement	Déployeur (3 catégories)
Déclenchement	Traitement à risque élevé	Premier usage du système
Autorité destinataire	CNIL (consultation si risque résiduel)	Autorité de surveillance du marché

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 s’applique le 2 décembre 2027

L’article 27 devait initialement s’appliquer le 2 août 2026. Le règlement (UE) 2026/1744, dit « omnibus IA », adopté le 8 juillet 2026, publié au Journal officiel le 24 juillet et entré en vigueur le 27 juillet 2026, a réécrit l’article 113 : les sections 1 à 3 du chapitre III — dont l’article 27 — s’appliquent aux systèmes à haut risque de l’annexe III à compter du 2 décembre 2027. La FRIA ne visant que les systèmes de l’article 6(2), c’est la seule date qui la concerne ; le report au 2 août 2028 des systèmes intégrés à des produits réglementés (annexe I) ne la touche pas.

Trois précisions utiles. D’abord, cette date est fixe : le mécanisme de la proposition initiale, qui subordonnait l’application à la disponibilité des normes harmonisées, a été abandonné en trilogue. Ensuite, l’omnibus n’a pas modifié le périmètre des déployeurs visés ni le contenu des six éléments de l’article 27(1) : le report change l’échéance, pas l’exigence. Enfin, un système à haut risque mis en service avant le 2 décembre 2027 n’est soumis au chapitre III qu’en cas de modification importante de sa conception après cette date (art. 111(2)) — mais cette règle protège le système, pas le déployeur qui le met en service pour la première fois après l’échéance, et les déployeurs publics restent tenus par la date butoir du 2 août 2030.

Ma recommandation est de ne pas jouer sur ce délai. Quinze mois correspondent au temps nécessaire pour cartographier les systèmes concernés, mener ou étendre l’AIPD, et bâtir un dispositif de réclamation qui fonctionne. Les organisations concernées — administrations, opérateurs de services publics, banques et assureurs — ont intérêt à préparer leurs FRIA dès maintenant, d’autant que l’ACPR, désignée par le projet de loi DDADUE comme autorité de surveillance du secteur financier, a annoncé exercer ses nouvelles missions à partir du 2 décembre 2027. Pour suivre l’ensemble des échéances, voir le calendrier d’application de l’AI Act et notre analyse de l’omnibus IA.

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.

Pour suivre l’échéance du 2 décembre 2027, le modèle de questionnaire du Bureau de l’IA et la loi DDADUE, inscrivez-vous à la newsletter : une analyse par semaine, écrite par un docteur en droit.

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 le 2 décembre 2027 (règlement (UE) 2026/1744), au lieu du 2 août 2026 ; le périmètre et le contenu de l’obligation sont inchangés. Sanction : jusqu’à 15 M€ ou 3 % du CA mondial (art. 99(4)).

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)).

À partir de quand l’obligation de FRIA est-elle applicable ?

À compter du 2 décembre 2027. Le règlement (UE) 2026/1744, entré en vigueur le 27 juillet 2026, a reporté à cette date l’application des sections 1 à 3 du chapitre III de l’AI Act aux systèmes à haut risque de l’annexe III, dont relève la FRIA. La date initiale du 2 août 2026 n’est plus applicable ; le report ne modifie ni les déployeurs visés ni le contenu de l’analyse.

---

Sources : Règlement (UE) 2024/1689 (AI Act), texte consolidé (EUR-Lex) — Règlement (UE) 2026/1744 du 8 juillet 2026 (EUR-Lex) — Commission européenne, Bureau de l’IA, calendrier de mise en œuvre de l’AI Act — ACPR, « Règlement européen sur l’IA (AI Act) »

Thiébaut Devergranne est docteur en droit (Paris II), titulaire du CAPA, et travaille depuis plus de vingt ans sur le droit des technologies, dont six ans au sein des services du Premier ministre (SGDN/DCSSI). Il est le fondateur de donneespersonnelles.fr et de Legiscope.