Logiciel RH et AI Act : votre outil est-il un système d'IA à haut risque ?

Un éditeur de logiciel RH qui ajoute un score, une recommandation ou un classement à son produit doit trancher une question avant toute autre : son outil est-il un système d'IA à haut risque au sens du règlement (UE) 2024/1689 ? La réponse fixe le budget de conformité, le calendrier produit et le prix de l'erreur, jusqu'à 15 millions d'euros ou 3 % du chiffre d'affaires mondial pour un fournisseur défaillant. La plupart des fonctionnalités d'un SIRH ne sont pas concernées, mais celles qui le sont ne se repèrent pas à l'intuition. Voici le test en trois étapes que j'applique, puis sept fonctionnalités courantes passées au crible.

Pourquoi la qualification est la première décision produit

Le règlement sur l'IA ne s'applique pas à « l'IA » en général. Il distribue des obligations selon le niveau de risque d'un usage précis. Pour un logiciel RH, trois issues sont possibles : la fonctionnalité sort du champ, elle relève du haut risque, ou elle tombe dans une pratique interdite. Entre la première et la deuxième, l'écart se compte en mois de travail : système de gestion des risques, gouvernance des données, documentation technique, journalisation, contrôle humain, évaluation de la conformité, marquage CE.

Le calendrier réel après l'omnibus

Le règlement (UE) 2026/1744 du 8 juillet 2026, dit omnibus numérique sur l'IA, publié au Journal officiel de l'Union le 24 juillet 2026 et entré en vigueur le 27 juillet 2026, a réécrit l'article 113. Les obligations des systèmes à haut risque de l'annexe III, celle qui couvre l'emploi, s'appliquent à compter du 2 décembre 2027, au lieu du 2 août 2026. Ce report est fixé en date calendaire ferme. Le détail des changements figure dans notre analyse de ce que l'omnibus numérique change dans l'AI Act.

Le report ne vaut pas pour tout. L'interdiction de la reconnaissance des émotions au travail s'applique depuis le 2 février 2025. L'obligation d'informer l'utilisateur qu'il échange avec une IA, prévue à l'article 50, s'applique depuis le 2 août 2026.

Un effet de seuil à anticiper

L'article 111, paragraphe 2, modifié par l'omnibus, prévoit que le règlement ne s'applique aux systèmes à haut risque mis sur le marché avant la date d'application du chapitre III que s'ils subissent ensuite d'importantes modifications de leur conception. Un éditeur a donc intérêt à savoir, dès aujourd'hui, quelles fonctionnalités il livrera avant le 2 décembre 2027 et lesquelles viendront après. La portée exacte de cette clause, notamment pour un SaaS mis à jour en continu, reste à préciser par la Commission : je ne bâtirais pas une feuille de route sur elle seule.

Étape 1 : votre logiciel RH est-il un système d'IA ?

L'article 3, point 1, définit le système d'IA comme un système automatisé qui, pour des objectifs explicites ou implicites, déduit, à partir des entrées qu'il reçoit, la manière de générer des sorties telles que des prédictions, du contenu, des recommandations ou des décisions. Le critère décisif est l'inférence. Un logiciel qui exécute des règles écrites par vos développeurs ne déduit rien : il applique.

Les lignes directrices de la Commission sur la définition du système d'IA, formellement adoptées le 29 juillet 2025 (C(2025) 5053), excluent plusieurs familles de logiciels :

• les systèmes fondés sur des règles définies uniquement par des personnes physiques pour exécuter automatiquement des opérations ;
• le traitement de données de base : tri, filtre, requête en base, tableur sans fonction d'IA ;
• l'analyse purement descriptive, comme un tableau de bord qui affiche l'absentéisme par service sans rien recommander ;
• l'amélioration de méthodes d'optimisation mathématique éprouvées et les heuristiques classiques ;
• les systèmes de prédiction simples, dont la performance est celle d'une règle statistique de base, par exemple une moyenne historique.

Ces lignes directrices ne lient pas le juge, mais elles fixent la grille de lecture des autorités de surveillance. En pratique, la frontière passe entre le code qui applique des règles explicites et le modèle entraîné sur des données qui produit une sortie que personne n'a écrite à l'avance. Un modèle d'apprentissage automatique, un réseau de neurones ou un grand modèle de langage branché sur votre produit franchit cette frontière.

Point de vigilance. La qualification se fait fonctionnalité par fonctionnalité, pas produit par produit. Un SIRH peut contenir un moteur de paie hors champ, un chatbot à risque limité et un module de détection des départs à haut risque. Votre documentation doit refléter cette granularité.

Étape 2 : l'annexe III emploi, bien au-delà du recrutement

L'article 6, paragraphe 2, renvoie à l'annexe III. Son point 4, intitulé « Emploi, gestion de la main-d'œuvre et accès à l'emploi indépendant », comporte deux branches.

Le point 4 a) vise les systèmes d'IA destinés au recrutement ou à la sélection, « en particulier pour publier des offres d'emploi ciblées, analyser et filtrer les candidatures et évaluer les candidats ». Le ciblage des offres y figure expressément : un moteur qui décide à quels profils montrer une annonce est concerné, pas seulement le tri de CV. Notre article sur les obligations de l'employeur qui utilise une IA de recrutement traite l'autre face du sujet, celle du client.

Le point 4 b) est plus large et c'est lui que les éditeurs de SIRH sous-estiment. Il vise les systèmes destinés à :

• prendre des décisions influant sur les conditions des relations professionnelles, la promotion ou le licenciement ;
• attribuer des tâches sur la base du comportement individuel, de traits de personnalité ou de caractéristiques personnelles ;
• suivre et évaluer les performances et le comportement des personnes dans le cadre de ces relations.

La destination, c'est vous qui l'écrivez

Le texte parle de systèmes « destinés à » un usage. L'article 3, point 12, définit la destination comme l'utilisation prévue par le fournisseur, telle qu'elle ressort de la notice d'utilisation, de la documentation technique, mais aussi des indications publicitaires ou de vente. Une plaquette qui promet de « repérer vos meilleurs talents » ou d'« objectiver vos décisions de promotion » qualifie votre produit autant que votre code.

Étape 3 : la dérogation de l'article 6.3 et ses pièges

Un système visé à l'annexe III n'est pas considéré comme à haut risque lorsqu'il ne présente pas de risque important de préjudice pour la santé, la sécurité ou les droits fondamentaux, y compris parce qu'il n'a pas d'incidence significative sur le résultat de la décision. L'article 6, paragraphe 3, énumère quatre conditions, dont une seule suffit sur le plan du texte :

1. le système accomplit une tâche procédurale étroite ;
2. il améliore le résultat d'une activité humaine préalablement réalisée ;
3. il détecte des constantes ou des écarts dans des décisions déjà prises, sans se substituer à l'évaluation humaine ni l'influencer sans examen humain approprié ;
4. il exécute une tâche préparatoire à une évaluation.

Le considérant 53 donne des exemples parlants pour un éditeur : transformer des données non structurées en données structurées, classer des documents entrants, détecter des doublons parmi un grand nombre de candidatures, reformuler un texte dans un ton professionnel, indexer ou traduire des documents.

Le profilage ferme toujours la porte

Le dernier alinéa de l'article 6, paragraphe 3, est sans appel : un système de l'annexe III qui effectue un profilage de personnes physiques est toujours à haut risque. Le règlement renvoie à la définition de l'article 4, point 4, du RGPD, qui cite expressément l'analyse ou la prédiction d'éléments concernant « le rendement au travail », la fiabilité ou le comportement d'une personne. Dans un logiciel RH, la plupart des fonctionnalités qui évaluent un individu sont donc, par construction, du profilage. La dérogation ne bénéficie en pratique qu'aux fonctions qui traitent des documents ou des flux, pas des personnes.

Une dérogation qui se documente et se déclare

L'article 6, paragraphe 4, impose au fournisseur qui écarte le haut risque de documenter son évaluation avant la mise sur le marché, de la produire à la demande des autorités et de s'enregistrer dans la base de données de l'Union au titre de l'article 49, paragraphe 2. L'omnibus a allégé le contenu de cet enregistrement : les points 7 et 9 de la section B de l'annexe VIII, qui exigeaient un résumé des motifs et la liste des États membres de commercialisation, sont supprimés. L'obligation de documenter l'évaluation, elle, reste entière.

Une dernière précaution : l'article 6, paragraphe 5, imposait à la Commission de publier des lignes directrices sur la classification au plus tard le 2 février 2026. Un projet a été publié le 19 mai 2026 et soumis à consultation jusqu'au 23 juillet 2026, avec une adoption annoncée pour la fin de 2026. Tant que la version définitive n'est pas parue, toute qualification reste provisoire et doit être relue à sa publication.

Ce qui est interdit, à part : la reconnaissance des émotions

L'article 5, paragraphe 1, point f), interdit depuis le 2 février 2025 la mise sur le marché, la mise en service à cette fin et l'utilisation de systèmes d'IA pour inférer les émotions d'une personne sur le lieu de travail, sauf raisons médicales ou de sécurité. Ce n'est plus une question de haut risque mais d'interdiction, sanctionnée jusqu'à 35 millions d'euros ou 7 % du chiffre d'affaires annuel mondial par l'article 99, paragraphe 3.

La définition du système de reconnaissance des émotions, à l'article 3, point 39, suppose des données biométriques. Les lignes directrices de la Commission sur les pratiques interdites (C(2025) 5052, adoptées le 29 juillet 2025) en tirent des conséquences très concrètes :

• l'interdiction couvre les candidats pendant le processus de recrutement et les salariés en période d'essai ;
• une analyse de sentiment portant sur du texte écrit n'est pas fondée sur des données biométriques et sort de l'interdiction ;
• en revanche, inférer des émotions à partir de la façon de taper au clavier, des expressions du visage, de la posture ou de la voix y entre ;
• analyser la voix des clients d'un centre d'appels reste permis, analyser celle des téléconseillers ne l'est pas ;
• un usage de pur entraînement personnel est toléré si les résultats ne sont jamais partagés avec les RH et ne pèsent sur aucune évaluation.

Pour un éditeur, la règle opérationnelle est simple : aucune fonctionnalité de votre roadmap ne doit déduire l'humeur, le stress ou l'engagement d'un salarié ou d'un candidat à partir de sa voix, de son visage ou de sa frappe. Le détecter en revue de code coûte moins cher que de le retirer du marché.

Sept cas pratiques de logiciel RH qualifiés

Les qualifications ci-dessous valent pour la configuration décrite. Une variante de destination ou de modèle peut inverser le résultat.

1. Le moteur de calcul de paie

Il applique des règles légales et conventionnelles codées par vos équipes : taux, plafonds, primes d'ancienneté. Aucune inférence, donc hors de la définition du système d'IA. La qualification change si vous ajoutez un module entraîné sur l'historique pour signaler les bulletins « anormaux » : ce module devient un système d'IA, qui reste toutefois hors annexe III tant qu'il contrôle des calculs et n'évalue pas des personnes.

2. La planification optimisée des équipes

Un solveur qui répartit les plannings sous contraintes (repos, compétences déclarées, disponibilités) relève de l'optimisation mathématique éprouvée : probablement hors définition. Si le moteur apprend des comportements individuels, par exemple l'absentéisme passé d'un salarié, pour lui attribuer moins de créneaux, il « attribue des tâches sur la base du comportement individuel » : haut risque au titre du point 4 b), et profilage.

3. La détection du risque d'attrition

Un modèle qui prédit la probabilité de départ de chaque salarié est un système d'IA qui analyse le comportement : c'est du profilage. Dès que la prédiction sert à orienter une augmentation, une promotion ou une mobilité, elle influe sur les conditions de la relation de travail. Haut risque, sans dérogation possible. Un indicateur agrégé par service, sans score individuel, peut en sortir.

4. La recommandation de formations

Suggérer à un salarié des modules adaptés à son poste, à sa seule attention, n'entre pas dans le point 4 b) : hors haut risque, sous réserve de documenter cette analyse. Si le manager voit les recommandations et s'en sert pour évaluer ou promouvoir, la fonctionnalité bascule vers le suivi des performances : haut risque probable.

5. L'analyse des entretiens

Trois variantes, trois qualifications. L'analyse de la voix ou du visage d'un candidat en visioconférence pour en déduire son assurance ou son stress : interdit. La notation de la transcription au regard d'une grille de compétences : haut risque au titre du point 4 a), et profilage. La simple transcription et la synthèse neutre des échanges, remises au recruteur qui évalue lui-même : tâche préparatoire, dérogation envisageable si aucune note ni aucun classement n'est produit.

6. Le chatbot RH

Un assistant fondé sur un grand modèle de langage qui répond aux questions sur les congés ou la mutuelle est un système d'IA, mais il ne relève pas de l'annexe III. Il est soumis à l'obligation de transparence de l'article 50, paragraphe 1 : l'utilisateur doit savoir qu'il échange avec une IA. Le piège classique : étendre le même assistant à la présélection de candidats ou au tri des demandes de mobilité, ce qui le fait entrer dans le haut risque. L'encadrement de ces usages côté client relève de la charte IA interne.

7. Le matching de mobilité interne

Un moteur qui propose à la DRH les salariés les plus adaptés à un poste ouvert sélectionne des candidats et influe sur des promotions : haut risque, profilage. La variante qui pousse vers chaque salarié des offres internes correspondant à son profil n'y échappe pas, puisque le point 4 a) vise expressément la publication d'offres d'emploi ciblées.

Documenter sa qualification : le dossier à constituer

Que la conclusion soit « hors champ » ou « haut risque », je recommande de la consigner dans un dossier daté, signé par un responsable identifié et versionné avec le produit. Il contient au minimum :

1. la description de chaque fonctionnalité et de sa destination, alignée mot pour mot avec la notice et les supports commerciaux ;
2. l'analyse au regard de l'article 3, point 1 : nature du modèle, données d'entraînement, sorties produites ;
3. la confrontation à l'annexe III, point 4, branche par branche ;
4. si la dérogation est invoquée, la condition de l'article 6, paragraphe 3, retenue, l'analyse du profilage et l'incidence sur la décision ;
5. la vérification de l'absence de toute inférence d'émotions fondée sur des données biométriques ;
6. la liste des événements qui imposent une nouvelle analyse.

Ce dossier sert trois publics : l'autorité de surveillance, qui peut le demander ; vos clients, dont les questionnaires d'achat posent désormais la question ; et vos investisseurs, pour qui une qualification non documentée est un passif.

Conseil d'avocat. Joignez au dossier une fiche destinée à vos clients sur leurs propres obligations en droit français, qui s'appliquent quelle que soit la qualification au titre du règlement. L'article L. 1221-8 du code du travail impose d'informer expressément le candidat des méthodes d'aide au recrutement utilisées à son égard, et exige qu'elles soient pertinentes au regard de la finalité poursuivie. L'article L. 2312-38 prévoit l'information du CSE sur ces méthodes et sur les traitements automatisés de gestion du personnel, et son information-consultation sur les outils de contrôle de l'activité. L'article 47 de la loi du 6 janvier 1978 interdit, sauf exceptions, toute décision produisant des effets juridiques fondée exclusivement sur un traitement automatisé. Un éditeur qui facilite ces démarches vend plus vite.

Quand requalifier après une évolution du produit

La qualification n'est pas un acte unique. Quatre événements imposent de la reprendre.

Un changement de modèle ou de sortie

Remplacer un moteur de règles par un modèle entraîné, ou ajouter un score là où l'outil se contentait de trier, fait passer une fonctionnalité de l'étape 1 à l'étape 2. C'est aussi le type d'évolution qui peut constituer une importante modification de conception au sens de l'article 111, paragraphe 2, et soumettre au règlement un système livré avant le 2 décembre 2027.

Une nouvelle promesse commerciale

Puisque la destination se lit aussi dans les supports de vente, toute nouvelle page produit, démonstration ou réponse à appel d'offres qui étend l'usage annoncé doit passer par la personne qui tient le dossier de qualification.

Une configuration client qui détourne l'outil

L'article 25, paragraphe 1, prévoit qu'un déployeur qui apporte une modification substantielle à un système à haut risque, ou qui modifie la destination d'un système non classé à haut risque de telle sorte qu'il le devienne, est considéré comme fournisseur. Votre client qui transforme votre outil de gestion des compétences en outil de sélection pour un plan de départs change de statut. L'omnibus a précisé l'article 25, paragraphe 2 : le fournisseur initial doit coopérer avec le nouveau fournisseur, sauf s'il a clairement indiqué que son système ne doit pas être transformé en système à haut risque. Cette mention, inscrite dans vos conditions d'utilisation et votre notice, est une protection à poser dès maintenant.

La publication des lignes directrices définitives

Les lignes directrices sur la classification attendues pour la fin de 2026 contiendront des exemples d'usages à haut risque et d'usages qui ne le sont pas. Relisez chaque qualification à leur parution, en priorité celles qui reposent sur la dérogation de l'article 6, paragraphe 3.

Ce qu'il faut retenir

Dans un logiciel RH, trois questions suffisent à trier l'essentiel. Le module infère-t-il, ou applique-t-il des règles écrites par vos équipes ? Sert-il à recruter, à cibler une offre, à attribuer des tâches, à évaluer ou à décider d'une promotion ou d'une rupture ? Évalue-t-il une personne, ce qui constitue un profilage et exclut toute dérogation ? Ajoutez une ligne rouge absolue, l'inférence d'émotions à partir de données biométriques, et vous avez la carte de votre exposition. Le panorama général du règlement est détaillé dans notre guide sur les obligations de l'AI Act pour les entreprises.

Le 2 décembre 2027 paraît loin. Il ne l'est pas pour un éditeur qui doit construire la journalisation, l'interface de contrôle humain et la documentation technique d'un module à haut risque, puis passer l'évaluation de conformité. J'accompagne les éditeurs dans cette qualification, fonctionnalité par fonctionnalité, et dans la rédaction du dossier qui la justifie : voir notre offre d'avocat en droit de l'intelligence artificielle. Si vous hésitez sur un module précis, échangeons sur la qualification de votre logiciel RH.