Le risque de défaut, expliqué à un développeur

Dans l'article sur le risque de contrepartie, EAD, PFE et CVA répondaient à un cas particulier : une exposition qui varie dans le temps, sur un contrat dérivé bilatéral. Le risque de défaut est le problème plus général dont la contrepartie n'est qu'une application : il se pose exactement de la même façon pour un prêt bancaire, une obligation d'entreprise, ou une ligne de crédit, dès qu'une somme est due dans le futur par quelqu'un qui peut ne pas être en mesure de la rembourser.

PD : estimer une probabilité de défaut#

La PD (Probability of Default) répond à une question directe : sur un horizon donné, souvent un an, quelle est la probabilité que cet emprunteur fasse défaut ? C'est l'équivalent financier d'un taux de panne historique : de la même façon qu'on estime la fiabilité d'un fournisseur cloud à partir de son historique d'incidents, une banque estime la PD d'un emprunteur à partir de son historique de paiement, de sa structure financière, et de son secteur d'activité.

Les agences de notation traduisent ce travail en une échelle lisible. Les ordres de grandeur suivants sont illustratifs, pas des chiffres de référence à citer tels quels : la PD réelle d'une note donnée varie selon l'agence, le cycle économique, et le secteur.

LGD : ce qu'on perd vraiment si le défaut survient#

Un défaut ne signifie pas une perte totale. La LGD (Loss Given Default) mesure la part réellement perdue, une fois le recouvrement pris en compte : LGD = 1 - taux de recouvrement. Un prêt garanti par un actif liquide (immobilier, nantissement de titres) a une LGD basse, souvent 20 à 40 %, parce que la garantie limite la perte réelle. Un crédit non garanti, en dernier rang de remboursement en cas de faillite, a une LGD élevée, parfois au-delà de 60 %, parce qu'il n'y a rien à saisir en priorité.

EAD, déjà vue, un rappel utile#

L'EAD (Exposure At Default) a été détaillée dans l'article sur le risque de contrepartie : c'est le montant exposé au moment où le défaut survient. Sur un prêt classique à montant fixe, l'EAD est simple, c'est le capital restant dû. Sur une ligne de crédit renouvelable, elle est plus incertaine, parce qu'un emprunteur en difficulté a tendance à tirer davantage sur sa ligne juste avant de faire défaut, ce qui pousse l'EAD au-dessus du solde observé aujourd'hui.

La formule qui réunit les trois : Expected Loss#

Les trois briques se combinent en une seule métrique, la perte attendue :

Expected Loss = PD × LGD × EAD

Exemple : un prêt corporate de 5 000 000 €, noté BB (PD = 1,2 %),
non garanti (LGD = 55 %)

EL = 0,012 × 0,55 × 5 000 000
   = 33 000 €

Ces 33 000 € ne sont pas une prédiction sur ce prêt précis, dont l'issue est binaire (défaut ou pas défaut). C'est une moyenne statistique, valable sur un grand portefeuille de prêts comparables : sur des milliers de crédits notés BB et non garantis, la perte moyenne observée tend vers ce chiffre, même si chaque prêt individuel finit soit intact, soit totalement en défaut. Le schéma résume comment les trois briques se combinent, sur cet exemple précis :

Perte attendue contre perte inattendue : deux traitements différents#

C'est la distinction la plus utile du sujet, et celle qui prépare directement la question du capital réglementaire. L'Expected Loss est traitée comme un coût normal de l'activité de prêt : une banque la provisionne à l'avance, elle est intégrée dans le prix du crédit, exactement comme on intègre le coût attendu du support client dans le prix d'un abonnement.

Ce que la provision ne couvre pas, c'est l'écart entre cette moyenne et un scénario où plusieurs emprunteurs font défaut simultanément, par exemple pendant une récession. Cet écart s'appelle la perte inattendue (Unexpected Loss), et il n'est pas couvert par une provision mais par du capital propre, mis de côté justement pour absorber le jour où la moyenne ne suffit plus. C'est précisément ce que Bâle III et Bâle IV réglementent : combien de capital une banque doit détenir pour que cette perte inattendue ne la mette pas en défaut elle-même.

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

Ce qui rend le calcul intéressant techniquement, ce n'est pas la formule elle-même, trois multiplications ne justifient pas un article. C'est l'estimation de chacun des trois paramètres, qui repose sur des modèles statistiques entraînés sur des historiques de défaut, recalibrés régulièrement, et validés indépendamment avant d'être utilisés pour calculer du capital réglementaire. C'est ce terrain que kotlin-counterparty-risk et Finance for Engineers rendent manipulable, en TDD, sans avoir besoin d'un accès à un système bancaire réel pour comprendre où PD, LGD et EAD viennent réellement de quelque part.