Détecter le model risk avant qu'il ne devienne une perte
Une banque américaine de taille moyenne exploitait un modèle de recouvrement qui a cessé de fonctionner pendant huit mois, sans bruit. Personne ne l'a remarqué au début. Le modèle continuait à scorer les comptes en défaut et à les classer pour les relances, mais le monde sous-jacent avait changé : évolution du mix clients après l'acquisition d'un portefeuille, nouveau programme d'aide aux emprunteurs en difficulté, modification de la façon dont les agents du centre d'appels enregistraient les résultats. Les prédictions du modèle se sont éloignées de la réalité, les recouvreurs ont relancé les mauvais comptes, les taux de recouvrement ont baissé, et quand quelqu'un a enfin rapproché les sorties du modèle des roll rates réels, la banque avait absorbé une perte mesurable et évitable. C'est un cas d'école de model risk réalisé, non pas parce que le modèle était mal construit, mais parce que personne ne le surveillait après sa mise en production.
Cette leçon porte sur la détection de ce drift avant qu'il n'apparaisse dans vos chiffres ou dans la lettre d'un superviseur.
Ce que signifie vraiment « model risk »
Le model risk est le risque de perte financière ou de mauvaise décision causé par un modèle faux, mal utilisé ou mal compris. Aux États-Unis, le cadre de référence est la guidance SR 11-7 de la Federal Reserve et de l'OCC sur le model risk management (2011), toujours le standard opérationnel des banques en 2026. Elle définit deux sources de model risk :
- Erreurs fondamentales : le modèle est conceptuellement faux ou construit sur de mauvaises données.
- Mauvais usage : le modèle est utilisé en dehors des conditions pour lesquelles il a été validé.
Le drift silencieux, comme dans le cas du recouvrement, relève généralement du second. Le modèle n'était pas faux à son lancement. Il l'est devenu quand son environnement a changé et que personne n'a revérifié l'adéquation.
En Europe, les attentes équivalentes figurent dans le guide de la BCE sur les modèles internes et, plus largement, dans l'EU AI Act (entré en vigueur en 2024, obligations échelonnées jusqu'en 2026-2027), qui classe les systèmes d'IA de solvabilité et de credit scoring comme « à haut risque », déclenchant des obligations de gestion des risques, de gouvernance des données et de supervision humaine.
Les trois familles de risque à surveiller
1. Data drift. Les propriétés statistiques des données entrantes changent. Exemple : une banque rachète le portefeuille de prêts d'une fintech ; les nouveaux emprunteurs ont des historiques 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 plus minces, le modèle voit donc des inputs sur lesquels il n'a jamais été entraîné.
2. Concept drift. La relation entre inputs et résultats change, même si les données d'entrée semblent stables. Exemple : un programme d'aide est lancé, si bien que les emprunteurs qui paraissent « à haut risque » selon l'ancienne logique du modèle se régularisent désormais plus vite parce qu'ils ont obtenu un allègement de paiement. Mêmes inputs, résultat différent.
3. Risque de boucle de rétroaction. Les décisions du modèle modifient les données futures. Exemple : un modèle de recouvrement déprioritise certains comptes, ces comptes reçoivent moins d'attention, ils se dégradent, et le modèle « apprend » qu'ils étaient à haut risque depuis le début, renforçant un 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 → auto-réalisateur. C'est particulièrement dangereux dans les modèles d'octroi et de recouvrement qui influencent qui est contacté, accepté ou bénéficie d'un allègement.
Indicateurs avancés : quoi surveiller avant que les pertes n'apparaissent
Les huit mois d'écart dans le cas ci-dessus existent parce que la banque surveillait les *résultats* (charge-offs, taux de recouvrement) et non le *comportement du modèle*. Les résultats ont des mois de retard. Les signaux comportementaux bougent plus vite. Suivez ceux-ci :
- Population Stability Index (PSI) : mesure l'ampleur du déplacement de la distribution des inputs (ou des scores) du modèle par rapport à la baseline d'entraînement. Un PSI supérieur à environ 0,25 est un seuil couramment utilisé dans l'industrie pour un « déplacement significatif » (estimation, variable selon la politique de chaque institution).
- Déplacement de la distribution des scores : y a-t-il soudain plus de comptes que d'habitude dans le décile supérieur ou inférieur ?
- Taux d'override : à quelle fréquence les agents humains passent-ils outre le modèle ? Un taux d'override en hausse est un signe précoce que les équipes ne lui font plus confiance.
- Écart champion-challenger : faites tourner en parallèle un modèle de benchmark plus simple ; si l'écart avec le modèle en production se creuse, quelque chose a changé.
- Complétude des données d'entrée : champs manquants, taux de valeurs nulles, ou nouvelles valeurs catégorielles (comme un nouveau code produit de prêt) qui s'infiltrent dans le flux.
Un contrôle de drift simple, exemple chiffré
Le PSI compare le pourcentage de comptes dans chaque bucket de score aujourd'hui et au moment de l'entraînement.
PSI = Σ (Actual% - Expected%) × ln(Actual% / Expected%)Supposons que le bucket de score « low risk » contenait 40 % des comptes à l'entraînement du modèle et en contient aujourd'hui 25 % :
Bucket contribution = (0.25 - 0.40) × ln(0.25 / 0.40)
= (-0.15) × ln(0.625)
= (-0.15) × (-0.47)
= 0.0705Faites la somme sur tous les buckets. Si le total dépasse le seuil de votre institution (couramment 0,1 pour « surveiller » et 0,25 pour « agir », à titre d'estimation), c'est un déclencheur de revue, indépendamment de l'apparition ou non de pertes.
import numpy as np
def psi(expected, actual):
return np.sum((actual - expected) * np.log(actual / expected))
expected = np.array([0.40, 0.35, 0.25]) # distribution d'entraînement
actual = np.array([0.25, 0.40, 0.35]) # distribution actuelle
print(round(psi(expected, actual), 3))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 → de gouvernance avant déploiement
Le model risk management (MRM) selon SR 11-7 repose sur trois piliers, et chacun se traduit par un contrôle concret avant déploiement :
- Développement et documentation : existe-t-il une model card ou un document équivalent précisant l'usage prévu, les sources de données et les limites connues ? Si la documentation du modèle de recouvrement avait précisé « non validé pour les populations bénéficiant d'un programme d'aide », le drift aurait été signalé le jour du lancement du programme.
- Validation indépendante : une équipe distincte des développeurs du modèle doit le tester avant le lancement puis périodiquement après. Ce n'est pas optionnel au regard des attentes prudentielles américaines, et sous l'EU AI Act, les systèmes à haut risque exigent des évaluations de conformité documentées avant mise sur le marché.
- Monitoring continu : des déclencheurs convenus à l'avance (comme les seuils de PSI ci-dessus) qui imposent une revue, et pas seulement un point annuel. La cadence de monitoring doit correspondre à la vitesse à laquelle la population sous-jacente peut changer : mensuelle voire hebdomadaire pour les modèles de recouvrement et de fraude, trimestrielle pour les modèles plus lents comme les notations de risque de crédit à long terme.
Une checklist pratique avant lancement :
- Usage prévu défini et conditions « hors périmètre » explicites
- Distribution des données de baseline capturée et stockée pour comparaison PSI future
- Modèle champion-challenger tournant en parallèle
- Processus d'override et d'escalade documenté pour les équipes de première ligne
- Propriétaire du modèle nommément désigné et responsable du monitoring post-lancement (et pas seulement l'équipe de build)
Vérification des acquis
1. Dans le cas du modèle de recouvrement, quelle était la cause fondamentale de la perte ?
2. Dans le cadre SR 11-7, comment distinguer au mieux le « mauvais usage » comme source de model risk d'une « erreur fondamentale » ?
3. Le modèle de risque de crédit d'une banque a bien performé lors de sa validation il y a deux ans. Depuis, la banque a acquis un nouveau portefeuille de prêts avec des caractéristiques d'emprunteurs différentes, mais le modèle n'a pas été revalidé. Qu'illustre principalement ce scénario ?
4. Sélectionnez TOUTES les réponses correctes expliquant pourquoi la défaillance du modèle de recouvrement est restée indétectée pendant huit mois.
Sélectionnez toutes les réponses correctes.
5. Sélectionnez TOUTES les réponses correctes concernant les pratiques efficaces pour détecter le model risk avant qu'il ne produise une perte.
Sélectionnez toutes les réponses correctes.
Pourquoi cela se reproduit sans cesse
Les banques sont bonnes pour valider les modèles avant leur lancement et comparativement faibles pour les surveiller ensuite. Une perspective de la Federal Reserve de 2023 et des enquêtes sectorielles (voir la bibliothèque de guidance prudentielle de la Fed) citent régulièrement le « monitoring continu insuffisant » comme la lacune MRM la plus fréquemment relevée par les superviseurs. Le schéma est structurel : les budgets de développement sont visibles et financés, les budgets de monitoring non.
Le cas du recouvrement l'illustre exactement. Le modèle a passé la validation. Personne n'en était propriétaire ensuite. La banque l'a découvert via une revue trimestrielle des pertes, le signal le plus lent possible, au lieu d'un dashboard PSI hebdomadaire, le plus rapide.
🎬 [VIDEO: "Model Risk Management Explained" - https://www.youtube.com/results?search_query=model+risk+management+explained+banking - un tour d'horizon des concepts de gouvernance du model risk de type SR 11-7 pour les praticiens bancaires]
Points clés
- Le model risk ne se réduit pas à « le modèle a été mal construit ». La plupart des pertes réelles viennent d'un mauvais usage ou d'un drift après le lancement, quand le monde change et le modèle non.
- Surveillez le comportement, pas seulement les résultats. Le PSI, les taux d'override et les écarts champion-challenger bougent des mois avant que les charge-offs ou les recouvrements ne révèlent les dégâts.
- Les cadres de gouvernance existent et sont précis : SR 11-7 aux États-Unis, la classification à haut risque du credit scoring par l'EU AI Act en Europe. Utilisez leurs trois piliers (développement, validation, monitoring) comme checklist.
- Chaque modèle déployé a besoin d'un propriétaire nommé et d'une cadence de monitoring convenue à l'avance, calée sur la vitesse à laquelle sa population peut évoluer : hebdomadaire pour le recouvrement et la fraude, plus lente pour les modèles de risque de crédit structurel.
- Documenter l'usage prévu et les conditions « hors périmètre » est votre assurance la moins chère. Cela transforme une défaillance silencieuse en défaillance évidente dès que les conditions changent.
Articles liés
Les articles récents du blog qui s'appuient sur cette leçon.
- IASR 11-7 n'a pas été écrit pour les LLMs, et c'est là que les banques se font piégerLa circulaire SR 11-7 de la Fed date de 2011, mais elle s'applique aujourd'hui à des modèles de crédit entraînés sur des milliards de paramètres que personne dans la banque ne peut vraiment expliquer. Comprendre comment articuler explainability et gouvernance des modèles n'est plus une question de conformité théorique : c'est ce qui détermine si un modèle reste en production ou passe devant le conseil de surveillance.
- IADécisions de crédit par IA : construire un modèle que le régulateur ne peut pas démonterLes modèles de crédit pilotés par l'IA multiplient la vitesse de décision, mais ils exposent les banques à un risque réglementaire que beaucoup sous-estiment jusqu'à ce que l'OCC ou le CFPB frappe à la porte. Ce guide pratique décrit la séquence de contrôles à intégrer dès la conception pour qu'un modèle survive à un examen de fair lending.