Shift-left data quality : intégrer la gouvernance dans le pipeline d'ingénierie

Les défaillances de qualité des données ont une géographie : elles proviennent presque toujours de la source.

Un rapport affiche de mauvais chiffres de chiffre d'affaires. L'investigation remonte le Data warehouseData warehouseUn référentiel central qui consolide les données de nombreux systèmes sources dans un stockage structuré et optimisé pour les requêtes, conçu pour l'analytique, le reporting et la business intelligence.Voir la définition complète →, le pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète → ETLETLL'ETL (Extract, Transform, Load) est un processus d'intégration de données qui extrait les données de sources multiples, les remet en forme dans un format cohérent et les écrit dans un système cible.Voir la définition complète →, la base de staging, l'intégration APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète →, et arrive finalement à un système source qui envoie des données malformées depuis six semaines. Six semaines de mauvaises données en production. Six semaines de décisions prises sur des informations incorrectes.

Le principe du « shift-left » est emprunté au génie logiciel : détecter les défauts le plus tôt possible dans le processus de développement, parce que corriger un bug en production coûte 100 fois plus cher que le détecter en code review. Appliqué à la donnée : détecter les problèmes de qualité à la source, pas après coup.

À quoi ressemble le shift-left data qualitydata qualityLe degré d'aptitude des données à l'usage prévu : exactes, complètes, cohérentes, à jour, valides et uniques. Une data quality faible fragilise l'analytics, le reporting et l'IA.Voir la définition complète →

Au niveau du système source : des règles de validation intégrées à l'application qui produit la donnée. Si un champ ne peut pas être null, l'application l'impose, le Data pipeline ne voit jamais de valeurs nulles parce qu'elles n'entrent jamais dans le système.

Au niveau de la couche d'ingestion : les contrôles de qualité s'exécutent dès que la donnée entre dans votre infrastructure. Si le schéma ne correspond pas au contrat, le pipeline s'arrête. Si la complétude passe sous le SLA, une alerte se déclenche. Great Expectations et Soda exécutent ici des contrôles de type assertion (Great Expectations est passé à son API GX 1.0 en 2024, la syntaxe Expectation des anciens tutoriels peut donc ne plus correspondre à la documentation actuelle). Monte Carlo fonctionne aux côtés de ces outils mais joue un rôle différent : c'est de la data observabilitydata observabilitySurveillance continue de la santé des données pour détecter pannes, dérives ou absences avant qu'elles n'atteignent un rapport ou un modèle.Voir la définition complète →, qui surveille la fraîcheur, le volume et le schemaschemaUn schema est le plan formel qui définit comment les données sont structurées, nommées, typées et reliées entre elles au sein d'une base de données, d'un fichier ou d'un message.Voir la définition complète → drift sur l'ensemble de votre warehouse et alerte quand quelque chose cloche, plutôt que de bloquer un pipeline sur une règle fixe. À noter que Monte Carlo a racheté la partie commerciale de Great Expectations en 2024, même si le projet open-source continue.

Au niveau de la couche de transformation : dbt (data build tool) intègre des tests natifs : tests not-null, tests unique, tests d'intégrité référentielle, tests accepted-value, tests SQLSQLSales Qualified Lead : un prospect que l'équipe commerciale a validé comme prêt pour une prise de contact directe et une proposition, après avoir passé des critères de qualification explicites.Voir la définition complète → personnalisés. Chaque modèle dbt devrait avoir des tests. Un dbt run qui comporte des tests en échec ne devrait pas être déployé en production. Beaucoup d'organisations exécutent leurs tests dbt dans des pipelines CI/CD, aucune transformation non testée n'atteint le Data warehouse.

Au niveau de la couche de restitution : les dashboards et rapports exposés aux utilisateurs métier devraient inclure des indicateurs de qualité des données : « Dernier rafraîchissement : il y a 2 heures. Score de qualité : 94 %. Incidents connus : 0. »

Intégrer la qualité des données dans le CI/CD

La référence en matière de shift-left data quality : les tests de qualité des données s'exécutent dans les pipelines CI/CD, les builds en échec sont bloqués au déploiement, et les métriques de qualité sont suivies dans le même dashboard que les métriques d'ingénierie.

Cela suppose :

1. Une couverture de tests pour la donnée : chaque pipeline critique dispose de tests de qualité documentés. Suivi comme une métrique : « Pourcentage d'actifs de données couverts par des tests de qualité : 67 %. » Le CDO devrait fixer une cible, disons 90 %, et la suivre chaque trimestre.

1. Une validation automatisée au merge : quand un data engineer soumet une pull request qui modifie un pipeline, des tests automatisés s'exécutent sur un échantillon de données de production. Les changements de schéma qui casseraient les contrats en aval font échouer le build avant le merge.

1. Des quality gates pour la promotion : la donnée ne passe pas du staging à la production sans avoir passé les contrôles de qualité. C'est un standard en génie logiciel (on ne déploie pas du code cassé). Cela devrait l'être aussi en data engineering.

Le framework Minerva d'Airbnb

Airbnb a construit un framework interne appelé Minerva pour résoudre un problème précis : des centaines d'analystes définissaient les mêmes métriques différemment, créant une incohérence qui minait la confiance dans la donnée.

Minerva est une metrics layer, un référentiel central où les métriques métier sont définies une seule fois (par le métier, avec l'équipe data), puis consommées de façon cohérente par tous les outils BI, les modèles de data science et les expérimentations.

L'idée clé : Minerva fait passer la question « que signifie cette métrique ? » du jugement ad hoc de l'analyste à une définition gouvernée et versionnée. Quand une métrique métier change (une nouvelle politique de retour modifie la façon de comptabiliser le chiffre d'affaires), la définition est mise à jour à un seul endroit et se propage à tous les consommateurs.

C'est du shift-left data quality appliqué à la cohérence sémantique plutôt qu'à la qualité technique. C'est l'un des investissements de data governance au meilleur effet de levier réalisés par Airbnb, et le pattern s'est désormais largement diffusé. Le dbt Semantic Layer tourne sur MetricFlow (dbt Labs a racheté Transform et son moteur MetricFlow en 2023 et l'a intégré), Looker a ses measures, et Cube propose une metrics layer autonome. Tous résolvent le problème que Minerva a résolu.

Ce que les CDO devraient suivre

• Couverture de tests : % d'actifs de données couverts par des tests de qualité automatisés
• Taux d'incidents sur les Data pipelines : nombre d'échecs de pipeline par semaine, en tendance
• Mean time to detection (MTTD) : à quelle vitesse les problèmes de qualité sont détectés
• Mean time to resolution (MTTR) : à quelle vitesse les problèmes détectés sont résolus
• Respect des SLA de fraîcheur : % de jeux de données respectant leur SLA de fraîcheur

Suivies mensuellement, ces métriques vous disent si votre programme shift-left fonctionne.

À retenir

• Les mauvaises données entrent généralement à la source, donc l'endroit le moins coûteux pour les intercepter est en amont, pas dans le warehouse.
• Utilisez le bon outil pour chaque couche : les contrôles par assertion (Great Expectations sur son API GX 1.0, Soda) détectent les violations de règles connues, tandis que les outils d'observability (Monte Carlo) font remonter les anomalies que vous n'aviez pas pensé à tester.
• Les tests dbt ont leur place dans le CI/CD, avec blocage des builds en échec avant la production, la même discipline que les équipes logicielles appliquent déjà au code.
• Une metrics layer (Minerva chez Airbnb, le dbt Semantic Layer sur MetricFlow, Looker, Cube) gouverne ce que signifie une métrique, pour que le chiffre d'affaires soit compté de la même façon partout.
• Suivez chaque mois MTTD, MTTR, couverture de tests, taux d'incidents et respect des SLA de fraîcheur pour savoir si le programme fonctionne réellement.