SMACL Assurances implique ses métiers sur la qualité des données

Dans le monde de l'assurance, l'arrivée de Solvabilité II remet au premier plan la question de la qualité des données. Cette réforme réglementaire demande aux compagnies de mieux évaluer leurs risques pour préserver leur stabilité financière. A l'automne 2012, SMACL Assurances décide de lancer un projet pour contrôler l'intégrité de ses données. Cette mutuelle de 600 personnes -comptant 90% de clients dans les collectivités territoriales- veut aussi mettre l'accent sur la qualité de service fourni à ses sociétaires, sur un marché où la concurrence se renforce. Son directoire confie le projet au responsable du domaine décisionnel de sa DSI qui avait lancé trois ans plus tôt une démarche similaire sur le risque statutaire.

Lors de cette première expérience, Philippe Guiraud avait été alerté sur la nécessité de corriger des données en amont du datawarehouse. « J'avais alors préféré mettre les non-qualités en évidence pour inciter les métiers à les corriger à la source », a-t-il exposé la semaine dernière à Paris, sur la conférence Information Builders Summit. Des règles de contrôle avaient été installées dans l'ETL d'alimentation pour détecter les anomalies, avec des tableaux de bord pour en rendre compte. L'initiative, encouragée par les commissaires aux comptes, est concluante. Mais elle n'est pas industrialisée et les exigences de qualité de Solvabilité II nécessitent le recours à un outil.

Un outil web de visualisation des anomalies

Un appel d'offres, lancé en octobre 2012, débouche sur le choix de la solution iWay Data Quality Center, d'Information Builders. Le produit est jugé ouvert et adaptable, même s'il n'apparait pas comme le plus simple. « Il était très orientée sur la correction des données, c'était vraiment ce qu'on cherchait. Et il incluait un outil web de visualisation des anomalies », a expliqué Philippe Guiraud en précisant que tous les utilisateurs potentiels avaient participé au choix. SMACL utilisait déjà l'ETL iWay Data Migrator de l'éditeur retenu, ainsi que son logiciel de reporting, WebFOCUS.

Outre la direction et le département informatique, le projet implique les fournisseurs de données, les responsables de la réglementation et les consommateurs de données. Il démarre en janvier par une réunion de sensibilisation de tous les acteurs concernés. Son pilote, Philippe Guiraud, souligne ici l'importance de désigner et d'impliquer des référents métiers parmi les utilisateurs. Dans ces démarches « parfois mal perçues en interne », ces référents sont des éléments moteurs, tant sur la dynamique de la mise en oeuvre que sur les aspects de sensibilisation. « Ils se font porte-parole, expliquent l'importance de certaines données dans les prises de décision, afin que la saisie soit plus attentive de manière naturelle. C'est aussi cela qui permet d'améliorer la qualité », a rappelé le responsable décisionnel de SMACL.

Treize règles de contrôles définies par les métiers

Les données issues des métiers sont vérifiées en entrée par l'ETL. Ce dernier déclenche les contrôles dans iWay Data Quality Center en se reportant au référentiel des paramètres contrôles. Le logiciel de gestion de la qualité des données génère ensuite un log des exécutions pour le reporting de communication et un log des anomalies pour le reporting opérationnel destiné au suivi des corrections. Au démarrage du projet, « nous avons listé les différentes typologies d'anomalies que l'on pouvait rencontrer : donnée non renseignée, type de champs (numérique, date, téléphone...), bornes et listes de valeurs valides, cohérence entre plusieurs données, etc. jusqu'au dédoublonnage », a détaillé Philippe Guiraud.

Au total, treize typologies. « Pour chacune d'entre elles, j'ai demandé aux métiers de trouver une règle de contrôle en estimant qu'une fois celles-ci développées, nous aurions pratiquement tous les cas de figure et réalisé le transfert de compétences », a expliqué le responsable décisionnel de SMACL Assurances. [[page]]« Et comme nous sommes ici dans un projet à très long terme, voire permanent, il m'a semblé nécessaire d'investir du temps dans un flux type de contrôle qui intègre tout ce que l'on peut mutualiser, avec le maximum d'informations paramétrées. Cela doit ensuite permettre, lorsqu'on nous demande une nouvelle règle de contrôle, de nous focaliser uniquement sur son écriture ». Ce flux type a demandé une quarantaine de jours, mais il devrait permettre de diviser par deux les temps de développement.

Une première salve de 70 règles à coder

Un outil de profiling est également utilisé pour exposer les données afin de pouvoir les analyser, avoir des statistiques sur les fréquences de valeur, de format... « Je pense qu'en donnant une visibilité sur le contenu de nos bases, les utilisateurs métiers vont plus facilement pouvoir définir les règles de contrôle », a précisé Philippe Guiraud. Quant à la partie décisionnelle, elle va permettre de démontrer la décroissance du nombre d'anomalies détectées. « Dans la directive Solvabilité II, il y a une forte notion de preuve et cela permettra de s'engager par rapport à l'autorité de contrôle en prouvant les vérifications effectuées à fréquences régulières sur différents pans d'activité ».

L'objectif du projet était de mettre en recette fin juin les 13 règles de contrôles, ce qui est fait. « Hors appel d'offres, nous avons passé à peu près 110 jours en interne, avec une assistance d'Information Builders de l'ordre de quinze jours », a évalué le responsable décisionnel. Dans ce projet, qui a une finalité réglementaire, il reste à écrire des procédures sur le rôle de chacun, et à industrialiser la saisie des formulaires par lequel les utilisateurs décrivent les règles de contrôle. Il y aura sans doute des impacts organisationnels dans le dimensionnement des équipes, notamment pour les corrections. « Dans le cadre des travaux sur Solvabilité II, il m'est arrivé la semaine dernière un premier lot de 70 règles de contrôle qui ont été définies et qu'il reste à coder. Cela signifie que le projet entre en maturité », estime Philippe Guiraud. La définition des 13 règles de contrôle a demandé deux semaines de travail. « Aujourd'hui, nous pourrons coder en une demi-journée une règle qui ne présente pas de difficulté particulière. »

Interrogé lors de la conférence Information Builders Summit sur le coût de la non-qualité des données, le responsable du projet de SMACL a en revanche reconnu qu'il restait toujours difficile à évaluer.