Data lineage et gouvernance pour le reporting réglementaire

Un chiffre figure dans la cellule D47 d'un template QRT Solvabilité II : « Best Estimate Liabilities, Line of Business 12, 340 662 000 EUR ». Un auditeur demande : d'où vient-il ? Si personne dans la salle ne peut le retracer, étape par étape, jusqu'à un enregistrement de police dans le système de gestion source, ce reporting présente un lineage gap. Les lineage gaps sont systématiquement le premier constat des audits de données réglementaires chez les assureurs européens et américains, d'après les rapports de revue prudentielle de l'EIOPA (European Insurance and Occupational Pensions Authority) et les examens NAIC (National Association of Insurance Commissioners) au niveau des États. Cette leçon porte sur la façon de combler cet écart : ce qu'est le lineage, comment le construire, et comment mesurer si votre gouvernance fonctionne réellement.

Ce que « lineage » veut dire en pratique

Le data lineagedata lineageLe data lineage cartographie les déplacements et transformations de la donnée à travers les systèmes, de l'origine à la consommation : d'où elle vient, ce qui l'a modifiée, et où elle va.Voir la définition complète → est le chemin documenté et traçable qu'emprunte un élément de donnée depuis son origine (un système source), à travers chaque transformation, agrégation et chargement, jusqu'à sa destination finale dans un rapport.

Chez un assureur, un chiffre reporté passe généralement par :

1. Systèmes sources/opérationnels : gestion des polices (primes, conditions de couverturecouvertureLe nombre de personnes uniques exposées à votre message sur une période donnée. Contrairement aux impressions, le reach compte chaque personne une seule fois, quel que soit le nombre d'expositions.Voir la définition complète →), systèmes de sinistres (réserves, paiements), systèmes de réassurance (montants cédés).
2. Data warehouse ou data lake : là où les enregistrements sont extraits, transformés et chargés (ETLETLL'ETL (Extract, Transform, Load) est un processus d'intégration de données qui extrait les données de sources multiples, les remet en forme dans un format cohérent et les écrit dans un système cible.Voir la définition complète →).
3. Modèles actuariels : moteurs de provisionnement, modèles de capital (par exemple modèles internes ou formule standard sous Solvabilité II).
4. Couche de reporting : l'outil qui alimente les QRT (Quantitative Reporting Templates) ou les annexes de l'Annual Statement du NAIC.

La documentation de lineage répond à trois questions pour chaque chiffre reporté : d'où vient-il, que lui est-il arrivé, et qui l'a manipulé.

Pourquoi les régulateurs y tiennent particulièrement

Deux régimes réglementaires structurent cette leçon :

• Solvabilité II (UE, en vigueur depuis 2016, supervisé par l'EIOPA et les régulateurs nationaux comme la BaFin en Allemagne ou l'ACPR en France) impose aux assureurs de transmettre des QRT ainsi qu'un RSR (Regulatory Supervisory Report) et un SFCR (Solvency and Financial Condition Report) annuels. Ses exigences de reporting « Pilier 3 » demandent explicitement des standards de qualité des données : exactitude, exhaustivité et adéquation (article 19 du règlement délégué 2015/35).
• Les exigences du NAIC aux États-Unis, appliquées État par État, encadrent l'Annual Statement, les déclarations RBC (Risk-Based Capital) et, depuis 2020, l'usage croissant des propres outils de collecte et d'analyse de données du NAIC. Il n'existe pas d'équivalent fédéral unique à Solvabilité II ; la supervision américaine est étatique, coordonnée par les standards du NAIC.

Les deux régimes convergent vers la même attente : les assureurs doivent pouvoir démontrer, sur demande, comment un chiffre a été produit. On parle souvent de « data traceability » ou d'« auditability ».

Les lignes directrices de l'EIOPA sur la gouvernance interne citent explicitement la documentation du data lineage comme une attente prudentielle, et pas seulement comme une bonne pratique.

Anatomie d'un lineage gap

Un écart apparaît dès qu'un maillon de la chaîne n'est pas documenté ou n'est pas vérifiable. Les causes fréquentes sur le terrain :

• Ajustements manuels sur tableur entre le warehouse et le modèle actuariel, sans contrôle de version ni journal de validation.
• Migrations de systèmes (événement courant après une opération de M&A) où la logique de mapping historique est perdue.
• Propriété floue des champs « brut vs net de réassurance », entraînant double comptage ou omission.
• Règles métier non documentées dans le code ETL, par exemple un taux de conversiontaux de conversionLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète → de devise codé en dur il y a des années et jamais revu.

Un enregistrement de lineage simplifié pour notre chiffre d'exemple pourrait ressembler à ceci :

Field: Best_Estimate_Liabilities_LoB12
Source: PolicyAdmin_System_EU (table: claims_reserve, field: reserve_amt)
Extract date: 2026-03-31
Transformation 1: currency conversion GBP->EUR, rate source = ECB daily rate
Transformation 2: aggregation by LoB per EIOPA LoB mapping table v4.2
Transformation 3: actuarial adjustment, model: Reserving_Model_v7.1, run_id: 20260405_02
Loaded to: QRT_S.17.01, cell D47
Approved by: Head of Actuarial Reporting, 2026-04-10

Cette dernière ligne compte autant que la trace technique : la gouvernance n'est pas seulement une affaire d'IT, c'est une affaire de responsabilité.

Rôles de gouvernance et métriques de contrôle

Les frameworks de gouvernance attribuent des responsabilités pour que le lineage ne repose pas sur la mémoire institutionnelle. Structure standard :

• Data owner : responsable d'un domaine de données (par exemple, le Head of Underwriting est propriétaire des données de polices).
• Data stewardData stewardUn responsable côté métier, garant de la qualité, de la cohérence et du bon usage des données de son domaine.Voir la définition complète → : gère opérationnellement la qualité et les définitions au quotidien.
• Comité qualité des données : examine les métriques et arbitre les priorités de remédiation, souvent rattaché à un Chief Data Officer.

Les métriques que les conseils d'administration et les régulateurs regardent réellement (les chiffres ci-dessous sont des benchmarks sectoriels indicatifs, à considérer comme des estimations et non comme des seuils universels) :

Exemple chiffré : supposons qu'un assureur ait 1 200 CDE alimentant ses QRT Solvabilité II. Un audit interne trouve une documentation de lineage complète pour 1 050 d'entre eux.

Couverture de lineage = 1 050 / 1 200 = 87,5 %

Si la cible interne est de 90 %, cet assureur a un écart de 2,5 points de pourcentage, soit environ 30 champs, à corriger avant le prochain cycle de reporting. Cet écart devient le constat d'audit.

Le lien avec BCBS 239BCBS 239Principe du Basel Committee on Banking Supervision imposant aux grandes banques une traçabilité stricte des données de risque, ayant catalysé la création de nombreux postes de CDO dans le secteur bancaire.

Bien qu'écrits pour les banques, les principes BCBS 239 du Comité de Bâle (« Principles for effective risk data aggregation and risk reporting », 2013) sont largement utilisés par les équipes data des assureurs comme modèle de gouvernance, parce qu'ils sont plus granulaires que le texte de Solvabilité II lui-même. Principes directement transposables : les données doivent être exactes, exhaustives, produites en temps voulu et adaptables, et les entreprises doivent pouvoir reproduire les rapports et les retracer jusqu'à la source sans délai significatif, ce que les praticiens interprètent généralement comme la capacité à répondre à une demande ad hoc du régulateur en quelques jours, pas en quelques semaines.

Construire un programme de lineage : étapes pratiques

1. Classez d'abord les CDE. N'essayez pas de documenter le lineage de tous les champs du warehouse. Commencez par ceux qui alimentent les QRT, les chiffres narratifs du SFCR et les calculs RBC.
2. Automatisez la capture quand c'est possible. Les outils ETL et les data catalogs modernes (Collibra, Informatica, Apache Atlas par exemple) peuvent générer automatiquement le lineage technique à partir des métadonnées des pipelines, réduisant la dépendance à une documentation manuelle qui se périme.
3. Journalisez chaque intervention manuelle. Si un actuaire ajuste un chiffre dans Excel avant son entrée dans le modèle, cette étape doit avoir un horodatage, un nom et une justification.
4. Testez le lineage, ne vous contentez pas de le documenter. Menez régulièrement des exercices de « trace-back » : prenez un chiffre reporté au hasard et demandez à quelqu'un extérieur à l'équipe d'origine de reconstruire son lineage à partir de la seule documentation. S'il n'y parvient pas, la documentation a échoué à son vrai test.
5. Reliez la remédiation aux métriques de gouvernance, et présentez ces métriques au comité des risques du conseil, pas seulement à l'IT.

🎬 [VIDEO: « What is Data Lineage? » - youtube.com - une courte vidéo accessible sur les concepts de data lineage applicables à toutes les industries régulées, utile pour un public non technique avant d'entrer dans les spécificités de l'assurance]

Points clés

• Le data lineage est le chemin traçable d'un chiffre depuis le système source jusqu'au reporting réglementaire ; les lineage gaps sont le constat le plus fréquent des audits de données Solvabilité II et NAIC.
• Solvabilité II (supervisé par l'EIOPA, UE) et le framework américain étatique du NAIC exigent tous deux des assureurs qu'ils démontrent l'exactitude, l'exhaustivité et la traçabilité des chiffres reportés, pas seulement qu'ils produisent le bon chiffre final.
• Gouvernez avec des rôles clairs : data owners, data stewards et un comité qualité des données, et mesurez avec des métriques concrètes comme la couverture de lineage et le ratio d'ajustements manuels.
• Un exemple chiffré : 1 050 CDE documentés sur 1 200 donnent 87,5 % de couverture de lineage, en dessous d'une cible interne courante de 90 %, et c'est précisément ce déficit que les examinateurs relèvent.
• BCBS 239, bien qu'issu du monde bancaire, est largement repris par les assureurs comme standard de gouvernance granulaire et pratique pour l'agrégation des données et l'intégrité du reporting.