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 le modèle renvoyait avec une faible confiance. 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'IA gère les motifs. 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 · Amélioration de la précision de fusion sur des enregistrements clients legacy

Une catégorie d'enregistrements clients était régulièrement signalée comme fusion incertaine par le pipeline de déduplication. La revue manuelle a révélé un motif sur lequel le modèle n'avait pas été entraîné. En documentant le motif et en ajustant la file d'attente de revue humaine, la précision de fusion sur cette catégorie s'est améliorée significativement et la charge de revue a diminué.

Méthodologie — identification de motifs par revue manuelle, documentation, restructuration de file d'attente.

Cas 2 · Réduction des escalades faux-positives

Une classe spécifique de sinistres était escaladée vers la revue humaine à un taux supérieur aux attentes. L'analyse a montré que le modèle traitait des variations routinières d'entrée comme des anomalies. Un pré-traitement d'entrée affiné a réduit substantiellement les escalades faux-positives sans affecter la détection des vrais positifs.

Méthodologie — analyse des motifs d'escalade, normalisation des entrées, déploiement contrôlé.

Cas 3 · Réconciliation inter-systèmes pour le reporting réglementaire

Une exigence de reporting impliquait de réconcilier des champs entre trois systèmes internes dont les définitions avaient dérivé au fil du temps. Le pipeline de réconciliation a été reconstruit avec une documentation explicite des mappings, réduisant le travail de réconciliation manuelle et produisant une piste d'audit plus claire pour le régulateur.

Méthodologie — audit champ par champ système par système, réconciliation des définitions, mapping documenté.

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.