Le risque modèle au-delà du biais : drift, brittleness et boîtes noires

Un service d'aide sociale de comté lance début 2024 un modèle d'IA pour repérer les demandes SNAP (Supplemental Nutrition Assistance Program) probablement éligibles et celles qui nécessitent un examen manuel. Précision au lancement : 94 %. Au milieu de 2025, les travailleurs sociaux remarquent quelque chose d'étrange : le modèle laisse passer des demandes qu'il devrait signaler, et signale celles qu'il ne devrait pas. Personne n'a touché au modèle. Ce qui a changé, c'est tout ce qui l'entoure : une mise à jour des seuils de revenus, un déplacement du profil démographique des demandeurs après la fermeture d'une usine, un nouveau formulaire d'État. Le modèle ne s'est pas dégradé. Le monde a bougé et le modèle n'a pas bougé avec lui.

Ce n'est pas un défaut d'équité au sens classique (aucun groupe protégé n'a été délibérément désavantagé à la conception). C'est une autre catégorie de risque, plus discrète : le model drift, qui se place aux côtés de la brittleness et de l'opacité comme l'un des trois modes de défaillance que tout déploiement d'IA dans le secteur public doit vérifier, au-delà des audits de biais.

Pourquoi le « au-delà du biais » compte

La plupart des discussions sur la gouvernance de l'IA dans le secteur public sautent directement au biais et à l'équité, à juste titre : des résultats discriminatoires dans des modèles d'aide sociale, de police ou de recrutement 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 →éent une exposition juridique réelle au titre de textes comme le cadre du US Civil Rights Act et l'AI Act européen (règlement (UE) 2024/1689), qui classe les systèmes d'éligibilité aux prestations publiques comme « systèmes d'IA à haut risque » soumis à une surveillance continue.

Mais un modèle peut être parfaitement équitable au lancement et échouer de manière catastrophique pour des raisons qui n'ont rien à voir avec le biais. Les régulateurs s'y adaptent : l'AI Act européen exige explicitement que les systèmes à haut risque fassent l'objet d'un suivi de leur « exactitude, robustesse et cybersécurité » tout au long de leur cycle de vie, et pas seulement au déploiement. L'AI Risk Management Framework du NIST (norme américaine volontaire publiée en 2023) le nomme directement : le risque n'est pas une certification ponctuelle, c'est une fonction de gestion continue.

Les trois catégories de risque au-delà du biais

1. Drift : le modèle est périmé

Le model drift survient lorsque la relation statistique entre les inputs et les résultats change après le déploiement : un modèle entraîné sur d'anciens schémas produit des prédictions de plus en plus fausses sur de nouvelles données.

Deux variantes comptent pour le secteur public :

• Data drift : la population d'entrée change. Exemple : le vivier de candidats d'un programme de reconversion professionnelle se modifie après un plan social régional, si bien que le modèle voit des profils de revenus et d'emploi sur lesquels il n'a jamais été entraîné.
• Concept drift : la *règle* qui relie les inputs à la bonne réponse change. Exemple : un État relève le seuil de revenus d'éligibilité au SNAP. Le revenu du demandeur n'a pas changé, mais le fait que ce revenu doive lui ouvrir droit, oui. Le modèle n'a aucune idée que la règle a bougé.

Le concept drift est particulièrement dangereux dans l'administration parce que les politiques publiques changent en permanence : cycles budgétaires, amendements législatifs, décisions de justice, dérogations d'urgence (comme les assouplissements SNAP de la période COVID). Un modèle figé au moment de l'entraînement devient silencieusement obsolète chaque fois qu'un législateur agit.

Contrôle de drift simple (illustratif, pas un jeu de données réel) :

# Comparer les distributions de variables : données d'entraînement vs. 90 derniers jours
from scipy.stats import ks_2samp

stat, p_value = ks_2samp(training_income, recent_income)
if p_value < 0.05:
    print("Significant distribution shift detected: flag for review")

Il s'agit d'un test de Kolmogorov-Smirnov, un contrôle statistique standard pour déterminer si deux échantillons proviennent de distributions différentes. Il ne vous dira pas *pourquoi* les choses ont bougé, mais il vous dit *quand* regarder.

2. Brittleness : le modèle casse sur des cas limites qu'il n'a jamais vus

La brittleness est l'incapacité d'un modèle à généraliser hors des conditions étroites de ses données d'entraînement. Il fonctionne bien en moyenne, mais se brise sur des inputs légèrement inhabituels, adversariaux ou simplement rares.

Exemple : un modèle de détection de fraude à l'assurance chômage entraîné majoritairement sur des salariés classiques déclarant un W-2 peut se tromper complètement sur des travailleurs de plateformes, des pêcheurs saisonniers ou des personnes ayant des revenus informels en liquide, non par biais, mais parce que ces profils sont statistiquement sous-représentés dans les données d'entraînement. Lors de la controverse sur la détection de fraude au chômage dans le Michigan (2013 à 2015), un système appelé MiDAS a signalé des dizaines de milliers de dossiers comme frauduleux, avec des taux d'erreur jugés ensuite extrêmement élevés ; un facteur contributif a été un système mal calibré sur la diversité réelle des dossiers, générant de fausses déterminations de fraude qui déclenchaient des pénalités avant que l'examen humain ne rattrape les erreurs.

La brittleness explique pourquoi le stress testing (soumettre délibérément au modèle des inputs inhabituels, des cas limites ou adversariaux avant le déploiement) compte autant que les tests de précision sur un jeu de validation propre.

3. Boîtes noires : personne ne peut expliquer la décision

L'opacité (le problème de la « boîte noire ») survient quand la logique interne d'un modèle n'est pas interprétable par les personnes qui doivent agir sur son résultat, le contester ou l'auditer.

Ce n'est pas qu'un désagrément technique. Dans le secteur public, c'est un enjeu juridique et constitutionnel. Le droit administratif américain exige généralement que les administrations motivent les décisions défavorables (question de due process). Les dispositions de l'AI Act européen sur le haut risque exigent une documentation et une supervision humaine suffisantes pour un examen effectif. Un modèle qui produit « refusé » sans raisonnement traçable ne satisfait pas cette exigence, quelle que soit sa précision.

Les modèles complexes (réseaux de neurones profonds, méthodes d'ensemble comme les arbres à gradient boosting) tendent à être plus précis mais moins interprétables que les plus simples (régression logistique, arbres de décision). Les administrations arbitrent en permanence entre précision et explicabilité, et doivent de plus en plus documenter cet arbitrage explicitement, notamment au titre des exigences de transparence de l'article 13 de l'AI Act européen.

Des outils comme SHAP (SHapley Additive exPlanations) tentent d'approcher les raisons pour lesquelles un modèle boîte noire a produit une prédiction donnée, mais une approximation n'est pas la vérité terrain, et les administrations devraient traiter ces outils comme des aides à l'examen, non comme une preuve d'équité ou d'exactitude.

Garde-fousGarde-fousRègles et contrôles qui maintiennent un système d'IA dans des limites sûres, légales et conformes à la marque, en bloquant les sorties et actions hors cadre.Voir la définition complète → avant déploiement

Une checklist pratique de pré-déploiement pour l'IA dans le secteur public, inspirée du NIST AI RMF et des obligations « haut risque » de l'AI Act européen :

• Plan de monitoring de référence : définir quelles métriques seront suivies après le lancement (précision, taux de faux positifs/négatifs par sous-groupe, distributions des inputs) et à quelle fréquence, avant la mise en production, pas après les plaintes.
• Déclencheurs de drift liés aux calendriers réglementaires : si les règles d'éligibilité changent, c'est un déclencheur automatique de réentraînement ou de revalidation, pas une tâche « peut-être un jour ».
• Jeu de stress test : construire un jeu de test délibérément bizarre (cas limites, types de ménages rares, profils de revenus inhabituels), distinct du jeu de validation de précision standard.
• Seuil minimal d'explicabilité : décider, avant le déploiement, quel niveau d'explication un travailleur social ou un demandeur a besoin d'obtenir, et confirmer que le modèle retenu peut le produire.
• Human-in-the-loop pour les décisions défavorables : les déterminations à haut risque (refus de prestation, signalements de fraude, recommandations de peine) doivent être orientées vers un examen humain, pas exécutées automatiquement. C'est à la fois un contrôle du risque et, au titre de l'AI Act européen, souvent une obligation légale.
• Version control et piste d'audit : journaliser quelle version du modèle a pris quelle décision, afin qu'une erreur due au drift dans six mois puisse être remontée jusqu'au moment où le comportement a réellement changé.

Une illustration chiffrée

Supposons que le modèle d'éligibilité SNAP ci-dessus ait été validé au lancement avec 94 % de précision (estimation, illustratif). Dix-huit mois plus tard, un audit interne échantillonne 500 décisions récentes et constate que la précision est tombée à 81 % (illustratif). Soit une baisse de 13 points de pourcentage. Si le service traite environ 10 000 demandes par an, cet écart implique plus de 1 000 demandes supplémentaires par an recevant désormais un signal d'éligibilité erroné, avant toute détection humaine. Voilà le coût concret de l'absence de contrôle de drift : pas une hypothèse, un nombre de personnes affectées chaque année à l'échelle d'un portefeuille de dossiers.

Points clés à retenir

• Les audits de biais détectent une conception discriminatoire ; ils ne détectent pas le drift, la brittleness ou l'opacité, qui sont des catégories de risque distinctes et tout aussi sérieuses.
• Le drift (de données ou de concept) signifie que le modèle se périme silencieusement à mesure que les populations ou les règles évoluent ; le concept drift est particulièrement fréquent dans l'administration en raison des changements législatifs et réglementaires fréquents.
• La brittleness signifie qu'une bonne précision moyenne masque des défaillances catastrophiques sur des cas limites ou des groupes sous-représentés ; le stress testing avant déploiement est la contre-mesure.
• L'opacité crée une exposition juridique (due process, règles de transparence de l'AI Act européen) indépendamment de la précision du modèle ; les administrations ont besoin d'un standard d'explicabilité fixé avant le lancement, pas rajouté après une plainte.
• Traitez le risque modèle comme une obligation continue sur tout le cycle de vie (selon le NIST AI RMF et les règles haut risque de l'AI Act européen), pas comme une certification ponctuelle : plans de monitoring, déclencheurs de drift et pistes d'audit comptent autant que la validation initiale.