Modèle de scoring qui discrimine : anatomie d'un sinistre à 80 000 €

Posons le décor. Un éditeur de logiciels RH vous confie en freelance le développement d'un modèle de scoring de candidatures : à partir des CV reçus, le système attribue un score de pertinence pour aider les recruteurs à prioriser les profils. Vous entraînez le modèle sur l'historique des recrutements passés de plusieurs entreprises clientes. Le modèle est performant, validé, mis en production. Mission accomplie, en apparence.

Six mois plus tard, un cabinet d'audit mandaté par l'un des utilisateurs finaux fait une découverte gênante : à compétences équivalentes, le modèle attribue systématiquement des scores plus faibles aux candidatures de femmes pour certains postes techniques. Pourquoi ? Parce que l'historique de recrutement sur lequel il a appris reflétait un déséquilibre passé. Le modèle n'a pas "décidé" de discriminer : il a fidèlement reproduit et amplifié un biais déjà présent dans les données.

C'est tout le piège du biais algorithmique. Il n'y a pas de ligne de code malveillante à pointer du doigt. Le système fait exactement ce pour quoi il a été optimisé. Et pourtant, le résultat est juridiquement et humainement problématique : une discrimination indirecte, potentiellement sanctionnable.

Le réflexe est de penser que c'est l'entreprise utilisatrice qui décide, donc qui assume. C'est en partie vrai sur le terrain de la décision finale. Mais sur le terrain de la conception du système, la chaîne de responsabilité remonte directement vers vous.

Voici comment se déroule la mise en cause :

• L'éditeur RH, votre client, est interpellé par son propre client final et doit corriger le système en urgence.
• Il analyse l'origine du défaut : un biais non détecté lors de la conception, faute d'audit d'équité sur les données d'entraînement.
• Il considère que vous avez manqué à votre obligation de diligence professionnelle : un ingénieur ML est censé connaître le risque de biais et le tester.
• Il vous adresse une réclamation pour les préjudices subis : coût de la refonte, immobilisation, atteinte à son image, voire indemnisation des personnes lésées.

La question juridique centrale n'est pas "avez-vous voulu discriminer ?" — évidemment non — mais "un professionnel diligent aurait-il dû détecter ce biais ?". Or, tester l'équité d'un modèle de scoring fait aujourd'hui partie de l'état de l'art. L'absence de ce test peut être qualifiée de faute de prestation, et c'est cette faute qui ouvre votre responsabilité.

Un argument de défense classique consiste à dire : "je n'ai fait qu'apprendre sur les données fournies par le client." Il a sa pertinence, mais il ne suffit pas à vous exonérer. Le devoir de l'ingénieur ML inclut une obligation d'alerte : si les données d'entraînement présentent un déséquilibre manifeste susceptible d'engendrer une discrimination, vous êtes censé le signaler à votre client. Avoir averti par écrit, ou au contraire être resté silencieux, pèse lourd dans l'appréciation de votre part de responsabilité.

Un sinistre de biais algorithmique n'a rien d'un petit litige. Il cumule plusieurs postes de coûts qui s'additionnent rapidement. Voici une estimation réaliste pour le scénario décrit :

Ce chiffre n'a rien d'extravagant. Les préjudices immatériels — perte d'exploitation du client, atteinte à sa réputation, coût d'opportunité — représentent souvent la part la plus lourde, et la plus difficile à anticiper. Pour un indépendant qui facture sa mission quelques dizaines de milliers d'euros, une réclamation de cet ordre est tout simplement hors de portée de la trésorerie.

Il faut aussi mesurer l'effet de temps long de ce type de dossier. Un biais peut rester invisible des mois, jusqu'à ce qu'un audit ou une plainte le révèle. Or la mission, elle, est terminée et facturée depuis longtemps. C'est pourquoi la reprise du passé dans votre contrat compte autant que le montant garanti : un sinistre déclaré aujourd'hui peut concerner un modèle livré l'an dernier. Sans garantie couvrant les réclamations postérieures à la mission, vous resteriez exposé sur des prestations que vous croyiez derrière vous.

C'est précisément la fonction d'une assurance RC Pro bien dimensionnée : elle prend en charge non seulement l'indemnisation due au client, mais aussi les frais de défense et les préjudices financiers immatériels, qui sont au cœur de ce type de dossier.

La bonne nouvelle, c'est qu'un sinistre de biais est largement évitable avec une méthode rigoureuse. La mauvaise, c'est qu'elle est encore trop souvent négligée par manque de temps ou de demande explicite du client. Voici les garde-fous qui font la différence :

1. Auditer les données d'entraînement avant tout. Identifier les déséquilibres et les variables corrélées à des caractéristiques protégées (genre, origine, âge) est la première ligne de défense.
2. Mesurer l'équité avec des métriques dédiées. Comparer les taux de faux positifs et de scores moyens entre groupes révèle les discriminations indirectes.
3. Documenter les limites du modèle. Une fiche signalant explicitement les risques de biais et les usages déconseillés vous protège juridiquement.
4. Prévoir une supervision humaine. Un score n'est pas une décision : le système doit laisser la main au recruteur.
5. Conserver les preuves de vos tests. Le jour de la réclamation, montrer que vous avez audité l'équité change radicalement la qualification de la faute.

Le test d'équité n'est pas une option de luxe : c'est, sur un modèle de scoring, le geste qui sépare le professionnel diligent du prestataire négligent aux yeux d'un juge.

Le biais algorithmique illustre une vérité inconfortable du métier : un ingénieur ML peut être de parfaite bonne foi, techniquement compétent, et pourtant exposé à un sinistre lourd. Le risque n'est pas le fruit d'une erreur grossière, mais d'un angle mort méthodologique sur un sujet qui devient ultra-sensible.

Deux protections se complètent :

• La prévention, par l'intégration systématique des tests d'équité et de la documentation des limites dans votre process. Elle réduit la probabilité du sinistre et constitue votre dossier de défense.
• La couverture financière, par une RC Pro adaptée aux métiers du numérique, qui absorbe le choc quand le sinistre survient malgré tout.

Pour le freelance, l'assurance d'un ingénieur machine learning doit explicitement couvrir les préjudices financiers immatériels causés au client par une faute de conception, car c'est là que se concentre le coût réel d'un sinistre de ce type. Une RC Pro qui ne couvrirait que les dommages matériels passerait à côté de l'essentiel. À mesure que les modèles prennent des décisions de plus en plus engageantes, ce risque ne fera que croître : mieux vaut être couvert avant le premier audit qui révèle un biais que vous n'aviez pas testé.