Le stress testing bancaire, expliqué à un développeur

Quand j'ai écrit sur la VaR, j'ai laissé de côté sa limite la plus connue : elle décrit un jour normal, pas un jour de crise. Le stress testing bancaire répond précisément à la question que la VaR élude : que se passe-t-il si tout part mal en même temps ?

Le problème, en termes d'ingénierie#

Un test de charge classique augmente le trafic jusqu'à ce que le système craque, dans des conditions par ailleurs normales. Un stress test bancaire fait l'inverse d'un test de charge en un sens : il ne fait pas varier un seul paramètre, il simule un scénario complet où plusieurs choses tombent en panne en même temps (marché actions en baisse de 40 %, taux qui grimpent de 300 points de base, spreads de crédit qui s'écartent), le tout simultanément plutôt qu'un paramètre à la fois. La VaR répond « quelle est ma perte probable un jour ordinaire ». Le stress test répond « quelle est ma perte si le pire scénario plausible se matérialise ».

Deux familles de scénarios#

• Scénarios historiques : rejouer une crise déjà survenue (2008, mars 2020) sur le portefeuille actuel. L'avantage : le scénario est crédible par construction, il s'est déjà produit. La limite : il ne couvre que des combinaisons de chocs déjà vues, jamais une nouvelle combinaison.
• Scénarios hypothétiques : construire un choc qui n'a jamais eu lieu mais reste plausible (un choc de taux combiné à une chute spécifique d'un secteur). L'avantage : ça couvre des combinaisons que l'histoire n'a pas encore produites. La limite : la plausibilité du scénario dépend entièrement du jugement de qui le construit.

Un exemple chiffré simplifié#

Prenons un portefeuille actions de 50M€, avec une sensibilité de 1,2 (un choc de marché de x % se traduit par une perte de 1,2 × x % sur le portefeuille, en simplifiant très fortement une réalité faite de betas différents par ligne) :

Scénario historique (type mars 2020) : marché actions -30 %
Perte estimée = 50 000 000 × 1,2 × 0,30
             = 18 000 000 €

Scénario hypothétique (choc de taux +300 bps combiné à un choc actions -15 %)
Perte estimée (composante actions) = 50 000 000 × 1,2 × 0,15
                                   = 9 000 000 €
+ perte sur la composante taux, calculée séparément sur les positions obligataires

Le scénario historique produit ici la perte la plus sévère, mais ce n'est pas systématique : un scénario hypothétique bien construit peut dépasser tous les scénarios historiques connus, c'est même souvent l'objectif recherché en le construisant.

Pourquoi Bâle III en fait une obligation, pas une option#

Bâle III ne se contente pas de recommander le stress testing, il conditionne une partie du capital réglementaire exigé au résultat de ces scénarios (le Pilier 2 du dispositif prudentiel). Une banque dont les stress tests révèlent une vulnérabilité concentrée sur un scénario donné doit détenir plus de capital en réserve, même si sa VaR quotidienne reste dans les clous. C'est ce qui distingue le stress testing d'un simple exercice académique : le résultat a un coût en capital immobilisé, donc un impact direct sur la rentabilité de la banque.

Pourquoi c'est un bon terrain pour un développeur curieux#

Techniquement, un moteur de stress testing ressemble à un moteur de simulation de scénarios : appliquer le même scénario à des milliers de positions hétérogènes (actions, taux, crédit, dérivés), agréger les pertes de façon cohérente, et le faire assez vite pour tester plusieurs dizaines de scénarios sur l'ensemble du portefeuille. C'est un problème de performance autant que de finance, et c'est exactement le genre de calcul que kotlin-counterparty-risk illustre déjà sur le risque de contrepartie : une fois qu'on sait simuler une exposition future (PFE), rejouer cette même simulation sous un scénario de stress plutôt que sous une distribution normale de marché est une extension naturelle, pas une réécriture.