Model risk management pour l'IA d'investissement

En 2007, un ensemble de fonds actions quantitatifs s'est débouclé en quelques jours. Leurs modèles, entraînés sur des données similaires avec des hypothèses similaires, ont tous vendu les mêmes titres au même moment. Personne n'avait modélisé le risque que les modèles eux-mêmes constituent la foule. Près de deux décennies plus tard, le machine learning a rendu ce mode de défaillance plus rapide, plus opaque et plus difficile à détecter. Cette leçon vous montre comment le gouverner.

Pourquoi SR 11-7 reste la référence

SR 11-7 est une guidance publiée en 2011 par la Réserve fédérale américaine et l'Office of the Comptroller of the Currency (OCC). Elle définit un « modèle » comme toute méthode quantitative qui transforme des données d'entrée en une estimation, et exige que chaque modèle soit validé de façon indépendante, documenté intégralement et monitoré en continu. Elle a été écrite pour les banques, mais elle est devenue le standard mondial de fait en matière de discipline de model risk.

Lisez la source primaire une fois. Elle est courte et lisible : guidance SR 11-7 de la Réserve fédérale.

L'idée centrale : le model risk est le risque de perte lié à un modèle erroné ou mal utilisé. SR 11-7 le décompose en deux sources.

• Le modèle est fondamentalement défectueux. Mauvaises hypothèses, mauvaises données, mauvaises maths.
• Le modèle est mal utilisé. Bon outil, mauvais contexte, ou personne ne le vérifie après le déploiement.

Les modèles d'alpha en ML échouent sur ces deux plans plus souvent que les modèles linéaires, parce qu'ils sont plus flexibles et moins interprétables. C'est précisément la flexibilité qui leur permet de mémoriser le bruit.

Transposer la discipline à l'alpha ML et à l'allocation

SR 11-7 repose sur trois piliers. Voici comment chacun se transpose à un process d'investissement piloté par l'IA.

1. Développement et documentation robustes

Chaque signal ML a besoin d'une « model card » écrite : ce qu'il prédit, sur quelles données, sur quel univers, avec quelles limites connues. Si un gérant ne peut pas expliquer en un paragraphe ce que fait un signal, celui-ci ne doit pas dimensionner une position.

Pour l'asset management en particulier, documentez la discipline de look-ahead. Une erreur de look-ahead signifie que le modèle a vu une information dont il n'aurait pas disposé en temps réel. Exemple : utiliser les résultats retraités d'une société (publiés des mois plus tard) comme s'ils étaient disponibles à la date de publication initiale. Cette seule erreur est la cause la plus fréquente de backtests brillants qui tradent comme des déchets.

2. Validation indépendante

L'équipe qui construit le modèle ne peut pas être celle qui le valide. En pratique, un asset manager de taille moyenne dispose d'une fonction de validation qui réimplémente le signal depuis zéro, sur des données mises de côté, et tente de le casser. Ce n'est pas une formalité. La validation indépendante attrape la fuite de données subtile à laquelle les constructeurs sont aveugles parce qu'ils veulent que le modèle fonctionne.

3. Monitoring continu

Les marchés sont non stationnaires. Un signal qui fonctionnait dans le régime de taux bas de 2015 à 2021 peut être activement nuisible dans un régime de taux et d'inflation plus élevés. Le monitoring consiste à suivre la performance live par rapport aux attentes issues du backtest et à déclencher une revue quand elles divergent.

Les trois risques spécifiques à l'IA qui cassent les modèles d'investissement

Backtest overfitting

Testez suffisamment de stratégies sur l'historique et certaines paraîtront rentables par pur hasard. C'est le backtest overfitting : prendre la chance pour du talent.

Les maths sont impitoyables. Marcos Lopez de Prado a montré que si vous essayez de nombreuses configurations de stratégie et gardez le meilleur ratio de Sharpe, ce meilleur résultat est biaisé à la hausse, parfois massivement. Le Deflated Sharpe Ratio ajuste un Sharpe publié pour tenir compte du nombre d'essais réalisés et de la longueur du track record.

Un garde-fou simple et concret : loggez chaque backtest que vous lancez.

# Track the number of independent trials so you can deflate later
import json, datetime

def log_trial(strategy_id, config, sharpe):
    record = {
        "ts": datetime.datetime.utcnow().isoformat(),
        "strategy_id": strategy_id,
        "config": config,
        "in_sample_sharpe": sharpe,
    }
    with open("trials.log", "a") as f:
        f.write(json.dumps(record) + "\n")
    # Un Sharpe publié de 2,0 issu d'un seul essai est très différent
    # d'un Sharpe de 2,0 sélectionné comme le meilleur sur 500 essais.

Exemple chiffré (illustratif, pas une vraie stratégie) : supposons que vous testiez 100 variantes de signal et que la meilleure affiche un Sharpe annuel de 1,5 sur 5 ans. Parce que vous avez sélectionné le maximum de 100 estimations bruitées, une part significative de ce 1,5 relève de la chance de sélection. La déflation pourrait ramener le Sharpe « vrai » attendu vers 0,5 ou moins. La règle : plus vous avez essayé de configurations, plus la barre à franchir par le gagnant est haute.

Changements de régime

Un modèle ML apprend la distribution conjointe de ses données d'entraînement. Quand cette distribution change (changement de régime), le modèle ne sait pas qu'il est désormais en extrapolation.

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 → :

• Validation par régime. Ne vous contentez pas d'un découpage aléatoire des données. Testez explicitement sur des régimes définis : 2008, le choc COVID de 2020, le repricing des taux de 2022. Un signal qui ne fonctionne que dans des marchés calmes est un pari short volatilité déguisé.
• Monitoring du feature drift. Suivez si les distributions des inputs live correspondent à celles de l'entraînement. Si les inputs de votre signal value dérivent, l'alarme doit sonner avant le P&L.

Des signaux black-box qui décident de capitaux réels

Quand un modèle de gradient boosting ou un réseau de neurones produit un trade, « le modèle l'a dit » n'est pas une réponse acceptable pour un comité des risques.

Utilisez des outils d'explicabilité, le plus souvent SHAP (SHapley Additive exPlanations), qui attribue une prédiction à ses features d'entrée. Si le principal signal d'un modèle de stock picking devient soudain une feature obscure, c'est un signal d'alerte. L'explicabilité ne rend pas une black box sûre. Elle la rend auditable, ce qui est l'exigence de la gouvernance.

La carte réglementaire pour 2026

Le model risk dans l'IA d'investissement se situe désormais à l'intersection de plusieurs régimes bien réels.

• EU AI Act. En vigueur depuis 2024, avec une entrée en application progressive jusqu'en 2026 et 2027. Il classe les systèmes d'IA par niveau de risque. La plupart des modèles de portefeuille ne sont pas « à haut risque » au sens du règlement, mais les attentes en matière de gouvernance, de logging et de supervision humaine donnent le ton que les régulateurs européens appliqueront. Voir le texte officiel de l'EU AI Act.
• SEC (US). La proposition de règle de 2023 de la Securities and Exchange Commission sur les analyses prédictives de données et les conflits d'intérêts a signalé une surveillance intense de l'IA susceptible de placer l'intérêt d'une firme avant celui de son client. Début 2026, la forme finale est encore débattue : traitez ce point comme une cible mouvante et vérifiez le statut courant.
• DORA (UE). Le Digital Operational Resilience Act, applicable depuis janvier 2025, encadre le risque ICT et le risque tiers. Si votre modèle d'alpha tourne sur le cloud d'un prestataire ou utilise un flux de données fournisseur, DORA s'y applique.
• Royaume-Uni. La Financial Conduct Authority (FCA) privilégie une approche par principes, axée sur les résultats, plutôt que des règles prescriptives sur l'IA, en s'appuyant sur les régimes existants de responsabilité des dirigeants.

Le fil commun à tous : la responsabilité doit être attachée à une personne nommée, et les décisions doivent être documentées et reproductibles.

Une checklist de pré-déploiement réellement applicable

Avant qu'un signal ML ne touche du capital réel, passez ce filtre. Un seul point en échec, pas de déploiement.

Intégrité des données

• Pas de look-ahead. Données point-in-time confirmées.
• Biais du survivant vérifié (titres délistés présents dans l'univers).
• Les pipelines de données d'entraînement et live sont le même code.

Contrôle de l'overfitting

• Nombre d'essais loggé ; Deflated Sharpe appliqué.
• Tests out-of-sample et out-of-time réussis sur des données que le modèle n'a jamais vues.
• La performance survit à des coûts de transaction et un slippage réalistes.

Robustesse

• Testé sur au moins trois régimes de stress historiques.
• Monitors de feature drift configurés avec des seuils d'alerte.
• Capacité estimée : quel montant de capital avant que le signal ne fasse bouger le marché contre lui-même.

Gouvernance

• Validation indépendante signée et archivée.
• Model card rédigée ; owner nommé désigné.
• Kill switch défini : quelles conditions forcent la mise hors ligne du modèle, et qui a l'autorité de le débrancher.

Ce dernier point est le plus important. Le débouclage quant de 2007 n'a pas été causé par un mauvais modèle. Il a été causé par le fait que personne n'avait l'autorité ni le déclencheur pour sortir de la foule à temps.

Points clés

• Les trois piliers de SR 11-7 (développement, validation indépendante, monitoring continu) se transposent directement aux modèles d'investissement ML. Le constructeur ne corrige jamais sa propre copie.
• Le backtest overfitting est un risque mesurable, pas vague. Loggez vos essais et déflatez votre Sharpe. Un excellent backtest issu de 500 tentatives est généralement du bruit.
• Validez sur des régimes, pas sur des découpages aléatoires. Un modèle qui n'a fonctionné que de 2015 à 2021 est un pari caché sur la poursuite de ce régime.
• L'explicabilité rend les black boxes auditables, pas sûres. Utilisez SHAP pour repérer quand un modèle s'appuie sur des features qu'il ne devrait pas.
• Chaque modèle déployé a besoin d'un owner nommé et d'un kill switch. La responsabilité et une porte de sortie définie sont ce que les régulateurs (EU AI Act, SEC, FCA) exigent de plus en plus.