Conformité · July 18, 2026 · 9 min de lecture

Règlement européen sur l'IA et recrutement : ce que « haut risque » implique

Le Règlement européen sur l'IA (EU AI Act) classe l'IA de recrutement comme système à haut risque, avec des obligations de documentation, supervision humaine, journalisation et transparence.

← Fait partie de IA de recrutement conforme : LL144 et le règlement européen sur l'IA

Si vous évaluez des candidats résidant dans l'Union européenne, le Règlement européen sur l'IA (EU AI Act) classe votre logiciel de recrutement dans son niveau à haut risque — la même catégorie réglementaire que les dispositifs médicaux et la notation de crédit — et ces obligations concernent tout employeur qui recrute des candidats dans l'UE, quel que soit son pays d'établissement. Ce point est important car la classification à haut risque ne s'obtient pas par argumentation : elle est déterminée par ce que fait le système, et elle entraîne des obligations de documentation, de supervision humaine, de journalisation et de transparence qu'un simple document de politique ne saurait satisfaire. Ce guide est destiné au responsable recrutement ou au directeur des talents qui doit rendre une plateforme d'évaluation des compétences native IA défendable avant le 2 décembre 2027, et il constitue un examen approfondi issu de notre guide plus large sur l'IA de recrutement axée sur la conformité.

Pourquoi le recrutement est à haut risque par définition

Le règlement adopte une approche par niveaux de risque. La plupart des logiciels relèvent d'une catégorie à risque minimal assortie de peu d'obligations ; un ensemble restreint de pratiques est purement et simplement interdit ; et entre les deux se situe le niveau à haut risque, où s'effectue l'essentiel du travail de conformité. L'emploi se trouve clairement dans cette catégorie intermédiaire. L'Annex III, domaine 4 — « emploi, gestion des travailleurs et accès au travail indépendant » — nomme explicitement l'IA utilisée pour recruter, présélectionner, filtrer et évaluer les candidats, ainsi que pour prendre ou étayer des décisions relatives à la promotion, au licenciement et à la répartition des tâches.

La conséquence est sans ambiguïté : si votre outil influence qui est embauché, il est à haut risque par classification, non par argumentation. Il n'existe aucun seuil de précision permettant à un fournisseur de s'y soustraire, et aucun cadrage du type « nous assistons seulement le recruteur » qui ferait passer l'outil dans un niveau plus léger. Un score de modèle sur lequel un recruteur s'appuie avec confiance est exactement le scénario pour lequel l'Annex a été rédigé. C'est pourquoi la posture la plus sûre traite la conformité comme une décision d'architecture prise en amont, dans le même esprit que la réduction des biais dans le recrutement — quelque chose que l'on intègre dès la conception, et non que l'on greffe après coup.

Les obligations fondamentales, en termes simples

Les exigences applicables aux systèmes à haut risque ressemblent à une liste de vérification de systèmes plutôt qu'à une abstraction juridique. Elles couvrent l'ensemble du cycle de vie du système, et chacune peut être mise en regard d'un élément concret dans un processus d'évaluation opérationnel.

• Gestion des risques tout au long du cycle de vie du système — un processus continu, non une validation ponctuelle
• Gouvernance des données — données d'entraînement, de validation et de test gérées pour leur pertinence, leur représentativité et la gestion des erreurs
• Documentation technique et tenue automatique de registres (journalisation) permettant à des tiers de reconstituer ce qui s'est passé
• Supervision humaine effective — une personne capable de comprendre, de surveiller et de passer outre les résultats
• Transparence et information à destination des déployeurs, afin que les personnes utilisant l'outil en connaissent les limites
• Exactitude, robustesse et cybersécurité appropriées à la finalité prévue

Considérées ensemble, ces obligations valorisent une conception dans laquelle les preuves sont générées comme sous-produit de l'utilisation normale. Si la seule façon de prouver la supervision humaine est une politique signée dont personne ne peut démontrer qu'elle a été respectée, la documentation devient une course contre la montre. En revanche, si chaque évaluation des candidats générée par IA laisse une trace consultable et si chaque décision du réviseur est journalisée, la majeure partie de la documentation se constitue d'elle-même.

La supervision humaine comme fonctionnalité, non comme politique

L'Article 14 est inhabituellement précis sur ce que signifie la supervision. Les personnes responsables doivent être en mesure de comprendre les capacités et les limites du système, de le surveiller pour détecter des anomalies ou des dysfonctionnements, d'interpréter correctement ses résultats et — point crucial — de rester vigilantes face au biais d'automatisation, cette tendance humaine à trop faire confiance à une machine affichant une grande assurance. Elles doivent conserver le pouvoir d'écarter le résultat, de le passer outre, ou de décider de ne pas utiliser le système du tout dans un cas donné.

Ce niveau d'exigence est difficile à satisfaire avec un document de politique, et facile à satisfaire avec le bon flux de travail. Une file de revue où un recruteur approuve, modifie ou rejette chaque résultat — chaque action étant horodatée et attribuée — est l'Article 14 rendu concret. Une supervision que vous pouvez prouver vaut infiniment mieux qu'une supervision que vous affirmez simplement. La distinction compte surtout lorsqu'un candidat rejeté demande comment la décision a été prise, ou lorsqu'un régulateur pose la même question deux ans plus tard.

Le biais d'automatisation est le mode d'échec à prévenir par la conception

Le règlement mentionne explicitement le biais d'automatisation car c'est la façon prévisible dont la supervision humaine s'effondre en pratique. Un réviseur confronté à une centaine de candidats et à un score affiché avec assurance va progressivement se contenter de valider mécaniquement. Les contre-mesures sont structurelles : présenter le raisonnement sous-jacent à un résultat plutôt qu'un simple chiffre, demander au réviseur d'enregistrer un jugement plutôt que de cliquer sur « accepter », et calibrer la charge de travail pour que la supervision reste réaliste. Cette même rigueur sous-tend une évaluation structurée et défendable en général — c'est la cohérence du processus qui rend une décision révisable.

La transparence envers les personnes évaluées

La classification à haut risque impose également des obligations de transparence envers les candidats, et pas seulement envers les auditeurs. Les personnes qui interagissent avec un système d'IA dans un contexte à haut risque doivent être informées que cela se produit, de manière qu'elles puissent réellement comprendre, et les déployeurs doivent fournir à la personne concernée les informations dont elle a besoin pour saisir comment le système s'inscrit dans une décision la concernant. Pour le recrutement, cela signifie indiquer clairement aux candidats que l'IA est utilisée dans l'évaluation, ce qu'elle évalue, et qu'un humain examine le résultat avant qu'il soit pris en compte.

La transparence est peu coûteuse à intégrer dès la conception et onéreuse à ajouter après coup. Un avis court et honnête au moment où un candidat commence une évaluation satisfait l'esprit de l'exigence et, selon notre expérience, améliore les taux de complétion plutôt que de les nuire — les gens sont plus disposés à être évalués par une machine lorsqu'on leur dit qu'une personne se tient derrière la décision. Des informations vagues ou enfouies produisent l'effet inverse et invitent précisément le type de plainte que la règle vise à prévenir. La même franchise soutient une expérience candidat solide — transparence et confiance vont dans le même sens.

Fournisseur versus déployeur : qui doit quoi

Le règlement répartit les obligations entre deux rôles. Un fournisseur développe le système d'IA, ou le fait développer, et le met sur le marché sous son propre nom. Un déployeur utilise ce système sous sa propre autorité — dans le cas d'un outil de recrutement, il s'agit généralement de l'employeur. Si vous achetez une plateforme d'évaluation et l'utilisez auprès de vos candidats, vous êtes un déployeur ; le vendeur est le fournisseur.

Les fournisseurs supportent la charge de conception la plus lourde : gestion des risques, gouvernance des données, documentation technique, journalisation, évaluation de la conformité et surveillance après commercialisation. Les déployeurs ont un ensemble d'obligations moins lourd mais bien réel — utiliser le système conformément aux instructions du fournisseur, assurer la supervision humaine en pratique, conserver les journaux générés par le système, et informer les personnes concernées lorsque requis. La position confortable pour un déployeur est de choisir un fournisseur dont le produit génère déjà les enregistrements nécessaires aux deux rôles, de sorte que vos obligations soient satisfaites en utilisant l'outil comme prévu, plutôt qu'en greffant une couche de conformité par-dessus.

Il existe une raison pratique de se soucier de son rôle au-delà de la simple répartition des responsabilités. Vos obligations probatoires diffèrent, et il en va de même pour ce que vous pouvez externaliser. Un déployeur ne peut pas déléguer la supervision humaine — elle est exercée par vos collaborateurs, auprès de vos candidats, quelles que soient les fonctionnalités du produit du fournisseur. Mais un déployeur peut — et doit — exiger que le fournisseur fournisse la documentation, la journalisation et les instructions qui rendent la supervision et la tenue de registres réalisables. Si un fournisseur ne peut pas vous montrer comment son outil génère les enregistrements dont vous aurez besoin, c'est un signal sur la part de la charge de conformité qu'il vous laisse discrètement sur les bras.

Le compte à rebours : 2 décembre 2027

Les obligations à haut risque pour les systèmes de l'Annex III deviennent désormais applicables le 2 décembre 2027. Le règlement « omnibus numérique » les a reportées de la date initiale du 2 août 2026, un report inconditionnel qui accorde aux employeurs environ seize mois supplémentaires. La date d'août 2026, elle, n'a pas disparu — c'est à ce moment qu'entrent en vigueur les obligations de transparence de l'Article 50, couvrant la divulgation de l'implication de l'IA et l'étiquetage des contenus générés par IA, et que le Bureau de l'IA de l'UE commence à faire respecter les obligations relatives à l'IA à usage général. Les règles interdisant un ensemble restreint de pratiques s'appliquaient déjà depuis février 2025. Les sanctions pour les infractions les plus graves atteignent plusieurs dizaines de millions d'euros ou une part du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu — des chiffres délibérément calibrés pour être significatifs pour un employeur mondial, et non de simples amendes absorbables.

Traitez le report comme une marge de manœuvre, pas comme un sursis. Seize mois suffisent pour construire correctement la documentation, les tests de biais et la supervision humaine — plutôt qu'en urgence — mais seulement si vous commencez maintenant : décembre 2027 est une date butoir ferme, et les obligations de transparence arrivent en août 2026 quoi qu'il arrive. La posture sûre est la même pour les fournisseurs et les déployeurs, et c'est la même posture vers laquelle les règles de contrôle des biais de New York City et les lois d'État américaines émergentes telles que le Colorado AI Act poussent déjà : un humain véritablement dans la boucle, et des journaux qui le prouvent. Construire dès maintenant pour la génération de preuves et la tenue de registres, et le fil conducteur de toutes les juridictions — maintenir un humain responsable, maintenir une trace — signifie que la même architecture répond à la majorité des questions en une seule fois.

À quoi ressemble concrètement une documentation défendable

Le mot « documentation » accomplit un travail considérable et discret dans le règlement, et il vaut la peine d'être concret sur ce qu'il exige. Pour un système de recrutement à haut risque, la documentation technique doit permettre à un tiers compétent de comprendre ce que fait le système, les données sur lesquelles il a été construit, ses performances et ses limites connues. La journalisation capture ensuite ce qui s'est réellement passé lors de l'utilisation : quel candidat a été évalué, quand, ce que le système a produit, et ce que le réviseur humain en a fait.

Pour un déployeur, le test honnête est simple : si un candidat se plaignait auprès d'un régulateur dans dix-huit mois, pourriez-vous reconstituer son évaluation de bout en bout à partir de registres qui existent déjà ? Si la réponse nécessite des suppositions, une reconstruction de mémoire, ou de demander au fournisseur de rechercher quelque chose, la documentation ne remplit pas encore son rôle. Les systèmes qui réussissent ce test sont ceux où le registre est un sous-produit de l'exécution de l'évaluation, et non un rapport que quelqu'un doit penser à rédiger. C'est la même raison pour laquelle un processus de recrutement native IA rigoureux maintient par défaut une trace consultable pour chaque résultat.

Comment le Règlement européen sur l'IA s'articule avec le RGPD

Le Règlement sur l'IA ne remplace pas le droit de la protection des données ; il s'y superpose. Pour une équipe de recrutement en Europe, le RGPD régit toujours la façon dont vous collectez, stockez et supprimez les données des candidats, et le Règlement sur l'IA ajoute des obligations sur la manière dont le système d'IA lui-même est construit, documenté et supervisé. Les deux se recoupent le plus visiblement autour de la supervision humaine : l'Article 22 du RGPD restreint déjà les décisions fondées uniquement sur un traitement automatisé, et l'Article 14 du Règlement sur l'IA précise ce qu'est un contrôle humain réel. Respecter correctement l'un vous place pour l'essentiel en conformité avec l'autre.

La conclusion pratique est que vous ne devriez pas mener deux projets de conformité séparés. Les données des candidats que vous minimisez au titre du RGPD sont les mêmes que celles couvertes par les obligations de gouvernance des données de votre système d'IA. Le consentement et les avis que vous fournissez au titre du RGPD constituent le cadre naturel de votre information sur la transparence de l'IA. Traiter les deux comme un seul programme, plutôt que deux, fait la différence entre un processus cohérent et un empilement de paperasse redondante. Notre guide sur le RGPD pour le recrutement décrit la partie protection des données de ce même tableau.

Ce qu'il faut faire avant l'échéance

Commencez par cartographier les points où l'IA intervient dans votre processus de recrutement — sourcing, présélection, évaluation, classement — et identifiez chaque point comme fourni par un prestataire ou développé en interne, car votre rôle détermine vos obligations. Confirmez ensuite trois choses pour chaque point de contact à haut risque : qu'une personne nommément désignée peut passer outre le résultat, que chaque décision est journalisée sous une forme que vous pourriez remettre à un auditeur, et que les candidats sont informés de l'implication d'un système d'IA là où le règlement l'exige. Si l'un des trois éléments est manquant, c'est là que se situe le travail de remédiation.

Enfin, veillez à ce que les registres soient lisibles par un humain. L'objectif de la documentation n'est pas de satisfaire une obligation de dépôt ; c'est de permettre à un réviseur, un auditeur ou un candidat rejeté de reconstituer comment une décision a été prise. Une approche axée sur la conformité traite cette reconstituabilité comme le produit, et l'attestation de conformité comme un effet secondaire. Découvrez comment la supervision et la journalisation fonctionnent en pratique dans une démo en direct.