FRIA : l'analyse d'impact sur les droits fondamentaux

De quoi il s'agit

FRIA est l'acronyme de Fundamental Rights Impact Assessment, l'analyse d'impact sur les droits fondamentaux prévue par le règlement (UE) 2024/1689. L'exercice consiste à décrire, avant la mise en service d'un système d'IA à haut risque, l'usage qui en sera fait, les personnes susceptibles d'en subir les effets, les risques d'atteinte à leurs droits, et les mesures prévues pour y répondre.

La logique est proche de celle de l'analyse d'impact relative à la protection des données que connaissent déjà les entreprises ayant traité des sujets RGPD sensibles. La différence tient au périmètre : on n'examine pas seulement la protection des données, mais l'ensemble des droits susceptibles d'être affectés, à commencer par la non-discrimination et l'accès à l'emploi.

Qui doit en réaliser une

C'est le point le plus souvent mal compris, y compris dans des documents commerciaux qui circulent sur le sujet. L'obligation de conduire une FRIA ne pèse pas sur tous les utilisateurs de systèmes à haut risque. Le règlement la réserve à certaines catégories de déployeurs, notamment les organismes de droit public, les entités privées chargées d'un service public, et les déployeurs de certains systèmes limitativement énumérés, en particulier dans le domaine de l'évaluation de la solvabilité et de la tarification en assurance vie et santé.

Concrètement, une PME du secteur privé qui utilise un outil de présélection de candidatures n'est, dans la plupart des cas, pas légalement tenue de produire une FRIA. Elle reste en revanche tenue d'autres obligations en tant qu'utilisateur : supervision humaine, utilisation conforme à la notice, conservation des journaux, information des salariés et de leurs représentants avant la mise en service.

Ce périmètre exact mérite d'être vérifié système par système, car il dépend de la qualification retenue et de la nature de l'activité. C'est précisément le rôle de la classification établie lors de la cartographie.

Pourquoi la mener malgré tout

Trois raisons, indépendantes de l'obligation légale.

Elle produit la preuve qui manque en cas de litige. Devant un conseil de prud'hommes saisi d'une contestation portant sur un processus de recrutement ou une évaluation, un document daté, antérieur au déploiement, décrivant les risques identifiés et les mesures prises, change la nature du débat.

Elle force les bonnes questions au bon moment. Beaucoup de projets se déploient sans que personne n'ait écrit qui décide en dernier ressort, ni ce qui se passe si le système se trompe. L'analyse oblige à trancher avant, pas après l'incident.

Elle constitue un argument commercial. Les donneurs d'ordre, notamment publics ou de grande taille, commencent à interroger leurs fournisseurs sur leur gouvernance de l'IA. Disposer du document place l'entreprise du bon côté de la question.

Ce que contient l'analyse

• La description du processus dans lequel le système s'insère : à quel moment il intervient, ce qu'il produit, ce qui en découle.
• La période et la fréquence d'utilisation, un outil utilisé chaque semaine n'exposant pas au même risque qu'un outil utilisé deux fois par an.
• Les catégories de personnes concernées, en n'oubliant pas celles qui ne sont pas dans l'entreprise, à commencer par les candidats.
• Les risques identifiés, formulés en termes d'atteinte concrète : une candidature écartée sur un critère indirectement discriminatoire, une évaluation faussée par une donnée d'historique.
• Les mesures de supervision humaine : qui contrôle, avec quelles compétences, à quel moment, et avec quel pouvoir réel de contredire.
• Les mesures à prendre en cas de matérialisation du risque : qui alerter, comment suspendre l'usage, comment corriger une décision déjà prise.

La méthode en quatre temps

Cadrer. Un système, un usage, un périmètre. Une analyse qui prétend couvrir « l'IA dans l'entreprise » ne conclut jamais.

Documenter l'existant. Notice du fournisseur, paramétrage retenu, données utilisées, personnes qui opèrent l'outil. Cette étape révèle souvent que le système est utilisé autrement que ce que la notice prévoit.

Identifier et hiérarchiser. Tous les risques ne se valent pas. Croisez gravité de l'atteinte et probabilité, et traitez ce qui figure en haut de la liste.

Décider et dater. Chaque mesure retenue reçoit un responsable et une échéance. Le document est signé et daté : c'est ce qui lui donne sa valeur probante.

À quel moment la conduire

Avant la mise en service, par construction. Le réflexe utile est de la déclencher au moment de la décision d'achat plutôt qu'au moment du déploiement : c'est encore le moment où l'on peut poser des exigences au fournisseur et, le cas échéant, choisir une autre solution.

Elle se met ensuite à jour à chaque changement significatif : nouvelle version, nouvel usage, extension à un autre service. C'est la logique de revue périodique que nous recommandons pour l'ensemble du dispositif de gouvernance.