Data Quality & dbt : Comment scaler le framework des 6 Dimensions sur une architecture multi-sources

💡 Série : Data Quality Engineering à l’échelle

Cet article est le premier d’une série en 5 actes détaillant la mise en place d’un “Data Health Score” de bout en bout sur une architecture de production complexe.

• Partie 1 : Le Framework (De la théorie au code dbt) — Vous êtes ici
• Partie 2 : L’Ingénierie (Automatisation et dette technique)
• Partie 3 : Le Run de Prod (Gérer le bruit et l’architecture)
• Partie 4 : Le Moteur de Scoring (Mathématiques et Snowflake)
• Partie 5 : L’Observabilité UI (Elementary OSS vs Streamlit)

L’illusion du Semantic Layer et le piège de la donnée aveugle

Dans le petit monde du Modern Data Stack, la promesse est belle : on centralise la donnée via Fivetran, on la transforme proprement dans Snowflake avec dbt, et on expose un magnifique Semantic Layer (Couche Sémantique). Le but ultime ? Rendre les équipes métiers 100 % autonomes pour requêter leurs indicateurs de Chiffre d’Affaires ou de churn.

Mais cette abstraction technologique est à double tranchant. En masquant la complexité des jointures et des sources sous-jacentes au métier, elle masque également les anomalies.

Si une synchronisation API échoue silencieusement, ou si un système source commence à générer des doublons, le Semantic Layer continuera d’exposer des métriques. Et le métier, en toute confiance, prendra des décisions sur des chiffres faux. Les conversations ressemblent alors souvent à cela :

“Est-ce que le chiffre d’affaires de mai sur ce dashboard est fiable ?” “On pense que oui, le pipeline a tourné cette nuit.”

Sur notre projet actuel (la consolidation financière et opérationnelle pour un grand courtier en assurance), “penser que oui” n’était plus suffisant. Avec des flux provenant d’ERPs métiers multiples (Winpass, Belair, bases ADP) et de fichiers manuels (Ad-hoc), consolidés à coup d’UNION ALL massifs, le risque d'erreur structurelle était décuplé.

Il nous fallait passer d’une certitude basée sur l’espoir à une métrique objective : un Data Health Score. Voici comment nous sommes passés de la théorie à une implémentation automatisée sur des centaines de modèles dbt, jusqu’à la restitution visuelle de ce score.

1. De la théorie académique au code : Le framework des 6 Dimensions

Avant de coder, il faut s’entendre sur ce qu’est une “bonne” donnée. Plutôt que de réinventer la roue, nous nous sommes appuyés sur le standard de l’industrie codifié par le DAMA-DMBOK, qui définit 6 dimensions fondamentales de la qualité des données.

Dans l’écosystème dbt, ces concepts abstraits se traduisent par des tests SQL très concrets. Voici notre mapping :

1. La Complétude (Completeness) : L’information critique est-elle présente ? En dbt : Les inévitables tests not_null ou not_null_proportion. Sur nos modèles Gold, une prime totale (total_premium) ou une date d'effet ne peuvent pas être vides.
2. L’Unicité (Uniqueness) : Éviter le fléau du double-comptage. En dbt : Les tests unique sur nos Surrogate Keys (id_tech_quittance). Vital lorsque l'on fusionne des données de systèmes qui n'ont aucun identifiant commun.
3. La Validité (Validity) : Le respect des règles de formatage et de classification. En dbt : L’utilisation stricte de accepted_values pour s'assurer que les statuts de contrats ou les types de gestion (ex: Gestion Déléguée vs Non-Déléguée) ne dérivent pas dans le temps, ou dbt_expectations pour borner temporellement nos données (rejet des dates > 2035).
4. L’Exactitude (Accuracy) : La donnée reflète-t-elle la réalité financière ?En dbt : C’est ici que dbt_utils.expression_is_true brille. Il nous permet de valider des équations comptables impératives ligne à ligne (ex: Taux Apériteur + Taux Co-assurance = 100 %, ou Prime Nette <= Prime Totale)
5. La Cohérence (Consistency) : L’intégrité référentielle entre nos différents domaines (ex: vision opérationnelle vs vision comptable consolidée). En dbt : Les tests de relationships (clés étrangères) pour s'assurer qu'un contrat facturé existe bien dans notre dimension globale des contrats.
6. La Fraîcheur (Freshness) : La donnée est-elle arrivée à temps pour le closing ? En dbt : Les blocs freshness natifs sur nos sources, couplés à des tests singuliers sur nos tables Gold pour garantir que le pipeline global s'est exécuté dans les SLA (ex: alerte si le dernier _fivetran_synced dépasse 48h).

2. L’arsenal : Les packages dbt incontournables

Pour implémenter ce framework sans réécrire des milliers de lignes de SQL complexe, nous nous sommes appuyés sur l’écosystème open source de dbt. Voici le trio gagnant de notre architecture :

⚙️dbt-utils & dbt-expectations : Les fondations robustes

• **dbt-utils** est le couteau suisse. Nous l’utilisons massivement pour la dimension Exactitude via la macro expression_is_true, ou pour l'Unicité avec unique_combination_of_columns.
• **dbt-expectations* (le portage de Great Expectations* pour dbt) excelle dans la dimension Validité. Il nous permet de borner nos données facilement (expect_column_values_to_be_between) ou de vérifier des expressions régulières.

🪄Elementary : La pépite de la Data Observability

Si les deux premiers packages gèrent des règles “statiques”, **Elementary* apporte la dimension dynamique. C’est un package open source* que beaucoup négligent à tort.

Plutôt que de figer des bornes d’alertes en dur dans notre code (ce qui est infernal à maintenir), Elementary crée un schéma d’artefacts dans Snowflake et surveille la distribution statistique de la donnée dans le temps via des algorithmes de Machine Learning (détection d’anomalies). Nous l’utilisons pour surveiller des dimensions critiques sans effort :

• volume_anomalies : Alerte si la source Winpass intègre soudainement 50 % de quittances en moins que d'habitude (Fraîcheur/Complétude).
• column_anomalies : Alerte si la moyenne des montants de prime s'effondre (Exactitude).

De plus, Elementary nous servira de base de restitution visuelle, comme nous le verrons dans la dernière partie de cette série.

Conclusion & Prochaines étapes

En théorie, cartographier ces 6 dimensions et définir les bons packages est intellectuellement satisfaisant. Mais en pratique, la réalité frappe à la porte.

Comment appliquer ce niveau de rigueur sur une architecture existante qui compte déjà plusieurs dizaines de modèles Gold et plus de 750 tests intermédiaires ? Si nous voulons calculer un Data Health Score, notre système doit savoir quel test correspond à quelle dimension.

Repasser sur 750 tests à la main dans 30 fichiers schema.yml différents pour ajouter des meta tags ? Hors de question.

Dans la Partie 2, nous verrons comment nous avons dompté cette dette technique et scaler notre approche de qualité en utilisant Python pour automatiser et injecter nos dimensions directement dans la base de code dbt, de manière chirurgicale.