Données d'assurance — gouvernance et analytique

Quatre années dans un groupe d'assurance belge — deux comme data steward sur la qualité des données, la gouvernance et la conformité RGPD, deux comme analyst sur l'extraction de données, la préparation des données KPI et l'automatisation. Aujourd'hui, coordination d'un projet de consolidation de processus réunissant quinze personnes. Spécificités anonymisées ; méthodologie et résultats décrits en détail.

2022 — 2024 · Data Steward

Les années de data steward étaient consacrées aux cas qui ne s'inscrivaient pas. Enregistrements qui refusaient de fusionner entre systèmes. Champs qui se contredisaient mutuellement. Cas limites que les règles de rapprochement ne tranchaient pas. Le travail était ingrat et lent, et il m'a appris plus sur le comportement réel des données d'assurance qu'aucun cours n'aurait pu le faire.

Ce que j'ai appris : la qualité des données n'est pas un problème qu'on règle une fois pour toutes. C'est une traduction continue entre ce que le métier dit vouloir, ce que les systèmes capturent réellement, et ce que les humains font effectivement. L’automatisation gère les motifs réguliers. Ce qui reste sur le bureau d'un humain, c'est la texture — et la texture, c'est là que vivent les vraies décisions.

2024 — actuellement · Data Analyst

Les années d'analyst transforment en décisions métier les données de meilleure qualité produites par les années de stewardship : extraction des données clients dans Salesforce, préparation des données qui alimentent les KPI, et extraction sous SAS des informations nécessaires aux commissions et aux paiements de masse — un travail où un champ erroné ne produit pas un graphique erroné, il produit un paiement erroné. J'ai également automatisé en Python le flux de messagerie de l'équipe, en remplacement d'un processus manuel répétitif.

Actuellement · Coordination d'un projet de consolidation de processus

Mon travail principal consiste aujourd'hui à rassembler en un flux unique et simple des procédures qui n'avaient jamais été standardisées, et à préparer les données qui alimentent les KPI correspondants. La coordination réunit quinze personnes de métiers différents, et c'est là que réside l'essentiel de la difficulté : la partie technique consiste à définir un champ une fois, la vraie partie consiste à amener quinze personnes, qui disposaient chacune d'une définition locale qui fonctionnait, à en accepter une seule.

Un KPI ne vaut que l'accord qui le sous-tend. Si deux départements comptent la même chose différemment, le tableau de bord ne rapporte pas la réalité : il rapporte le désaccord. L'essentiel de mon travail consiste à rendre cet accord explicite, puis à le tenir.

Études de cas sélectionnées

Les études de cas suivantes sont décrites au niveau méthodologique, avec les détails et informations d'identification spécifiques anonymisés conformément aux obligations de confidentialité.

Cas 1 · Fusion d'enregistrements clients (MDM)

Pendant deux ans comme data steward, mon travail a porté sur le rapprochement et la fusion d'enregistrements clients. La règle n'est pas « le plus récent gagne » : il faut regarder le contrat rattaché, la source de l'information et les obligations de conservation. Un enregistrement ancien peut porter le contrat le plus récent, tandis qu'un enregistrement plus récent ne contient qu'une information transmise oralement. J'ai défini des règles de priorité, arbitré champ par champ, et identifié les cas où une fusion ne doit pas avoir lieu.

Méthodologie — priorité par contrat rattaché, arbitrage champ par champ, respect des durées de conservation.

Cas 2 · Le cycle de clôture mensuel

Chaque début de mois, environ 150 tableaux de bord Power BI repassent au rouge. Les remettre au vert est un travail de chaîne : vérifier que les requêtes sont prêtes, extraire les sinistres et la production sous SAS, préparer les fichiers, les charger en masse dans Salesforce avec Data Loader, puis demander par ticket Jira le calcul du ratio sinistres/primes une fois les deux volets validés. Deux tiers de la chaîne sont automatisés ; quand une étape échoue, il faut l'identifier, la faire corriger et reprendre la suite dans le bon ordre.

Méthodologie — contrôle de disponibilité des données, extraction SAS, chargement en masse, coordination avec l'IT par ticket.

Cas 3 · Quand un chiffre devient une commission

Le ratio issu de ce cycle détermine les paliers de commission des courtiers. C'est ce qui change la nature du travail : une erreur ne produit pas un graphique faux, elle produit un paiement faux. Dans le même périmètre, je rapproche les contrats courtiers avec le CRM, je vérifie les conditions courtiers et agents, et je traite les demandes de mise à jour venant de la plateforme sinistres — par exemple enregistrer qu'un paiement a bien eu lieu.

Méthodologie — rapprochement contrat/CRM, contrôles de cohérence, traitement des demandes métier.

Ce qui reste sur le bureau d'un humain, c'est la texture — les cas qui ne s'inscrivent pas. Cette texture, c'est là que vivent la plupart des décisions réelles.

Ce que ce travail m'a appris

• Les cas intéressants sont ceux que l'IA renvoie, pas ceux qu'elle classe avec confiance.
• Une bonne qualité des données ressemble à un non-événement en production. Elle ne se remarque que lorsqu'elle échoue.
• La connaissance du domaine se compose. Quatre ans de travail avec des données d'assurance est qualitativement différent de quatre mois — les motifs déjà vus sont ce qui permet de repérer les nouveaux.
• La documentation n'est pas optionnelle. Les systèmes les plus propres sont ceux dont les définitions sont réconciliées et écrites.

Pour des questions spécifiques sur la méthodologie, les outils, ou des exemples anonymisés, je suis heureux d'en discuter en entretien.