La checklist avant déploiement : red-teaming de l'IA publique

En 2023, un service d'urbanisme de l'Ohio a discrètement déployé un outil d'IA pour pré-filtrer les permis de rénovation de logements. En quelques semaines, les habitants d'un code postal recevaient des refus automatiques à un taux presque triple de celui d'un quartier plus aisé de la même ville, pour le même type de demande. Personne n'avait testé ce scénario avant le lancement. Cette leçon parcourt la checklist qui aurait dû exister, en prenant une IA de délivrance de permis comme cas d'étude fil rouge.

Pourquoi l'IA de permis est le stress test idéal

Les décisions de permis (permis de construire, licences d'activité, dérogations de zonage) se situent à une intersection sensible : gros volumes, suffisamment fondées sur des règles pour donner envie d'automatiser, mais suffisamment lourdes de conséquences pour qu'une mauvaise décision bloque la rénovation d'un logement ou les moyens de subsistance de quelqu'un.

Cela fait de l'IA de permis une bonne loupe pour l'ensemble de la boîte à outils de gouvernance avant déploiement. La même checklist s'applique à l'éligibilité aux prestations sociales, à la détection de fraude ou au scoring de risque en justice pénale.

Aux États-Unis, les déploiements d'IA publique relèvent aujourd'hui généralement de frameworks de gouvernance propres à chaque agence, issus du mémorandum M-24-10 (2024) de l'Office of Management and Budget (OMB) de la Maison-Blanche, qui exige des agences fédérales de désigner des Chief AI Officers et de mener des risk assessments pour les IA « rights-impacting », catégorie qui inclut explicitement les décisions de permis et de licences. En Europe, l'EU AI Act (entré en vigueur en 2024, obligations échelonnées jusqu'en 2027) classe les systèmes qui déterminent l'accès aux services publics comme « à haut risque », ce qui déclenche des évaluations de conformité obligatoires avant déploiement.

Porte 1 : définir la décision que l'IA a réellement le droit de prendre

Avant qu'un modèle ne touche la moindre donnée, écrivez précisément ce que le système décide et ne décide pas.

Dans notre cas : l'IA recommande-t-elle l'approbation, ou approuve-t-elle ? Signale-t-elle des dossiers pour revue humaine, ou prononce-t-elle des refus définitifs ? Les régulateurs et le service juridique de l'agence doivent valider cette frontière avant le début du développement, car elle détermine quelles obligations légales s'appliquent (droits de la défense, exigences de procédure administrative, droits de recours).

Règle pratique concrète : si le logement, le revenu ou la liberté d'une personne est en jeu, l'IA doit recommander, pas décider, sauf si un texte autorise explicitement une action automatisée définitive. C'est la distinction entre « human-in-the-loop » et « human-on-the-loop », et ce n'est pas qu'une question de sémantique : cela change entièrement votre exposition juridique.

Porte 2 : data lineagedata lineageLe data lineage cartographie les déplacements et transformations de la donnée à travers les systèmes, de l'origine à la consommation : d'où elle vient, ce qui l'a modifiée, et où elle va.Voir la définition complète → et audit de biais

Tout jeu de données d'entraînement pour un modèle de permis contient une histoire incorporée. Si les approbations passées reflètent des décennies d'application inégale du code selon les quartiers, le modèle apprend ce 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 → comme « normal ».

Éléments de la checklist :

• Documentez la provenance de chaque champ d'entraînement (data lineage) et qui y a touché.
• Menez un test de disparate impact : comparez les taux d'approbation/refus et les délais de traitement selon les catégories protégées et la géographie, avant le déploiement, pas après l'arrivée des plaintes.
• Vérifiez les variables proxy. Le code postal, le secteur scolaire ou les « infractions au code antérieures » peuvent encoder silencieusement l'origine ethnique ou le revenu même si ces champs sont exclus.

Un contrôle simple de disparate impact, souvent appelé « règle des quatre cinquièmes » (une ligne directrice de l'Equal Employment Opportunity Commission américaine largement reprise en audit algorithmique), signale un problème si le taux de sélection d'un groupe est inférieur à 80 % du taux du groupe le plus favorisé.

# Simple four-fifths rule check
approval_rate_group_a = 0.72
approval_rate_group_b = 0.51

ratio = approval_rate_group_b / approval_rate_group_a
print(f"Impact ratio: {ratio:.2f}")
if ratio < 0.8:
    print("FLAG: potential disparate impact, investigate before deployment")

Ici, 0,51 / 0,72 = 0,71, en dessous du seuil de 0,8. C'est un signal d'arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êt du déploiement, pas une note de bas de page pour l'annexe.

Porte 3 : tests adverses et red-teaming

Le « red-teaming » consiste à attaquer délibérément son propre système pour trouver les modes de défaillance avant qu'un adversaire, un journaliste ou un procès ne le fassent. Emprunté aux pratiques militaires et à la cybersécurité, c'est désormais une exigence nommée dans l'AI Risk Management Framework du NIST (AI RMF, 2023), ce qui se rapproche le plus d'une norme technique américaine pour une IA digne de confiance.

Pour une IA de permis, le red-teaming consiste à essayer activement de :

• Contourner le système : un demandeur peut-il reformuler une demande pour transformertransformerUn Transformer est une architecture de réseau de neurones qui utilise le self-attention pour traiter des séquences en parallèle. Elle est au cœur de la plupart des modèles de langage et d'IA générative actuels.Voir la définition complète → un refus en approbation sans changer le projet réel ? Si un permis de terrasse refusé est approuvé simplement parce qu'on le renomme « patio », le modèle fait du pattern-matching textuel, il n'évalue pas le fond.
• Le casser avec des cas limites : biens en secteur sauvegardé, immeubles à usage mixte, mobil-homes, dossiers avec champs manquants. Les cas limites sont là où les modèles entraînés sur des cas « typiques » échouent silencieusement.
• Exploiter les angles morts : soumettez-lui des dossiers de petites associations ou de primo-demandeurs à l'historique mince. Les modèles pénalisent souvent « pas d'historique » comme s'il s'agissait de « mauvais historique ».

Technique pratique : construisez un jeu de test red-team délibérément pondéré vers les 10 % de dossiers réels les plus désordonnés, pas les 90 % propres utilisés pour les métriques d'accuracy à l'entraînement. Un modèle qui affiche 95 % d'accuracy globale peut encore échouer sur 60 % des cas limites qui comptent le plus.

Porte 4 : simuler avant de déployer

Faites tourner le modèle en « shadow mode » : laissez-le scorer les dossiers réels entrants, mais gardez les décideurs humains pleinement aux commandes, et comparez les résultats pendant des semaines ou des mois avant de le mettre réellement en service.

Cela fait remonter des problèmes qu'aucun test en laboratoire ne détecte : pics saisonniers (saison des rénovations au printemps), évolutions d'arrêtés locaux sur lesquelles le modèle n'a pas été réentraîné, ou drift à mesure que le vocabulaire des dossiers évolue.

Documentez un ensemble pré-enregistré de seuils pass/fail avant le début de la période shadow (par exemple : le ratio de disparité doit rester au-dessus de 0,8, le taux de faux refus sur les dossiers en appel doit rester sous un plafond fixé). Fixer les seuils après avoir vu les résultats invite au raisonnement motivé.

Porte 5 : l'override humain par conception, pas en rattrapage

Tout système d'IA publique rights-impacting a besoin d'un chemin d'override conçu et testé, pas d'un contournement caché du type « écrivez au service ».

À quoi ressemble une bonne conception d'override :

• Un code de motif visible et précis pour chaque recommandation de l'IA (pas seulement « refusé », mais « refusé : distance de recul inférieure à la section 4.2 du code »).
• Un relecteur humain nommé, doté de l'autorité pour renverser l'IA, et un journal tracé des overrides (si aucun override n'a jamais lieu, c'est en soi un signal d'alerte : les agents peuvent se sentir incapables de contester le système).
• Une procédure de recours accessible au public qui ne demande aucune littératie technique.

L'EU AI Act codifie cela explicitement, en exigeant des mesures de « contrôle humain » pour les systèmes à haut risque, y compris la possibilité pour un humain de renverser ou d'ignorer complètement la sortie du système (article 14).

Porte 6 : le monitoring après mise en service fait partie de la checklist

Les tests avant déploiement sont nécessaires mais pas suffisants. Mettez en place :

• Un monitoring du drift : suivez si les données d'entrée (types de dossiers, profils des demandeurs) s'éloignent de ce sur quoi le modèle a été testé.
• Des audits de résultats à cadence fixe : revérifications trimestrielles du disparate impact, pas seulement au lancement.
• Un kill switch : une procédure documentée et répétée pour revenir à un traitement entièrement manuel dans un délai fixé en heures si le monitoring signale un problème sérieux.

Les agences qui sautent cette étape découvrent souvent les biais seulement après une enquête de la presse locale ou un procès, ce qui est une manière bien plus coûteuse de l'apprendre.

🎬 [VIDEO: "The UK's A-Level Grading Algorithm Scandal" - youtube.com - un cas d'étude très cité sur ce qui se produit quand un système de notation automatisé remplace le jugement humain sans red-teaming suffisant, cherchez les reportages de la BBC ou les explainers du Guardian]

Points clés

• Définissez d'emblée si l'IA recommande ou décide ; ce seul choix détermine vos obligations légales et de supervision humaine sous des frameworks comme l'OMB M-24-10 (États-Unis) et l'EU AI Act.
• Menez un test de disparate impact (comme la règle des quatre cinquièmes) avant le lancement, et cherchez les variables proxy comme le code postal qui peuvent faire passer du biais dans des données « neutres ».
• Faites du red-teaming sur le modèle avec des cas limites et des tentatives de contournement, pas seulement avec des données moyennes et propres ; un score d'accuracy global élevé peut masquer un échec systématique sur les cas qui comptent le plus.
• Pilotez en shadow mode avec des seuils pass/fail pré-enregistrés avant de laisser l'IA toucher de vraies décisions.
• Intégrez l'override humain, la journalisation d'audit et un kill switch dès le premier jour, et maintenez le monitoring après le lancement, car les tests avant déploiement ne suffisent pas à eux seuls.