Quand votre ATS devient la brèche : sécuriser les données personnelles des candidats

Une fuite de données sur une plateforme de recrutement figure désormais parmi les cibles les plus prisées de votre stack, car un système de suivi des candidatures (ATS) concentre la plus forte densité de données personnelles réglementées que votre entreprise manipule : noms officiels, adresses, prétentions salariales, CV, et de plus en plus de pièces d’identité officielles, d’entretiens vidéo enregistrés et de données biométriques dérivées par l’IA. Quand ce système est compromis, les attaquants ne récupèrent pas une liste de prospects marketing. Ils récupèrent un kit clé en main de vol d’identité et de deepfake. La solution n’est pas de « choisir un fournisseur qui promet la sécurité ». C’est le privacy-by-design : collecter moins, chiffrer ce que vous conservez, supprimer selon un calendrier, et traiter l’ATS comme un système que votre plan de réponse aux incidents couvre vraiment.

Si vous êtes responsable de la stack de recrutement et que votre RSSI ou votre conseil d’administration a commencé à demander « est-ce que ce qui est arrivé à Mercor pourrait nous arriver ? », cet article est pour vous. Voici ce qui s’est réellement passé, pourquoi les plateformes de recrutement sont soudain dans le viseur, l’exposition juridique qui en découle, et une checklist concrète de contrôles que vous pouvez exiger de n’importe quel fournisseur.

Ce qui est arrivé à Mercor (et pourquoi ça devrait inquiéter toute équipe de recrutement)

Fin mars 2026, la plateforme de recrutement pour l’industrie de l’IA Mercor a été compromise et environ 4 To de données ont été exfiltrés, dont des numéros de sécurité sociale (SSN) de candidats, des scans de passeports et de permis de conduire, des données biométriques faciales et des entretiens vidéo en HD. Mercor, qui servirait à sourcer des prestataires chargés d’entraîner les modèles des grands labos d’IA, n’a pas été attaquée de front. Elle a été frappée par une dépendance.

L’attaque s’est invitée via la compromission de la chaîne d’approvisionnement de LiteLLM. Un acteur malveillant suivi sous le nom de TeamPCP a compromis les identifiants de publication PyPI de LiteLLM et a poussé deux versions vérolées du paquet, v1.82.7 et v1.82.8. Selon le billet de sécurité de LiteLLM lui-même, les paquets malveillants sont restés en ligne sur PyPI pendant environ 40 minutes le 24 mars 2026 avant d’être mis en quarantaine. Quarante minutes ont suffi. La charge utile a moissonné les variables d’environnement, les clés SSH, les identifiants cloud, les jetons Kubernetes et les mots de passe de bases de données. Le groupe d’extorsion Lapsus$ a ensuite référencé Mercor sur son site de fuites aux alentours du 31 mars et a mis les données aux enchères ; Mercor a divulgué l’impact début avril, se décrivant comme « l’une des milliers d’entreprises » touchées.

Les données revendiquées par Lapsus$ se décomposent en environ 939 Go de code source, une base de données candidats de 211 Go, et près de 3 To de fichiers stockés (Repello AI ; SecurityWeek). La base de données candidats contenait, semble-t-il, des CV, des coordonnées vérifiées et des SSN. Les fichiers stockés constituaient la partie réellement alarmante : des vidéos HD de candidats, des scans de pièces d’identité et les données biométriques faciales utilisées pour faire correspondre les visages aux pièces d’identité.

La leçon n’est pas « LiteLLM était mauvais ». LiteLLM est largement utilisé ; Wiz l’a trouvé présent dans 36 % des environnements cloud analysés (Wiz). La leçon, c’est que le rayon d’impact de vos données candidats englobe les fournisseurs de vos fournisseurs, et que le tas de données le plus sensible que vous possédez se trouve peut-être dans un système auquel personne dans votre équipe de sécurité ne pense.

Pourquoi les plateformes de recrutement sont désormais des cibles de choix

Les plateformes de recrutement sont des cibles à haute valeur parce que l’entonnoir d’embauche collecte plus de données sensibles que presque tout autre système de back-office, tout en étant rarement intégré au programme de sécurité d’une entreprise. Pensez à ce qui transite par un ATS pour un seul recrutement : nom officiel, adresse personnelle, téléphone, e-mail, parcours professionnel complet, prétentions salariales, CV, références, et pour beaucoup de stacks modernes un entretien vidéo enregistré, une pièce d’identité officielle pour les vérifications du droit au travail, et des transcriptions ou des scores générés par l’IA. C’est un profil plus riche que ce que contiennent la plupart des CRM, des systèmes de facturation ou des wikis internes.

Deux bascules structurelles ont aggravé la situation ces dernières années.

Les outils de recrutement dopés à l’IA collectent par défaut des données proches du biométrique. Les entretiens vidéo, l’analyse vocale et la mise en correspondance visage/pièce d’identité sont désormais des fonctionnalités courantes. Chacune transforme une étape de recrutement en enregistrement biométrique permanent.

Les passerelles et proxys d’IA concentrent les identifiants. Des outils comme LiteLLM se placent devant les API de modèles et accumulent clés d’API et identifiants cloud. Toute plateforme qui en adopte un hérite de son risque amont sur la chaîne d’approvisionnement, et c’est exactement le chemin qui a mené à Mercor.

Mettez tout cela bout à bout et vous obtenez un système qui détient des données joyaux de la couronne, élargies par des fonctionnalités d’IA, exposées via des dépendances, et presque jamais incluses dans le plan de réponse aux incidents. Les attaquants l’ont remarqué avant la plupart des équipes de recrutement.

Les données que vous ne pouvez pas réinitialiser

La raison pour laquelle une fuite de données de recrutement est pire qu’une fuite de PII classique est simple : les identifiants biométriques ne peuvent pas être réinitialisés. Comme le résumait une analyse de la brèche Mercor : « il n’existe pas de bouton “réinitialiser” pour votre visage » (IQ Source).

Un mot de passe volé est réémis en quelques secondes. Une carte bancaire divulguée est annulée et réimprimée. Mais un scan de visage volé, accompagné d’un enregistrement vocal, est permanent, et c’est précisément la matière première nécessaire pour générer des deepfakes convaincants. Dans le cas de Mercor, cela signifie usurper l’identité de prestataires qui ont accès à des labos d’IA, une chaîne de conséquences qui survit à n’importe quel e-mail de réinitialisation de mot de passe. Les entretiens vidéo enregistrés et les transcriptions vocales par IA appartiennent à la même catégorie. Ils sont proches du biométrique, ils sont fonctionnellement irréversibles une fois divulgués, et la plupart des entreprises les stockent sans la moindre politique de conservation ou de suppression.

C’est l’argument central en faveur de la minimisation des données dans le recrutement. Les données que vous n’avez jamais collectées ne peuvent pas fuir. Les données que vous avez supprimées dans les temps ne peuvent pas figurer dans le prochain dump. Chaque entretien vidéo que vous conservez « au cas où » est une responsabilité permanente posée sur le bucket S3 de quelqu’un d’autre.

Le rayon d’impact juridique

Une fuite de données candidats n’est pas qu’un incident de sécurité ; c’est un événement réglementaire et contentieux, et les factures arrivent vite. Dans la première semaine d’avril 2026, au moins quatre recours collectifs ont été déposés contre Mercor, la plupart auprès de la U.S. District Court for the Northern District of California, des rapports ultérieurs portant le décompte à cinq ou six (HR Dive ; ComplianceHub). Une plainte propose une classe nationale de plus de 40 000 personnes, avec des griefs allant de la négligence à la violation de contrat implicite, en passant par l’atteinte à la vie privée et la Unfair Competition Law de Californie. Une autre poursuite au Texas vise des sous-traitants en aval, transformant un problème de tiers en problème de quatrième partie.

Les régimes réglementaires en vigueur relèvent encore les enjeux :

Sources : National Law Review ; evidenced.app.

Le schéma est partout le même : les régulateurs récompensent la minimisation, une conservation documentée, le consentement et la capacité de supprimer sur demande. Ce ne sont pas de simples cases à cocher de conformité. Ce sont les mêmes contrôles qui réduisent une brèche.

Comment protéger les données des candidats dans un ATS : la checklist

Pour protéger les données des candidats dans un ATS, appliquez le privacy-by-design : collecter le minimum, le chiffrer au niveau des colonnes, définir des valeurs de conservation par défaut qui suppriment les données selon un calendrier, journaliser les accès, contrôler les sous-traitants de votre fournisseur, honorer les demandes de suppression, et placer l’ATS dans votre plan de réponse aux incidents. Voici la version courte que vous pouvez remettre à un fournisseur ou à votre propre équipe :

1. Minimisez la collecte. Ne récoltez pas de SSN, de pièces d’identité complètes ou de vidéos enregistrées sauf si une étape précise l’exige réellement. La donnée la moins coûteuse à protéger est celle que vous n’avez jamais prise.
2. Chiffrez les PII au niveau des colonnes. Les champs sensibles doivent être chiffrés au repos dans la couche applicative, pas avec un vague « disque chiffré » qui noie le poisson.
3. Définissez des valeurs de conservation par défaut. Chaque fiche candidat, chaque vidéo et chaque transcription a besoin d’un compte à rebours de suppression par défaut mesuré en mois, pas en « pour toujours ».
4. Journalisez les accès. Qui a consulté quel CV, et quand, doit constituer une trace vérifiable.
5. Contrôlez les fournisseurs et leurs fournisseurs. Demandez quelles dépendances et passerelles d’IA se trouvent derrière votre ATS. Le rayon d’impact de Mercor passait par un paquet que la plupart de son équipe n’a jamais choisi directement.
6. Honorez la suppression sur demande. Le RGPD et le CCPA donnent aux candidats le droit à l’oubli ; votre stack doit l’exécuter proprement sur les vidéos, les transcriptions et les données dérivées.
7. Intégrez l’ATS à votre plan de réponse aux incidents. Un système qui détient des SSN, des passeports et de la vidéo biométrique est un actif joyau de la couronne et doit figurer dans le périmètre, pas dans un angle mort.

Votre ATS a sa place dans votre plan de réponse aux incidents

La lacune la plus fréquente est structurelle : les plans de réponse aux incidents couvrent l’infrastructure « de production » et excluent discrètement le système de recrutement, alors même que l’ATS détient souvent les données les plus sensibles de l’entreprise. Un périmètre CSIRT moderne inclut explicitement les systèmes qui détiennent les données les plus sensibles, ainsi que les fonctions juridiques et RH nécessaires pour gérer la notification des violations (FIRST CSIRT Services Framework). Un ATS qui détient des SSN, des passeports et de la vidéo biométrique est exactement ce type de système.

Traiter l’ATS comme une surface de sécurité implique trois choses concrètes. D’abord, il figure dans votre inventaire d’actifs et vos cartographies des flux de données, avec sa classification de données étiquetée. Ensuite, le risque lié à son fournisseur et à ses sous-traitants est passé en revue au même rythme que le reste de votre chaîne d’approvisionnement. Enfin, lorsqu’un incident survient, les personnes capables de répondre à « quelles données candidats s’y trouvaient et qui devons-nous notifier » figurent déjà sur la liste de réponse, au lieu de courir partout. La plupart des entreprises font tourner recrutement et sécurité comme deux mondes déconnectés. Les poursuites contre Mercor, c’est ce qui arrive quand la couture entre les deux est précisément là où vivent les données.

L’approche de Kit

Kit est une plateforme combinée de recrutement et de sécurité, et les défaillances de Mercor correspondent à des contrôles qu’elle met déjà en œuvre, ce qui fait de cet article un argument de posture plutôt qu’un argument marketing. Rien de tout cela ne rend un fournisseur à l’épreuve des brèches, les attaques sur la chaîne d’approvisionnement peuvent frapper n’importe qui, mais les bons paramètres par défaut réduisent à la fois le rayon d’impact et l’exposition réglementaire lorsque quelque chose tourne mal.

• Chiffrement au niveau des colonnes des PII des candidats. Kit chiffre au repos les champs candidats les plus sensibles grâce à Active Record Encryption. L’e-mail est chiffré de façon déterministe pour rester interrogeable en vue de la déduplication, tandis que les champs qui n’ont besoin d’aucune recherche sont chiffrés de façon non déterministe. La leçon « stocker les PII chiffrées, pas en clair », rendue concrète.
• La conservation comme paramètre de premier ordre. Le consentement du candidat porte une fenêtre de conservation configurable, avec une valeur par défaut raisonnable mesurée en mois, et le consentement lui-même peut être renouvelé, refusé et expiré plutôt que stocké indéfiniment. Les données que vous supprimez dans les temps ne peuvent pas figurer dans le prochain dump.
• Un traitement rigoureux des vidéos et des transcriptions. Les entretiens enregistrés et les transcriptions par IA sont traités comme les actifs proches du biométrique et soumis à conservation qu’ils sont, avec une journalisation des accès aux CV des candidats pour constituer une piste d’audit.
• Isolation multi-tenant et suppression défendable. Les données candidats sont cloisonnées par compte, et la suppression réversible (soft-delete) couplée à la journalisation des accès soutient le « droit à la suppression » exigé par le RGPD et le CCPA.
• Un module CSIRT intégré. Parce que Kit livre un module complet de divulgation des vulnérabilités et de réponse aux incidents aux côtés du recrutement, la même discipline de réponse appliquée à la production peut couvrir l’ATS. Les deux mondes que Mercor maintenait séparés ne forment ici qu’une seule surface.

Nous avons traité la mise en place du volet « réponse » dans comment mettre en place un programme de divulgation des vulnérabilités, et la pression de conformité qui pèse désormais sur les petites équipes dans l’échéance de divulgation du Cyber Resilience Act de l’UE. Cet article constitue la couche « données candidats » qui se trouve sous les deux.

FAQ

Mon système de suivi des candidatures est-il un risque de fuite de données ?

Oui, par défaut, c’est l’un de vos systèmes les plus à risque, car il concentre des PII réglementées (noms, adresses, SSN, pièces d’identité officielles, données salariales) et, de plus en plus, des données biométriques issues des entretiens vidéo, tout en étant rarement inclus dans les programmes de sécurité. Le risque est réductible : minimisez ce que vous collectez, chiffrez-le, fixez des limites de conservation, et intégrez l’ATS au périmètre de votre réponse aux incidents. La brèche Mercor a montré que les données sont là, que vous les protégiez ou non.

Quelles données candidats sont les plus dangereuses lors d’une fuite ?

Les données biométriques et d’identité : scans de visage, enregistrements vocaux, entretiens vidéo et images de pièces d’identité officielles. Contrairement à un mot de passe ou à une carte bancaire, elles ne peuvent être ni réinitialisées ni réémises, et elles constituent la matière première des deepfakes et du vol d’identité. Les SSN sont eux aussi extrêmement dangereux. La posture la plus sûre consiste à éviter purement et simplement de collecter ces données, sauf si une étape précise l’exige, et à les supprimer selon un calendrier fixe le cas échéant.

Combien de temps un ATS doit-il conserver les données des candidats ?

Assez longtemps pour servir l’objectif de recrutement et respecter les obligations légales, puis supprimez-les. Sous le RGPD, vous avez besoin d’une durée de conservation définie et documentée plutôt que d’un stockage indéfini, et de nombreuses équipes retiennent par défaut environ deux ans pour les candidatures non retenues, avec un compte à rebours de suppression clair. Les entretiens vidéo et les transcriptions méritent la fenêtre la plus serrée, puisque ce sont les données dont la conservation est la plus difficile à défendre. La conservation doit être une valeur par défaut configurée, pas un nettoyage manuel que personne ne lance.

En résumé

La brèche Mercor est le cas d’école de l’ATS qui devient la brèche : 4 To partis dans la nature via une dépendance, dont la seule catégorie de données — votre visage et votre voix — que personne ne pourra jamais réinitialiser. La réponse défendable n’est pas d’acheter un fournisseur qui promet la sécurité. C’est le privacy-by-design comme une posture que vous pouvez vérifier : collecter moins, chiffrer au niveau des colonnes, définir des valeurs de conservation par défaut qui suppriment dans les temps, journaliser les accès, contrôler les fournisseurs de vos fournisseurs, et faire entrer le système de recrutement dans le plan de réponse aux incidents auquel il a toujours eu sa place.

Si vous auditez votre stack de recrutement et souhaitez que minimisation, chiffrement, conservation et discipline de réponse aux incidents soient intégrés dès le départ, démarrez un essai gratuit de Kit et configurez dès aujourd’hui un processus de recrutement privacy-by-design.