Le 28 du mois, le directeur financier d'un assureur vie découvre que son capital réglementaire a dérapé de 8 %. Personne ne sait pourquoi. Le calcul vit dans quatorze onglets Excel et trois notebooks, tenus par autant d'actuaires différents. Le régulateur attend une explication sous 48 heures. Personne ne peut la donner.
Le problème n'est pas actuariel. Il est industriel. Et c'est exactement là que Python dans dbt arrête d'être un sujet d'ingénieur pour devenir une décision de gouvernance financière.
Pourquoi le SQL ne suffit pas à clôturer Solvency II
Deux chiffres structurent la solvabilité d'un assureur. Le Best Estimate of Liabilities, c'est-à-dire la valeur attendue de tout ce qu'on devra payer aux assurés dans le futur. Et le capital de solvabilité requis (le SCR), le coussin de fonds propres que le régulateur impose pour absorber un choc.
Aucun des deux ne ressemble à un calcul que le SQL sait bien faire. Sur un portefeuille de cinq millions de contrats, projeter les flux sur quarante ans avec mille scénarios économiques produit des dizaines de milliards de lignes. Le SQL filtre et agrège ça sans peine.
Ce qu'il ne sait pas faire proprement, c'est le cœur du calcul actuariel : générer des milliers de scénarios aléatoires pour estimer une distribution de résultats, ce qu'on appelle une simulation Monte Carlo, ou ajuster des modèles statistiques sur la mortalité et les courbes de taux. Ces calculs réclament des bibliothèques scientifiques comme NumPy ou SciPy, et une logique qui n'a rien de déclaratif.
Résultat chez la plupart des assureurs : la chaîne actuarielle vit en dehors du data warehouse. Les données d'entrée viennent du système de gestion. Les calculs se font ailleurs, en Excel ou en notebook. Les sorties sont réinjectées à la main dans les tableaux de bord et les états réglementaires. Trois ruptures de chaîne, et aucune traçabilité entre la donnée brute et le capital publié.
C'est ce trou de gouvernance que Python dans dbt vient combler. Pour un directeur des risques, ce n'est pas un détail technique. Un écart inexpliqué entre deux clôtures déclenche un échange avec le régulateur qui mobilise une équipe risque pendant trois semaines. Multiplié par tous les rapports réglementaires de l'année, ce coût caché représente facilement deux temps plein actuariels. Deux temps plein qui ne produisent aucune analyse : ils refont des calculs déjà faits, parce que personne ne sait prouver que le premier passage était bon.
Concrètement, qu'est-ce qui change dans le pipeline
Un modèle Python dans dbt, c'est un fichier .py dans le projet, traité comme n'importe quel autre nœud du graphe. Il référence ses entrées, se documente et se teste avec les mêmes commandes que les modèles SQL. Il produit une table consommable comme une autre. Si l'idée d'orchestrer SQL et Python dans une même chaîne vous est nouvelle, notre guide sur dbt comme couche de transformation en pose les bases.
La différence tient à l'exécution. Le code Python ne tourne pas sur un ordinateur portable. Il est compilé par dbt puis exécuté par le moteur de la plateforme cible (sur Snowflake, c'est Snowpark). La simulation tourne là où la donnée vit. Pas de transfert massif. Pas de notebook qu'on relance le lundi matin parce que personne ne se souvient du dernier passage.
Voici à quoi ressemble une chaîne Solvency II industrialisée. Les premiers modèles font le travail SQL : nettoyer les contrats, joindre les référentiels produits, importer les scénarios économiques. Les modèles intermédiaires en Python font le calcul actuariel : projection des flux, agrégation par module de risque. Les derniers modèles reprennent la main en SQL pour produire les tables de reporting. Une seule chaîne, un seul orchestrateur, une seule traçabilité de la donnée d'entrée jusqu'au capital final. C'est le même principe de couches que l'architecture Médaillon, appliqué au calcul réglementaire.
Le bon dosage, ce n'est pas du Python partout
L'erreur classique, quand on découvre les modèles Python, c'est de vouloir tout migrer. Mauvaise direction.
La règle qu'on applique : 90 % du projet reste en SQL. Le moteur SQL d'un warehouse moderne est imbattable sur les jointures de portefeuille, les agrégations massives, les filtres par date. Y ajouter du Python ne ferait que ralentir l'exécution et brouiller la lecture du code.
Les 10 % qui méritent Python, c'est la complexité algorithmique pure. On la reconnaît à trois familles de calculs. Les simulations, quand il faut générer des milliers de scénarios pour estimer une distribution de résultats. La calibration, quand on ajuste un modèle mathématique sur des données de marché observées. Et les calculs itératifs, ceux qui bouclent sur la donnée étape par étape, chaque étape dépendant de la précédente. Tout le reste se traite mieux en SQL.
C'est ce mélange qui rend le projet lisible pour les analystes comme pour les actuaires. Et c'est lui qui sépare une vraie industrialisation d'un notebook qu'on aurait simplement renommé en .py. La logique est la même que pour la qualité du code : ce n'est pas l'outil qui la fait, c'est la discipline de découpage. Si vous voulez approfondir cette discipline, notre retour d'expérience sur comment refondre des modèles dbt maintenables détaille la méthode.
Pourquoi c'est une affaire de CFO, pas seulement d'IT
Pour le directeur financier et le directeur des risques, ça se mesure sur trois chiffres.
D'abord l'auditabilité. Chaque passage est versionné, et la traçabilité remonte de la donnée brute jusqu'au capital publié. Quand le régulateur demande de reconstituer un calcul d'un trimestre passé, la réponse prend des heures, pas des semaines. Sur un assureur qu'on opère, le délai de réponse aux contrôles est passé de trois semaines à six heures.
Ensuite la reproductibilité. Mêmes entrées, mêmes sorties, garanties. Fini l'Excel où un actuaire a changé une cellule en mars sans le noter. Les tests valident à chaque passage que les formules clés donnent le résultat attendu sur un jeu de référence. Si quelqu'un casse une formule, la chaîne ne livre pas en production. Cette logique de contrôle automatique rejoint celle des standards de qualité et data contracts.
Enfin le délai de clôture. La clôture trimestrielle passe de plusieurs semaines à quelques jours, non parce que le calcul devient magiquement plus rapide, mais parce qu'on supprime les manipulations manuelles entre systèmes et que les calculs qui tournaient en série sur un poste tournent désormais en parallèle dans le warehouse.
Pendant ce temps, la pression réglementaire monte, le coût des actuaires expérimentés grimpe, et les volumes de données doublent à chaque révision du référentiel. Garder la chaîne actuarielle dans Excel devient un choix qui coûte plus cher chaque trimestre.
Ce qu'on observe sur le terrain
On opère ce type de migration chez plusieurs assureurs et mutuelles depuis deux ans. Le piège récurrent n'est jamais technique, il est organisationnel.
Les actuaires détiennent une expertise réglementaire que personne ne sait répliquer. Les data engineers détiennent l'industrialisation. Les mettre dans la même chaîne impose un cadre clair : qui valide une formule, qui peut modifier un modèle critique, comment on teste un calcul réglementaire avant la production. Sans ce cadre, le projet finit en notebooks renommés et le problème de départ n'a pas bougé d'un millimètre.
Le bon point d'entrée n'est jamais le grand soir. C'est l'identification de trois ou quatre calculs où Python apporte une valeur immédiate. On industrialise ceux-là dans dbt, on garde le reste en SQL pour l'instant, et on étend par vagues. Premier résultat en production sous 6 à 8 semaines, mesurable et audité.
Python dans dbt ne remplace pas le SQL. Il sort la finance quantitative de son purgatoire Excel pour la mettre où elle aurait toujours dû être : dans le data warehouse, sous gouvernance, avec une traçabilité et des tests. Pour un directeur financier d'assureur, ça vaut largement la lecture d'une documentation technique.