dbt et la transformation moderne des données

De l'ETL monolithique au contrat de données : pourquoi dbt change la donne

Pendant des années, la transformation des données en entreprise a rhymé avec des pipelines ETL opaques, des scripts SQL éparpillés sur des dizaines de serveurs, et des équipes data condamnées à jouer les pompiers. Un changement de logique de la table source en production ? Trois semaines de chantier, deux incidents en cascade et une réunion de crise. Cette réalité, les équipes data de SFEIR la connaissent bien, et elles l'ont vue évoluer radicalement avec l'émergence de dbt (data build tool).

dbt n'est pas simplement un nouveau maillon dans la chaîne data. C'est une philosophie : appliquer aux données les mêmes pratiques d'ingénierie logicielle que celles qui ont transformé le développement applicatif au cours de la dernière décennie — versioning, tests automatisés, documentation vivante, revues de code, déploiement continu. En 2025, dbt est devenu l'outil de référence de la couche transformation dans la quasi-totalité des architectures data modernes, qu'elles reposent sur Snowflake, BigQuery, Databricks ou Redshift.

Mais comprendre dbt pleinement, c'est aussi comprendre le contexte architectural dans lequel il s'inscrit : celui du Data Mesh, une approche qui redistribue la responsabilité de la donnée au sein de l'organisation. C'est cette convergence — outil technique et paradigme organisationnel — que nous allons explorer dans cet article.

dbt en quelques mots : SQL, Git et bonnes pratiques

À sa base, dbt est un outil open source (avec une offre cloud payante, dbt Cloud) qui permet aux équipes data de transformer des données directement dans l'entrepôt de données, en écrivant du SQL et du Jinja. Là où les outils ETL traditionnels déplacent les données avant de les transformer, dbt embrasse le paradigme ELT (Extract, Load, Transform) : on charge d'abord les données brutes dans le data warehouse, puis on les transforme sur place, là où la puissance de calcul est la plus grande.

Concrètement, un projet dbt est un dépôt Git structuré contenant :

• Des modèles : des fichiers .sql qui définissent des transformations sous forme de vues ou de tables matérialisées
• Des tests : des assertions sur la qualité des données (unicité, non-nullité, intégrité référentielle, règles métier)
• De la documentation : des descriptions enrichies, générées automatiquement en un site web navigable
• Des sources : la déclaration explicite des tables d'entrée, avec leurs contrats de fraîcheur
• Des macros : des fonctions réutilisables en Jinja pour factoriser la logique

Le résultat est un DAG (Directed Acyclic Graph) de transformations, entièrement traçable, testable et reproductible. La commande dbt run matérialise les modèles dans l'ordre des dépendances. La commande dbt test valide la qualité. La commande dbt docs generate publie la documentation. Simple sur le papier, mais profondément structurant en pratique.

Le Data Mesh : quand l'organisation rattrape la technique

Pour saisir toute la portée de dbt dans les organisations modernes, il est indispensable d'aborder le concept de Data Mesh, théorisé par Zhamak Dehghani et qui s'est imposé comme l'une des architectures data les plus discutées de ces dernières années.

Le constat de départ est organisationnel autant que technique : les plateformes data centralisées — lac de données monolithique géré par une équipe data centrale — créent un goulot d'étranglement structurel. Plus l'organisation grandit, plus les domaines métier se multiplient, et plus l'équipe centrale croule sous les demandes. La qualité des données se dégrade, les délais s'allongent, la confiance des utilisateurs s'érode.

Le Data Mesh propose une réponse en quatre principes fondateurs :

• La propriété décentralisée par domaine : chaque domaine métier (finance, produit, supply chain, marketing…) est responsable de ses propres données, de leur production à leur consommation
• Les données comme produit : chaque équipe domaine publie ses données sous forme de data products — des ensembles de données documentés, testés, versionnés et fiables, consommables par d'autres équipes
• Une infrastructure self-service : une plateforme commune fournit les outils et l'infrastructure permettant à chaque domaine d'opérer en autonomie
• La gouvernance fédérée : des standards partagés (nommage, formats, SLAs) garantissent l'interopérabilité sans recentraliser le pouvoir

Ce paradigme transforme profondément le rôle des équipes data. L'équipe centrale cesse d'être le producteur unique de données pour devenir un enabler : elle fournit la plateforme, définit les standards, accompagne les domaines. La responsabilité de la qualité et de la pertinence des données revient aux équipes qui les connaissent le mieux.

dbt et Data Mesh : une symbiose naturelle

C'est ici que dbt révèle toute sa pertinence architecturale. Les projets dbt, structurés autour de domaines, avec des contrats de données explicites, une documentation générée automatiquement et des tests intégrés, sont l'outil idéal pour implémenter les principes du Data Mesh.

Prenons un exemple concret. Une entreprise retail souhaite adopter le Data Mesh. L'équipe domaine commandes devient propriétaire des données de transactions. Elle crée un projet dbt dédié, dans lequel elle modélise ses données brutes en plusieurs couches :

• Une couche staging qui nettoie et normalise les données sources
• Une couche intermediate qui applique les règles métier spécifiques au domaine
• Une couche marts qui expose les data products finaux : orders_daily_summary, customer_lifetime_value, etc.

Ces data products sont documentés dans dbt, testés à chaque exécution, et exposent un contrat clair : définition de chaque colonne, fraîcheur garantie, règles de qualité. L'équipe domaine finance, qui consomme ces données pour ses réconciliations comptables, peut s'y fier sans avoir à comprendre les transformations internes. La gouvernance fédérée se matérialise via des standards partagés définis dans un projet dbt central (dbt packages) que chaque domaine importe.

dbt pousse naturellement vers les bonnes pratiques du Data Mesh :

• La documentation des sources force à déclarer explicitement les dépendances entre domaines
• Le versioning Git crée une traçabilité et permet des revues de code inter-domaines
• Les tests automatisés matérialisent les SLAs de qualité promis aux consommateurs
• Le lineage (traçabilité de la généalogie des données) offre une visibilité de bout en bout, essentielle dans un environnement décentralisé

Les patterns d'architecture dbt en production

Après des années d'accompagnement de clients sur des projets dbt, les équipes data de SFEIR ont identifié plusieurs patterns d'architecture récurrents selon la maturité et la taille des organisations.

Le mono-repo : simple mais limitant

Le point d'entrée naturel est le projet dbt unique, dans un seul dépôt Git, géré par une équipe centrale. C'est le bon choix pour débuter : simplicité opérationnelle, lineage global, gouvernance unifiée. Mais ce pattern atteint ses limites dès que l'organisation grandit — les temps de compilation s'allongent, les conflits de merge se multiplient, et on recrée structurellement le goulot d'étranglement que le Data Mesh cherche précisément à éviter.

Le multi-repo avec packages partagés

Le pattern mature, aligné sur les principes du Data Mesh, repose sur plusieurs projets dbt indépendants par domaine, consommant des packages communs pour les macros et tests partagés. Chaque domaine déploie son projet indépendamment. La gouvernance fédérée se matérialise via un projet platform qui publie les standards (macros de date, tests de qualité custom, conventions de nommage).

Ce pattern requiert une infrastructure self-service solide : un registre de packages interne, des pipelines CI/CD par domaine, et un outil de catalogage (DataHub, Atlan, ou le catalogue natif du cloud provider) pour agréger la documentation de tous les projets.

dbt Mesh : la réponse officielle à l'échelle

dbt Labs a formalisé cette approche avec dbt Mesh (disponible dans dbt Cloud), qui introduit la notion de cross-project references : un projet dbt peut référencer directement des modèles d'un autre projet, avec des contrats de données explicites (définition de schéma imposée) et des politiques d'accès (quels projets peuvent consommer quel modèle). C'est la traduction technique la plus fidèle du Data Mesh, avec une gestion native de la gouvernance fédérée.

Qualité, observabilité et gouvernance : les trois piliers opérationnels

Adopter dbt ne suffit pas. Les organisations qui tirent le meilleur parti de l'outil ont investi dans trois dimensions complémentaires.

La qualité des données comme pratique d'ingénierie

Les tests dbt natifs (unique, not_null, accepted_values, relationships) sont un premier niveau indispensable. Mais les équipes matures vont plus loin avec des packages comme dbt-expectations (port de Great Expectations) ou dbt-data-reliability (Elementary), qui permettent de définir des assertions statistiques sur les distributions de données, détecter des anomalies volumétriques, et suivre l'évolution de la qualité dans le temps.

L'idée clé est de faire de la qualité un critère de déploiement : si les tests échouent en CI/CD, le modèle ne se déploie pas en production. Cette approche, empruntée aux pratiques DevOps, change fondamentalement la culture de l'équipe data.

L'observabilité : savoir ce qui se passe

Un pipeline dbt en production, c'est potentiellement des centaines de modèles qui s'exécutent à des fréquences variables. L'observabilité data — savoir en temps réel si les données sont fraîches, si les volumes sont normaux, si des anomalies apparaissent — est devenue un enjeu critique. Des outils comme Monte Carlo, Metaplane ou Elementary s'intègrent nativement avec dbt pour analyser les métadonnées des runs et déclencher des alertes pertinentes.

La gouvernance : du contrat informel au contrat explicite

La vraie maturité d'un projet dbt se mesure à la rigueur de sa gouvernance. Cela passe par des contracts dbt (disponibles depuis dbt 1.5) qui imposent un schéma strict sur les modèles publiés — si un développeur tente de supprimer une colonne d'un data product consommé par d'autres équipes, dbt bloque la compilation. C'est le garde-fou technique qui rend le Data Mesh viable à grande échelle.

dbt à l'ère de l'IA agentique : vers le data engineering augmenté

Le contexte technologique de 2025-2026 ne peut être ignoré. Les équipes data de SFEIR, comme celles de nos clients, vivent la même rupture que les équipes de développement logiciel : l'émergence d'agents IA capables d'agir sur l'environnement de travail, pas seulement de suggérer du code.

Cette évolution, que nous documentons dans nos Tech Trends 2026, représente une rupture opérationnelle et non un simple gain de productivité incrémental. Des outils comme Claude Code, lancé en février 2025, illustrent ce passage de l'IA "assistante" à l'IA "agentique" : l'agent ne suggère plus un modèle dbt, il peut analyser le schéma de la base source, comprendre les règles métier documentées, écrire l'ensemble des modèles, générer les tests correspondants, et soumettre une pull request — le data engineer passant au rôle de superviseur et d'architecte.

Cette convergence entre dbt et l'IA agentique ouvre des perspectives concrètes :

• Génération automatique de tests à partir de la documentation des data products
• Rétro-ingénierie de pipelines : un agent analyse un pipeline ETL legacy et propose sa réécriture en modèles dbt
• Détection et suggestion de corrections sur les anomalies de qualité détectées par l'observabilité
• Documentation enrichie : génération automatique de descriptions de colonnes et de contexte métier à partir du SQL et des sources de données

Mais cette puissance nouvelle impose aussi une rigueur accrue. Lorsque des agents IA modifient des modèles dbt en production, les pratiques DevOps — revues de code systématiques, tests automatisés, politique de branches stricte — ne sont plus optionnelles. Elles deviennent les garde-fous indispensables d'un système où la vélocité de production a été démultipliée.

C'est précisément ce qu'illustre la convergence entre dbt Mesh et les agents IA : d'un côté, des contrats de données explicites et des tests automatisés qui contraignent ce que l'agent peut modifier ; de l'autre, une capacité de production augmentée qui permet enfin de tenir les promesses du Data Mesh à l'échelle, sans que la charge de travail de documentation et de test devienne un frein.

Ce que SFEIR accompagne concrètement

Les équipes data de SFEIR accompagnent des organisations de toutes tailles dans leur modernisation data, et dbt est désormais un composant central de la quasi-totalité de nos missions de transformation. Quelques réalités que nous observons sur le terrain :

La migration depuis des ETL legacy est souvent le point d'entrée. Nous aidons nos clients à cartographier leurs pipelines existants, identifier les transformations à valeur ajoutée à migrer en priorité, et structurer le projet dbt initial avec les bonnes fondations (conventions de nommage, structure de couches, politique de tests minimale).

La définition de la cible architecturale est l'étape stratégique. Mono-repo ou multi-repo ? Quelle granularité de domaines ? Quel outil de catalogage ? Quel niveau de maturité du Data Mesh est réaliste compte tenu de l'organisation ? Ces choix ont des conséquences durables, et notre rôle est d'apporter l'expérience de nombreux projets pour éviter les impasses.

L'accompagnement humain et culturel est souvent sous-estimé. Le Data Mesh, en particulier, n'est pas un projet technique — c'est une transformation organisationnelle. Convaincre les équipes métier de prendre la propriété de leurs données, les former aux pratiques d'ingénierie data, définir les interfaces entre domaines : c'est un travail de fond qui dépasse largement la configuration d'un outil.

L'intégration dans les pratiques DevOps est systématiquement abordée. Un projet dbt sans CI/CD, sans politique de branches, sans environnements (dev / staging / prod) correctement isolés, reste fragile. Nous aidons nos clients à construire des pipelines de déploiement robustes, en s'appuyant sur les pratiques qui ont fait leurs preuves dans le développement logiciel — et que l'IA agentique rend encore plus nécessaires.

Conclusion : dbt comme levier de maturité data

dbt n'est pas une silver bullet. Il ne résout pas à lui seul les problèmes de gouvernance, de qualité ou d'organisation. Mais il crée les conditions techniques nécessaires pour que ces problèmes puissent être résolus : en rendant les transformations traçables, testables et documentées, il donne aux organisations les fondations sur lesquelles construire une pratique data sérieuse.

Couplé aux principes du Data Mesh, dbt permet de concilier deux impératifs souvent perçus comme contradictoires : la décentralisation de la responsabilité data (pour la rapidité et la pertinence) et la cohérence de la gouvernance (pour la confiance et l'interopérabilité). C'est précisément cette tension que les organisations data les plus matures ont appris à gérer.

À l'horizon 2026, avec l'accélération de l'IA agentique dans les pratiques d'ingénierie, les équipes qui auront investi dans ces fondations — contrats de données explicites, tests automatisés, lineage complet — seront les mieux positionnées pour bénéficier de la prochaine vague de productivité. Pas parce que leurs outils sont les plus modernes, mais parce que leur discipline d'ingénierie crée la confiance nécessaire pour laisser des agents IA agir sur leurs pipelines de données critiques.

C'est cette vision — technique, organisationnelle et prospective — que les équipes de SFEIR mettent au service de leurs clients. Parce que la transformation moderne des données n'est pas qu'une question d'outils : c'est une question de pratiques, de culture, et d'architecture pensée pour durer.