Une FRIA est une analyse d’impact sur les droits fondamentaux appliquée à certains systèmes d’IA à haut risque. L’article 27 de l’AI Act demande au déployeur concerné de décrire le processus réel, la durée et la fréquence d’usage, les personnes susceptibles d’être touchées, les risques de préjudice, la surveillance humaine et les mesures prévues si le risque se matérialise. Ce n’est donc ni une fiche produit fournie par l’éditeur, ni un inventaire abstrait de principes européens.
Au 9 août 2026, le calendrier mérite une attention particulière. Le règlement européen 2026/1744, dit Digital Omnibus sur l’IA, a repoussé au 2 décembre 2027 l’application des sections relatives aux systèmes à haut risque classés par l’article 6, paragraphe 2, et l’annexe III. Une organisation peut préparer son dossier maintenant, mais elle ne doit pas présenter cette échéance comme si elle était restée fixée au 2 août 2026.
Réponse en bref
Pour préparer une FRIA exploitable :
- décrivez le système, son fournisseur, sa version et surtout la décision ou l’action à laquelle il contribue ;
- vérifiez s’il relève bien de l’article 6, paragraphe 2, et d’une catégorie de l’annexe III ;
- identifiez le déployeur et contrôlez s’il appartient aux catégories visées par l’article 27 ;
- notez la date d’application correspondant à cette qualification dans la version consolidée du règlement ;
- constituez les six pièces demandées par l’article 27, paragraphe 1 ;
- reliez chaque risque à un droit, une personne concernée, un scénario et une mesure contrôlable ;
- réutilisez les éléments pertinents d’une analyse d’impact RGPD sans confondre les deux exercices ;
- faites relire les scénarios par les équipes métier, juridique, sécurité, données et réclamation ;
- consignez une décision de déployer, modifier, limiter, différer ou abandonner ;
- programmez une révision lorsque le processus, les personnes touchées, la fréquence, le fournisseur ou les contrôles changent.
La prochaine action utile n’est pas de remplir un questionnaire générique. Prenez un seul usage candidat, écrivez en une phrase la décision influencée et vérifiez sa catégorie réglementaire avec la version consolidée du texte.
Le calendrier exact après le Digital Omnibus
Le règlement initial prévoyait une application générale à partir du 2 août 2026, avec plusieurs exceptions. Cette date continue d’exister dans le texte consolidé, mais elle ne suffit plus pour dater toutes les obligations.
Le règlement 2026/1744, publié le 24 juillet 2026 et en vigueur, a modifié l’article 113. Pour les systèmes classés à haut risque au titre de l’article 6, paragraphe 2, et de l’annexe III, les sections 1, 2 et 3 du chapitre III s’appliquent désormais à partir du 2 décembre 2027, sous réserve des exceptions indiquées par le texte. Les systèmes à haut risque liés à des produits de l’annexe I suivent une autre échéance, fixée au 2 août 2028 pour les dispositions visées.
L’article 27 se trouve dans la section 3 et vise les systèmes de l’annexe III. Sa préparation doit donc être pilotée avec l’échéance du 2 décembre 2027 en tête, pas avec une ancienne frise copiée avant l’amendement.
Ce report ne justifie pas l’inaction. Une FRIA sérieuse dépend d’informations rarement disponibles la veille d’un lancement : parcours métier réel, catégories de personnes touchées, consignes du fournisseur, modalités de recours, incidents de test et pouvoir concret de la personne chargée de la surveillance. Le délai supplémentaire sert à réunir ces preuves et à modifier le projet si l’analyse révèle un problème.
Qui doit conduire une FRIA au titre de l’article 27
L’obligation ne concerne pas toute entreprise qui utilise ChatGPT, un moteur de recherche interne ou un outil de résumé. Trois filtres doivent être franchis.
Le premier porte sur le système. L’article 27 vise un système à haut risque relevant de l’article 6, paragraphe 2, donc d’une catégorie de l’annexe III. Celle-ci comprend notamment certains usages en biométrie, éducation, emploi, services essentiels, forces de l’ordre, migration et justice. La simple présence d’un modèle d’IA dans un logiciel ne suffit pas : la finalité prévue et le rôle du système dans le cas d’usage comptent.
Le deuxième filtre porte sur le déployeur. L’article vise les organismes de droit public, les entités privées fournissant des services publics et, quelle que soit cette qualité, les déployeurs des systèmes mentionnés aux points 5 b et 5 c de l’annexe III. Ces deux points concernent l’évaluation de la solvabilité ou l’établissement d’un score de crédit, hors détection de fraude, ainsi que l’évaluation du risque et la tarification en assurance vie et santé.
Le troisième filtre tient aux exclusions et au contexte. L’article 27 écarte les systèmes à haut risque destinés au domaine du point 2 de l’annexe III, qui concerne certaines infrastructures critiques. D’autres règles peuvent néanmoins s’appliquer. Une conclusion « pas de FRIA article 27 » ne signifie donc ni « pas de risque », ni « pas d’analyse d’impact », ni « pas d’obligation sectorielle ».
Qualifier le système avant d’ouvrir un modèle de document
La qualification commence par le processus, pas par le nom commercial de l’outil. « Assistant IA RH » ne dit pas s’il rédige une annonce, classe des candidatures, recommande une promotion ou répond à une question interne. Or ces usages n’ont ni la même finalité, ni le même effet, ni nécessairement le même statut.
Créez un registre de qualification avec les champs suivants :
| Champ | Question à trancher | Preuve attendue |
|---|---|---|
| système | quelle version et quelle configuration seront utilisées ? | contrat, fiche technique, journal de version |
| finalité prévue | quelle tâche le fournisseur autorise-t-il ? | instructions d’utilisation |
| usage local | dans quel processus l’organisation l’insère-t-elle ? | schéma du parcours réel |
| effet | quelle décision, priorité ou action peut changer ? | règle métier et exemple de dossier |
| personnes | qui subit, bénéficie ou conteste cet effet ? | catégories définies sans données inutiles |
| catégorie | quel point précis de l’annexe III est envisagé ? | référence juridique motivée |
| rôle | qui est fournisseur, intégrateur et déployeur ? | responsabilités contractuelles et opérationnelles |
| échéance | à quelle date la disposition identifiée s’applique-t-elle ? | version consolidée datée |
| décision | FRIA requise, autre analyse, doute à lever ou hors champ ? | validation nommée et datée |
Cette fiche empêche deux raccourcis. Le premier consiste à considérer tout système génératif comme haut risque. Le second consiste à conclure qu’un outil généraliste ne peut jamais le devenir dans un processus sensible. La qualification porte sur le système et sa finalité dans le cadre juridique applicable, pas sur l’impression produite par son interface.
Les six pièces du dossier FRIA
L’article 27, paragraphe 1, fournit une structure minimale très concrète. Chaque exigence peut devenir une pièce autonome, reliée aux autres par un identifiant de cas d’usage.
1. Le processus et la finalité prévue
Décrivez le parcours avant et après l’introduction du système. N’écrivez pas seulement « l’IA aide l’agent ». Indiquez les entrées, le résultat produit, la personne qui le reçoit, la décision possible, les systèmes connectés et le moment où une intervention humaine reste possible.
Ajoutez un cas normal, un cas ambigu et un cas qui doit être refusé. Ce trio révèle si l’usage reste aligné sur la finalité prévue par le fournisseur. Si le système est réutilisé pour une décision que ses instructions n’encadrent pas, la FRIA ne peut pas réparer à elle seule ce décalage.
2. La durée et la fréquence d’utilisation
L’impact d’un test de deux semaines sur un petit échantillon n’est pas celui d’un traitement quotidien appliqué à toutes les demandes. Documentez la période prévue, le volume estimé, les pics, les horaires, les phases pilote et production ainsi que les conditions d’arrêt.
La fréquence aide aussi à dimensionner la surveillance. Un contrôle manuel de chaque sortie peut être réaliste pour dix dossiers et purement décoratif pour dix mille. La description doit montrer le contrôle qui fonctionnera à la charge attendue.
3. Les personnes et groupes susceptibles d’être affectés
Ne réduisez pas cette pièce aux utilisateurs internes. Une personne peut ne jamais voir l’interface et subir pourtant un délai, un classement, un refus, une surveillance ou une orientation produits par le processus.
Cartographiez au moins quatre positions : la personne directement évaluée, les groupes qui peuvent subir un effet disproportionné, les salariés qui utilisent ou supervisent le système et les tiers qui reçoivent la décision. Évitez de collecter des données sensibles uniquement pour remplir le document. L’objectif est d’identifier les effets plausibles et les besoins de recours, pas de constituer une nouvelle base intrusive.
4. Les risques de préjudice pour les droits fondamentaux
Une liste de droits sans scénario n’est pas actionnable. Utilisez une chaîne courte : situation, comportement du système, effet sur la personne, droit concerné, gravité, possibilité de correction.
Exemple fictif : une candidature rédigée dans un format atypique est mal extraite, le score descend sous un seuil, le dossier n’est pas relu et la personne perd l’accès à l’étape suivante. Le risque peut alors être discuté sous l’angle de la non-discrimination, de l’accès au travail, de l’explication et du recours. L’équipe peut tester l’extraction, supprimer le rejet automatique, créer une revue ciblée et observer les écarts par scénario autorisé.
La probabilité ne doit pas effacer la gravité. Un événement rare mais difficilement réversible peut justifier une interdiction d’action automatique. À l’inverse, une erreur fréquente mais détectable avant tout effet peut être traitée par un contrôle robuste et mesuré.
5. La surveillance humaine réellement mise en œuvre
L’article 27 demande de décrire l’application des mesures de surveillance humaine selon les instructions d’utilisation. Nommez la personne ou la fonction, son accès aux informations, son temps disponible, son pouvoir d’interrompre et la manière dont son action est enregistrée.
Un bouton « valider » ne prouve rien si l’opérateur ne peut pas voir les données décisives, comprendre les limites du système ou contredire sa recommandation. Testez la surveillance avec des cas où la bonne décision consiste à refuser la sortie, demander une information supplémentaire ou revenir au processus sans IA.
6. Les mesures en cas de matérialisation du risque
Le dossier doit enfin prévoir ce qui se passe lorsque le risque devient réel. L’article mentionne notamment la gouvernance interne et les mécanismes de réclamation. Définissez un canal accessible, un délai de prise en charge, une personne responsable, la conservation des éléments nécessaires, une voie de correction et les critères de suspension du système.
Reliez les mesures à des seuils observables. Par exemple : suspendre la décision automatisée si un contrôle critique échoue, revenir à une procédure manuelle si les journaux sont incomplets, réexaminer les dossiers potentiellement touchés et informer les fonctions compétentes. Une promesse générale de « correction rapide » n’est pas une mesure opératoire.
FRIA et analyse d’impact RGPD ne sont pas synonymes
Une analyse d’impact relative à la protection des données, souvent appelée AIPD ou DPIA, évalue un traitement susceptible d’engendrer un risque élevé pour les droits et libertés des personnes. Une FRIA article 27 examine l’effet du cas d’usage d’un système d’IA à haut risque sur les droits fondamentaux selon les éléments précis du règlement IA.
Les deux dossiers peuvent partager des informations : description du traitement, catégories de personnes, flux de données, risques, mesures, propriétaires et mécanismes de recours. La version consolidée de l’article 27 permet désormais d’intégrer des renvois vers les sections pertinentes de l’AIPD ou d’en reprendre des parties. Elle ne dit pas qu’une AIPD existante remplace automatiquement la FRIA.
Utilisez une table de correspondance plutôt qu’un copier-coller :
| Élément | AIPD RGPD | FRIA AI Act | Action |
|---|---|---|---|
| finalité | finalité du traitement | processus et finalité prévue du système | aligner les deux descriptions |
| personnes | personnes concernées | personnes et groupes affectés par l’usage | ajouter les effets indirects |
| risques | droits et libertés liés au traitement | droits fondamentaux dans le contexte d’usage | compléter les scénarios manquants |
| mesures | sécurité et réduction des risques | surveillance, gouvernance et réclamation | relier chaque mesure à un test |
| cycle de vie | changement du traitement | premier usage puis changement d’un élément | partager les déclencheurs de revue |
Organiser un atelier de contradiction
Une FRIA rédigée uniquement par l’équipe projet risque de reprendre les hypothèses qui ont justifié l’achat. Organisez un atelier court où chaque rôle cherche un type d’angle mort.
Le métier explique le processus réel et ses exceptions. La fonction juridique vérifie le périmètre et les droits concernés. La protection des données distingue les informations nécessaires des collectes excessives. La sécurité examine les accès, dépendances et possibilités de détournement. Le support ou le service réclamation décrit ce qu’une personne peut comprendre et contester. Un représentant des utilisateurs teste le temps et les informations disponibles pour la surveillance.
L’atelier ne doit pas produire un vote moyen. Une objection portant sur un effet grave, non détectable ou non réversible doit rester visible jusqu’à sa résolution. Consignez la décision, la preuve attendue, le responsable et la date de contrôle.
Transformer l’analyse en décision de déploiement
La sortie de la FRIA n’est pas forcément « conforme » ou « non conforme ». Elle peut conduire à cinq décisions utiles :
- déployer si les conditions et preuves sont réunies ;
- limiter à un périmètre, une fréquence ou un type de dossier ;
- modifier le processus, les permissions ou la surveillance ;
- différer tant qu’une instruction, un test ou un mécanisme de recours manque ;
- abandonner si le risque reste incompatible avec le service attendu.
Pour chaque décision, enregistrez les conditions qui la rendent valable. Si le fournisseur, la version, le seuil de décision, la population, le volume ou l’intégration change, la décision initiale ne doit pas être réutilisée mécaniquement.
Les déclencheurs de mise à jour
L’article 27 prévoit une mise à jour lorsque les éléments de l’analyse ont changé ou ne sont plus à jour. Transformez cette règle en déclencheurs concrets :
- nouvelle finalité ou nouvelle étape du processus ;
- modification substantielle de la configuration ou du modèle ;
- ajout d’un outil, d’une source de données ou d’une permission d’écriture ;
- extension à une autre population ou à un volume différent ;
- changement de fréquence ou passage du mode assisté au mode automatique ;
- nouvel incident, nouvelle réclamation ou écart révélé par les tests ;
- modification des instructions du fournisseur ;
- évolution du texte applicable, d’une mesure nationale ou du calendrier.
Le registre de versions doit montrer ce qui a changé, quels scénarios ont été rejoués et qui a renouvelé la décision. Modifier seulement la date du document ne constitue pas une révision.
Plan de préparation jusqu’au 2 décembre 2027
Une organisation qui pense entrer dans le périmètre peut utiliser le temps restant sans figer trop tôt un formulaire encore évolutif.
Pendant le premier mois, inventoriez les usages susceptibles d’influencer une décision concernant une personne et qualifiez leur catégorie. Ensuite, récupérez les instructions, versions, responsabilités et preuves auprès des fournisseurs. Sur le trimestre suivant, testez les cas normaux, ambigus et défavorables, puis construisez les mécanismes de surveillance et de réclamation. Enfin, faites relire les dossiers, contrôlez les changements du cadre européen et préparez la notification à l’autorité de surveillance du marché prévue par l’article 27 lorsque l’obligation devient applicable.
Le texte prévoit que l’AI Office développe un modèle de questionnaire, y compris sous forme d’outil automatisé. En attendant une version officielle applicable et à jour, un dossier interne peut suivre les six pièces du règlement. Il devra être rapproché du modèle officiel au moment opportun, sans supposer que le gabarit interne suffira à la notification.
Limites
Ce guide propose une méthode de préparation fondée sur la version consolidée de l’AI Act consultée le 9 août 2026. Il ne constitue pas un avis juridique et ne qualifie aucun système particulier. Les catégories de haut risque, les exceptions, les mesures nationales, les autorités compétentes et les documents de mise en œuvre doivent être vérifiés pour le cas réel.
Le calendrier a déjà été modifié en juillet 2026. Il peut encore évoluer, tout comme le modèle de questionnaire annoncé par l’AI Office. Une organisation doit conserver la référence exacte du texte utilisé et vérifier la version en vigueur avant toute notification ou mise en service.
Articles liés
- Article 50 de l’AI Act : rendre un chatbot et ses contenus transparents
- Maîtrise de l’IA et AI Act : construire un plan de formation prouvable
- Fine-tuning et AI Act : quand devient-on fournisseur d’un modèle GPAI ?
- Charte IA en entreprise : un modèle d’usage en 12 règles
Pour cadrer un usage, ses responsabilités et ses preuves avant un projet, la page conseil IA présente l’accompagnement proposé.
Sources vérifiées
- AI Act, version consolidée au 27 juillet 2026 , consultée le 9 août 2026
- Règlement (UE) 2026/1744, Digital Omnibus sur l’IA , consultée le 9 août 2026
- AI Act, cadre réglementaire européen , consultée le 9 août 2026
- Règlement général sur la protection des données , consultée le 9 août 2026