Model risk management appliqué à l'IA, pas seulement aux tableurs

Le modèle de détection de fraude d'une banque américaine de taille moyenne a dérivé sans bruit pendant quatorze mois. Personne ne s'en est aperçu jusqu'à ce que les chargebacks bondissent de 40 % en un seul trimestre, estimation fondée sur les communications post-incident habituelles, parce que le modèle notait toujours les transactions comme au lancement, alors que les réseaux de fraude avaient déjà adapté leurs schémas. Le modèle n'était pas cassé. Il n'était pas piloté. Cette distinction est tout le sujet de cette leçon.

Les banques mènent des programmes de model risk management (MRM) depuis des décennies, construits pour l'essentiel autour des modèles de taux, des formules de credit scoring et des outils de valorisation sous Excel. Ces modèles sont statiques : on les construit une fois, on les valide une fois, on les utilise pendant des années avec des recalibrages mineurs. Les modèles d'IA, en particulier ceux de machine learning, ne sont pas statiques. Ils apprennent à partir de nouvelles données, se dégradent silencieusement, et peuvent être manipulés par des adversaires en temps réel. Les traiter comme des tableurs, c'est exactement ainsi que des établissements finissent sous procédure de sanction.

Ce que signifie réellement le MRM

Le Model Risk Management est une discipline formelle, codifiée le plus clairement aux États-Unis par la Federal Reserve et l'OCC (Office of the Comptroller of the Currency) dans la SR 11-7, une lettre de supervision de 2011 qui reste la référence sur la façon dont les banques doivent gouverner leurs modèles. Elle définit le risque de modèle comme la possibilité de conséquences défavorables résultant de décisions fondées sur des sorties de modèle incorrectes ou mal utilisées.

La SR 11-7 repose sur trois piliers :

• Développement et implémentation : le modèle est-il conceptuellement solide et construit sur des données appropriées ?
• Validation : une fonction indépendante (pas les concepteurs du modèle) teste si le modèle fait ce qu'il prétend faire.
• Gouvernance : politiques, documentation et supervision, incluant un inventaire des modèles et des responsabilités définies.

En Europe, les attentes équivalentes viennent des lignes directrices de l'Autorité bancaire européenne (EBA) sur la gestion des risques informatiques et de sécurité, et de plus en plus de l'AI Act européen, entré en vigueur en 2024, qui classe de nombreux usages de l'IA dans le secteur financier (le credit scoring, par exemple) comme « à haut risque », déclenchant des obligations de systèmes de gestion des risques, de documentation et de supervision humaine.

Aucun de ces cadres n'a été écrit en pensant au deep learning. Les appliquer à l'IA suppose d'étirer chacun des piliers.

Pourquoi l'IA fait céder l'ancien playbook

Un modèle de fraude en régression logistique compte peut-être 15 coefficients. Un analyste peut lire l'équation et expliquer pourquoi une transaction a été signalée. Un modèle de gradient boosting ou un réseau de neurones qui note la même transaction peut utiliser des centaines de features construites et produire un score qu'aucun humain ne peut retracer par simple inspection. C'est l'explainability gap, et il entre directement en collision avec l'attente réglementaire selon laquelle les banques doivent pouvoir expliquer les décisions défavorables (aux États-Unis, au titre des exigences de notification d'adverse action de l'Equal Credit Opportunity Act).

Trois risques propres à l'IA méritent d'être nommés :

Model drift : la relation statistique entre entrées et résultats change dans le temps. Les schémas de fraude évoluent ; un modèle entraîné sur les tactiques de fraude de 2023 se dégrade face à celles de 2026. Le MRM traditionnel contrôle les modèles une ou deux fois par an. La dérive peut survenir en quelques semaines.

Adversarial gaming : les fraudeurs peuvent sonder un modèle en production (via des transactions tests) pour reconstituer ses angles morts, ce qui est presque impossible avec une formule de souscription statique.

Boucles de rétroaction : si un modèle de fraude bloque certains types de transactions, les données d'entraînement de la version suivante ne voient plus jamais ces schémas, 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 →éant des angles morts qui s'aggravent au fil des cycles de réentraînement.

Le cycle de vie réel d'un modèle de fraude

Suivons un modèle de fraude sur les paiements à travers ce à quoi ressemble un véritable cycle de vie MRM chez un émetteur de cartes ou un processeur de paiements.

1. Validation avant déploiement. Des validateurs indépendants testent le modèle sur des données hors échantillon, vérifient l'existence d'un impact disparate entre groupes démographiques (un enjeu de fair lending qui s'étend aussi aux taux de faux positifs en fraude) et le stress-testent contre des transactions adverses synthétiques.

2. Challenger models. Avant le déploiement complet, le modèle en place tourne en parallèle avec un ou plusieurs modèles « challenger » sur du trafic réel (mais sans effet décisionnel). C'est le champion-challenger testing : les scores du challenger sont enregistrés mais ne pilotent pas encore les décisions. Sur plusieurs semaines, les équipes comparent précision, rappel et coût des faux positifs. Les systèmes antifraude au niveau réseau de Visa et Mastercard, et la plupart des grands programmes d'émetteurs, mènent ces comparaisons en continu, pas seulement au lancement, parce qu'un challenger qui gagne en janvier peut perdre en juin.

3. Promotion du champion ou shadow mode. Si le challenger surperforme de façon constante, il est promu en production complète, mais souvent d'abord en « shadow mode », c'est-à-dire qu'il prend des décisions en temps réel sur une petite fraction du trafic (disons 5 %) tandis que le reste tourne encore sur l'ancien champion, ce qui limite le blast radius.

4. Monitoring continu. Après déploiement, les équipes suivent le population stability index (PSI), une métrique standard mesurant à quel point la distribution des données d'entrée s'est écartée de la baseline d'entraînement. Un PSI supérieur à environ 0,25 est une règle empirique répandue dans l'industrie, une estimation plutôt qu'un standard légal, signalant une dérive matérielle qui doit déclencher une revue.

5. Kill switches. Voici la pièce dont les tableurs n'ont jamais eu besoin et dont l'IA a absolument besoin. Un kill switch est un mécanisme rapide, pré-autorisé, permettant de revenir à une version antérieure du modèle ou à un fallback plus simple à base de règles si le monitoring détecte un problème sérieux (pic de faux positifs, résultats biaisés, rupture d'un pipeline de donnéespipeline de donnéesSéquence automatisée d'étapes qui déplace les données de la source vers la destination : ingestion, transformation, validation et chargement, pour qu'elles arrivent propres et prêtes à l'emploi.Voir la définition complète →). Sans kill switch, la seule option d'un établissement quand un modèle dérape est l'intervention manuelle, ce qui, en fraude, où les décisions se prennent en millisecondes, est bien trop lent.

Un contrôle de monitoring simplifié, du genre que les équipes de model risk automatisent, ressemble à ceci :

import numpy as np

def population_stability_index(expected, actual, bins=10):
    """Estimate PSI between training (expected) and live (actual) score distributions."""
    breakpoints = np.percentile(expected, np.linspace(0, 100, bins + 1))
    breakpoints[0], breakpoints[-1] = -np.inf, np.inf
    exp_pct = np.histogram(expected, breakpoints)[0] / len(expected)
    act_pct = np.histogram(actual, breakpoints)[0] / len(actual)
    exp_pct = np.clip(exp_pct, 1e-4, None)
    act_pct = np.clip(act_pct, 1e-4, None)
    return np.sum((act_pct - exp_pct) * np.log(act_pct / exp_pct))

# psi > 0.25 (règle empirique du secteur, pas un seuil légal) -> déclencher une revue

Ce n'est pas du code de production, mais c'est la logique réellement présente dans les dashboards de dérive en temps réel des sociétés de paiement.

Pourquoi les procédures de sanction arrivent

Les régulateurs ne sanctionnent généralement pas les banques pour avoir un modèle imparfait. Ils les sanctionnent pour ne pas avoir su que leur modèle était imparfait, ou pour l'avoir su sans agir.

Le Consumer Financial Protection Bureau (CFPB) et la Federal Trade Commission (FTC) américains ont tous deux signalé, dans leurs orientations publiques et leurs actions répressives, que l'usage d'une IA « black box » n'est pas une défense contre des griefs de fair lending ou de pratiques déloyales ; voir le circular du CFPB sur les notifications d'adverse action et les algorithmes complexes pour un exemple concret de la façon dont cela se joue pour les modèles de crédit, un proche cousin du scoring de fraude en termes de gouvernance.

En Europe, sous l'AI Act, les systèmes d'IA à haut risque utilisés dans l'évaluation de solvabilité font face à des obligations explicites : systèmes de gestion des risques, documentation de gouvernance des données, supervision humaine et monitoring post-commercialisation, applicables par les autorités nationales de supervision avec des amendes pouvant atteindre 7 % du chiffre d'affaires annuel mondial pour les violations les plus graves (un plafond légal, pas une sanction typique).

Le fil commun des récits de sanction : un modèle qui a dérivé, une équipe de validation pas assez indépendante, ou un processus de gouvernance qui existait sur le papier mais n'a pas été suivi quand le modèle a réellement échoué. La guidance SR 11-7 de 2011 précède le deep learning de plusieurs années, mais son intuition centrale, à savoir que le risque de modèle est un risque organisationnel et pas seulement un problème mathématique, est précisément ce qui la rend toujours applicable.

🎬 [VIDEO: "Model Risk Management Explained" - youtube.com/results?search_query=model+risk+management+explained+banking - chercher du contenu explicatif récent de cabinets de conseil en risque ou de chaînes pédagogiques de la Federal Reserve sur la SR 11-7 et les fondamentaux du MRM]

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 de déployer

Une checklist pratique avant déploiement, pour tout modèle d'IA touchant l'argent ou les décisions des clients :

• Équipe de validation indépendante, organisationnellement séparée des développeurs du modèle
• Entrée documentée dans l'inventaire des modèles (ce que la SR 11-7 appelle un registre vivant de la finalité, du propriétaire et du niveau de risque)
• Champion-challenger testing sur du trafic shadow réel avant la bascule complète
• Métriques de dérive définies (comme le PSI) avec seuils numériques et propriétaires nommés
• Un kill switch ou une procédure de rollback testée, exercée au moins une fois avant le go-live
• Tests de fair lending ou d'impact disparate sur les classes protégées, le cas échéant
• Revue human-in-the-loop pour les cas limites et les décisions défavorables

Points clés

• La SR 11-7 (États-Unis) et l'AI Act (Europe) sont les deux cadres d'ancrage de la gouvernance des modèles d'IA en finance ; tous deux exigent une validation indépendante et un monitoring continu, pas une validation unique.
• Les modèles d'IA dérivent, se font manipuler et créent des boucles de rétroaction d'une façon que les formules statiques de tableur n'ont jamais connue, et c'est pourquoi les cycles de revue annuels sont insuffisants.
• Le champion-challenger testing et le déploiement en shadow mode permettent de comparer un nouveau modèle à celui en place sur du trafic réel avant qu'il ne prenne de vraies décisions.
• Les kill switches ne sont pas une infrastructure optionnelle. Ce sont les mécanismes de retour rapide que les régulateurs attendent quand un modèle dérape en temps réel.
• Les actions répressives visent les défaillances de gouvernance (ne pas savoir, ou ne pas agir) beaucoup plus souvent que les mathématiques sous-jacentes.