Amazon a construit un recruteur par IA qui a appris tout seul à détester les femmes. J'en ai construit un qui ne le peut pas.

En 2014, une équipe d'ingénieurs en apprentissage automatique à Édimbourg s'est attelée à résoudre le recrutement à l'échelle d'Amazon. On alimente le système avec 100 CV, il renvoie les cinq meilleurs, classés d'une à cinq étoiles — comme pour noter des produits. Élégant. Efficace. Et en l'espace de trois ans, ils ont découvert que le système s'était appris à lui-même qu'être une femme constituait une caractéristique disqualifiante.

L'IA pénalisait les CV contenant le mot « women's » (féminin) — comme dans « Women's Chess Club Captain » (capitaine du club d'échecs féminin). Elle déclassait les diplômées de deux universités exclusivement féminines. Non pas parce que quelqu'un le lui avait ordonné. Mais parce que lorsqu'on entraîne un modèle sur dix ans de données d'embauche issues d'un secteur à dominante masculine, « être un homme » devient, statistiquement, l'un des plus forts prédicteurs du fait « d'être embauché ».

Je me souviens d'avoir lu l'enquête de Reuters au moment où elle a éclaté. J'étais déjà plongé dans la construction de systèmes de graphes de connaissances chez Veriprajna, et ma première réaction n'a pas été la stupeur — c'était la reconnaissance. Cela faisait des mois que je soutenais que les moteurs de corrélation statistique n'avaient rien à faire à prendre des décisions sur le potentiel humain. L'affaire Amazon n'était pas une anomalie. C'était une inévitabilité mathématique. Et cela m'a radicalisé au point de croire que toute l'approche architecturale du recrutement par IA était défectueuse — non pas à la marge, mais dans ses fondations.

Le problème n'est pas le biais. C'est l'architecture.

Voici ce que la plupart des gens comprennent de travers à propos de la débâcle d'Amazon : ils pensent que les ingénieurs ont été négligents. Ils ne l'étaient pas. C'étaient parmi les meilleurs ingénieurs en apprentissage automatique de la planète. Lorsqu'ils ont découvert le biais de genre, ils ont essayé de le corriger. Ils ont explicitement programmé le modèle pour qu'il ignore les termes propres au genre. Et le modèle a trouvé des contournements.

C'est le concept des variables proxy, et c'est la chose qui m'empêche de dormir la nuit. Les modèles d'apprentissage profond sont d'implacables chercheurs de motifs. Retirez le mot « femme » de l'entrée, et le modèle s'accroche à la structure des phrases. Des études montrent que les CV masculins tendent à utiliser des verbes comme « executed » (exécuté) et « captured » (capturé), tandis que les CV féminins penchent vers un langage plus communautaire. Le modèle voit « executed » corréler avec « embauché » et reconstruit silencieusement le biais de genre par la seule linguistique.

Les ingénieurs d'Amazon ne pouvaient pas retirer chirurgicalement le biais sans détruire la capacité prédictive du modèle. Ils ont donc mis fin à l'ensemble du projet.

On ne peut pas réparer un système qui discrimine par accident. Il faut en construire un qui ne puisse pas discriminer par conception.

Cette phrase est mon étoile polaire depuis trois ans. Et c'est la raison pour laquelle nous avons bâti le moteur de recrutement de Veriprajna sur des graphes de connaissances plutôt que sur des réseaux de neurones.

Pourquoi tout recruteur par IA finit-il par apprendre à discriminer ?

J'ai besoin que vous compreniez quelque chose sur le fonctionnement de l'apprentissage profond dans le recrutement, car le mode de défaillance est contre-intuitif.

Un réseau de neurones ne comprend pas ce que signifie « Python ». Il ne sait pas que Python est un langage de programmation utile pour la science des données. Il sait seulement que la chaîne « Python » apparaissait fréquemment dans les CV des personnes qui ont été embauchées. Si « Lacrosse » apparaissait aussi fréquemment — peut-être en raison de corrélations socio-économiques entre certains sports, certaines écoles et certaines entreprises qui alimentent leurs recrutements — le modèle pourrait pondérer « Lacrosse » aussi lourdement que « Python ».

C'est de la corrélation qui se fait passer pour de l'intelligence. Le modèle ne raisonne pas sur la cause et l'effet. Il trouve des motifs et les optimise. Et voici le côté insidieux : l'amplification du biais signifie que ces modèles ne se contentent pas de reproduire les biais historiques — ils les exagèrent. Si les hommes représentaient 60 % de la main-d'œuvre dans les données d'entraînement, le modèle pourrait pousser à embaucher 80 % ou 90 % d'hommes pour maximiser son score de précision.

J'ai eu très tôt une conversation avec un investisseur potentiel qui m'a dit : « Utilisez simplement GPT-4 pour le tri des CV. Tout le monde le fait. » Je lui ai demandé : si vous soumettez deux fois le même CV à GPT-4, obtenez-vous le même score ? Il a marqué une pause. La réponse est non — les LLM sont stochastiques. Ils sont non déterministes. Soumettez deux fois la même entrée, vous obtenez deux sorties différentes. Dans un scénario d'audit, ce n'est pas une bizarrerie. C'est un manquement à la conformité.

Les murs réglementaires se referment

Ce n'est plus théorique. Les gouvernements ont vu l'affaire Amazon et ils légifèrent.

La loi locale 144 de New York (NYC Local Law 144), en vigueur depuis juillet 2023, exige que tout employeur utilisant un outil automatisé de décision d'emploi se soumette à un audit de biais indépendant annuel. Non pas un vague audit du type « nous avons vérifié l'équité » — un audit spécifique et quantitatif. La loi impose le calcul des taux de sélection et des ratios d'impact pour chaque catégorie de race, d'origine ethnique et de sexe. Si le taux de sélection d'un groupe protégé, divisé par le taux du groupe le plus sélectionné, tombe en dessous de 0,8 — la « règle des quatre cinquièmes » — cela constitue une preuve prima facie d'impact disparate.

La loi européenne sur l'IA (EU AI Act) va plus loin. Elle classe les systèmes d'IA utilisés pour le recrutement comme à haut risque — la même catégorie que les dispositifs médicaux et les infrastructures critiques. L'article 13 exige que ces systèmes soient « suffisamment transparents pour permettre aux utilisateurs d'interpréter la sortie du système ». L'article 14 requiert une supervision humaine — la capacité de passer outre les décisions de l'IA. Mais on ne peut pas passer outre de manière significative une décision que l'on ne comprend pas.

Et en vertu du RGPD, l'article 15(1)(h) accorde aux personnes concernées le droit d'accéder à « des informations utiles concernant la logique sous-jacente » aux décisions automatisées. Le considérant 71 mentionne explicitement le droit d'« obtenir une explication quant à la décision prise ».

Essayez d'expliquer la décision d'un réseau de neurones. Allez-y. « Le neurone 4 502 s'est activé à une intensité de 0,8 » n'est pas une explication utile. Pas plus que « le modèle a déterminé que vous correspondiez à 73 % » sans aucun autre détail.

L'écart entre la complexité technique et l'exigence légale d'une explication simple est la crise centrale des technologies RH modernes.

J'ai écrit plus en détail sur ce paysage réglementaire dans la version interactive de notre livre blanc, qui explique précisément comment chaque réglementation s'applique aux différentes architectures d'IA.

Et si l'IA ne pouvait pas du tout voir le genre ?

C'est ici que je dois vous parler de la nuit où tout s'est éclairé pour moi.

Nous avions expérimenté différentes approches de débiaisement — entraînement antagoniste, augmentation contrefactuelle, la panoplie habituelle. Et j'étais assis dans notre bureau à 23 h, fixant une visualisation de graphe sur mon écran, quand j'ai eu l'une de ces révélations évidentes rétrospectivement : nous essayions d'apprendre au modèle à ignorer le biais. Et si nous construisions une architecture où le biais ne pouvait littéralement pas entrer dans le moteur de raisonnement ?

Dans un graphe de connaissances, les données sont stockées sous forme de nœuds (entités) et d'arêtes (relations). Un nœud Personne se connecte à des nœuds Compétence. Les nœuds Compétence se connectent à d'autres nœuds Compétence par des relations sémantiques. Le graphe sait que « PyTorch » est une bibliothèque pour l'« apprentissage profond », lequel est un sous-ensemble de l'« intelligence artificielle ». Ainsi, si un poste exige une « expérience en IA » et qu'un candidat mentionne « PyTorch », le graphe retrace le chemin et trouve une correspondance — même sans que le mot-clé « IA » n'apparaisse nulle part sur le CV.

Voici la décision architecturale cruciale : lorsque notre algorithme de correspondance s'exécute, il opère sur un sous-graphe restreint. Ce graphe d'inférence contient les Compétences, les Rôles, les niveaux d'Expérience et les Certifications. Il exclut explicitement les nœuds pour le Nom, le Genre, l'Origine ethnique, l'Adresse et les dates d'obtention de diplôme.

Le biais n'est pas supprimé. Il est structurellement sectionné. Il n'existe aucun chemin de « Candidat » à « Genre » à « Rôle », parce que le nœud Genre n'existe pas dans le graphe que l'algorithme peut voir.

Comparez cela à un modèle d'apprentissage profond, qui ingère l'intégralité du texte brut. Même si vous supprimez le champ « Genre », le modèle lit « Women's Chess Club » (club d'échecs féminin) et en déduit le genre. Dans notre système, le LLM qui analyse le CV fait correspondre « Women's Chess Club » à un nœud neutralisé : (:Activity {type: "Strategy Club", role: "Leadership"}). Le modificateur genré est retiré avant qu'il n'entre dans le moteur de raisonnement.

Je me souviens du débat au sein de l'équipe à ce sujet. L'un de mes ingénieurs s'y est fermement opposé — il pensait que nous perdions un signal précieux en retirant le contexte. « Et si le club d'échecs féminin était en réalité plus compétitif que le club ordinaire ? » Argument recevable. Mais nous n'optimisions pas pour une extraction maximale d'information. Nous optimisions pour l'équité sous examen juridique. Et je préfère passer à côté d'un signal marginal plutôt que de construire un système qui apprend à pénaliser la moitié de la population.

Comment mesure-t-on réellement le talent sans biais ?

Nous ne prédisons pas qui réussira. Nous mesurons la distance entre compétences — l'écart géométrique entre ce que possède un candidat et ce qu'exige un poste. Cela fait passer le recrutement de la probabilité subjective à la mesure objective.

Les systèmes traditionnels de suivi des candidatures utilisent une logique booléenne : le CV contient-il le mot-clé « Java » ? Oui ou non. C'est fragile et stupide. Cela passe à côté de quiconque emploie une terminologie différente pour la même compétence.

Nous utilisons des plongements de graphe — des algorithmes comme Node2Vec qui apprennent une représentation vectorielle pour chaque compétence de notre ontologie. Les compétences qui coexistent fréquemment dans le graphe (comme « Python » et « Pandas ») finissent proches les unes des autres dans l'espace vectoriel. Les compétences sans rapport (comme « Python » et « phlébotomie ») finissent éloignées.

Pour noter un candidat, nous calculons la similarité cosinus entre l'ensemble des vecteurs de compétences du candidat et l'ensemble des vecteurs d'exigences du poste. Cela nous donne un crédit partiel. Un candidat à qui il manque « Tableau » mais qui possède « Power BI » obtient un score de similarité élevé, car ces nœuds sont des voisins sémantiques dans la grappe « Business Intelligence ». Une recherche par mot-clé lui attribuerait un zéro.

Nous superposons la similarité de Jaccard pour le recoupement brut des compétences et la distance géodésique — des calculs de plus court chemin à travers le graphe — pour l'analyse des lacunes. Si un poste exige Kubernetes et qu'un candidat possède Docker, le graphe trouve le chemin : Docker → Conteneurisation → Orchestration → Kubernetes. Distance : 3 sauts. Interprétation : formable. Si la distance est de 6 sauts ou plus, il s'agit d'une lacune profonde.

Le score final de distance entre compétences est une métrique purement fondée sur les compétences, totalement aveugle aux données démographiques. Nous ne devinons pas qui est bon. Nous mesurons à quel point ils en sont proches.

Pour une explication technique complète de ces algorithmes — y compris les mathématiques derrière la similarité cosinus et notre modèle de notation composite — consultez notre article de recherche.

Le moment du « SQL manquant »

Rendons cela concret avec quelque chose qui s'est produit pendant les tests.

Nous avons soumis un profil de candidat à la fois à un recruteur boîte noire standard et à notre système. La boîte noire a rejeté le candidat. Sans raison donnée. (Nous avons déterminé plus tard que le candidat avait fréquenté une petite université peu connue — une pénalité de pedigree classique.)

Notre système a renvoyé ceci : « Le candidat manque d'expérience explicite en SQL. Cependant, l'analyse du graphe révèle une expérience approfondie avec les DataFrames de Pandas et dplyr de R. La distance dans le graphe entre les DataFrames et SQL est courte (concept partagé : manipulation de données). Recommandation : entretien. Forte transférabilité. »

Ce candidat — celui que la boîte noire avait écarté — possédait toutes les compétences dont le poste avait besoin. Il utilisait simplement des mots différents pour les désigner. Et il avait fréquenté une école que la boîte noire n'avait pas assez vue dans ses données d'entraînement pour la considérer comme « couronnée de succès ».

C'est ce que je veux dire lorsque j'affirme que les graphes de connaissances élargissent le vivier de talents. Ils trouvent des gens qui possèdent les compétences mais pas le pedigree ni le vocabulaire exact. Et cela améliore naturellement la diversité — non pas par des quotas ou des ajustements, mais par une meilleure mesure.

Que se passe-t-il lorsque le système signale un problème ?

On me demande : « Et si votre système produisait tout de même des résultats biaisés ? » C'est une question légitime, et je me méfierais de quiconque prétendrait que son système est parfait.

Voici la différence : lorsqu'une boîte noire produit des résultats biaisés, vous êtes bloqué. Vous pouvez voir l'impact disparate dans les chiffres, mais vous ne pouvez pas voir pourquoi. Est-ce le nom des universités ? Les codes postaux ? Le style d'écriture ? Vous déboguez un système comportant des millions de paramètres et aucune logique lisible.

Lorsque notre système produit une anomalie statistique — disons un ratio d'impact inférieur à 0,8 pour un groupe démographique particulier — nous pouvons la retracer. Nous pouvons identifier les nœuds spécifiques du graphe à l'origine de la disparité. Peut-être qu'une description de poste exige une certification onéreuse particulière qui corrèle avec le statut socio-économique. Nous pouvons le constater, le signaler, et l'équipe de recrutement peut décider si cette certification est vraiment nécessaire ou n'est qu'une exigence héritée que personne n'a jamais remise en question.

La boîte de verre ne signifie pas que le système a toujours raison. Elle signifie que lorsqu'il se trompe, vous pouvez découvrir pourquoi et le corriger.

Le LLM a toujours un rôle — mais pas le rôle important

Je dois être clair : nous utilisons des LLM. Nous ne sommes pas des luddites. Mais nous les utilisons comme vous utiliseriez un traducteur — pour lire et écrire, pas pour juger.

Notre architecture impose une stricte séparation des responsabilités. Le LLM se charge de la perception : il lit le texte non structuré du CV et en extrait les entités. « J'ai orchestré une équipe de 5 développeurs pour construire une application React Native » devient des données structurées — Compétence : React Native, Compétence : direction d'équipe, Contexte : développement mobile. Le LLM normalise les synonymes : « ReactJS » et « React.js » correspondent tous deux au même nœud.

Mais le LLM ne prend jamais de décision d'embauche. Toute la mise en correspondance, la notation et le classement se produisent par un parcours déterministe du graphe. Même graphe plus même requête égale même résultat, à chaque fois. Nous utilisons également le LLM en bout de chaîne — il génère des explications lisibles par un humain, mais uniquement à partir de faits vérifiés par le graphe. Il ne peut pas halluciner une correspondance de compétence que le graphe ne soutient pas.

Je le vois comme le LLM étant les yeux et la bouche du système, tandis que le graphe de connaissances en est le cerveau. Vous ne laisseriez pas votre bouche prendre des décisions à votre place. (Enfin, la plupart d'entre nous ne le feraient pas.)

Entre quoi choisissons-nous réellement ?

Telle que je la vois, l'industrie est à une bifurcation. Un chemin mène à des modèles plus grands, plus de paramètres, plus d'opacité — et à une partie sans fin de tape-taupe avec le biais qui ne cesse de trouver de nouvelles variables proxy à exploiter. L'autre chemin mène à un raisonnement structuré, à une mesure sémantique et à des systèmes capables de s'expliquer à un régulateur, à un recruteur ou à un candidat rejeté.

J'ai parlé à des responsables RH d'entreprises qui utilisent encore des outils de tri boîte noire. Ils connaissent le risque. Ils ont lu ce qui s'est passé chez Amazon. Mais changer d'architecture semble coûteux et incertain, alors ils continuent de rafistoler. Ils ajoutent des « couches d'atténuation du biais » par-dessus des systèmes fondamentalement biaisés. Ils embauchent des consultants pour mener des audits annuels qui leur disent ce qui est cassé sans leur donner les outils pour le réparer.

Les données sont un miroir. Si vous entraînez un modèle sur le passé, vous reproduisez le passé. Dans un monde en quête d'équité, reproduire le passé est une condition d'échec.

Je ne vais pas conclure sur une réserve prudente. J'ai passé des années à construire cela, j'ai vu l'alternative échouer de façon spectaculaire, et je suis convaincu de la conclusion : l'avenir de l'IA de recrutement ne consiste pas à prédire qui réussira sur la base de qui a réussi auparavant. Il consiste à mesurer la distance réelle entre ce que quelqu'un peut faire et ce qu'exige un poste — et à rendre cette mesure transparente, déterministe et structurellement incapable de discrimination.

Vous pouvez continuer à prédire le passé. Ou vous pouvez commencer à mesurer l'avenir.