Une journée dans la vie d'un Data Steward
Suivons un scénario réaliste : une équipe marketing remarque un chiffre qui semble étrange dans un dashboard. Que se passe-t-il ensuite ? Étape par étape, le Data Steward intervient.
Lundi 9h. L'équipe Marketing TGV-IC ouvre son dashboard hebdomadaire et constate que le nombre de clients « Grand Voyageur Le Club » actifs sur la liaison Paris-Lyon a chuté de 32% en une semaine. Personne ne s'attendait à ça. Un email arrive dans la boîte du Data Steward : « Est-ce que les chiffres sont bons ? »
Reproduire et qualifier
- Le Data Steward ouvre le dashboard, vérifie qu'il voit bien la même chose que le métier.
- Il regarde si la baisse est isolée à cette liaison ou présente ailleurs : c'est uniquement Paris-Lyon.
- Il vérifie l'historique : la métrique était stable depuis 6 mois, la chute est brutale et concerne une seule semaine.
Hypothèse : c'est probablement un problème de donnée, pas un effondrement business réel. À investiguer.
Remonter le lineage
- Le Data Steward ouvre le data catalog et consulte la fiche de la métrique : elle est calculée par une vue SQL sur le Socle Data Relation Client.
- Il remonte les sources de cette vue : table Transactions (depuis la billetterie) + table Client (depuis le RCU) + table ContratFidelite (depuis le programme Grand Voyageur).
- Il interroge chaque source isolément. La table Transactions affiche un volume normal. La table Client aussi. Mais la table ContratFidelite a perdu 28% de ses lignes pour la semaine en question.
L'anomalie vient bien de la source ContratFidelite. Reste à comprendre pourquoi.
Diagnostiquer la cause racine
- Le Data Steward contacte l'équipe IT qui maintient le pipeline d'ingestion du programme Grand Voyageur.
- Il découvre qu'un changement de format sur le système source (mise à jour applicative le mardi précédent) a fait échouer silencieusement l'ingestion d'un sous-ensemble de contrats.
- Plus précisément : tous les contrats créés avant 2018 ont un champ date au format ancien, désormais rejeté par le pipeline.
Cause racine identifiée : régression dans la transformation après mise à jour de la source. Pas une perte business mais une perte de visibilité sur la donnée.
Piloter la correction
- Le Data Steward déclare officiellement un incident dans l'outil de ticketing (criticité élevée car le métier prend des décisions sur cette donnée).
- Il coordonne avec les Data Engineers : correctif du pipeline pour gérer les deux formats de date.
- Il déclenche un rattrapage de données : on rejoue l'ingestion sur la fenêtre temporelle perdue (1 semaine).
- Il vérifie après rattrapage que le dashboard remonte bien les bons chiffres.
- Il informe l'équipe Marketing du retour à la normale, en expliquant ce qui s'est passé.
Données corrigées. Le métier a confiance que le problème est résolu et compris.
Capitaliser pour la prochaine fois
- Le Data Steward documente l'incident dans l'outil de gestion des connaissances : symptôme, cause racine, correctif, leçon apprise.
- Il propose d'ajouter un contrôle qualité automatique : alerte si le volume d'une table source chute de plus de 15% d'une semaine à l'autre.
- Il met à jour la fiche de la métrique dans le data catalog avec une note sur les deux formats historiques de date.
- Il partage le retour d'expérience avec ses pairs Data Stewards lors du point hebdomadaire.
L'incident est une opportunité d'amélioration. La gouvernance progresse à chaque fois.