Data quality en production : comment automatiser la validation de vos pipelines pour éviter les data disasters

Une ligne mal formatée et un rapport client part en fumée

Mardi, 9h12. Le rapport d’acquisition mensuel part chez un client. À 11h30, un mail tombe : « le coût d’acquisition a doublé, c’est normal ? » Non. Une colonne de montant était arrivée en texte au lieu de numérique, et le calcul s’est fait sur des chaînes de caractères. Aucun test rouge, aucune alerte, aucun signal visible. Juste un chiffre faux dans un livrable signé, et un client qui commence à douter de toutes les données qu’on lui envoie.

C’est le vrai visage de la data quality en production : elle ne casse pas bruyamment. Un pipeline en panne se voit immédiatement. Une donnée de mauvaise qualité, non : elle traverse les jointures, remplit les dashboards, se recopie dans les exports, et reste fausse jusqu’à ce que quelqu’un la conteste. D’où la question que toute équipe data finit par se poser : comment savoir si la donnée que j’utilise aujourd’hui est correcte ? On a automatisé cette réponse sur nos pipelines, et voici comment.

Data quality : de quoi on parle vraiment en production

La data quality, ce n’est pas une donnée propre, c’est une donnée adaptée à son usage : exacte, complète, cohérente, fraîche, valide, unique. La même table peut être parfaite pour un reporting financier et inutilisable pour un scoring de churn, parce que l’usage n’est pas le même. La qualité des données se juge contre une décision à servir, jamais dans l’absolu.

3 notions circulent souvent mélangées, et elles posent 3 questions différentes à 3 moments du cycle de vie des données. La qualité des données demande : est-ce adapté à mon usage ? L’intégrité des données demande : est-ce fiable et non altéré sur ce cycle de vie ? L’observabilité demande : où en sont mes pipelines maintenant, en exécution ? Et la data quality n’est presque jamais un problème purement technique. C’est généralement un problème de collaboration, de process ou de produit en amont, rarement un problème data en silo.

Les 6 dimensions à surveiller sur un pipeline en production

Ces 6 dimensions de la qualité des données sont des critères intrinsèques, pas des opinions : chacune se mesure et se traduit en un test automatisable.

2 remarques de mise en œuvre. Une précision imparfaite vaut mieux qu’une absence de contrôle : un test mal calibré se corrige en une journée, un trou de couverture se paie en incident. Et ces dimensions sont couplées : des données complètes peuvent être fausses, et une donnée exacte peut être périmée.

Qualité, intégrité, observabilité : ne pas confondre les trois

La qualité regarde la donnée par rapport à l’usage, l’intégrité par rapport à son cycle de vie (non altérée, gérée de façon cohérente), l’observabilité par rapport à l’exécution (fraîcheur, complétude, cohérence, schéma, lineage). Les deux étages se complètent : les tests préviennent, l’observabilité détecte. Les tests as code sont le pendant design time de l’observabilité, qui est runtime. Un test au vert ne prouve donc rien sur le niveau de qualité actuel d’une donnée si personne ne surveille ce qui se passe entre deux exécutions, et sans traçabilité on ne sait même pas quelle alerte concerne quelle table.

Ce que coûte une donnée de mauvaise qualité

Les chiffres sont têtus. La mauvaise qualité des données coûte en moyenne 12,9 M$ par an aux organisations (Gartner et IBM). Un taux d’erreur de 5% dans les données d’entraînement peut dégrader la performance d’un modèle de 15 à 20%. Les coordonnées de contact B2B se dégradent de 3,6% par mois sans vérification, et la saisie manuelle génère 1 à 4% d’erreurs, davantage sur les champs complexes.

L’effet est démultiplicateur : une erreur qui entre à l’ingestion ressort dans dix rapports puis dans trois décisions budgétaires. Les données de mauvaise qualité se repèrent rarement à l’œil, et c’est tout le problème. Le point clé tient en une phrase : une donnée fausse coûte plus cher qu’un pipeline en panne, parce qu’elle n’a aucun signe visible. Les coûts d’une non-qualité ne se lisent pas dans les logs, ils se lisent en réunion.

L’impact sur les décisions et les rapports

Le symptôme le plus fréquent d’une défaillance de qualité, ce sont des chiffres contradictoires pour le même KPI entre deux départements : les ventes calculent le pipeline depuis le CRM, la finance calcule le revenu depuis un ERP cloisonné. Deux vérités pour la direction, des impacts stratégiques et financiers immédiats. Entre les deux, les contournements manuels s’installent, copier-coller entre outils, réconciliations à la main. Ces pratiques masquent la corruption à la direction, et la conséquence est une érosion de la confiance dans tout le pipeline de données.

L’impact opérationnel : le temps perdu et les clients mécontents

Côté opérations, une donnée de mauvaise qualité se paie en retraitement, en heures de re-vérification manuelle, en rapports rejoués en urgence. Ces opérations consomment du temps d’ingénieur qui ne produit rien de nouveau. Il y a aussi le budget gaspillé : campagnes envoyées à des contacts injoignables, audiences corrompues, délivrabilité dégradée. Et la perte la plus difficile à rattraper reste la crédibilité : quand un livrable client doit être corrigé après envoi, la confiance met des mois à revenir.

2 étages : les tests as code dans dbt et l’observabilité en production

Le test de données automatisé valide la fonctionnalité et l’intégrité du warehouse par des cas rejouables. Le test manuel ne tient pas la combinatoire des transformations : même une grosse équipe QA ne couvre pas toutes les combinaisons de sources, de typages et de fenêtres temporelles. L’automatisation, elle, applique les mêmes étapes de validation à répétition, fréquemment, sans heures de vérification manuelle. Produire des données fiables n’est pas un effort ponctuel : les règles de qualité deviennent des bonnes pratiques d’amélioration continue, versionnées comme du code.

Les tests intégrés au modèle dbt

dbt a imposé un standard simple : les tests vivent dans le modèle. Not null, unique, intégrité référentielle, valeurs acceptées : la donnée est certifiée avant d’être exposée. On ne vérifie pas après coup dans un audit ponctuel, on vérifie à la construction, dans le même fichier YAML que la documentation des colonnes. 3 raisons expliquent cette adoption : la fiabilité, le time to market et le self-service. Et le cadre compte autant que l’outil : Git, CI/CD, tests. Un contrôle de qualité en échec bloque le déploiement, donc il bloque la publication d’un rapport incorrect.

L’observabilité runtime : les 5 piliers

Côté exécution, 5 piliers structurent la surveillance en continu :

• Fraîcheur : la table a-t-elle été mise à jour dans les délais attendus ?
• Complétude : y a-t-il des valeurs ou des lignes manquantes ?
• Cohérence : les distributions et les volumes restent-ils dans les plages normales ?
• Schéma : la structure des tables a-t-elle changé de manière inattendue ?
• Lineage : d’où vient cette donnée, et qu’est-ce qui en dépend ?

Sans lineage, une alerte qualité reste une alerte isolée. Avec le lineage, elle devient une base de triage et d’évaluation d’impact. Et un rappel utile : le mauvais chiffre vient souvent du silo, pas du dashboard. On corrige un graphique en 10 minutes, on répare deux bases de données cloisonnées en 3 mois.

Notre stack : dbt, Snowflake, Great Expectations et Slack

Le choix de l’open source répond à 3 contraintes : pas de lock-in, coût maîtrisé, intégration dans la stack existante. On a écarté les solutions packagées qui enferment la donnée et le savoir-faire. Aucune brique ne doit devenir une sortie impossible, et le dispositif doit tenir avec une petite équipe.

• dbt : les transformations SQL versionnées et les tests intégrés au modèle.
• Snowflake : l’entrepôt, là où la donnée se charge, se transforme et se consomme.
• Great Expectations : les suites de tests hors dbt, notamment au moment de l’ingestion.
• Slack : le point de livraison des alertes, là où les équipes travaillent déjà.

Le pipeline de bout en bout

Ingestion vers un staging brut, transformation dbt en couches successives, exécution des tests à chaque run, routage des échecs vers Slack. La règle : chaque étape a un propriétaire nommé et au moins un test qui la garde.

Où placer chaque test dans le pipeline

La question du « où » compte autant que celle du « quoi », parce qu’un contrôle posé au mauvais endroit se contente de constater les dégâts plus tard.

• À l’ingestion : valider au point de collecte, bloquer les événements malformés, versionner les schémas en CI. C’est ici que la charge d’erreurs entre, ou n’entre pas.
• En transit : normaliser les enums et les horodatages, faire le profilage des distributions, détecter les anomalies et le début de dérive par champ.
• Dans le warehouse : unicité, intégrité référentielle et complétude sur les tables critiques, juste avant exposition aux métiers, sinon un problème non corrigé à l’ingestion cascade et chaque étape suivante hérite d’une entrée fausse.

Les 3 tests qu’on ne zappe jamais en production

On a fait un choix assumé : peu de tests, mais bien choisis. Une couverture massive et illisible finit ignorée, tandis que 3 tests ciblés sur les tables critiques, tout le monde les regarde. Un test qu’on ne comprend pas n’est pas un test, c’est du bruit. Ces 3 là couvrent les pannes les plus fréquentes et les plus coûteuses qu’on a réellement rencontrées.

Test 1 : la validation de schéma

Objectif : détecter un changement de structure non attendu avant qu’il ne casse les modèles en aval. Exemple concret : une source renomme la colonne order_date en ordered_at, ou fait passer un montant de numeric à string. Sans test, le modèle en aval échoue au mieux et produit des nulls au pire. Pourquoi c’est le plus rentable au regard de son coût : quelques lignes de configuration contre des heures de diagnostic. On versionne les structures attendues, on compare à chaque exécution, on alerte à la première dérive de format, de normes ou de typage.

Test 2 : fraîcheur et complétude

Deux questions : la donnée a-t-elle été mise à jour dans les délais attendus, et aucune ligne ne manque-t-elle ? Un seuil de fraîcheur se pose par table critique, jamais en global. Une table de transactions doit être fraîche de 2 heures, une table de référence clients peut vivre 24 heures.

L’analogie qui aide à calibrer vient du crawl : une URL nouvelle est découverte en environ 20 heures, mais son rafraîchissement prend environ 30 jours. Une donnée non rafraîchie n’est pas forcément cassée, elle peut être dans sa constante de temps normale. À l’inverse, une capacité de crawl qui chute en quelques secondes met 1 à 3 semaines à se rétablir, ce qui justifie d’alerter sur la cause amont avant le symptôme aval. Conclusion : des tables complètes mais périmées restent inutilisables, et un test de complétude sans seuil documenté ne maintient aucun niveau de qualité, il produit du bruit.

Test 3 : unicité et intégrité référentielle

Les doublons gonflent le stockage, ralentissent les traitements et injectent du bruit dans les analyses. Le test d’unicité se pose sur chaque clé primaire, sans exception.

L’intégrité référentielle vérifie que chaque clé étrangère pointe vers une ligne existante. Exemple typique : une fiche client dupliquée qui fausse un décompte de clients actifs. Personne ne s’en aperçoit jusqu’au jour où deux équipes annoncent deux chiffres différents. Ensemble, unicité et intégrité référentielle font d’une table un point de vérité exploitable plutôt qu’un agrégat de sources plus ou moins fiables.

Automatiser les alertes : seuils, gates et routage

Une alerte mal réglée détruit la surveillance qu’elle est censée porter. Trois règles évitent le pire :

• Un seuil par table et par dimension, jamais un seuil unique pour tout le warehouse.
• Une logique de confidence gates : ne pas alerter tant que le signal n’atteint pas un seuil de confiance.
• Une livraison de l’alerte là où l’équipe travaille déjà (Slack, orchestrateur, BI) pour réduire le temps de détection.

Pourquoi ces gates ? Parce qu’une alerte qui se rétracte 10 minutes plus tard coûte plus de crédibilité qu’un silence. C’est le même principe qu’une boundary de décision AUTO / CONFIRM / ESCALATE : une communication sortante est une action irréversible, elle ne doit jamais être en chemin automatique. La sécurité d’un dispositif tient moins au nombre d’alertes qu’à leur lisibilité.

Routage : l’alerte doit arriver dans Slack, pas dans un onglet oublié

Le principe : les insights qualité arrivent dans les outils existants, pas dans une interface dédiée de plus. Personne ne consulte un dashboard d’observabilité tous les matins, tout le monde a Slack ouvert.

L’objectif se mesure : réduire le MTTD (Mean Time To Detect) et le MTTR (Mean Time To Resolve). Un message utile contient 4 informations, quelle table, quelle règle, quel impact, quel propriétaire. C’est un sujet de collaboration concrète entre équipes : l’alerte doit être lue, comprise et prise en charge au premier coup d’œil, sinon elle rejoint la liste des notifications qu’on a appris à ignorer.

Éviter l’alerte qui ne veut rien dire

Un score de qualité isolé ne signifie rien : il ne prend son sens qu’évalué contre une politique, avec un score de qualité minimum, un score de gouvernance minimum et une revue humaine au-dessus d’un seuil. C’est la différence entre un critère intrinsèque mesuré et une décision fondée. Le piège classique, c’est le test qui passe au vert alors que la donnée est déjà périmée : il contrôle une forme, pas la pertinence de l’usage. Et il faut distinguer 2 scores qu’on confond souvent, le score de qualité (les règles passent-elles ?) et le score de gouvernance (le dataset est-il décrit, les PII taguées, le propriétaire assigné ?). Une gouvernance des données sérieuse tient les deux ensemble.

Le lineage : trier les alertes par impact, pas par volume

La question à se poser : si cette table est corrompue, quels dashboards, quels modèles et quels exports sont impactés ? Sans cette réponse, toutes les alertes ont le même poids et on traite d’abord ce qui fait le plus de bruit. Le lineage est le composant qui différencie vraiment l’observabilité de la simple data quality : il donne la traçabilité de bout en bout, d’où vient la donnée, quels liens existent entre les tables, qui est propriétaire de chaque colonne.

Prioriser par criticité des dépendances

Conséquence pratique : on priorise les corrections selon la criticité des dépendances, pas selon le nombre d’alertes. Une table qui alimente un rapport de direction passe avant une table de test interne qui déclenche 40 alertes par jour. Et pour les incohérences les plus discrètes, le lineage est souvent le seul moyen de remonter à la source : une colonne mal calculée 4 transformations plus haut explique le pic de nulls observé en bout de chaîne.

Résultats : ce que l’automatisation a changé

Le dispositif tourne en production depuis plusieurs mois. Au moment où j’écris ces lignes, il embarque 68 tests actifs sur les tables critiques, exécutés 2 fois par jour, au run nocturne et au rafraîchissement de mi-journée.

L’avant/après parle plus qu’un argumentaire :

• Temps de détection d’un incident : de plusieurs jours à moins de 30 minutes sur les tables critiques.
• Rapports rejoués en urgence : de plusieurs par trimestre à quasi zéro sur le dernier trimestre.
• SLA qualité formalisés et visibles par les métiers, table par table.
• Moins de retraitement manuel, donc du temps d’ingénieur rendu à d’autres chantiers.

Ce qui rend ce type d’investissement défendable devant une direction, ce n’est pas la promesse d’éviter un incident, c’est la preuve chiffrée de ce qui a été évité. On l’expose en réunion comme une évidence mesurable plutôt que comme une conviction.

Les pièges à éviter quand tu automatises la data quality

3 pièges nous ont coûté du temps. Le premier : le test qui ne veut rien dire, avec un seuil arbitraire copié quelque part, qui alerte tous les jours sans que personne n’agisse. Le deuxième : la dérive silencieuse, le risque principal d’un pipeline qui semblait propre, où les distributions glissent et les taux de nulls montent lentement sans que rien ne plante. Le troisième : la gouvernance qu’on ne peut pas respecter dans les délais, qui est une gouvernance qui ne s’applique pas réellement. La contre-mesure tient en un mot, observer avant de corriger, avec un mois de profilage avant de fixer un seuil. Les bonnes pratiques ne sortent pas d’un manuel, elles sortent de la distribution réelle de tes données. Et la sécurité des données appartient à la même revue, permissions et clés d’accès comprises.

Le piège de la donnée périmée qui a l’air propre

Une donnée périmée dégrade silencieusement la performance d’un modèle ou la justesse d’un rapport. La certification d’un dataset est une photo à un instant T : sans observabilité continue, elle devient un artefact historique.

D’où un impératif à tenir partout : ce qui a été observé d’un côté, ce qui a été estimé de l’autre. Ne jamais présenter une estimation comme une observation, et ne jamais laisser un score continuer à vivre sans date de dernière vérification, sinon il devient faux à mesure qu’il vieillit. Des données fiables, c’est un état qui se maintient, pas un certificat qu’on affiche.

Et au-delà des pipelines : la data quality pour l’IA

Les mêmes dimensions s’appliquent aux pipelines IA, avec des symptômes nouveaux. Des données corrompues dans un index vectoriel produisent des réponses dégradées, sans aucun signe visible. Une dérive sur les embeddings signifie que la distribution des données n’est plus la même qu’à l’entraînement, et le modèle continue de répondre avec assurance. Le cas le plus vicieux reste l’agent qui lit un score de qualité périmé : il s’appuie sur des preuves fausses, avec l’aplomb d’un système sûr de lui. C’est un enjeu stratégique, pas un détail de plomberie, d’autant que la majorité des échecs ML et IA en entreprise ne viennent pas du modèle mais de la qualité des données en amont. Investir dans un modèle sans investir dans la fonction qui l’alimente, c’est repeindre une voiture en espérant qu’elle démarre.

Ce qu’il faut retenir et comment démarrer cette semaine

Le résumé actionnable est volontairement court :

1. Choisis 2 ou 3 tables critiques. Pas 20.
2. Pose 3 tests sur chacune : schéma, fraîcheur et complétude, unicité et intégrité référentielle.
3. Envoie les échecs dans Slack, avec table, règle, impact et propriétaire.
4. Ajoute le lineage dans un second temps, quand les alertes sont déjà lisibles.
5. Fixe des SLA qualité visibles par les métiers, pose des règles plutôt que des intentions, et tiens-les.

À l’échelle de l’organisation, 5 principes portent le reste : aligner les équipes sur des standards communs, intégrer les contrôles dans les workflows existants plutôt qu’en audit ponctuel, rendre l’état de qualité visible, réviser après chaque cycle, et assigner une responsabilité claire à chaque étape du pipeline.

Est-ce que la data quality est un problème d’outil ou d’organisation ?

Position tranchée : la data quality révèle presque toujours un problème de collaboration, de process ou de produit en amont. Les outils ne règlent rien si personne n’est responsable d’un chiffre contesté. Le data quality management échoue rarement par manque de plateforme, il échoue par manque de clarté sur qui décide quoi. La data governance, dans ce sens, n’est pas un livrable mais un fonctionnement quotidien.

4 contrôles rendent une gouvernance des données réellement opérante : nommer un responsable du chiffre contesté, documenter le calcul de référence que tout le monde doit utiliser, tester qu’un contrôle de qualité en échec empêche la publication d’un rapport incorrect, et conserver le propriétaire et la règle à côté du rapport pour que la personne suivante n’ait pas à refaire l’enquête.

Le test final, formulé négativement : ton cadre explique-t-il ce qui se passe quand le marketing et la finance ne sont pas d’accord ? S’il répond seulement à « qui peut ouvrir un dashboard », ce n’est pas encore une gouvernance des données, c’est un annuaire, et il n’existe pas de solution unique pour le combler. Et pour répondre franchement, c’est souvent les 2 à la fois, un problème d’outil et un problème d’organisation, mais l’organisation d’abord. L’initiative technique ne tiendra que si une équipe est propriétaire des chiffres qu’elle publie, et si des données fiables ont un nom en face.

Si tu veux suivre l’aventure, abonne-toi !