Full-load et traçabilité brisée : anatomie d'un sinistre Datavault en environnement Solvabilité II

Imaginons une mission classique : un consultant Datavault intervient chez un assureur pour industrialiser l'entrepôt qui alimente les calculs prudentiels Solvabilité II. Dans ce cadre, l'entrepôt ne sert pas qu'à produire des tableaux de bord. Il doit, en cas de contrôle, démontrer la traçabilité complète de chaque donnée : d'où elle vient, et surtout à quel moment elle est entrée dans le système.

C'est tout l'intérêt du Datavault : les colonnes techniques comme la load date (date de chargement) et le record source (source d'origine) constituent une piste d'audit native. Le régulateur, comme le commissaire aux comptes, peut reconstituer l'état exact de la donnée à n'importe quelle date passée. Cette auditabilité est une exigence, pas un confort.

Tant que le pipeline tourne en incrémental, cette piste d'audit s'enrichit proprement. Le risque naît au moment d'une opération qui paraît anodine : un rechargement complet.

Au cours de la mission, une incohérence est détectée dans plusieurs satellites. La décision est prise de faire un full-load : vider et recharger intégralement l'entrepôt depuis les sources, pour repartir d'une base saine. L'intention est louable.

Mais le script de rechargement comporte un défaut discret : au lieu de préserver les load dates historiques, il réinitialise toutes les dates de chargement à la date du rechargement. En une nuit, l'entrepôt affirme désormais que toutes les données sont entrées dans le système le même jour. La valeur métier est correcte. La chronologie d'arrivée, elle, est anéantie.

L'entrepôt n'est pas faux. Il est devenu incapable de prouver quand il a su quoi. Et en Solvabilité II, c'est exactement ce qu'on lui demande.

Personne ne s'en aperçoit immédiatement. Les reportings sont justes, les chiffres prudentiels tombent. Le sinistre est latent.

Le défaut se révèle plusieurs mois plus tard, au pire moment possible : lors d'un contrôle. Le commissaire aux comptes demande à reconstituer l'état d'un portefeuille à une date de clôture passée. L'équipe data lance la requête point-in-time, et découvre que tout l'historique pointe vers une seule et même date de chargement.

Impossible de prouver la chronologie. L'auditeur ne peut pas valider la piste d'audit. La situation remonte, et l'assureur se retrouve dans une posture délicate vis-à-vis de son régulateur. La cause est rapidement identifiée : le script de full-load livré pendant la mission.

Le donneur d'ordre se retourne alors vers le consultant. C'est le déclenchement classique d'une réclamation en responsabilité civile professionnelle.

Ce type de sinistre est lourd parce que la remédiation est complexe et le contexte régulé. Voici une décomposition réaliste des postes de coûts.

On dépasse aisément les six chiffres. Pour un freelance ou une petite structure, c'est un montant qui peut mettre fin à l'activité s'il n'est pas couvert.

Deux niveaux de protection auraient changé l'issue de ce sinistre.

Sur le plan technique, le réflexe métier est de ne jamais écraser les colonnes techniques d'audit lors d'un rechargement. Un full-load en Datavault doit préserver les load dates d'origine ou, à défaut, reconstruire la chronologie à partir des sources. Une revue de code dédiée à cette opération sensible aurait intercepté le défaut.

Sur le plan assurantiel, une RC Pro déclarant explicitement les missions en environnement régulé (Solvabilité II, Bâle III, IFRS) prend en charge l'indemnisation et les frais de défense. Le surcroît de risque de ces secteurs est précisément ce que l'assureur doit connaître pour vous couvrir. Pour un consultant intervenant en banque-assurance, c'est un point non négociable : vérifiez que vos missions régulées figurent bien au contrat. Les offres dédiées aux consultants Datavault intègrent ces environnements.

Ce sinistre n'a rien d'anecdotique : il illustre une caractéristique propre aux missions Datavault en banque-assurance. Dans ces secteurs, l'entrepôt de données n'est pas un outil de confort, c'est un élément de la chaîne de conformité réglementaire. Une défaillance ne reste pas confinée à la direction informatique : elle remonte au régulateur, au commissaire aux comptes, parfois à l'autorité de contrôle prudentiel.

Cette exposition se traduit par trois facteurs aggravants qui distinguent ces missions d'un projet décisionnel classique :

1. Le délai de révélation : un défaut de traçabilité ne se voit qu'au moment d'une reconstitution d'historique, souvent à la clôture annuelle. Entre la livraison et la découverte, des mois s'écoulent, pendant lesquels le défaut s'enracine.
2. L'effet de levier sur le préjudice : un retard de clôture réglementaire ou une réserve d'un auditeur génèrent des coûts internes et un risque de sanction sans commune mesure avec la valeur de la prestation initiale.
3. La traçabilité des responsabilités : en environnement régulé, tout est documenté. La mission, les livrables, les scripts livrés : il est aisé de remonter jusqu'à l'auteur d'une modification fautive.

Pour le consultant, la conclusion est limpide. Ces missions sont parmi les plus rémunératrices, mais aussi les plus risquées. Les accepter sans une RC Pro dimensionnée pour le secteur régulé revient à parier son activité sur l'absence d'erreur sur toute la durée d'exploitation de l'entrepôt. Un pari que personne ne devrait tenir.