Biais, explicabilité et model cards

En 2019, Apple et Goldman Sachs ont lancé une carte de crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →édit co-brandée. En quelques semaines, un développeur nommé David Heinemeier Hansson a tweeté que sa limite de crédit était 20 fois supérieure à celle de sa femme, malgré un score de crédit meilleur chez elle et une déclaration fiscale commune. Steve Wozniak a rapporté la même expérience. Le New York Department of Financial Services a ouvert une enquête. La défense de Goldman était révélatrice : « Il n'y a aucune variable de genre en entrée de l'algorithme. » Cette affirmation, techniquement vraie, constituait aussi tout le problème. La banque n'avait aucun moyen de démontrer l'*absence* de discrimination par proxy, aucune documentation du comportement du modèle selon les groupes protégés, et aucune revue avant déploiement qui aurait détecté des résultats disparates. Ce n'est pas le modèle qui a échoué. C'est la gouvernance autour de lui.

C'est là l'exposition réelle du CDO en IA. Vous serez rarement celui qui a écrit le code biaisé. Vous serez toujours celui à qui l'on demandera d'expliquer, sous serment ou sous un titre de presse, pourquoi personne n'a rien vu. Cette leçon porte sur la construction de la machinerie qui détecte le préjudice avant la mise en production.

L'équité est un choix, pas une métrique

La première chose à intégrer, et à enseigner à vos équipes, c'est qu'il n'existe pas de définition unique et universelle de « l'équité ». Ce n'est pas une esquive philosophique ; c'est un fait mathématique avec des conséquences opérationnelles.

Prenez un modèle de crédit. Vous pouvez optimiser la parité démographique (taux d'approbation égaux entre groupes), les equalized odds (taux de vrais positifs et de faux positifs égaux entre groupes) ou la calibration (une probabilité de remboursement prédite à 80 % signifie la même chose pour chaque groupe). Un résultat marquant, mis en lumière lors du débat sur l'algorithme de récidive COMPAS, a prouvé que lorsque les taux de base diffèrent entre groupes, vous *ne pouvez pas* satisfaire les trois simultanément. Optimiser l'un dégrade l'autre.

Cela signifie que l'équité est une décision business et éthique que le CDO doit mettre sur la table, pas déléguer aux réglages par défaut d'un data scientist. La mauvaise approche consiste à laisser l'équipe de modélisation choisir discrètement une métrique parce que c'est celle que sa bibliothèque implémente le plus facilement. La bonne approche est une décision documentée et transverse :

• Parité démographique quand vous avez une obligation positive d'égaliser l'accès (certains contextes de recrutement ou de prospection).
• Equalized odds quand c'est le coût des erreurs qui compte et qu'il doit être supporté également (triage médical, alertes de fraude).
• Calibration quand le score lui-même est consommé en aval comme une probabilité (tarification basée sur le risque).

Le travail du CDO est de faire asseoir le juridique, le business owner et l'équipe modèle dans une même pièce pour choisir, puis de consigner *pourquoi*. Quand le régulateur appelle, « nous avons choisi les equalized odds parce que les faux positifs exposent juridiquement le demandeur, et voici la note de décision signée » est une position défendable. « La bibliothèque l'avait par défaut » ne l'est pas.

Chasser les proxys

Supprimer l'attribut protégé, « il n'y a aucune variable de genre en entrée », est pire qu'inutile, car cela crée une fausse confiance pendant que les proxys font la discrimination. Le code postal encode l'origine. Les catégories d'achat encodent le genre. L'établissement d'origine et le prénom encodent les deux. Un modèle privé de la variable sensible la reconstruira volontiers à partir d'entrées corrélées.

La technique pratique est la détection de proxys : entraînez un modèle secondaire à prédire l'attribut protégé à partir de votre jeu de features. S'il y parvient avec une précision élevée, vos features laissent fuiter l'attribut, et votre modèle « aveugle » ne l'est pas. Vous devez alors soit retirer les features en cause, soit recourir au dé-biaisage adversarial, soit, point critique, *conserver* l'attribut protégé en votre possession précisément pour mesurer l'impact disparate. On ne peut pas auditer ce qu'on refuse de collecter. Beaucoup d'organisations font l'inverse : elles suppriment les données démographiques au nom de la « vie privée » et rendent ainsi toute mesure de biais impossible.

Explicabilité : adapter l'explication au destinataire

L'explicabilité échoue dans la plupart des organisations parce que les équipes la traitent comme un livrable unique. Elle ne l'est pas. Il y a au moins trois audiences distinctes, chacune ayant besoin d'un artefact différent.

Le régulateur ou l'auditeur a besoin d'explicabilité *globale* : comment le modèle se comporte-t-il sur l'ensemble de la population ? Quelles features pilotent les décisions en agrégé ? La logique est-elle stable et non arbitraire ?

La personne concernée a besoin d'explicabilité *locale* et actionnable : « Votre demande a été refusée parce que votre ratio dette/revenu était de 47 % alors que notre seuil est de 40 % ; le ramener sous 40 % changerait la décision. » C'est une exigence légale au titre de l'Equal Credit Opportunity Act américain (notifications d'action défavorable) et du « droit à l'explication » du RGPDRGPDRèglement de l'UE encadrant la collecte, le stockage et l'usage des données personnelles, avec des amendes indexées sur le chiffre d'affaires mondial.Voir la définition complète → européen. Notez le mot *actionnable* : un graphique de valeurs SHAP n'est pas une raison sur laquelle un humain peut agir.

Le model owner interne a besoin d'explicabilité de *debugging* : où le modèle est-il fragile, où s'appuie-t-il sur des corrélations fallacieuses, où échouera-t-il en cas de dérive de distribution ?

Les outils dominants sont SHAP (attributionattributionUn framework qui attribue le crédit d'une conversion aux différents touchpoints y ayant contribué, afin de mesurer quels canaux et quelles interactions génèrent réellement des résultats.Voir la définition complète → de features issue de la théorie des jeux, solide en global comme en local, coûteux en calcul) et LIME (approximations locales rapides, moins cohérentes). Le CDO n'a pas à choisir l'algorithme. Le CDO doit exiger que chaque audience reçoive un artefact adapté à son usage, et que « l'explication » fournie à un demandeur refusé soit une raison lisible par un humain, pas une visualisation de data science.

Une mise en garde à placer devant vos équipes : les explications post-hoc peuvent être *trompeuses*. SHAP sur une boîte noire vous dit ce à quoi le modèle est corrélé, pas pourquoi, et des adversaires peuvent même manipuler les méthodes d'explication. Pour des décisions réellement à fort enjeu, un modèle intrinsèquement interprétable (un modèle de gradient boosting monotone, une grille de score) l'emporte souvent sur une boîte noire assortie d'une explication à laquelle on ne peut pas se fier entièrement. L'interprétabilité par conception est un choix d'architecture légitime, et parfois le choix responsable.

Model cards : la documentation qui rend la revue possible

Une model card est un document court et standardisé, proposé par des chercheurs de Google menés par Margaret Mitchell, qui accompagne chaque modèle en production. Voyez-la comme l'étiquette nutritionnelle : elle oblige l'équipe à déclarer, avant déploiement, à quoi sert le modèle, comment il performe, et où il ne doit *pas* être utilisé.

La raison pour laquelle un CDO doit imposer les model cards n'est pas la documentation pour elle-même. C'est que *l'acte de remplir la carte* fait remonter les défaillances. Une équipe qui doit écrire « usage prévu » est forcée de nommer les limites. Une équipe qui doit reporter la performance *désagrégée par sous-groupe* ne peut pas dissimuler un modèle qui fonctionne bien globalement mais échoue pour une population. La carte est un mécanisme de contrainte, pas une formalité.

Une model card minimale et opposable contient :

model_card:
  model_name: credit_line_assignment_v3.2
  owner: risk_ml_team
  date: 2024-11-01
  intended_use: "Assign initial credit limits for approved applicants."
  out_of_scope_use: "NOT for approve/deny decisions. NOT for existing-customer limit changes."
  training_data: "18 months applicant data; excludes pre-2022 (policy change)."
  fairness_metric_chosen: equalized_odds
  performance:
    overall_auc: 0.84
    disaggregated:
      - group: female,   approval_rate: 0.61, fpr: 0.09
      - group: male,     approval_rate: 0.63, fpr: 0.10
  known_limitations: "Underperforms for thin-file applicants (<2yr history)."
  human_review_trigger: "Any limit >5x median for applicant income band."
  approved_by: [cdo_office, legal, model_risk]

Observez ce que cette structure impose. Le champ out_of_scope_use aurait signalé le problème de l'Apple Card : un modèle conçu pour un usage auquel on en confie un autre. La performance disaggregated aurait exposé un écart de genre avant le lancement. Le human_review_trigger intègre un coupe-circuit dans le déploiement lui-même.

Faites de la carte une condition de merge. Un modèle sans carte complétée et signée ne se déploie pas, contrainte appliquée dans le pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète → CI/CD, pas dans un PDF de politique que personne ne lit. Quand la documentation est un point de passage obligé, elle est écrite. Quand c'est une « bonne pratique », elle ne l'est pas.

Construire le processus de revue qui détecte le préjudice

Les frameworks sont inertes sans un processus qui les applique. Voici le modèle opérationnel qu'un CDO installe, et les modes de défaillance honnêtes contre lesquels concevoir.

Étagez la revue par le risque, pas par l'équipe

Ne revoyez pas tous les modèles de la même façon ; vous serez noyé et vos meilleurs éléments se mettront à tamponner sans lire. Adoptez un tiering du risque aligné sur la logique de l'EU AI Act, qui devient le standard mondial :

• Interdit / inacceptable : ne le construisez pas (notation sociale, systèmes manipulatoires).
• Risque élevé : modèles affectant le crédit, l'emploi, la santé, le logement, les services essentiels. Traitement complet : model card obligatoire, audit d'équité sur la métrique choisie, human-in-the-loop, validation indépendante.
• Risque limité : outils d'efficacité interne, classement de contenus. Carte allégée, auto-certification, audits ponctuels.
• Risque minimal : filtres anti-spam, recherche interne. Enregistrez et passez à la suite.

Le CDO définit la grille de tiering pour qu'une équipe ne puisse pas auto-classer un modèle à risque élevé en risque limité afin d'échapper au contrôle. La classification est revue par votre bureau, pas par celui qui construit.

Séparez les constructeurs des relecteurs

C'est le principe structurel le plus important, emprunté directement au model risk management bancaire (SR 11-7). L'équipe qui construit le modèle ne peut pas être celle qui l'approuve. Il vous faut une fonction de validation indépendante, qui vous reporte à vous, et non à la ligne business dont le chiffre d'affaires dépend de la mise en production du modèle. Dans une organisation plus petite, cela peut être une personne plus un auditeur externe sous contrat ; le principe tient quelle que soit la taille. C'est l'indépendance qui transforme la revue de théâtre en contrôle.

Faites de la revue un gate, puis une boucle

La revue avant déploiement est nécessaire mais insuffisante, parce que les modèles se dégradent. Un modèle équitable au lancement dérive à mesure que la population change. Votre processus a besoin de deux horloges :

1. Le gate : aucun modèle à risque élevé ne se déploie sans carte complétée, audit d'équité sur la métrique choisie et validation indépendante. C'est binaire et appliqué dans le pipeline.
2. La boucle : monitoring en production de la dérive de performance *et* de la dérive d'équité, avec des métriques désagrégées recalculées mensuellement sur les données live. Un human_review_trigger et un seuil de rollback automatique sont configurés avant le lancement, pas après un incident.

Le mode de défaillance contre lequel concevoir est le schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → launch-and-forget, où toute l'énergie de gouvernance va dans le gate et aucune dans la boucle. La plupart des préjudices IA rendus publics, y compris des résultats biaisés qui apparaissent des mois après le lancement, sont des défaillances de dérive, pas de lancement.

Le chemin d'escalade doit avoir des dents

Un comité de revue qui ne peut que *recommander* est un comité de revue qu'un VPVPFormulation claire des bénéfices apportés par votre produit, des problèmes qu'il résout et des raisons pour lesquelles les clients doivent vous choisir plutôt qu'une alternative.Voir la définition complète → avec un objectif trimestriel contourne. Le CDO doit obtenir, par écrit, du CEO ou du board, l'autorité de bloquer le déploiement d'un modèle à risque élevé. Sans cela, tout ce qui précède documente votre propre impuissance. L'épisode de l'Apple Card a coûté à Goldman une surveillance réglementaire et de la réputation précisément parce que l'incitation à livrer a pris le pas sur la discipline de revue. Votre travail est de faire de « nous l'avons bloqué » un acte de carrière survivable pour ceux qui lèvent la main.

Points clés à retenir

• Mettez la décision d'équité sur la table. Vous ne pouvez pas satisfaire à la fois la parité démographique, les equalized odds et la calibration. Réunissez le business, le juridique et la modélisation pour en choisir une, documentez pourquoi, et conservez la note signée : cette note est votre défense réglementaire.

• Ne supprimez jamais l'attribut protégé ; servez-vous-en pour auditer. Retirer les features sensibles crée une fausse confiance pendant que les proxys discriminent. Faites tourner des modèles de détection de proxys et conservez les données démographiques précisément pour mesurer l'impact disparate.

• Livrez des explications adaptées à l'audience. Les régulateurs ont besoin de la logique globale, les individus de raisons actionnables d'action défavorable, les model owners de vues de debugging. Pour les décisions à plus fort enjeu, envisagez un modèle intrinsèquement interprétable plutôt qu'une boîte noire que vous ne pouvez qu'approximer.

• Faites de la model card un gate du pipeline, pas une politique. Imposez une carte signée avec performance désagrégée, limites d'usage hors périmètre et déclencheurs de revue humaine comme condition de merge. Un modèle sans carte ne se déploie pas.

• Séparez constructeurs et relecteurs, gate plus boucle. Installez une validation indépendante qui vous reporte, étagez la revue par le risque, surveillez la dérive d'équité en production et sécurisez par écrit l'autorité de bloquer un déploiement. Une revue qui ne peut que recommander est du théâtre.