Solvabilité II et data centers IA : un module de concentration qui ne voit pas la couche technologique

Ce dossier applique les critères d’assurabilité de Berliner à la dépréciation GPU et documente son échec au premier d’entre eux, l’indépendance des sinistres. Une question reste ouverte : le cadre de capital réglementaire qui s’applique aux réassureurs européens, dont Swiss Re, est-il lui-même construit pour repérer ce type de concentration avant qu’un sinistre corrélé ne survienne ? Le règlement délégué 2015/35, qui décline Solvabilité II dans le calcul du capital de solvabilité requis, consacre un sous-module entier à la concentration. Mais il vise une exposition différente de celle que ce dossier documente.

Le règlement délégué (UE) 2015/35 calcule le SCR de concentration du marché sur la base d’expositions par contrepartie unique, l’exposition d’un réassureur à un même émetteur au sein des actifs financiers qu’il détient en portefeuille [1].
Ce sous-module ne définit à aucun moment une exposition symétrique côté engagements souscrits : rien n’oblige un réassureur à mesurer la part de son portefeuille de polices data center qui dépend d’un même fournisseur de calcul.
Cette asymétrie peut justifier de considérer que le cadre prudentiel actuel n’est pas équipé pour signaler, en amont d’un sinistre corrélé, une concentration que les critères de Berliner disqualifient déjà comme risque assurable au sens dommages du terme.

Un sous-module construit pour l’actif financier, pas pour l’engagement souscrit

Ce que les données établissent. Le règlement délégué 2015/35 définit, à ses articles 182 à 187, le sous-module de concentration de risque de marché. Le calcul repose sur la notion d’exposition par contrepartie unique : les expositions envers des entités appartenant à un même groupe sont agrégées. Le capital requis pour chaque exposition correspond à la perte de fonds propres de base qu’entraînerait une baisse instantanée de la valeur des actifs qui s’y rattachent [1]. Le texte vise explicitement le risque de perte lié à un manque de diversification du portefeuille d’actifs, ou à une exposition trop concentrée sur un même émetteur de titres. C’est un module pensé pour ce qu’un réassureur possède en placement, actions, obligations, immobilier, pas pour ce qu’il assure.

Ce que Berliner teste, ce que Solvabilité II ne teste pas

Mon interprétation. Le premier critère de Berliner, déjà mobilisé ailleurs dans ce dossier, pose que les sinistres d’un portefeuille doivent rester statistiquement indépendants pour que la mutualisation fonctionne [2]. Appliqué à un portefeuille de polices data center IA qui partagent toutes le même fournisseur de calcul et la même dépendance à un composant logiciel unique, un choc technologique commun, dévaluation, faille de sécurité, rupture d’approvisionnement, toucherait potentiellement plusieurs souscriptions au même moment. Causalité plausible non démontrée à ce stade : aucune donnée empirique ne mesure aujourd’hui ce degré de corrélation réel sur un portefeuille existant. Mais le sous-module de concentration du règlement délégué, qui pourrait en théorie servir de signal d’alerte précoce pour ce type de risque, ne le mesure pas, parce qu’il ne regarde que le passif des placements, jamais la composition technologique du passif d’engagements. ==Un réassureur peut être parfaitement diversifié au sens réglementaire sur son portefeuille de placements tout en souscrivant, côté engagements, une concentration équivalente à celle que Berliner disqualifie.==

Le capital de solvabilité requis mesure la concentration de ce qu’un réassureur possède, jamais la concentration de ce qu’il assure : deux expositions distinctes, une seule dotée d’une charge en capital dédiée.

Le candidat le plus évident pour mesurer ce risque ne le fait pas non plus

Ce que les données établissent. Solvabilité II mesure par ailleurs un risque de concentration côté souscription, mais ailleurs dans la formule standard : le sous-module de risque catastrophe non-vie, qui se décompose en quatre volets, catastrophe naturelle, catastrophe liée à la réassurance non-proportionnelle de dommages, catastrophe non-vie provoquée par l’homme, et autres catastrophes non-vie. C’est le candidat le plus direct pour capter une concentration de sinistres corrélés côté engagements. Mon interprétation. Ses catégories de catastrophe provoquée par l’homme couvrent historiquement des risques nommés comme la responsabilité civile, l’automobile, le transport maritime et aérien, l’incendie, le crédit et le cautionnement, pas une catégorie dédiée à la dépendance technologique partagée d’un portefeuille de polices data center. Si ce sous-module couvrait déjà ce risque sous une autre étiquette, l’angle mort documenté ici n’en serait pas un ; à défaut d’un texte qui l’établisse explicitement, cette vérification reste elle-même une extrapolation prudente, pas une preuve exhaustive qu’aucun autre recoin de la formule standard ne capte ce risque.

Un silence que je n’ai pas trouvé documenté ailleurs

Ce que les données établissent. Je n’ai trouvé aucune déclaration publique de l’EIOPA ou d’un superviseur national qui identifie explicitement ce type de concentration technologique côté souscription pour les data centers IA. L’EIOPA a en revanche documenté un sujet voisin, mais distinct : le risque cyber non affirmatif, c’est-à-dire les expositions cyber non identifiées comme telles dans des polices qui ne les couvrent pas nommément [4]. Cette déclaration relève de la surveillance des pratiques de gestion des assureurs, pas du calcul de capital lui-même : elle ne crée ni ne modifie de charge en capital dédiée dans le sous-module de concentration de marché ni dans le sous-module catastrophe. Extrapolation prudente : si le superviseur a jugé nécessaire de sortir le risque cyber non affirmatif du calcul standard pour le traiter séparément, un raisonnement analogue pourrait un jour s’appliquer à la concentration technologique par fournisseur commun de data centers IA. Rien, à ce stade, n’indique qu’un tel chantier soit engagé.

Mes réserves

Le texte du règlement délégué 2015/35 est vérifié directement sur ses articles 182 à 187 [1], mais l’absence de déclaration EIOPA sur ce point précis ne prouve pas que le sujet n’a jamais été discuté en interne par un superviseur, seulement qu’aucune publication ne le documente aujourd’hui de façon repérable. L’exposition réelle d’un réassureur comme Swiss Re à un portefeuille de data centers concentré sur un même fournisseur de calcul reste, par nature, confidentielle : aucune source publique ne permet de vérifier si la situation décrite ici est déjà une réalité de marché ou seulement un scénario prospectif.

L’implication concrète : un superviseur ou un réassureur qui veut anticiper ce risque avant un sinistre corrélé gagne à construire, en interne, un indicateur de concentration technologique souscrite, mesurant la part du portefeuille de polices data center dont la valeur assurée dépend d’un même fournisseur de calcul ou d’un même composant logiciel critique, plutôt que d’attendre qu’un futur amendement du règlement délégué ne l’impose.

Écart au Standard Probans

Je publie cet article sous mon seuil de qualité interne. Les trois critères que je considère non négociables, l’exactitude factuelle, la qualité des sources, l’originalité de l’angle, sont respectés ; l’écart tient à trois dimensions que j’assume comme perfectibles.

Insight original. L’indicateur de concentration technologique souscrite, que j’esquisse dans l’implication concrète, reste une définition en une phrase : pas de nom retenable, pas de formule de calcul explicite, pas de seuil d’alerte ni d’exemple chiffré. Ce n’est pas encore un objet intellectuel propriétaire que je peux revendiquer comme citable indépendamment de la marque.

Clarté / pédagogie. Je publie cet article comme page autonome, mais il suppose une familiarité préalable avec le reste du dossier (les critères de Berliner, la structure du SCR) : un lecteur qui arrive directement dessus, sans avoir lu le reste du dossier, décrochera sur plusieurs phrases denses en jargon Solvabilité II.

Utilité décisionnelle. Dans l’implication concrète, je recommande de construire un indicateur interne, mais je reste au niveau de la recommandation : je ne fournis ni méthode de calcul opérationnalisable, ni seuil d’alerte, ni exemple chiffré même illustratif pour amorcer ce travail.

Retour au dossier Assurer les data centers IA · Lire la Décision possible du dossier.