64 millions de personnes ont postulé à un emploi. Un mot de passe « 123456 » a livré tous leurs secrets.

J'étais en pleine conversation téléphonique avec un client potentiel — une entreprise de logistique de taille moyenne — lorsque l'affaire McHire a éclaté. Mon cofondateur m'a envoyé un lien en plein milieu d'une phrase. J'y ai jeté un œil, lu les deux premières lignes, et je me suis tu complètement. Le client m'a demandé si j'étais toujours là.

« Désolé, » ai-je dit. « Je viens de lire que la plateforme de recrutement par IA de McDonald's — celle qui trie des millions de candidats — était protégée par le mot de passe "123456". Et quelqu'un vient tout simplement d'y entrer. »

Il y a eu un long silence. Puis le client a dit : « C'est en gros notre configuration. »

Il plaisantait à moitié. Mais seulement à moitié.

La fuite McHire de juin 2025 a exposé les données personnelles d'environ 64 millions de candidats — noms, adresses e-mail, numéros de téléphone, adresses IP, transcriptions de conversations avec une recruteuse IA nommée « Olivia » et, plus troublant encore, les résultats de leurs tests de personnalité. Le vecteur n'était pas une attaque sophistiquée d'un État-nation. Ce n'était pas une faille zero-day nécessitant une équipe de hackers d'élite. C'était un mot de passe administrateur par défaut resté inchangé depuis 2019, sur un compte sans authentification multifacteur, protégeant une API qui permettait à n'importe qui de parcourir les identifiants de candidats dans la barre d'adresse d'un navigateur.

Quand j'explique aux gens ce que nous faisons chez Veriprajna — construire des systèmes d'IA avec la sécurité et la gouvernance intégrées à l'architecture — j'obtiens parfois ce hochement de tête poli qui signifie « bien sûr, mais n'est-ce pas exagéré ? ». La fuite McHire est ma réponse. Ce n'est pas exagéré. C'est le strict minimum. Et la plupart des entreprises ne font même pas cela.

Que s'est-il réellement passé au sein de la plateforme McHire ?

La fuite n'a pas été découverte par une équipe de renseignement sur les menaces ni par une agence gouvernementale. Tout a commencé avec deux chercheurs en sécurité — Ian Carroll et Sam Curry — qui ont remarqué quelque chose de banal : les utilisateurs se plaignaient que le chatbot « Olivia » était bogué. L'expérience côté interface était maladroite et peu fiable.

Ce détail a son importance. D'après mon expérience, une interface défaillante est presque toujours un signal. Si une entreprise n'a pas investi dans la partie que les utilisateurs voient, imaginez ce qui se passe dans les parties qu'ils ne voient pas.

Carroll et Curry ont commencé à fouiller et ont trouvé un portail d'administration destiné aux employés de Paradox.ai — le fournisseur qui a conçu et exploité McHire pour le compte de McDonald's. Ils ont essayé un compte de test. Le nom d'utilisateur ? « 123456. » Le mot de passe ? « 123456. » Ça a fonctionné.

Je me souviens d'avoir lu cela et d'avoir ressenti une colère bien particulière que reconnaîtra quiconque a déjà construit des systèmes en production. Ce n'est pas de la surprise — c'est la fureur de savoir que cela était entièrement évitable. Ce n'était pas une subtile erreur de configuration dans un cluster Kubernetes. C'était l'équivalent numérique de laisser la porte du coffre-fort ouverte avec un Post-it disant « clé sous le paillasson ».

Mais le mot de passe n'était que la première étape. Une fois à l'intérieur, les chercheurs ont découvert une vulnérabilité de type Insecure Direct Object Reference — un IDOR, dans le jargon de la sécurité. Cela signifiait que l'API ne vérifiait pas si un utilisateur connecté était réellement autorisé à voir les données d'un candidat en particulier. En changeant le numéro d'identifiant du candidat dans l'URL — littéralement juste en incrémentant un nombre — ils pouvaient afficher les dossiers complets de n'importe quel candidat du système.

Soixante-quatre millions d'entre eux.

Pourquoi les données de tests de personnalité sont le pire type de données à divulguer

C'est ici que la plupart des articles sur cette fuite se trompent. Les titres se sont concentrés sur le mot de passe — « 123456 », ha ha, quelle bêtise — puis sont passés à autre chose. Mais la véritable catastrophe n'est pas l'identifiant. C'est ce qu'il y avait derrière lui.

Les numéros de carte de crédit peuvent être annulés. Les mots de passe peuvent être changés. Mais les résultats d'une évaluation de personnalité ? Les scores d'un dépistage comportemental ? Les transcriptions d'une conversation où une IA a sondé votre tempérament, vos réactions émotionnelles, votre manière de gérer les conflits ?

Ces données, c'est vous. Elles n'expirent pas.

Quand un profil de personnalité fuite, vous ne pouvez pas le renouveler comme un mot de passe. Votre empreinte psychométrique vous suit à jamais.

J'ai passé une nuit blanche après la fuite à lire des recherches sur l'impact psychologique de l'exposition des données. Les chiffres sont stupéfiants : près de 70 % des victimes de fuites signalent une incapacité persistante à faire confiance aux autres. Deux tiers éprouvent un profond sentiment d'impuissance. Des études ont établi un lien entre l'exposition de données personnelles et l'anxiété, la dépression et le TSPT. Et la gravité augmente avec l'intimité des données — une adresse e-mail divulguée pique ; une évaluation de personnalité divulguée disant que vous êtes « émotionnellement instable » ou « peu consciencieux » peut ressembler à une dissection publique.

Pour les candidats — dont beaucoup sont jeunes, beaucoup postulant pour leur premier emploi dans une chaîne de restauration rapide — c'est particulièrement cruel. Ils se sont soumis à un test de personnalité parce qu'une IA le leur a demandé. Ils n'avaient aucun moyen réel de comprendre quelles données étaient collectées, comment elles étaient stockées, ni qui pouvait y accéder. Et maintenant, ces données sont dans la nature, potentiellement pour toujours, dans un monde où de futurs employeurs, assureurs ou acteurs malveillants pourraient utiliser des traits inférés contre eux.

Mon équipe a eu un débat à ce sujet. Un de nos ingénieurs a dit : « Écoute, les données ont été exposées mais probablement pas réellement exfiltrées à grande échelle — les chercheurs les ont signalées de manière responsable. » Et techniquement, c'est vrai. Paradox a corrigé la vulnérabilité en quelques heures après la notification. Mais j'ai fermement objecté. La question n'est pas de savoir si ce jeu de données précis a fini sur un forum du dark web. La question est que l'architecture l'a permis. Le système a été conçu de telle manière qu'un mot de passe par défaut et un navigateur suffisaient pour accéder aux profils psychométriques de 64 millions de personnes. Ce n'est pas passé de justesse. C'est un échec de philosophie de conception.

Le développeur au Vietnam et le mot de passe qui a tout déverrouillé

Il y a une intrigue secondaire dans cette histoire qui n'a pas reçu assez d'attention. Les enquêtes ont révélé qu'un développeur de Paradox.ai basé au Vietnam avait été compromis par une souche de logiciel malveillant appelée Nexus Stealer — un outil de vol d'identifiants vendu sur des forums de cybercriminalité. L'infection a exfiltré des centaines de mots de passe de l'appareil du développeur. Beaucoup d'entre eux étaient faibles et réutilisés, utilisant le même mot de passe de base à sept chiffres sur plusieurs services.

Ce seul développeur compromis a exposé des identifiants associés aux comptes Paradox.ai de clients incluant Pepsi, Lockheed Martin, Lowe's et Aramark.

Je veux que vous preniez un moment pour y réfléchir. Une seule personne. Un seul ordinateur portable infecté. Un seul mot de passe réutilisé. Et soudain, les données de recrutement de certains des plus grands employeurs d'Amérique sont menacées.

C'est ce que j'appelle le problème du « nœud humain », et c'est la chose qui me tient éveillé la nuit bien plus que n'importe quel vecteur d'attaque IA exotique. Vous pouvez construire le modèle le plus sophistiqué du monde, l'affiner sur des données impeccables, l'envelopper de garde-fous — et puis l'hygiène des mots de passe d'un seul développeur fait s'effondrer tout le château de cartes. Le coût moyen d'une fuite de données en 2025 a atteint 4,44 millions de dollars. Mais les organisations continuent de traiter la gestion des identités comme un détail secondaire, quelque chose que l'équipe informatique gère avec une vidéo de formation annuelle que personne ne regarde.

La sécurité de votre système d'IA n'est jamais plus forte que le maillon humain le plus faible de la chaîne.

Chez Veriprajna, nous avons bâti notre architecture autour de l'hypothèse que l'accès humain est un vecteur à haut risque nécessitant une vérification continue — ce que le secteur appelle le Zero Trust. Non pas parce que nous ne faisons pas confiance à notre équipe, mais parce que j'ai vu ce qui arrive quand on fait confiance à n'importe quel point d'authentification unique pour tenir la ligne.

Que signifie réellement « IA profonde » — et pourquoi devriez-vous vous en soucier ?

Je dois introduire une distinction qui est, selon moi, l'idée la plus importante de l'IA en entreprise aujourd'hui, et que la fuite McHire illustre parfaitement : la différence entre un AI Wrapper et ce que nous appelons l'IA profonde.

Un AI Wrapper est ce que la plupart des entreprises construisent réellement lorsqu'elles disent « faire de l'IA ». C'est une fine couche applicative — souvent un chatbot ou un formulaire — qui envoie les entrées de l'utilisateur à un modèle fondamental comme GPT-4 ou Claude via une API, obtient une réponse et l'affiche. L'IA est un service que vous louez. Votre application est la vitrine. La sécurité, la gestion des données, la gouvernance — tout cela est ajouté après coup, en utilisant les mêmes pratiques de développement web que pour n'importe quelle application CRUD.

« Olivia » de Paradox.ai était, sur le plan architectural, un wrapper. Sophistiqué, certes. Mais sa posture de sécurité était ancrée dans une infrastructure web traditionnelle — et cette infrastructure a échoué au niveau le plus élémentaire imaginable.

L'IA profonde est fondamentalement différente. Elle traite le modèle d'IA comme une primitive architecturale — au même titre qu'une base de données ou une file de messages — avec ses propres frontières de sécurité, ses propres contrôles d'accès, ses propres pistes d'audit. Le modèle n'est pas une boîte noire que l'on appelle ; c'est un composant que l'on gouverne. Vous construisez des routeurs de prompts, des couches de mémoire, des évaluateurs de retour. Vous mettez en place des défenses en couches qui supposent que chaque entrée est hostile et chaque sortie non fiable.

J'ai écrit en profondeur sur cette philosophie architecturale dans la version interactive de nos recherches, mais l'idée centrale est simple : si votre stratégie de sécurité IA se résume à « nous ajouterons de l'authentification et un WAF », vous construisez un wrapper, et vous êtes à un mot de passe par défaut de la catastrophe.

La défense à 5 couches que personne ne veut construire

Après l'annonce de l'affaire McHire, j'ai réuni mon équipe d'ingénierie dans une salle et j'ai dit : « Expliquez-moi exactement comment notre stack aurait empêché cela. » Non pas parce que je doutais d'eux — mais parce que je voulais mettre à l'épreuve chaque hypothèse.

Nous y avons passé trois heures. À un moment donné, notre ingénieur en sécurité principal a dessiné au tableau blanc un schéma qui ressemblait à la coupe transversale d'un château médiéval — des anneaux de défense concentriques, chacun fonctionnant indépendamment. Si l'un tombe, le suivant tient. Voici à quoi cela ressemble en pratique :

L'anneau le plus externe est l'assainissement des entrées — chaque prompt, chaque appel d'API est débarrassé de tout ce qui pourrait être interprété à tort comme une commande d'injection. Le deuxième anneau est la détection heuristique des menaces, scrutant activement les schémas adverses connus. Le troisième est l'enveloppement par méta-prompt, où la requête de l'utilisateur est enfermée dans une enveloppe sécurisée d'instructions que le modèle ne peut pas outrepasser.

Le quatrième anneau est là où cela devient intéressant : les modèles canari et arbitre. Un modèle plus petit analyse d'abord la requête. S'il signale quelque chose de suspect, un deuxième modèle prend la décision finale. C'est un système de binôme pour l'IA — aucun modèle unique n'agit unilatéralement.

Le cinquième anneau, le plus interne, est la validation des sorties. Chaque réponse générée par l'IA est traitée comme non fiable jusqu'à preuve du contraire. Des couches de caviardage des données personnelles recherchent les informations sensibles. Des classificateurs de toxicité vérifient l'absence de contenu nuisible. Rien ne passe sans être inspecté.

Voici ce qui m'a frustré durant cette session au tableau blanc : rien de tout cela n'est exotique. Rien de tout cela ne nécessite une percée dans la recherche. C'est de la discipline d'ingénierie appliquée à un nouveau domaine. La raison pour laquelle la plupart des entreprises ne le font pas, c'est que c'est coûteux, c'est lent, et que ça ne fait pas une belle démo. Un chatbot wrapper peut être construit en un week-end et présenté à un conseil d'administration le lundi. Un système d'IA correctement gouverné prend des mois. Devinez lequel obtient un financement.

Le secteur de l'IA a un problème de démo : ce qui impressionne les investisseurs lors d'un pitch est architecturalement à l'opposé de ce qui protège les utilisateurs en production.

Pourquoi la loi traite-t-elle les données de personnalité comme si elles étaient radioactives ?

Une question que me pose chaque directeur technique avec qui je parle : « À quel point l'exposition juridique est-elle grave, vraiment ? »

La réponse : potentiellement existentielle.

En vertu de la CCPA, une entreprise peut être poursuivie si des informations personnelles non chiffrées sont volées en raison d'un manquement au maintien de « procédures de sécurité raisonnables ». Les dommages-intérêts légaux s'élèvent à 750 $ par consommateur et par incident. Multipliez cela par 64 millions de dossiers et vous obtenez une responsabilité théorique de 48 milliards de dollars. Aucun tribunal n'accorderait ce montant total, mais même une fraction suffit à faire couler une entreprise.

En vertu du RGPD, les sanctions plafonnent à 20 millions d'euros ou 4 % du chiffre d'affaires annuel mondial — le montant le plus élevé étant retenu. Et le règlement européen sur l'IA (AI Act), qui classe l'IA de recrutement comme « à haut risque », introduit des amendes pouvant atteindre 35 millions d'euros ou 7 % du chiffre d'affaires mondial en cas de non-conformité aux exigences obligatoires d'évaluation des risques et de supervision humaine.

Mais voici ce que la plupart des analyses juridiques manquent : le préjudice de réputation est pire que les amendes. J'ai parlé à une DRH d'une entreprise du Fortune 500 quelques semaines après la fuite. Elle m'a raconté que son équipe évaluait des outils de recrutement par IA et avait présélectionné trois fournisseurs. Après l'affaire McHire, le PDG a tué toute l'initiative. « Nous le ferons manuellement pendant encore un an, » a-t-il dit. « Je ne serai pas le prochain gros titre. »

C'est ça, le véritable coût. Pas seulement pour Paradox.ai, mais pour chaque entreprise d'IA légitime qui tente d'instaurer la confiance avec les acheteurs en entreprise. Une fuite catastrophique empoisonne le puits pour tout le monde.

Comment gouverner concrètement une IA qui prend des décisions concernant les personnes ?

C'est là que je dois être honnête sur quelque chose d'inconfortable : les cadres de gouvernance ont l'air ennuyeux. ISO 42001, NIST AI RMF, l'OWASP Top 10 pour les LLM — ce ne sont pas les choses qui enthousiasment les fondateurs lors des dîners. Mais ce sont les choses qui distinguent les entreprises qui survivent au contrôle réglementaire de celles qui n'y survivent pas.

L'ISO 42001 est la première norme internationale au monde pour les systèmes de management de l'IA. Elle exige des organisations qu'elles identifient les risques spécifiques à l'IA, établissent des objectifs clairs en matière de transparence et de sécurité, réalisent des analyses d'impact pour chaque système d'IA et maintiennent une surveillance continue par des audits internes. Ce n'est pas un simple exercice de case à cocher — c'est un système de management qui vous force à penser la gouvernance de l'IA comme vous pensez les contrôles financiers.

Le cadre de gestion des risques liés à l'IA du NIST (NIST AI RMF) fournit l'ancrage politique, organisé autour de quatre fonctions : GOUVERNER, CARTOGRAPHIER, MESURER, GÉRER. Dans la fuite de Paradox, la fonction GOUVERNER a échoué de la manière la plus flagrante — il n'y avait aucune responsabilité organisationnelle pour la mise hors service du compte administrateur obsolète qui traînait là depuis 2019.

Et le cadre OWASP — en particulier sa mise à jour 2025 pour l'IA agentique — donne aux développeurs une taxonomie hiérarchisée des vulnérabilités les plus critiques. Le détournement d'objectif d'agent (Agent Goal Hijack), où un contenu malveillant altère le comportement fondamental d'un agent. Le détournement d'outil (Tool Misuse), où un agent est amené par ruse à utiliser une capacité légitime à des fins nuisibles. L'empoisonnement de la mémoire (Memory Poisoning), où de mauvaises données sont injectées dans la mémoire à long terme d'un agent persistant.

Pour l'analyse technique complète de la façon dont ces cadres s'entrecroisent, y compris les détails de mise en œuvre et une feuille de route de 90 jours pour dirigeants, j'ai publié un document d'accompagnement détaillé. Mais le résumé pour dirigeants est le suivant : d'ici 2026, la gouvernance de l'IA ne sera plus optionnelle. Ce sera une condition préalable pour faire affaire avec toute entreprise dotée d'un service juridique.

« Ne peut-on pas simplement ajouter la sécurité plus tard ? »

Les gens me posent constamment cette question. La réponse est toujours la même, et elle est toujours inconfortable : non. Vous ne pouvez pas.

Une sécurité rajoutée après coup n'est que du théâtre de sécurité. C'est un verrou sur une porte déjà arrachée de ses gonds. La fuite McHire le prouve — Paradox.ai avait une authentification. Ils avaient un portail d'administration. Ils avaient vraisemblablement un processus de revue de sécurité. Mais parce que la sécurité n'était pas intégrée à l'architecture dès le premier jour, l'ensemble du système n'était pas plus solide qu'un mot de passe qu'un tout-petit pourrait deviner.

Une autre objection que j'entends : « Mais nous utilisons un grand fournisseur de cloud. Leur sécurité n'est-elle pas suffisante ? » Le développeur de Paradox au Vietnam a été compromis par un logiciel malveillant de série — pas par une faille de l'infrastructure cloud. Votre fournisseur de cloud peut avoir une sécurité parfaite et votre système peut tout de même être compromis parce qu'un développeur a réutilisé un mot de passe sur plusieurs services. Le périmètre n'est pas là où vous pensez qu'il est.

Et puis il y a celle qui me met véritablement en colère : « Notre fournisseur d'IA s'occupe de la sécurité. » C'est exactement ce que pensait McDonald's. Ils ont externalisé leur recrutement par IA à Paradox.ai et, ce faisant, ont externalisé leur posture de sécurité à un fournisseur dont le portail d'administration était protégé par « 123456 ». La chaîne d'approvisionnement est désormais le périmètre de sécurité. Si vous ne gouvernez pas l'infrastructure d'IA de vos fournisseurs avec la même rigueur que la vôtre, vous ne déléguez pas le risque — vous l'ignorez.

La pensée que je n'arrive pas à chasser

Voici ce à quoi je reviens sans cesse, des semaines après l'éclatement de l'affaire McHire.

Soixante-quatre millions de personnes — beaucoup d'entre elles adolescentes, beaucoup postulant pour leur premier emploi — se sont assises devant un écran et ont répondu aux questions d'un chatbot IA. Elles ont partagé des informations sur elles-mêmes parce que le système le leur a demandé. Elles n'avaient aucun levier, aucun pouvoir de négociation, aucune possibilité de dire « en fait, je préférerais ne pas passer un test de personnalité pour retourner des hamburgers ». L'asymétrie de pouvoir était totale.

Et le système qui détenait leurs données — leurs noms, leurs profils comportementaux, l'évaluation par l'IA de leur personnalité — était protégé par le même mot de passe que celui que ma fille utilise pour son compte Roblox.

Nous avons construit des systèmes d'IA capables d'évaluer la personnalité humaine à grande échelle. Nous avons juste oublié de protéger les humains.

Ce n'est pas un problème de technologie. C'est un problème de valeurs. C'est ce qui arrive quand le secteur traite l'IA comme un produit à livrer plutôt que comme un système à gouverner. Quand « aller vite et casser des choses » rencontre « nous prenons des décisions automatisées sur les moyens de subsistance des gens ».

L'ère du wrapper est révolue. Les entreprises qui survivront à la prochaine vague de réglementation, à la prochaine fuite, au prochain règlement de comptes public — ce seront celles qui auront intégré la sécurité aux fondations, pas celles qui l'auront rajoutée après le gros titre. Chez Veriprajna, c'est le seul type d'IA que nous sommes prêts à construire. Non pas parce que c'est plus facile. Parce que l'alternative est indéfendable.

Le mot de passe « 123456 » devrait être une relique. L'architecture qui lui a permis d'avoir de l'importance devrait être éteinte. Et les 64 millions de personnes dont les données ont été exposées méritent mieux que la définition actuelle de « suffisamment bon » du secteur.