+150 XP

Cartographier le paysage des données assurantielles de bout en bout

Un seul sinistre auto peut transiter par onze systèmes différents avant qu'un chèque soit émis : le système de gestion des contrats, un flux télématique issu du téléphone du conducteur, la plateforme de devis d'un carrossier, une API de rapport de police, une interrogation d'un bureau de crédit, le fichier de traité d'un réassureur, entre autres. Aucun de ces systèmes n'a été conçu pour dialoguer avec les autres. Votre travail, en tant que personne qui doit décider à partir de ces données, consiste à savoir lequel dit la vérité.

Cette leçon parcourt la donnée de bout en bout : d'où elle vient, comment elle se consolide, et quelles métriques vous indiquent si vous pouvez lui faire confiance.

Les principales sources de données

L'entrepôt de chaque assureur repose sur une poignée de types de sources récurrents. Apprenez-les et vous saurez lire n'importe quel schéma d'architecture de données d'assureur.

Systèmes de gestion des contrats (PAS, policy administration systems). Le système de référence pour ce qui a été vendu : plafonds de garantie, primes, avenants, dates d'effet. Exemples d'éditeurs : Guidewire, Duck Creek, Sapiens. C'est généralement le « golden record » (la version unique faisant autorité pour un champ de données, utilisée lorsque plusieurs systèmes divergent) pour les conditions du contrat.

Systèmes de gestion des sinistres. Ils suivent un sinistre depuis la déclaration (FNOL, First Notice of Loss) jusqu'au règlement. Guidewire ClaimCenter et Duck Creek Claims dominent le marché américain. Les données sinistres constituent le golden record pour les montants de perte, les provisions et les dates de règlement, même si les données contrat y sont injectées.

Systèmes de facturation et de comptabilité des primes. Ils suivent ce qui a été effectivement facturé et encaissé, ce qui diverge fréquemment de ce que le contrat indique comme dû, en raison de modifications en cours d'année, de résiliations ou de délais de grâce.

Systèmes de réassurance. Ils suivent les affaires cédées, c'est-à-dire la part de risque qu'un assureur transfère à un réassureur (une société qui assure les assureurs) comme Munich Re ou Swiss Re. Ces systèmes détiennent le golden record pour les conditions de traité et les recouvrables (montants dus en retour à la cédante).

Données de bureaux tiers. Sources d'enrichissement externes : bureaux de crédit (Equifax, TransUnion), relevés d'informations véhicule, rapports CLUE (Comprehensive Loss Underwriting Exchange, une base américaine d'historique de sinistres gérée par LexisNexis), et modèles catastrophe d'éditeurs comme Verisk ou Moody's RMS. Aucune n'est un golden record pour les champs internes, mais elles constituent souvent le *seul* enregistrement de faits de risque externes, comme un sinistre antérieur non déclaré.

Données télématiques et IoT. Les programmes d'assurance à l'usage (UBI) comme Snapshot de Progressive ou Drive Safe & Save de State Farm génèrent des flux bruts de comportement de conduite (freinage, vitesse, kilométrage) qui sont agrégés en scores de risque avant d'atteindre l'entrepôt.

Données de distribution et CRM. Portails courtiers et agents, moteurs de devis, logs de centres d'appels. Souvent la source la plus désordonnée, car la qualité de saisie varie selon l'intermédiaire.

Les couches de données réglementaires à connaître

Aux États-Unis, les états statutaires de la NAIC (National Association of Insurance Commissioners) imposent un reporting standardisé sur les provisions techniques et les primes, ce qui explique que les assureurs américains maintiennent un « data mart statutaire » parallèle, distinct de leurs données de reporting GAAP (Generally Accepted Accounting Principles).

En Europe, Solvabilité II (la réglementation européenne de solvabilité fondée sur le risque, en vigueur depuis 2016) exige une documentation granulaire du lineage pour tout ce qui alimente les calculs de capital, ce qui explique que les assureurs européens investissent lourdement dans l'outillage de data governance dédié au reporting réglementaire, sous la supervision de l'EIOPA (European Insurance and Occupational Pensions Authority).

À qui appartient le golden record ?

C'est la compétence la plus utile de cette leçon : pour un champ donné, savoir quel système fait autorité.

ChampDétenteur du golden recordPourquoi
Plafond de garantieSystème de gestion des contratsC'est le contrat
Montant de la provision sinistreSystème sinistresLes gestionnaires l'actualisent en continu
Adresse clientGénéralement le CRM, parfois le PASDépend du dispositif MDM de l'assureur
Historique de sinistres antérieursBureau (CLUE)Les systèmes internes ne voient que leur propre historique
Montant de perte cédéeSystème de réassuranceLes conditions de traité y résident
Score d'assurance fondé sur le créditFlux du bureau de créditCalculé en externe, ingéré en lecture seule

Quand deux systèmes divergent, ce tableau est votre première étape de diagnostic. Un écart entre la prime du PAS et celle du système de facturation n'est pas nécessairement une erreur ; il peut signifier qu'un avenant en cours d'année n'a pas encore été synchronisé.

Comment tout cela se consolide : le pipeline

La plupart des grands assureurs exploitent aujourd'hui une variante de ce flux :

Source systems (PAS, Claims, Billing, Reinsurance, Bureau feeds)
        ↓ (batch ETL or streaming CDC)
Data lake / landing zone (raw, schema-on-read)
        ↓ (transformation, validation rules)
Enterprise data warehouse (conformed, modeled)
        ↓
Master Data Management (MDM) layer resolves entity conflicts
        ↓
Reporting marts (actuarial, finance, regulatory) + ML feature stores

Le CDC (Change Data Capture) remplace de plus en plus l'ETL (Extract, Transform, Load) en batch nocturne, car les gestionnaires de sinistres et les souscripteurs attendent désormais une visibilité quasi temps réel. Une règle de validation basique exécutée au niveau de la landing zone pourrait ressembler à ceci :

sql
-- Signaler les sinistres dont le montant payé dépasse le plafond de garantie (contrôle de qualité de données courant)
SELECT claim_id, policy_id, paid_amount, coverage_limit
FROM claims_landing c
JOIN policy_snapshot p ON c.policy_id = p.policy_id
WHERE c.paid_amount > p.coverage_limit
  AND c.paid_amount IS NOT NULL;

Ce type de règle détecte les bugs d'intégration (un sinistre rattaché à la mauvaise version de contrat) avant qu'ils ne contaminent le provisionnement en aval.

Vérification des acquis

1. Si les données du système de gestion des contrats et celles du système de gestion des sinistres divergent sur le plafond de garantie d'un sinistre ouvert, quelle valeur doit généralement faire autorité, et pourquoi ?

2. Pourquoi les données de facturation et de comptabilité des primes peuvent-elles diverger de ce que le système de gestion des contrats indique comme dû ?

3. Quelle est la principale raison pour laquelle un seul sinistre auto peut transiter par des systèmes comme des flux télématiques, des plateformes de devis de carrossiers et des API de rapports de police, dont aucun n'a été conçu pour interopérer ?

CHOIX MULTIPLES

4. Sélectionnez TOUTES les réponses correctes concernant les systèmes qui font office de « golden record » pour des types de données spécifiques dans le paysage des données assurantielles.

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Sélectionnez TOUTES les réponses correctes expliquant pourquoi comprendre les types de systèmes sources récurrents importe pour quelqu'un qui décide à partir de données d'assurance.

Sélectionnez toutes les réponses correctes.

Les métriques de qualité de données qui comptent

Les frameworks génériques de qualité de données (complétude, exactitude, fraîcheur, cohérence) s'appliquent ici, mais l'assurance leur donne des dents précises et mesurables.

Taux de complétude : pourcentage de champs obligatoires renseignés. Une cible courante pour les champs sinistres critiques (date de survenance, cause du sinistre) se situe au-dessus de 98 pour cent ; en deçà, les modèles actuariels de provisionnement commencent à produire des résultats peu fiables.

Taux de rapprochement en entity resolution : lorsque le MDM tente de relier « John A. Smith » entre le CRM, le PAS et un flux de bureau, les assureurs suivent généralement la part qui se résout automatiquement par rapport à celle qui nécessite une revue manuelle. Les praticiens du secteur citent souvent des taux de rapprochement automatique de 80 à 95 pour cent comme sains, mais cela varie énormément d'un assureur à l'autre et ne constitue pas un benchmark universel ; considérez tout chiffre précis comme une estimation.

Délai / latence : le temps écoulé entre un événement (un paiement de sinistre) et son apparition dans l'entrepôt. Le reporting réglementaire sous Solvabilité II ou les états statutaires NAIC exige typiquement une finalité mensuelle ou trimestrielle, mais le provisionnement interne réclame de plus en plus des flux quotidiens ou quasi temps réel.

Taux d'écarts de réconciliation : le pourcentage d'enregistrements qui ne se rapprochent pas entre deux systèmes censés concorder, par exemple la prime comptabilisée dans le PAS face à la prime reconnue au grand livre. Les équipes finance et actuariat le suivent mensuellement ; un taux d'écarts en hausse est un signal précoce de défaillance d'intégration.

Couverture du lineage : le pourcentage de champs reportables dont le lineage jusqu'à la source est documenté et auditable. Les examinateurs Solvabilité II en Europe le testent spécifiquement lors de la validation des modèles.

Un exemple chiffré simple : si un assureur traite 500 000 sinistres par an et que les tests de complétude en trouvent 9 500 sans code obligatoire de « cause du sinistre », le taux de complétude = (500 000, 9 500) / 500 000 = 98,1 pour cent. On est juste au niveau du seuil interne courant, ce qui vaut la peine d'être signalé au comité de data governance plutôt qu'ignoré.

Les structures de gouvernance derrière les métriques

La plupart des assureurs formalisent cela via un Data Governance Council, associant typiquement un Chief Data Officer à des responsables actuariat, conformité et IT, et un modèle de data stewardship où des propriétaires métier nommés (pas l'IT) sont responsables de domaines spécifiques, comme le « claims data steward » ou le « policy data steward ». C'est une pratique standard chez les grands assureurs et elle devient de plus en plus obligatoire, et non optionnelle, compte tenu à la fois des exigences documentaires de Solvabilité II en Europe et du renforcement des attentes de la NAIC en matière de gouvernance des modèles aux États-Unis, à la suite de l'essor des outils de souscription fondés sur l'IA.

Pour une introduction pratique aux dimensions de la qualité de données applicables à tous les secteurs, voir l'aperçu du framework DAMA-DMBOK, un standard largement référencé en data management.

How Insurance Companies Use Data

Watch on YouTube

Points clés

  • Les données d'assurance proviennent de sources structurellement différentes (gestion des contrats, sinistres, réassurance, bureaux, télématique), chacune avec son propre golden record ; les divergences entre systèmes sont souvent des questions de timing, pas des erreurs.
  • Prenez l'habitude de demander « quel système détient ce champ ? » avant de diagnostiquer un écart de données ; c'est le raccourci diagnostique le plus rapide du secteur.
  • Les métriques de qualité de données les plus utiles opérationnellement : taux de complétude, taux de rapprochement en entity resolution, latence et taux d'écarts de réconciliation ; suivez-les mensuellement, pas annuellement.
  • Les cadres réglementaires (NAIC aux États-Unis, Solvabilité II et EIOPA en Europe) imposent de plus en plus un lineage documenté, ce qui fait passer la gouvernance du confort à l'exigence d'audit.
  • Considérez tout pourcentage de benchmark comme une estimation, sauf s'il provient d'un régulateur ou d'une étude nommément identifiés ; les seuils internes varient fortement selon l'assureur et la branche.