Un groupe de 26 professionnels a intenté une action contre Meta lundi dernier, le 13, devant un tribunal californien. L’accusation est directe. Selon l’action, l’entreprise aurait utilisé l’intelligence artificielle pour noter, classer et déterminer qui allait figurer sur la liste des licenciements. Meta conteste. Dans un communiqué, la société affirme que ce sont des personnes qui ont pris les décisions d’ordre organisationnel, et non l’IA.
Pourtant, l’affaire retient l’attention de ceux qui développent des logiciels. Après tout, ce qui est débattu ne concerne pas seulement une politique RH. C’est l’architecture d’un système de classement.
Ce que le procès décrit de Meta, en termes d’ingénierie
Les documents évoquent une constellation de systèmes internes baptisée Metamate. Selon l’action, cet ensemble aurait été entraîné avec les données des employés eux-mêmes. Parmi les sources figureraient le système controversé de surveillance des frappes et des activités, ainsi que des tableaux d’utilisation des tokens d’IA et des évaluations de performance basées sur des algorithmes.
Traduisant cela en langage technique : la télémétrie d’activité est devenue une feature. Ensuite, ces features ont alimenté un score. Enfin, le score a ordonné les personnes.
Jusque-là, rien ne paraît excentrique. N’importe quel ingénieur a déjà monté un pipeline similaire. Cependant, c’est précisément dans le passage suivant que les choses dérapent.
Le bug ne venait pas du modèle, il venait des données manquantes
Voici le cœur de l’accusation. Des collaborateurs en congé, y compris pour congé médical, ne généraient tout simplement pas de métriques durant la période concernée. Par conséquent, ils avaient moins de signaux à comparer.
Et que se passe-t-il lorsque le signal manque ? Le système ne renvoie pas “inconnu”. Il renvoie un chiffre faible.
Autrement dit, l’absence était interprétée comme une faible performance. Selon le dossier, le résultat a été que les employés ayant pris des congés protégés ont été sélectionnés de manière disproportionnée. Or, dans la pratique, le score pénalisait ceux qui exerçaient un droit légal.
C’est un schéma que tout développeur reconnaît. Les données manquantes traitées comme zéro. Ce n’est pas une malveillance de l’algorithme. C’est le comportement par défaut de l’implémentation.
Pourquoi ce cas Meta devient une affaire juridique et non une simple dette technique
L’action affirme une violation du droit du travail et des actes discriminatoires, notamment en rapport avec le congé maternité et les personnes en situation de handicap. Le groupe demande la réintégration de ceux qui ont été licenciés.
Remarquez le saut. Une décision consistant à attribuer des valeurs nulles, prise dans une ligne de code, est devenue une discrimination systémique. Il n’y avait pas d’intention déclarée. Cependant, l’effet a été corrélé à des catégories protégées.
Par conséquent, le concept clé ici est le disparate impact. La règle semble neutre. Toutefois, le résultat ne l’est pas.
Quatre questions à se poser avant le prochain déploiement
Tout le monde ne construit pas un système de licenciement. Pourtant, beaucoup conçoivent des classements, des scores de crédit, un tri de CV et une priorisation des demandes. Les questions ci-dessous s’appliquent à tous ces cas.
Premier : que fait votre pipeline avec les valeurs nulles ?
Vérifiez l’imputation. Zéro, moyenne et médiane ne sont que des choix politiques déguisés en défaut statistique.
Deuxième : la période d’observation est-elle égale pour tout le monde ?
Si quelqu’un est sorti de la fenêtre, normalisez par le temps actif. Sinon, vous mesurez la présence, pas la productivité.
Troisième : existe-t-il un proxy caché ?
Le comptage des frappes peut être corrélé à une déficience motrice. L’utilisation de tokens peut corréler à une fonction. Ainsi, la variable protégée peut entrer par une porte dérobée, même si vous ne l’avez jamais collectée.
Quatrième : le score est-il auditable ?
Si l’équipe juridique demande l’explication d’une ligne spécifique six mois plus tard, pouvez-vous reconstruire ? Sans versionnage des données, du modèle et du stock de features, la réponse est généralement non.
Le détail qui compte plus que le verdict
Meta affirme que les accusations ne reposent ni sur des faits ni sur des preuves. Selon l’entreprise, la gestion de la main-d’œuvre a été assurée par des personnes.
Supposons que cela soit vrai. Il reste pourtant une question gênante. Si un humain appose sa signature sur une liste ordonnée par un modèle, qui décide réellement ?
C’est la figure du rubber stamp. La supervision humaine figure dans l’organigramme. Cependant, elle n’existe pas dans le flux réel de la décision. Et les tribunaux commencent à en prendre conscience.
Ce que cela change pour celui qui écrit le code
Pendant des années, la réponse par défaut était rassurante. Le modèle est un outil, la décision appartient au responsable. Or, cet argument perd de son poids lorsque le responsable reçoit une liste prête à l’emploi et des délais serrés.
C’est pourquoi trois pratiques ne sont plus optionnelles :
- Enregistrer l’origine de chaque feature, y compris la source de collecte et le consentement associé.
- Réaliser des tests d’impact ventilés par groupe avant tout système qui ordonne les personnes.
- Documenter les décisions d’imputation dans un fichier qui survive à la rotation des équipes.
Aucune de ces mesures n’a quelque glamour que ce soit. Pourtant, elles font la différence entre un choix technique et une preuve judiciaire.
Acompagnez notre profil sur Instagram !
