L'algorithme qui a refusé un logement à des femmes noires — et ce qu'il m'a appris sur la construction d'une IA qui ne peut rien cacher

J'étais assis dans mon bureau à domicile un mardi soir, en parcourant les documents définitifs de règlement dans l'affaire Louis et al. c. SafeRent Solutions, LLC, lorsqu'un simple détail m'a glacé.

Mary Louis et Monica Douglas — deux femmes noires détentrices de bons de logement financés par l'État fédéral — s'étaient vu refuser des appartements. Non pas par un propriétaire qui les avait regardées dans les yeux pour dire non. Par un score. Un nombre compris entre 200 et 800, généré par un algorithme baptisé « Registry ScorePLUS », qui décidait qu'elles présentaient un risque trop élevé pour être logées. L'algorithme ne savait pas qu'elles étaient noires. Il n'en avait pas besoin. Il savait seulement que leurs antécédents de crédit ressemblaient aux antécédents de crédit de personnes systématiquement exclues des systèmes financiers depuis des générations — et il appelait cela un « risque ».

Le règlement s'élevait à 2,275 millions de dollars. L'injonction dure cinq ans. Et la décision contenait une phrase que j'ai relue trois fois parce que je n'arrivais pas à croire qu'un tribunal fédéral l'ait réellement dit : si un propriétaire s'appuie principalement sur un score d'IA tiers pour prendre des décisions de logement, l'entreprise qui a conçu le score partage la responsabilité au titre du Fair Housing Act.

J'ai refermé mon ordinateur portable et je suis resté là, dans le noir, un bon moment. Parce que cette décision n'a pas seulement transformé le secteur du filtrage des locataires. Elle a transformé tout le calcul de ce que signifie construire de l'IA pour des marchés réglementés. Et elle a validé quelque chose que mon équipe chez Veriprajna défendait — parfois face à des investisseurs sceptiques, parfois jusqu'à notre propre épuisement — depuis des années : la façon dont la plupart des entreprises déploient l'IA dans des décisions à fort enjeu n'est pas seulement discutable sur le plan éthique. Elle est architecturalement défaillante.

Qu'est-ce qui a réellement mal tourné dans l'algorithme de SafeRent ?

La défaillance technique est trompeusement simple à décrire et exaspérément difficile à corriger sans repenser entièrement votre approche de la conception des modèles.

Le système de notation de SafeRent s'appuyait fortement sur les antécédents de crédit traditionnels et les dettes non liées à la location — des choses comme les factures médicales, les vieux soldes de cartes de crédit, le genre de cicatrices financières qui s'accumulent quand on a passé des années à naviguer dans la pauvreté. Ce qu'il ne prenait pas en compte, c'était le fait le plus pertinent au sujet de ses sujets : les détenteurs de bons de choix de logement disposent d'un flux de revenus garanti provenant du gouvernement fédéral. Leur loyer est subventionné. Leur probabilité de manquer un paiement est, statistiquement, assez différente de ce que suggérerait un score de crédit brut.

Mais le modèle ne le savait pas. Ou plus précisément, personne ne lui avait dit d'en tenir compte.

L'algorithme n'a pas discriminé volontairement. Il a discriminé par conception — en traitant des données historiquement biaisées comme une vérité neutre.

C'est là que les chiffres deviennent accablants. En octobre 2021, le score de crédit médian des consommateurs blancs était de 725. Pour les consommateurs hispaniques, 661. Pour les consommateurs noirs, 612. Lorsqu'on construit un modèle qui traite le score de crédit comme un prédicteur principal du « risque de performance du bail », on ne fait pas un choix mathématique neutre. On encode un siècle de redlining, de prêts prédateurs et d'inégalités patrimoniales dans un seul poids de caractéristique. L'algorithme de SafeRent a regardé les antécédents de crédit de Mary Louis et y a vu un risque. Ce qu'il aurait dû voir, c'était une femme disposant d'un loyer garanti et un système qui ne lui avait jamais donné une réelle chance de se constituer un crédit.

Pourquoi un tribunal a-t-il déclaré le fournisseur de logiciels responsable ?

C'est la partie qui devrait empêcher tout fondateur d'entreprise d'IA de dormir la nuit.

SafeRent a tenté la défense évidente : nous sommes un fournisseur de technologie, pas un propriétaire. Nous ne prenons pas de décisions de logement. Nous fournissons simplement de l'information. Le tribunal a rejeté cet argument catégoriquement. Le ministère de la Justice a déposé une déclaration d'intérêt soutenant que lorsqu'un propriétaire externalise sa prise de décision à un algorithme, le développeur de cet algorithme fait fonctionnellement partie de la chaîne de décision.

Réfléchissez un instant à ce que cela signifie. Toute entreprise vendant de la notation, du filtrage, de la souscription ou de l'évaluation des risques alimentés par l'IA sur un marché réglementé vient de perdre la capacité de dire « nous n'avons fait que construire l'outil ».

Je me souviens de la conversation avec mon cofondateur la semaine suivant l'annonce de la décision. Nous étions en visioconférence, censés examiner un livrable client, et à la place nous avons passé quarante-cinq minutes à cartographier chaque secteur où ce précédent pourrait s'appliquer. La notation de crédit. La souscription d'assurance. Le filtrage à l'embauche. Le triage médical. La liste ne cessait de s'allonger. À un moment, l'un de nous a dit : « Ce n'est pas une affaire de logement. C'est le début du droit de la responsabilité du fait des produits d'IA. » Nous ne célébrions pas — nous avions mis en garde contre ce scénario précis — mais il y avait une satisfaction amère à voir le système juridique enfin rattraper ce que la technologie faisait sans contrôle.

Le règlement n'a pas seulement coûté 2,275 millions de dollars à SafeRent. Il a imposé une injonction de cinq ans qui a du mordant :

SafeRent ne peut plus émettre de recommandations automatisées d'approbation ou de refus pour les détenteurs de bons à moins que le modèle ne soit validé sur le plan de l'équité par des experts indépendants des droits civiques. Sans cette validation, le système ne peut fournir que des informations de fond brutes — dépouillées de sa notation prédictive. L'entreprise doit également former ses clients aux limites des modèles de notation pour les populations subventionnées. Et ces conditions s'appliquent à l'échelle nationale, pas seulement dans le Massachusetts.

Pour un examen plus approfondi de la structure du règlement et de ses implications réglementaires, j'ai rédigé une analyse interactive détaillée de l'affaire complète.

Le piège du wrapper LLM

Environ un an avant que le règlement SafeRent ne soit finalisé, j'ai eu une réunion avec un client potentiel — une société de gestion immobilière de taille moyenne exploitant environ 12 000 logements dans le Sud-Est. Ils avaient été démarchés par un fournisseur proposant une « solution de filtrage des locataires alimentée par l'IA » construite sur un grand modèle de langage. L'argumentaire était léché : traitement du langage naturel, résumés de risque instantanés, tableaux de bord superbes. Le fournisseur avait levé une série A. Ils avaient des logos sur leur site web.

J'ai posé une seule question : « Le système peut-il expliquer, pour un candidat précis, quelles caractéristiques ont motivé la décision de refus d'une manière qui satisfasse les exigences de notification d'action défavorable du Fair Credit Reporting Act ? »

Silence. Puis : « Nous pouvons générer une explication en langage naturel de la décision. »

« Générée par le LLM ? »

« Oui. »

« Donc l'explication est un récit plausible sur les raisons pour lesquelles la personne a été refusée, et non une trace causale vérifiée du calcul réel du modèle ? »

Encore du silence.

C'est le problème fondamental de ce que j'appelle les « wrappers LLM » — et c'est le problème que l'affaire SafeRent a mis en lumière dans un détail brutal et coûteux. Un grand modèle de langage peut résumer un contrat de bail. Il peut rédiger une lettre. Il peut même produire une explication convaincante des raisons pour lesquelles un candidat a été rejeté. Mais il ne peut pas certifier que son raisonnement est causalement lié au véritable cheminement décisionnel. Il ne peut pas prouver qu'une caractéristique protégée n'a pas influencé le résultat. Il ne peut pas rechercher d'alternatives moins discriminatoires. Il hallucine des explications de la même manière qu'il hallucine tout le reste — en prédisant le prochain jeton statistiquement le plus probable.

Dans les décisions à fort enjeu, la capacité de générer une réponse plausible ne vaut rien. La capacité d'en prouver une équitable vaut tout.

Des investisseurs m'ont dit : « Utilise simplement GPT et ajoute une couche de conformité par-dessus. » L'un me l'a dit en face lors d'un événement de pitch, comme si c'était évident, comme si nous compliquions les choses à l'excès. J'aurais voulu lui tendre les documents de règlement de SafeRent et lui demander quelle couche de conformité aurait détecté un modèle qui ignorait systématiquement les revenus des bons. La réponse est aucune d'entre elles. Parce que le biais n'était pas dans le formatage de la sortie ni dans l'interface utilisateur. Il était dans les poids des caractéristiques. Il était dans les données d'entraînement. Il était dans l'architecture fondamentale de ce que le modèle était optimisé pour prédire.

En quoi les directives 2024 du HUD changent-elles la donne ?

En mai 2024, le HUD a publié des directives qui ont concrètement codifié les leçons de l'affaire SafeRent en attentes réglementaires pour l'ensemble du secteur du logement. La norme est celle de l'« impact disparate » — ce qui signifie qu'un système peut être illégal même si personne n'avait l'intention de discriminer, dès lors qu'il produit des effets négatifs disproportionnés sur une classe protégée qui ne peuvent être justifiés par un intérêt légitime et non discriminatoire.

Trois exigences se démarquent :

La pertinence des caractéristiques doit être causale, et non simplement corrélationnelle. Chaque point de données d'un modèle de filtrage doit avoir un lien défendable avec la performance réelle du bail. « Le score de crédit prédit le défaut » n'est pas suffisant si le score de crédit est un proxy de la race et que vous n'avez pas testé si le revenu ajusté par les bons est un meilleur prédicteur.

Les candidats doivent disposer d'une voie concrète pour contester les résultats de l'IA. Cela signifie que l'examen avec intervention humaine n'est pas optionnel — il est obligatoire. Un système qui produit un score sans mécanisme de recours est un système qui attend d'être poursuivi.

Les développeurs doivent rechercher des Alternatives Moins Discriminatoires. C'est la disposition qui change tout. Il ne suffit pas de construire un modèle qui fonctionne. Vous devez démontrer que vous avez cherché des modèles qui fonctionnent tout aussi bien avec un impact moins discriminatoire — et soit les avoir adoptés, soit pouvoir prouver qu'aucun n'existe.

Cette dernière exigence — l'Alternative Moins Discriminatoire, ou AMD — est là où la plupart des entreprises d'IA que j'ai vues s'effondrent. Non pas parce que les mathématiques sont impossiblement difficiles, mais parce qu'elles n'ont jamais été contraintes de le faire. Elles optimisent pour la précision. Elles livrent. Elles passent à autre chose. L'idée que vous pourriez avoir besoin de parcourir des milliers de configurations de modèles alternatives pour en trouver une qui maintienne la performance tout en maximisant l'équité entre les groupes démographiques ? Ce n'est pas une demande de fonctionnalité que la plupart des chefs de produit ont jamais reçue.

Ce que nous construisons réellement à la place

Je dois être honnête à propos d'une chose : lorsque nous avons commencé à construire des systèmes soucieux de l'équité chez Veriprajna, nous nous sommes trompés.

Notre approche initiale était l'audit a posteriori. Construire le modèle, le tester pour détecter les biais, ajuster les seuils si quelque chose semblait anormal. Cela semblait responsable. Cela semblait suffisant. Ça ne l'était pas.

Le problème du post-traitement, c'est que vous essayez de rapiécer les résultats sans en comprendre les causes. Vous pouvez ajuster un seuil de décision de sorte que les taux d'approbation paraissent similaires entre les groupes — une technique appelée « Equalized Odds » — mais si le modèle sous-jacent a appris une représentation biaisée du risque, vous ne faites que maquiller un problème structurel. Le modèle pense toujours que certaines personnes sont plus risquées. Vous ne faites que le surpasser au dernier kilomètre. Et la première fois que quelqu'un audite les importances des caractéristiques, le biais est là, à vous regarder droit dans les yeux.

La percée — et j'emploie ce mot avec précaution, parce que cela ressemblait davantage à une lente et frustrante accumulation d'échecs qu'à un moment d'illumination — est survenue lorsque nous avons commencé à traiter l'équité comme une contrainte d'optimisation plutôt que comme un audit après déploiement.

Voici ce que cela signifie en pratique. Pendant l'entraînement du modèle, nous ne nous contentons pas de minimiser l'erreur de prédiction. Nous pénalisons simultanément le modèle si un réseau « adverse » secondaire peut prédire un attribut protégé (comme la race ou le genre) à partir des sorties du modèle principal. Si l'adversaire réussit — s'il peut regarder les prédictions du modèle et deviner qui est noir et qui est blanc — le modèle principal est pénalisé et réentraîné. Le résultat est un modèle qui a été contraint d'apprendre des caractéristiques véritablement indépendantes des caractéristiques protégées.

Nous associons cela à ce que les chercheurs appellent le « test contrefactuel ». Pour chaque candidat que le modèle évalue, nous posons la question : si la race de cette personne était différente mais que tout le reste demeurait identique, la décision changerait-elle ? Si la réponse est oui, le modèle échoue. Pas « signalé pour examen ». Il échoue.

L'équité contrefactuelle pose la question que tout avocat des droits civiques finira par poser : cette personne aurait-elle été approuvée si elle avait été blanche ? Votre modèle a intérêt à donner la même réponse.

Il y a eu une nuit — je crois que c'était vers 2 heures du matin — où nous avons effectué notre premier audit contrefactuel complet sur un prototype de modèle de filtrage que nous avions construit à partir d'un jeu de données de logement public. Nous nous attendions peut-être à un écart de 3 à 4 %. Le chiffre réel était plus proche de 11 %. Onze pour cent des décisions se seraient inversées si nous ne changions rien d'autre que le groupe démographique. Mon ingénieur m'a envoyé un message Slack qui disait simplement : « Nous avons un problème. » Nous avons passé les trois semaines suivantes à reconstruire de zéro le pipeline de caractéristiques, en remplaçant le score de crédit par un indicateur composite qui pondérait le revenu des bons, l'historique des paiements de loyer directs et la stabilité de l'emploi. L'écart contrefactuel est tombé sous 1 %.

C'est la différence entre ce que j'appelle la « Deep AI » et un wrapper LLM. Il ne s'agit pas d'avoir de meilleurs prompts ou une interface plus jolie. Il s'agit de savoir si l'équité est une propriété de l'architecture du système ou un autocollant que vous mettez sur la boîte.

Pour la présentation technique complète de notre approche d'ingénierie de l'équité — y compris la méthodologie de débiaisage adverse et la formalisation mathématique des métriques que nous utilisons — consultez notre article de recherche sur l'intégrité algorithmique et le risque d'entreprise.

Pourquoi ne pas simplement auditer après le déploiement ?

Les gens me posent constamment cette question, et j'en comprends l'attrait. L'audit paraît moins coûteux. Il paraît moins perturbateur. Vous construisez vite, livrez vite, auditez plus tard, corrigez ce qui casse.

Le problème, c'est que sur les marchés réglementés, « ce qui casse », ce sont des vies humaines.

Au moment où l'algorithme de SafeRent a été contesté en justice, il fonctionnait depuis des années. Combien de Mary Louis y avait-il qui n'ont jamais intenté de procès ? Combien de familles détentrices de bons se sont vu refuser un logement par un algorithme incapable de voir au-delà de leur score de crédit ? Ces refus ne sont pas annulés par un règlement. Ces appartements sont allés à quelqu'un d'autre. Ces familles ont trouvé un endroit pire où vivre, ou n'ont trouvé nulle part du tout.

Les audits statiques passent aussi à côté de quelque chose de crucial : la dérive des données. Les schémas socioéconomiques qu'un modèle a appris pendant l'entraînement évoluent au fil du temps. Les taux d'utilisation des bons changent. Les méthodologies de notation de crédit évoluent. Les marchés locatifs se resserrent ou se détendent. Un modèle qui était « suffisamment équitable » en 2022 pourrait être discriminatoire en 2024 — non pas parce que quelqu'un a changé le code, mais parce que le monde a changé autour de lui.

C'est pourquoi nous avons évolué vers une surveillance continue avec des déclencheurs de réentraînement automatisés. Le modèle n'est pas simplement audité une fois par an. Il est audité chaque fois qu'il prend une décision, face à une batterie de métriques d'équité — Statistical Parity Difference, Disparate Impact Ratio, Equalized Odds — s'exécutant en temps réel. Lorsqu'une métrique dérive au-delà d'un seuil, le système la signale avant même qu'un humain ne voie la sortie.

Je vois cela ainsi : vous ne construiriez pas un pont, ne l'inspecteriez qu'une seule fois, puis ne le vérifieriez plus jamais. Vous le surveilleriez en continu pour détecter les contraintes, la fatigue, les changements environnementaux. Les systèmes d'IA qui prennent des décisions sur le logement, le crédit et l'emploi des gens méritent au moins la même rigueur d'ingénierie que celle que nous accordons au béton et à l'acier.

Que signifie le règlement sur l'IA de l'UE pour les entreprises américaines ?

Si le règlement SafeRent et les directives du HUD représentent le plancher réglementaire actuel, le règlement sur l'IA de l'UE — dont l'application progressive commence en 2025-2026 — représente la direction que prend le plafond.

Le règlement classe les systèmes d'IA utilisés pour la notation de crédit, le filtrage des locataires et les décisions d'emploi comme « à haut risque », les soumettant à des évaluations de conformité obligatoires, à des exigences de transparence et à des obligations de supervision humaine. Les entreprises américaines qui servent les marchés européens, ou qui servent les marchés américains d'une manière qui intéresse les régulateurs européens, devront s'y conformer.

Mais voici ce que je trouve plus intéressant que les exigences spécifiques : le règlement de l'UE opérationnalise les quatre piliers du NIST AI Risk Management Framework — Govern, Map, Measure, Manage — en obligations juridiquement contraignantes. Ce qui était une directive volontaire devient une pratique obligatoire. Les entreprises qui ont aligné tôt leurs architectures sur ces principes trouveront la conformité simple. Les entreprises qui ont traité l'équité comme un argument marketing la trouveront coûteuse.

J'ai vu ce schéma se dérouler dans la protection des données (RGPD), l'information financière (SOX), et maintenant la gouvernance de l'IA. La trajectoire réglementaire ne se déplace que dans une seule direction. Construire pour les exigences de demain dès aujourd'hui n'est pas de l'idéalisme. C'est de la gestion des risques.

Le problème de la multiplicité des modèles dont personne ne parle

Il existe un concept dans la recherche en apprentissage automatique appelé « multiplicité des modèles » — l'observation selon laquelle, pour tout jeu de données donné, il existe potentiellement des millions de modèles qui atteignent une précision presque identique mais présentent des profils d'équité radicalement différents. Certains de ces modèles sont profondément biaisés. Certains sont remarquablement équitables. Et sans une recherche explicite et systématique des modèles équitables, les développeurs se rabattront presque toujours sur celui que l'optimiseur trouve en premier.

C'est le fondement technique de l'exigence d'Alternative Moins Discriminatoire, et c'est pourquoi je crois que la recherche d'AMD deviendra la capacité la plus importante du développement d'IA réglementée au cours de la prochaine décennie.

Lorsque nous menons une recherche d'AMD, nous n'entraînons pas un seul modèle. Nous en entraînons des centaines, en faisant varier les ensembles de caractéristiques, les architectures, les hyperparamètres et les contraintes d'équité, puis nous cartographions tout le paysage des compromis précision-équité. L'objectif est de trouver le modèle qui atteint l'objectif métier — prédire la performance du bail, évaluer le risque de crédit, quelle que soit la tâche — avec l'impact discriminatoire minimal possible.

Parfois, cette recherche révèle quelque chose d'inconfortable : le modèle « le plus précis » est aussi le plus biaisé, parce que la précision et le biais historique sont corrélés dans les données d'entraînement. Le deuxième modèle le plus précis pourrait sacrifier un demi-point de pourcentage de pouvoir prédictif tout en réduisant de 40 % l'écart du Disparate Impact Ratio. Ce compromis en vaut-il la peine ?

Si votre modèle est 0,5 % moins précis mais 40 % moins discriminatoire, et que vous avez choisi la précision — bonne chance pour l'expliquer à un juge.

Dans l'affaire SafeRent, la question fondamentale était de savoir si un modèle aurait pu prédire la performance du bail tout aussi bien sans pénaliser les détenteurs de bons. La réponse, d'après tout ce que nous savons des données, est presque certainement oui. SafeRent n'a simplement jamais cherché.

La nuit où j'ai failli accepter de construire un wrapper

Je veux terminer avec une histoire que je n'ai jamais racontée publiquement auparavant.

Il y a environ dix-huit mois, nous avons été approchés par une entreprise — je ne la nommerai pas — qui voulait que nous construisions un outil de filtrage de conformité pour un grand client de services financiers. Le budget était conséquent. Le calendrier était agressif. Et le cahier des charges qu'ils nous ont remis était, essentiellement, un wrapper LLM : prendre un modèle de fondation, l'affiner sur des documents réglementaires, ajouter une couche de notation, livrer.

Mon équipe était divisée. La moitié voyait le chiffre d'affaires. L'autre moitié voyait l'affaire SafeRent au ralenti. Nous avons eu un appel qui a duré près de trois heures. L'un de mes ingénieurs — quelqu'un en qui j'ai profondément confiance — a dit quelque chose qui m'est resté : « Nous pouvons construire ce qu'ils demandent en huit semaines. Nous pouvons construire ce dont ils ont besoin en huit mois. Si nous construisons ce qu'ils demandent, nous devenons la prochaine étude de cas sur les raisons de l'échec de cette approche. »

Nous avons renoncé à l'accord. Ce fut la décision la plus coûteuse que j'aie prise en tant que fondateur. Je l'ai remise en question pendant des semaines.

Je ne la remets plus en question.

Le règlement SafeRent a prouvé que le marché de l'IA dans les secteurs réglementés n'est pas une course à celui qui livre le plus vite. C'est une course à celui qui livre le plus sûrement — où « sûr » signifie architecturalement équitable, juridiquement défendable, et conçu pour résister au type d'examen médico-légal qu'un tribunal fédéral finira par appliquer. Les entreprises qui comprennent cela construiront les systèmes qui durent. Les entreprises qui ne le comprennent pas construiront la prochaine mise en garde à 2,275 millions de dollars.

L'ère de la boîte noire est révolue. Non pas parce que les régulateurs l'ont tuée, mais parce qu'elle n'a jamais été conçue pour survivre au contact de la réalité. La question n'est pas de savoir si votre IA peut prendre une décision. C'est de savoir si votre IA peut en défendre une.