+150 XP

Scorer la qualité des données entre les systèmes de police et de sinistres

Un gestionnaire de sinistres chez un assureur américain de taille moyenne ouvre un dossier de sinistre auto pour autoriser un règlement de 14 000 $. Le champ numéro d'identification du véhicule (VIN) est vide, la date de sinistre se situe trois semaines après la date de résiliation de la police, et l'adresse du réclamant comporte deux codes postaux différents selon les systèmes. Personne n'a inventé ce scénario : c'est un mardi tout à fait ordinaire en gestion de sinistres. Avant que les actuaires puissent se fier à ce dossier pour la tarification ou le provisionnement, quelqu'un doit le scorer.

Cette leçon explique comment les assureurs procèdent concrètement à ce scoring.

Pourquoi la qualité des données est un problème propre aux assureurs

L'assurance fonctionne avec des données collectées par de nombreuses mains : agents, gestionnaires tiers (TPA, sociétés externes qui traitent les sinistres pour le compte d'un assureur), boîtiers télématiques, réparateurs, professionnels de santé, et les assurés eux-mêmes qui remplissent des formulaires. Chaque transmission introduit un risque d'erreur.

Contrairement à un distributeur doté d'un seul système d'encaissement, un assureur assemble généralement :

  • Les systèmes de gestion des polices (PAS) : où résident les garanties, la prime et les avenants.
  • Les systèmes de gestion des sinistres : où résident les détails du sinistre, les provisions et les paiements.
  • Les moteurs de souscription et de tarification : où résident les scores de risque et les variables de tarification.
  • Les flux de données externes : scores d'assurance basés sur le crédit, relevés d'information des véhicules (MVR), données immobilières (par ex. CoreLogic), données météo et catastrophes (par ex. flux NOAA).

Les actuaires qui tarifent un portefeuille ou fixent des provisions dépendent de la cohérence de l'ensemble. Un « score de qualité des données » est la réponse du département data de l'assureur à une seule question avant diffusion : ce jeu de données est-il apte à la décision que quelqu'un s'apprête à prendre avec ?

Les quatre métriques fondamentales

La plupart des frameworks de gouvernance des données des assureurs (souvent vaguement alignés sur le Data Management Body of Knowledge de DAMA International) convergent vers quatre dimensions. Les définitions comptent ici, car les interlocuteurs non techniques les confondent souvent.

1. Complétude : les champs obligatoires sont-ils renseignés ?

Exemple : un flux sinistres de 10 000 lignes dont 400 sans VIN, alors que le VIN est requis pour la subrogation (récupérer les coûts auprès de l'assureur d'un tiers responsable). C'est un défaut de complétude.

2. Exactitude : la valeur reflète-t-elle la réalité ?

Exemple : un dossier de police indique l'âge de la toiture d'une maison à 5 ans alors qu'une photo d'inspection montre une usure visible compatible avec 20 ans. Le champ est renseigné (complet) mais faux (inexact).

3. Fraîcheur : la donnée est-elle disponible au moment voulu, et à jour ?

Exemple : l'estimation de provision d'un sinistre (le montant mis de côté par l'assureur pour le règlement attendu) n'a pas été mise à jour depuis 90 jours malgré l'arrivée de nouvelles factures médicales. Une donnée périmée fausse l'adéquation des provisions.

4. Cohérence : les valeurs concordent-elles d'un système à l'autre et dans le temps ?

Exemple : la date de naissance du réclamant est 03/14/1980 dans le système de polices et 04/13/1980 dans le système de sinistres. Même personne, deux systèmes, deux vérités.

Certains frameworks ajoutent la validité (la valeur respecte-t-elle un format ou une plage autorisés, comme un code d'État qui doit faire partie des 50 abréviations postales américaines) et l'unicité (aucun doublon d'identifiant de police ou de sinistre). Dans cette leçon nous restons sur les quatre dimensions les plus fréquemment pondérées dans les scorecards des assureurs.

Un exemple chiffré : scorer un échantillon de flux sinistres

Supposons que le département data échantillonne 1 000 dossiers de sinistres auto avant de les transmettre à l'équipe actuarielle de provisionnement. Il vérifie quatre règles, une par dimension :

MétriqueRègle vérifiéeDossiers en échecTaux de conformité
ComplétudeChamp VIN renseigné4096,0 %
ExactitudeDate de sinistre comprise dans les dates d'effet de la police2597,5 %
FraîcheurProvision mise à jour dans les 30 jours suivant la dernière activité sur le sinistre8092,0 %
CohérenceDate de naissance du réclamant identique entre systèmes police et sinistres1598,5 %

Un score composite de qualité des données simple est la moyenne des quatre taux de conformité :

Composite score = (96.0 + 97.5 + 92.0 + 98.5) / 4 = 96.0%

Beaucoup d'assureurs utilisent plutôt un score pondéré, car les défauts de fraîcheur sur les provisions pèsent financièrement plus lourd qu'un code postal périmé. Un schéma de pondération plausible :

Weights: Completeness 20%, Accuracy 35%, Timeliness 30%, Consistency 15%

Weighted score = (96.0×0.20) + (97.5×0.35) + (92.0×0.30) + (98.5×0.15)
             = 19.2 + 34.1 + 27.6 + 14.8
             = 95.7%

Les assureurs fixent généralement un seuil de diffusion (les benchmarks internes couramment cités vont de 95 % à 98 % selon l'usage aval du jeu de données ; ce sont des illustrations, pas des standards universels). En dessous du seuil, le fichier est renvoyé aux propriétaires des systèmes sources pour correction avant que les actuaires n'y touchent.

C'est conceptuellement proche d'un data quality firewall : une barrière automatisée qui bloque les lots mal scorés avant qu'ils ne circulent en aval, utilisée sous diverses formes par les grands assureurs et réassureurs gérant des flux sinistres à fort volume.

Un contrôle Python simple pour une règle

Voici à peu près à quoi ressemble un contrôle d'exactitude (date de sinistre comprise dans les dates de la police) sous forme de règle, le type de logique qui se trouve dans un pipeline de qualité des données d'un assureur :

python
import pandas as pd

def check_loss_date_accuracy(df):
    # df contient les colonnes : loss_date, policy_effective_date, policy_expiry_date
    valid = (df['loss_date'] >= df['policy_effective_date']) & \
            (df['loss_date'] <= df['policy_expiry_date'])
    pass_rate = valid.mean() * 100
    return round(pass_rate, 1)

# check_loss_date_accuracy(claims_df) -> 97.5

Les versions en production tournent à bien plus grande échelle et journalisent chaque dossier en échec dans une file de correction, mais la logique est aussi directe que cela.

Le lien avec la réglementation et la gouvernance

La qualité des données n'est pas qu'une question d'efficacité interne. Elle a une portée réglementaire :

  • Dans l'UE, Solvabilité II (le cadre prudentiel des assureurs, supervisé par l'EIOPA, l'Autorité européenne des assurances et des pensions professionnelles) impose explicitement aux assureurs de démontrer que les données utilisées dans les provisions techniques (calculs de provisionnement) répondent à des critères d'exactitude, de complétude et de pertinence. Les superviseurs peuvent contester, et contestent, des calculs de provisions bâtis sur des données de mauvaise qualité.
  • Aux États-Unis, la Model Audit Rule de la NAIC (National Association of Insurance Commissioners) et les contrôles de pratiques commerciales au niveau des États examinent les données de gestion des sinistres, en particulier les délais de paiement et le traitement cohérent de sinistres similaires.
  • Le RGPD (Règlement général sur la protection des données, UE) et diverses lois d'États américains sur la vie privée (par ex. le CCPA californien) ajoutent une obligation de cohérence et d'exactitude du côté de l'individu : les assurés peuvent demander la rectification des données personnelles inexactes détenues par l'assureur.

Effet pratique : un « score de qualité des données » n'est pas un dashboard de confort, c'est une preuve qu'un assureur peut avoir à présenter à un examinateur.

Vérification des acquis

1. Pourquoi le scoring de la qualité des données est-il particulièrement difficile pour les assureurs comparé à un distributeur doté d'un seul système d'encaissement ?

2. Dans le scénario d'ouverture, l'adresse du réclamant présente deux codes postaux différents selon les systèmes. Cet écart illustre le mieux quel problème de qualité des données sous-jacent ?

3. Le département data d'un assureur demande « ce jeu de données est-il apte à la décision que quelqu'un s'apprête à prendre avec ? » avant de diffuser les données. Qu'implique ce cadrage pour le scoring de la qualité des données ?

CHOIX MULTIPLES

4. Sélectionnez TOUTES les bonnes réponses concernant les sources de données alimentant la prise de décision d'un assureur décrites dans la leçon.

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Sélectionnez TOUTES les bonnes réponses expliquant pourquoi l'exemple du dossier sinistre (VIN vide, date de sinistre postérieure à la résiliation, codes postaux discordants) compte avant que les actuaires ne l'utilisent pour la tarification ou le provisionnement.

Sélectionnez toutes les réponses correctes.

Benchmarks et ce à quoi ressemble le « bon » niveau

Il n'existe pas de benchmark universel unique (méfiez-vous de quiconque cite un chiffre précis comme parole d'évangile), mais quelques points de repère utiles, signalés comme des estimations :

  • Les équipes de gouvernance des données des assureurs visent couramment 95 % et plus de complétude sur les champs désignés comme « critical data elements » (CDE), une qualification formelle utilisée en gouvernance des données pour identifier le sous-ensemble de champs (VIN, numéro de police, date de sinistre) qui affectent matériellement les décisions aval.
  • Les benchmarks de délais sur les sinistres renvoient souvent aux lois d'État sur les délais de paiement (de nombreux États américains exigent une décision ou un paiement sous 15 à 45 jours selon la branche et l'État), ce qui met indirectement sous pression la qualité des données de fraîcheur en amont.
  • Les réassureurs et sociétés de modélisation catastrophe (par ex. Verisk, Moody's RMS) publient des orientations générales selon lesquelles des données d'exposition (caractéristiques des biens alimentant les modèles catastrophe) en dessous d'environ 90 % de complétude sur les champs clés élargissent sensiblement l'incertitude du modèle ; il s'agit d'une estimation directionnelle, pas d'un seuil fixe.

À retenir honnêtement : les benchmarks sont contextuels. Un jeu de données marketing tolère plus de bruit qu'un jeu de données de provisionnement alimentant des validations actuarielles.

À retenir

  • Scorez la qualité des données sur quatre dimensions fondamentales : complétude (la donnée est-elle là), exactitude (est-elle juste), fraîcheur (est-elle à jour), cohérence (concorde-t-elle entre systèmes).
  • Un score composite peut être une moyenne simple ou un score pondéré reflétant les erreurs qui coûtent le plus (la fraîcheur des provisions pèse généralement plus qu'un code postal périmé).
  • Les assureurs fixent des seuils de diffusion (couramment 95 à 98 %, à titre d'estimation) avant de laisser actuaires ou souscripteurs utiliser un jeu de données pour des décisions de tarification ou de provisionnement.
  • La réglementation donne du poids à tout cela : Solvabilité II dans l'UE et les standards de pratiques commerciales de la NAIC aux États-Unis tiennent les assureurs responsables de la qualité des données sous-jacentes aux provisions et à la gestion des sinistres.
  • Les critical data elements (CDE) comme le VIN, la date de sinistre et les dates de police méritent des seuils plus stricts que les champs cosmétiques, car leurs erreurs se propagent directement dans les résultats financiers et réglementaires.