(2/3) La facture de l'AI Act atterrit sur l'employeur, pas sur le fournisseur
Il y a une hypothèse confortable ancrée dans la façon dont la plupart des entreprises pensent l'EU AI Act : c'est un problème pour ceux qui construisent l'IA. Les fournisseurs ont entraîné les modèles, les fournisseurs feront les évaluations de conformité, les fournisseurs porteront le poids de la conformité. Nous, on a juste acheté une licence.
Pour l'IA à haut risque utilisée dans le recrutement et les RH, cette hypothèse est fausse d'une manière qui crée une exposition réelle. La loi répartit la responsabilité entre deux rôles — le fournisseur (provider) qui développe et met le système sur le marché, et le déployeur (deployer) qui l'utilise sous sa propre autorité. Oui, les fournisseurs portent le fardeau le plus lourd au moment de la conception. Mais la loi place délibérément un ensemble distinct et non délégable d'obligations sur le déployeur. Et si vous êtes une entreprise qui fait tourner un outil d'IA de filtrage sur vos candidats, vous êtes le déployeur. La conformité du fournisseur n'absorbe pas la vôtre.
C'est la Partie 2 d'une série en trois parties. La Partie 1 a cartographié pourquoi la quasi-totalité de l'IA RH est classée à haut risque et ce qui est purement interdit. Ici, je détaille ce que la loi exige réellement de l'employeur qui déploie ces systèmes — et pourquoi l'essentiel ne peut pas être externalisé vers une clause d'achat.
Les obligations du déployeur, en termes simples
Les devoirs essentiels figurent dans l'Article 26 (« Obligations des déployeurs de systèmes d'IA à haut risque »). Retirez le jargon juridique et ils se résument à une poignée d'engagements qui sont opérationnels, pas théoriques :
- Utiliser le système comme prévu (Art. 26(1)). Vous devez l'opérer conformément aux instructions du fournisseur. Détournez un outil de filtrage de candidats vers quelque chose pour lequel il n'a pas été conçu ou documenté, et vous êtes potentiellement passé de déployeur à fournisseur — héritant au passage de l'ensemble complet des obligations du fournisseur.
- Attribuer une véritable supervision humaine (Art. 26(2)). La supervision doit être confiée à des personnes physiques ayant la compétence, la formation et l'autorité pour l'exercer. Pas un nom sur un organigramme. Une personne qui comprend le système et peut réellement agir sur ce qu'elle observe.
- Conserver les journaux (Art. 26(6)). Les déployeurs doivent conserver les journaux générés automatiquement par le système pendant une durée appropriée — au moins six mois sauf disposition légale contraire. Si vous ne pouvez pas reconstituer ce que le système a fait et pourquoi, vous ne pouvez pas démontrer votre conformité.
- Informer les personnes qui y sont soumises (Art. 26(11)). Les individus soumis à des décisions prises ou assistées par un système à haut risque doivent en être informés.
- Prévenir d'abord les effectifs (Art. 26(7)). Celle-ci mérite sa propre section.
L'obligation sur laquelle les entreprises vont trébucher : prévenir les travailleurs
L'Article 26(7) est court et facile à manquer, et c'est là que je m'attends à ce que le plus d'entreprises se fassent prendre. Avant de mettre en service un système d'IA à haut risque sur le lieu de travail, les déployeurs qui sont des employeurs doivent informer les représentants des travailleurs et les travailleurs concernés qu'ils y seront soumis.
Ce n'est pas une courtoisie. C'est une condition préalable au déploiement légal, et cela se branche directement sur le tissu existant du droit du travail européen — qui dispose déjà de solides droits d'information et de consultation pour les comités d'entreprise et les représentants du personnel. Dans plusieurs États membres, déployer un système qui surveille ou évalue le personnel sans passer par cette consultation n'est pas seulement une question d'AI Act ; c'est une question de droit collectif du travail.
La Belgique est l'exemple le plus net de cette superposition. Bien avant que l'AI Act n'existe, la Convention collective de travail n° 39 (1983) obligeait déjà les employeurs à informer et consulter lors de l'introduction d'une nouvelle technologie affectant significativement l'emploi ou les conditions de travail. L'AI Act ne la remplace pas — il s'empile par-dessus. Ainsi, une entreprise qui déploie un outil d'IA RH en Belgique répond désormais à deux régimes à la fois, et des superpositions nationales similaires existent à travers le bloc.
L'enseignement stratégique : vous ne pouvez pas allumer discrètement un système d'évaluation par IA. La transparence envers les effectifs fait partie du déploiement, et « on le leur dira s'ils demandent » n'est pas ce que dit la loi.
Une supervision humaine qui compte vraiment
« Human in the loop » est devenue l'une des expressions les plus galvaudées de l'IA. La loi tente de lui donner du mordant, à travers deux articles qui travaillent ensemble.
L'Article 14 oblige les fournisseurs à concevoir les systèmes à haut risque de manière à ce qu'ils puissent être efficacement supervisés par un humain — avec les interfaces, les informations et les commandes d'arrêt qui rendent la supervision possible. L'Article 26(2) oblige ensuite le déployeur à réellement doter cette supervision de quelqu'un de compétent et habilité.
La barre que fixe la loi, c'est une supervision significative : la personne doit être capable de comprendre la sortie du système, de l'interpréter correctement, de décider de ne pas l'utiliser, et de la contourner ou de l'annuler. Un humain qui valide d'office une liste classée de candidats parce que l'outil l'a produite, ce n'est pas de la supervision — c'est de l'automatisation avec un témoin. La supervision signifie que le jugement de l'humain peut, et parfois doit, changer le résultat.
C'est précisément le point où la loi et la bonne ingénierie convergent. Une supervision que vous pouvez démontrer est une supervision que vous avez conçue : un point de décision où un humain examine, une trace de ce qu'il a décidé, et un vrai chemin pour être en désaccord avec la machine.
Les deux analyses d'impact
Les systèmes RH à haut risque entraînent deux obligations d'analyse distinctes, et les gens les confondent régulièrement.
- L'analyse d'impact sur les droits fondamentaux (Art. 27). Certains déployeurs de systèmes à haut risque doivent évaluer l'impact sur les droits fondamentaux avant le déploiement — qui est affecté, ce qui pourrait mal tourner, quelles mesures d'atténuation et de supervision humaine sont en place. Pour les systèmes qui décident qui est embauché ou promu, ce n'est pas un exercice hypothétique.
- L'analyse d'impact relative à la protection des données (GDPR Art. 35). L'IA de recrutement traite des données personnelles — souvent en grande quantité, parfois sensibles. L'Article 26(9) de l'AI Act dit explicitement aux déployeurs d'utiliser les informations fournies par le fournisseur au titre de l'Article 13 pour réaliser leur DPIA au titre du GDPR. Les deux régimes sont conçus pour s'imbriquer.
Si cela ressemble à deux documents qui se recoupent, c'est en partie le cas — et le bon réflexe est de les mener comme une seule analyse coordonnée plutôt que comme deux exercices de paperasse déconnectés.
La couche GDPR que vous deviez déjà
L'AI Act n'est pas arrivé dans le vide. Le GDPR régit le traitement automatisé des données personnelles depuis 2018, et l'une de ses dispositions a toujours visé directement l'IA de recrutement : l'Article 22, le droit de ne pas faire l'objet d'une décision fondée exclusivement sur un traitement automatisé lorsqu'elle produit des effets juridiques ou des effets similairement significatifs.
Une décision de rejet entièrement automatisée — aucun humain impliqué — est le cas d'école que l'Article 22 a été écrit pour encadrer. Les candidats ont des droits à l'information, à l'intervention humaine et à contester la décision. Les exigences de supervision humaine de l'AI Act et l'Article 22 du GDPR sont désormais deux raisons qui se renforcent mutuellement de garder un humain compétent dans la décision plutôt qu'autour d'elle.
Le Digital Omnibus proposé que j'ai mentionné en Partie 1 est en partie une tentative de clarifier comment ces deux régimes s'articulent. Tant que ce n'est pas tranché, présumez la lecture la plus stricte : une personne, pas seulement un pipeline, est propriétaire du résultat.
Ce que tout cela donne au total
Mettez les obligations bout à bout et une forme claire émerge. Pour déployer légalement de l'IA dans le recrutement au sein de l'UE, une entreprise doit :
- Confirmer l'outil et le cas d'usage, et l'opérer tel que documenté.
- Mettre un humain compétent et habilité aux commandes de la supervision — et rendre cette supervision réelle.
- Informer les travailleurs et leurs représentants avant le déploiement.
- Mener une analyse des droits fondamentaux et un DPIA coordonné.
- Conserver les journaux et être capable d'expliquer toute décision que le système a touchée.
- Respecter les droits GDPR des candidats à l'information, à l'intervention humaine et à la contestation.
Aucune de ces obligations n'est satisfaite par un badge de conformité du fournisseur. Chacune d'elles est quelque chose que l'employeur déployeur doit assumer, doter en personnel et documenter.
C'est un fardeau — mais c'est aussi un plan directeur. Les entreprises qui traitent cette liste comme un cahier des charges de conception plutôt que comme un désagrément juridique se retrouvent avec des processus de recrutement qui ne sont pas seulement conformes, mais réellement meilleurs : plus transparents pour les candidats, plus responsables en interne, et plus défendables quand un candidat rejeté demande pourquoi.
Dans la Partie 3, je deviens précis sur ce à quoi cela ressemble en pratique — en utilisant le seul processus que je connaisse intimement : comment nous avons construit la présélection des candidats à distance chez Conectia pour que l'IA fasse ce dans quoi elle est bonne, que les humains restent responsables de la décision, et que l'ensemble était déjà façonné comme la loi avant que la loi ne l'exige.


