Gouverner les modèles de risque sous le regard du régulateur

# Gouverner les modèles de risque sous le regard du régulateur

Un examinateur pose une seule question sur la table : « Montrez-moi d'où vient cette variable. » Le nouveau modèle de credit scoring de la banque est prêt à être lancé. L'équipe data science est confiante. Mais si personne ne peut retracer un input jusqu'à son système source, le modèle ne passe pas en production. C'est la réalité de la gouvernance des modèles de risque dans une banque régulée.

Cette leçon vous place dans cette revue de validation. Vous y verrez les règles appliquées par les examinateurs, les contrôles qu'ils exigent, et pourquoi le 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 → est le point de tension sur lequel la plupart des modèles échouent.

Pourquoi les banques gouvernent leurs modèles

Un modèle en banque, c'est toute méthode quantitative qui transforme des données d'entrée en une décision ou une estimation. Un modèle de credit scoring prédit le risque de défaut. Un modèle de lutte anti-blanchiment (AML) signale les transactions suspectes. Un modèle de stress-testing estime les pertes en cas de récession.

Quand un modèle se trompe, de l'argent réel et des personnes réelles sont affectés. Un modèle de scoring biaisé peut refuser des prêts injustement. Un modèle AML faible peut laisser passer une activité criminelle. Les régulateurs appellent cette exposition le model risk : le risque de perte lié à des décisions fondées sur des modèles défaillants ou mal utilisés.

Le corpus de référence aux États-Unis est SR 11-7, une guidance publiée conjointement par la Federal Reserve et l'Office of the Comptroller of the Currency (OCC) en 2011. Elle reste la norme de référence en 2026. La source primaire est ici : SR 11-7 Guidance on Model Risk Management.

Les trois piliers de SR 11-7

SR 11-7 est court mais exigeant. Il repose sur trois idées.

1. Effective challenge

Quelqu'un d'indépendant des développeurs du modèle doit le passer en revue de façon critique. C'est l'effective challenge. Le relecteur a besoin de la compétence pour comprendre les mathématiques, de l'influence pour imposer des changements, et de l'indépendance pour dire non.

En pratique, une banque met en place une fonction Model Risk Management (MRM) séparée de l'équipe data science. Les développeurs construisent. MRM challenge.

2. Validation sur tout le cycle de vie

La validation n'est pas un point de passage unique. SR 11-7 exige une revue au moment du développement, avant le déploiement, puis en continu. Un modèle de scoring qui fonctionnait en 2024 peut se dégrader à mesure que les comportements clients évoluent. Cette dégradation s'appelle le model drift, et son monitoring est obligatoire.

3. Gouvernance, politique et contrôles

Le conseil d'administration et la direction générale portent le model risk. Il doit exister un model inventory (un registre complet de tous les modèles utilisés), des politiques documentées et des rôles clairs. Un examinateur demandera l'inventaire en premier. Un modèle manquant constitue à lui seul un défaut de gouvernance.

À l'intérieur de la revue de validation

Imaginez la salle. Sont présents le développeur du modèle, un validateur MRM, un responsable data governancedata governanceLa data governance est l'ensemble des politiques, rôles et processus qui garantissent que les données sont exactes, sécurisées, bien définies et utilisées de façon responsable dans toute l'organisation.Voir la définition complète → et souvent un compliance officer. Ils déroulent une checklist.

Solidité conceptuelle. Le modèle a-t-il du sens ? Si un modèle 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 utilise le code postal comme variable, quelqu'un demandera s'il s'agit d'un proxy de l'origine ethnique, ce qui soulèverait des enjeux de fair lending.

Qualité des données. Les données d'entraînement sont-elles exactes, complètes et représentatives ? Un modèle entraîné uniquement sur des emprunteurs acceptés souffre d'un survivorship bias : il n'a jamais vu comment les candidats refusés se seraient comportés.

Analyse des résultats. Le modèle prédit-il réellement ce qu'il prétend ? Les validateurs backtestent les prédictions contre les résultats réels.

Tests d'implémentation. Le code déployé correspond-il au modèle approuvé ? Une formule qui fonctionne dans un notebook peut casser en production.

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 → : le contrôle décisif

Retour à la question de l'examinateur : « Montrez-moi d'où vient cette variable. »

Le 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 → est le chemin documenté d'une donnée depuis son origine, à travers chaque transformation, jusqu'à son usage dans le modèle. Voyez-le comme un reçu pour chaque chiffre.

Pourquoi les examinateurs en font une obsession :

• Si vous ne pouvez pas retracer une variable, vous ne pouvez pas prouver qu'elle est exacte.
• Vous ne pouvez pas confirmer que vous avez le droit de l'utiliser.
• Vous ne pouvez pas reproduire le modèle, ce qui casse l'auditabilité.

Un exemple concret. Une feature « ratio dette/revenu » paraît simple. Mais le revenu peut venir d'un système, la dette d'un autre, et le ratio être calculé dans un troisième avec des règles d'arrondi différentes de celles de la source. Chaque saut est un endroit où se cachent des erreurs et des changements de règles.

Les banques modernes suivent le lineage avec des outils de métadonnées et du contrôle de version. Voici le genre d'information que capture un enregistrement de lineage :

feature: debt_to_income_ratio
source_income: core_banking.customer_income   # vérifié mensuellement
source_debt: credit_bureau.total_obligations  # rafraîchi à chaque extraction
transformation: debt / income
null_handling: exclude_if_income_missing
owner: retail_credit_risk
consent_basis: loan_application_terms
last_validated: 2026-01-15

Remarquez la ligne consent_basis. C'est là que lineage et privacy se rejoignent.

Les règles de privacy qui contraignent les données

Un modèle ne peut utiliser que des données que la banque a légalement le droit d'utiliser pour cette finalité.

Aux États-Unis, le Fair Credit Reporting Act (FCRA) encadre l'usage des données 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 et exige que les consommateurs puissent savoir pourquoi ils ont été refusés. C'est pourquoi les prêteurs doivent produire des adverse action reasons : les facteurs précis derrière un refus. Un modèle incapable d'expliquer ses principaux motifs viole la loi, quelle que soit sa précision.

Les lois de fair lending (l'Equal Credit Opportunity Act) interdisent la discrimination sur des caractéristiques protégées. Même si un modèle ne voit jamais l'origine ethnique, une variable corrélée peut produire un disparate impact, un résultat qui pénalise un groupe protégé. Les validateurs font tourner des tests de fairness pour le détecter.

Dans l'UE et au Royaume-Uni, le General Data Protection Regulation (GDPR) ajoute la limitation de finalité (des données collectées pour une raison ne peuvent pas être librement réutilisées), le droit à l'explication pour les décisions automatisées, et des règles de consentement strictes.

Ce qu'il faut en retenir : la privacy n'est pas une considération juridique ajoutée à la fin. C'est une contrainte de conception qui détermine quelles features un modèle peut même contenir.

🎬 [VIDEO: "Model Risk Management Explained" - youtube.com - un tour d'horizon clair des principes de SR 11-7 et de la façon dont les banques valident les modèles avant déploiement]

Explicabilité et problème de la boîte noire

Les examinateurs sont prudents face aux modèles de machine learning complexes parce qu'ils peuvent être difficiles à interpréter. Une simple régression logistique (un modèle statistique qui pondère chaque input) montre exactement comment chaque variable influence le score. Un réseau de neurones profond, non.

Cela n'interdit pas les modèles complexes. Cela relève le niveau d'exigence documentaire. Les banques utilisent des outils comme les SHAP values (une méthode qui attribue une prédiction à chaque input) pour expliquer les décisions individuelles. Si un client est refusé, la banque doit tout de même produire des adverse action reasons honnêtes.

La règle empirique dans la salle : si vous ne pouvez pas l'expliquer, vous ne pouvez pas le déployer dans une décision régulée.

Le monitoring continu après le lancement

L'approbation n'est pas la ligne d'arrivée. Une fois le modèle en production, MRM met en place un monitoring continu.

Le performance monitoring surveille la précision dans le temps. Si la qualité de prédiction du défaut baisse, le modèle peut nécessiter un recalibrage.

La stabilité de la population vérifie si les candidats entrants ressemblent toujours à la population d'entraînement. Une métrique courante est le Population Stability Index (PSI), qui alerte quand la distribution des inputs a suffisamment bougé pour être préoccupante.

Le suivi des overrides enregistre la fréquence à laquelle des humains passent outre le modèle. Des overrides fréquents suggèrent que le modèle n'est pas jugé fiable ou n'est pas adapté à son usage.

Quand un modèle franchit ses seuils, la politique de gouvernance dicte l'escalade : recalibrer, revalider ou retirer.

Ce que les examinateurs veulent réellement voir

Ramené à l'essentiel, une banque doit démontrer :

• Un model inventory complet avec des propriétaires.
• Une validation indépendante avec un véritable effective challenge.
• Un 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 → de bout en bout pour chaque input du modèle.
• Une conformité documentée en matière de privacy et de fair lending.
• Une explicabilité suffisante pour justifier chaque décision.
• Un monitoring continu avec des déclencheurs d'escalade définis.

S'il en manque un, le déploiement attend. C'est pourquoi l'équipe data science de notre scène d'ouverture ne pouvait pas lancer sur la seule base de sa confiance.

Points clés

• Le model risk se gouverne, il ne se présume pas. SR 11-7 exige un effective challenge indépendant, une validation sur tout le cycle de vie et une responsabilité au niveau du conseil via un model inventory.
• Le data lineage est le contrôle qui casse en premier. Si vous ne pouvez pas retracer une variable jusqu'à sa source et prouver comment elle a été transformée, le modèle ne se déploie pas.
• La privacy est une contrainte de conception. FCRA, règles de fair lending et GDPR limitent les données qu'un modèle peut utiliser et imposent des adverse action reasons honnêtes ainsi que des tests de fairness.
• Dans les décisions régulées, l'explicabilité prime sur la précision brute. Un modèle que vous ne pouvez pas expliquer ne peut pas être déployé, quelle que soit sa qualité de prédiction.
• La validation continue après le lancement. Surveillez le drift avec des métriques comme le PSI, suivez les overrides et escaladez quand les seuils sont franchis.