Le butin · Lingot n°1 · Poste actuel

Contrôle qualité et fiabilisation de flux de données financiers sur GCP

Des contrôles automatisés pour que les données financières restent fiables, chaque jour.

Employeur
Mobilize Financial Services (Renault Group)
Période
octobre 2024 à aujourd’hui
Rôle
Data engineer, équipe Data Platform RCI
Type
Pipelines de données et contrôle qualité sur une Data Platform cloud
Statut
En production
Illustration : un flux de données traverse des portiques de contrôle laser, une anomalie est arrêtée et entourée au stylo

Le butinDes données financières sous surveillance permanente : chaque anomalie repérée, expliquée et signalée avant d’atteindre le métier.

Sommaire du dossier
  1. Le repérage Contexte
  2. La cible Le problème
  3. Le plan La solution
  4. L’exécution Ce que j’ai réalisé
  5. Le matériel Stack technique
  6. Les imprévus Défis techniques
  7. Le bilan Résultats

Le repérageContexte

Depuis octobre 2024, je suis data engineer chez Mobilize Financial Services, la filiale de services financiers du Renault Group, au sein de l’équipe Data Platform RCI. Je pilote des projets sur GCP, je recueille les besoins avec les business analysts et je participe directement aux développements des cas d’usage.

Ce poste est salarié. Le travail décrit ici reste générique : il montre la nature des missions, pas leur contenu.

La cibleLe problème

Une Data Platform d’entreprise rassemble des données financières venues de plusieurs systèmes et de plusieurs entités. Avant de servir le métier, ces données doivent être harmonisées. Entre la donnée brute et la donnée raffinée, chaque étape peut introduire une anomalie : correspondance de référentiel manquante, doublon, rupture de volume, valeur hors nomenclature, incohérence entre deux jeux de données censés se correspondre.

Une anomalie qui n’est pas repérée tôt se propage à tous les usages en aval.

Les équipes métier et data avaient besoin d’un contrôle automatique, régulier et lisible, pour détecter ces écarts, les qualifier et les corriger.

Le planLa solution

Des traitements de contrôle qualité orchestrés automatiquement, à une fréquence adaptée à chaque contrôle : chaque jour ou chaque semaine.

Chaque exécution vérifie la donnée sous plusieurs angles : continuité des volumes, complétude des valeurs, unicité, fraîcheur des imports, conformité aux nomenclatures de référence, cohérence entre jeux de données liés. Les résultats partent par e-mail aux personnes concernées, sous une forme directement exploitable, et les équipes techniques sont alertées en cas d’échec.

Les contrôles sont pilotés par configuration. Ajouter un périmètre ou un contrôle ne demande pas de réécrire le traitement.

Orchestration Airflow · Cloud Composerune chaîne quotidienne, une chaîne hebdomadaireConfigurationdes contrôlesSystèmes sourcesZone bruteCloud Storage, BigQueryZone raffinéeBigQueryharmonisationanomalie arrêtéeVolumesComplétudeUnicitéFraîcheurNomenclaturesCohérencePortiques de contrôle qualitéSQL sur BigQuery, pilotés par configurationRapportspar e-mail au métierAlertessi un traitement échoue
Orchestration Airflow · Cloud Composerquotidienne et hebdomadaireSystèmes sourcesZone bruteCloud Storage, BigQueryZone raffinéeBigQueryharmonisationVolumesComplétudeUnicitéFraîcheurNomenclaturesCohérenceanomalie arrêtéeRapportspar e-mail au métierAlertessi un traitement échoue
Schéma de principe : des sources à la donnée raffinée, avec des portes de contrôle qualité, puis rapports par e-mail et alertes

L’exécutionCe que j’ai réalisé

  • Des contrôles en SQL sur BigQuery, intégrés au moteur de contrôle qualité de la plateforme : conformité aux nomenclatures, cohérence entre jeux de données, unicité et doublons, complétude, continuité des volumes.
  • L’évolution des pipelines Airflow sur Cloud Composer, générés à partir de configuration, et la réorganisation de l’ordonnancement en deux chaînes distinctes, quotidienne et hebdomadaire, selon la nature des contrôles.
  • Des diagnostics en production : recherche de causes racines en remontant dans l’historique de BigQuery pour comparer l’état de la donnée à différents moments.
  • Un traitement de tri automatique des e-mails par IA, que j’ai conçu, puis migré vers Office 365 : refonte du code pour isoler l’accès à la messagerie, puis bascule vers Microsoft Graph API.
  • Le lien avec le métier : recueil des besoins avec les business analysts, rédaction des spécifications, restitution automatique des résultats et accompagnement des équipes sur les corrections.

Le matérielStack technique

  • Cloud : Google Cloud Platform, BigQuery, Cloud Composer, Cloud Storage, Cloud Functions.
  • Orchestration : Airflow, pipelines pilotés par configuration.
  • Langages : SQL, Python.
  • Intégrations : Microsoft Graph API, Office 365.
  • Environnements : développement, intégration, recette et production séparés.

Les mêmes compétences dans le coffre

Le Cerveau

Le Coach

Les imprévusDéfis techniques

  1. Incident n°1retrouver l’origine de doublons dans un flux quotidien

    Imprévu. Un traitement en production a échoué à cause de doublons inattendus. Au moment de l’analyse, la donnée avait déjà changé : impossible de voir ce qui s’était passé en regardant l’état courant.

    Parade. J’ai reconstitué l’état exact des données au moment de l’échec grâce au time travel de BigQuery, puis je l’ai comparé à l’état courant et aux référentiels. Une série de requêtes d’investigation, de validation et de contre-vérification a isolé la cause : une incohérence de format sur une clé de jointure. La même méthode a ensuite confirmé que la correction tenait.

    Ce que j’en retiens. Sur un flux vivant, un diagnostic fiable exige de figer le contexte. L’historique de l’entrepôt est un outil d’enquête à part entière.

    État passéreconstitué au moment de l’échec (time travel BigQuery)État présentla donnée telle qu’elle est aujourd’huidoublondéjà modifiéeRequêtes d’investigationcomparer, valider, contre-vérifier la correction
    État passéreconstitué au moment de l’échecdoublonÉtat présentla donnée aujourd’huidéjà modifiéeRequêtes d’investigationcomparer, valider, contre-vérifier
    Schéma de principe de l’enquête : état passé et état présent de la donnée comparés

  2. Incident n°2des contrôles que le métier peut lire

    Imprévu. Des besoins de vérification exprimés en langage métier, et des écarts entre jeux de données qui passaient jusque-là inaperçus.

    Parade. Les règles ont été formalisées avec le métier, puis écrites en SQL de façon générique pour couvrir plusieurs jeux de données. Les mesures sont croisées par périmètre (présent d’un côté, absent de l’autre) et le résultat se lit simplement : une ligne par écart, avec sa proportion.

    Ce que j’en retiens. Un contrôle vaut autant par la lisibilité de son résultat que par sa justesse technique. Mesurer avant d’affirmer facilite le dialogue avec les équipes sources.

  3. Incident n°3migrer un tri d’e-mails vers Office 365

    Imprévu. La boîte mail qui alimentait le traitement de tri automatique devait passer sur Office 365. Le code n’avait pas été conçu pour changer de messagerie : l’accès à la boîte était mêlé à toute la logique du traitement.

    Parade. J’ai d’abord refactorisé en profondeur pour séparer l’accès à la messagerie du reste, puis basculé l’intégration vers Microsoft Graph API. Le traitement continue de lire, d’analyser et de ranger les e-mails dans le nouvel environnement.

    Ce que j’en retiens. Un code qui isole ses dépendances externes se migre en quelques jours. Refactoriser avant de migrer réduit le risque de la bascule.

    1 · Avantl’accès à la messagerie est mêlé à tout le traitementTraitement de triLireAnalyser (IA)RangerAncienne messagerie2 · Refactorisationl’accès est isolé derrière une seule interfaceTraitement de triLireAnalyser (IA)RangerAccès messagerieAncienne messagerie3 · Basculeseule l’interface change de branchementTraitement de triLireAnalyser (IA)RangerAccès messagerieMicrosoft Graph APIOffice 365
    1 · Avantl’accès à la messagerie est mêlé à tout le traitementTraitement de triLireAnalyser (IA)RangerAncienne messagerie2 · Refactorisationl’accès est isolé derrière une seule interfaceTraitement de triLireAnalyser (IA)RangerAccès messagerieAncienne messagerie3 · Basculeseule l’interface change de branchementTraitement de triLireAnalyser (IA)RangerAccès messagerieMicrosoft Graph APIOffice 365
    Schéma de principe de la migration du tri d’e-mails : l’accès à la messagerie est d’abord isolé, puis basculé vers Microsoft Graph API et Office 365

Le bilanRésultats

Les résultats de ce poste restent qualitatifs : aucun chiffre ne peut être communiqué.

  • Les anomalies sont repérées plus tôt et plus systématiquement, avant d’atteindre les usages métier.
  • Les diagnostics en production sont plus rapides et mieux étayés, grâce à une méthode d’enquête reproductible.
  • Les contrôles évoluent plus facilement, grâce à la configuration et à la séparation des chaînes par fréquence.
  • Les équipes métier reçoivent des résultats lisibles et peuvent agir directement sur les écarts signalés.

Votre projet est le prochain coup.

Monter le prochain coup