Avant d'intégrer un modèle d'IA dans un produit ou un processus décisionnel, je veux être sûr qu'il ne va pas amplifier des injustices ou générer des décisions erronées pour certains groupes. Voici la checklist technique que j'utilise — pragmatique, vérifiable et applicable quel que soit le fournisseur (open source, API cloud ou solution propriétaire). Je l'ai conçue pour les décideurs techniques et non techniques : vous pouvez la suivre vous-même ou l'exiger comme prérequis auprès d'une équipe ML ou d'un fournisseur.

Comprendre le contexte et définir les risques

La première étape, que beaucoup sautent, est de définir précisément ce que serait un "préjudice" dans votre contexte. Un modèle de recrutement peut discriminer sur le genre, un modèle de scoring de crédit sur l'origine géographique, un modèle de reconnaissance faciale sur la couleur de peau.

Je commence par ces questions :

  • Quel est l'usage final du modèle ?
  • Quelles sont les populations protégées ou sensibles ? (genre, âge, origine, handicap, etc.)
  • Quelles conséquences réelles peuvent résulter d'un biais ? (refus d'accès, exclusion, coûts financiers, atteinte à la réputation)

    • Audit des données d'entraînement

    Rien ne remplace une bonne exploration des données. J'effectue systématiquement un audit des datasets :

  • Vérifier la représentativité : distribution des classes et des caractéristiques démographiques.
  • Identifier les labels bruyants ou biaisés : qui a annoté, selon quelles règles ?
  • Rechercher les corrélations proxies : certaines variables apparemment innocentes (code postal, nom) peuvent proxyfier un attribut sensible.
  • Historique et dérive : les données reflètent-elles une réalité passée qui n'est plus pertinente ?

    • Pour cela, j'utilise des visualisations simples (histogrammes, heatmaps) et des tests statistiques (chi2 pour catégoriques, KS pour continues).

    Métriques de biais à calculer

    Il n'existe pas une métrique magique. Je calcule toujours un panel de mesures pour avoir une vue complète :

  • Disparate Impact (ratio de sélection entre groupes) — utile pour la conformité.
  • Statistical Parity Difference — différence de taux favorables entre groupes.
  • Equalized Odds / Equal Opportunity — comparer TPR/FPR entre groupes.
  • Calibration par groupe — les scores de probabilité doivent avoir le même sens pour tous.
  • Counterfactual fairness — vérifier si la prédiction change si on modifie uniquement l'attribut sensible dans un échantillon synthétique.

    • Je calcule ces métriques sur un ensemble de test séparé et, si possible, sur plusieurs sous-ensembles (régions, tranches d'âge, appareils).

    Tests pratiques et scénarios réels

    Les métriques globales sont utiles, mais j'aime confronter le modèle à des cas d'usage concrets :

  • Scénarios simulés : créer des paires identiques sauf pour l'attribut sensible (ex : deux CV identiques, un avec un prénom féminin, un masculin).
  • Tests de bord : performance sur données rares ou catégories sous-représentées.
  • Stress tests d'entrée : entrées malléables, adversariales ou malformées pour voir si le modèle réagit différemment selon le groupe.
  • Benchmarks externes : comparer avec modèles publics (ex : BERT finetuné, modèles fournis par AWS/GCP/Azure) pour détecter déviations étranges.

    • Interprétabilité et explications

    Je n'accepte pas une "boîte noire" sans explications. Les outils d'interprétabilité me permettent d'identifier si le modèle s'appuie sur des signaux non pertinents :

  • SHAP / LIME pour explicabilité locale — est-ce que les features importantes sont cohérentes ?
  • Feature importance globales — surveiller si des variables proxy émergent.
  • Analyse de clustering des erreurs — vérifier si certaines sous-populations subissent des erreurs systématiques.

    • Outils et bibliothèques que j'utilise

    Pour automatiser ces vérifications, j'intègre souvent des outils open source :

  • AI Fairness 360 (IBM) — métriques et mitigations.
  • Fairlearn (Microsoft) — visualisations et algorithmes d'atténuation.
  • What-If Tool (TensorBoard) — tests interactifs sans code.
  • SHAP/LIME — explications locales et globales.

    • Si je consomme une API commerciale (ex : OpenAI, Google Cloud), j'exige des model cards et des audits délivrés par le fournisseur.

    Mitigation et ré-entraînement

    Si je détecte un biais inacceptable, j'évalue plusieurs stratégies :

  • Rééquilibrage des données : sur-échantillonnage ou augmentation des groupes minoritaires.
  • Pré-processing : supprimer ou transformer les features proxy (par exemple, anonymisation de certains champs).
  • In-processing : modèles avec contraintes de fairness (ex : contraintes d'égalité de TPR).
  • Post-processing : ajuster les seuils par groupe pour aligner les métriques souhaitées.

    • Je documente toujours l'impact sur la performance globale : une correction qui casse la qualité produit peut être aussi nuisible qu'un biais non traité.

    Gouvernance, documentation et model cards

    Avant l'intégration, j'exige une documentation complète :

  • Model card : origine des données, métriques de performance et de fairness, limites connues.
  • Data provenance : qui a fourni les données et avec quelles conditions d'utilisation ?
  • Log des expérimentations : hyperparamètres, seeds, versions des librairies.
  • Plan de monitoring post-déploiement : métriques à surveiller, seuils d'alerte.

    • Monitoring en production

    Le biais peut surgir après le déploiement (dérive de données, changement d'usage). Mon plan de monitoring inclut :

  • Surveillance des distributions d'entrée (drift) et des performances par groupe.
  • Alerting automatique si une métrique de fairness passe sous un seuil prédéfini.
  • Collecte d'échantillons réels pour ré-audit périodique (mensuel/quotidien selon le risque).
  • Processus de rollback rapide ou de mise en quarantaine du modèle.

    • Checklist rapide (tableau)

    ÉtapeVérificationCritère
    Définition des risquesCas d'usage documentésOui/Non
    Audit donnéesReprésentativité & labelsPas d'échantillon majeur manquant
    MétriquesDisparate Impact, TPR/FPR par groupeConforme aux seuils internes
    Tests pratiquesScénarios pairs & stress testsPas d'écart significatif
    InterprétabilitéSHAP/LIME examinésFeatures explicables
    DocumentationModel card & provenanceComplète
    MonitoringPlan & alertesOpérationnel

    Cette checklist est celle que j'applique avant toute intégration. Elle n'est pas rigide : certains cas demandent des contrôles supplémentaires (santé, justice, finance). L'essentiel est d'avoir un processus reproductible, des seuils clairs et une gouvernance capable d'agir rapidement si le modèle montre des signes de biais en production.