Les modèles SQL hérités, c'est une archéologie de la data. Tables interconnectées sans documentation. Zéro version. Zéro test. Quand un chiffre est faux, vous tracez cinq niveaux de requêtes imbriquées pour trouver le bug. Changer une colonne casse cascadement dix autres tables. Bienvenue en 2010.
dbt en 2026 s'impose comme le standard incontournable pour refondre. Parce qu'il transforme le SQL brut en code : versionnement, tests, documentation, CI/CD natif, lineage automatique. Refondre avec dbt c'est pas une tâche ponctuelle, c'est une transformation profonde de la fabrication de données.
Pourquoi le legacy SQL meurt
Les modèles SQL hérités ont une maintenance coûteuse - 40% du temps des data engineers juste à maintenir. Gartner (2025) rapporte que 78% des data teams utilisent dbt ou le considèrent sérieusement. Pourquoi ? Parce que dbt offre ce que le SQL classique ne peut pas.
La modularité : décomposer en couches claires. Les tests intégrés : capturer les bugs avant la production. La documentation vivante : pas du Word obsolète. L'infrastructure CI/CD native. Le DAG (Directed Acyclic Graph) qui rend les dépendances explicites.
Un refactoring progressif prend 6-12 mois mais réduit de 80% la dette technique. C'est pas un coût, c'est un investissement que vous payez progressivement.
Trois couches avec responsabilités claires
L'architecture dbt repose sur trois couches, chacune avec un rôle précis.
Couche staging (raw) : transformation minimale des données brutes. Renommage des colonnes, typage, déduplication, normalisation des formats. Pas de logique métier ici. Juste du nettoyage de surface.
Couche intermediate : la logique complexe vit ici. Calculs, jointures, agrégations. Les tables intermédiaires sont réutilisables par plusieurs marts finaux. C'est où les données commencent à parler le langage du business.
Couche marts : tables métier prêtes pour la BI. Suffisamment structurées pour l'analyse. C'est ce que consomment finalement les utilisateurs.
Cette séparation réduit de 60% le coût de maintenance parce qu'une logique complexe n'est définie qu'une fois en intermédiaire, réutilisée partout. L'erreur classique : mettre toute la logique en marts. Résultat : duplication de code, cauchemar de maintenance.
Tests = confiance en production
Les tests en dbt sont de première classe. Not_null, unique, accepted_values, relationships. Et tests custom SQL. Chaque colonne critique doit avoir au minimum un test.
Les tables intermédiaires sont testées pour détecter anomalies avant propagation en marts. dbt Labs rapporte que les modèles avec tests réduisent de 85% les bugs en production.
Les tests s'exécutent dans la CI dbt Cloud : chaque merge request déclenche les tests avant production. C'est la barrière de sécurité contre les mauvaises transformations. Sans tests, c'est du code non-fiable. Avec tests, c'est de l'ingénierie.
Documentation vivante, pas papier mort
dbt génère automatiquement la doc via les fichiers YAML. Chaque colonne, chaque table peut avoir description détaillée avec règles de calcul et cas d'usage. Le lineage DAG montre visuellement comment les données circulent de la source à la BI.
Un changement en staging montre immédiatement l'impact sur les marts dépendants. C'est la traçabilité qui réduit énormément les investigations en production. La documentation dbt est vivante - elle est mise à jour quand le code change. C'est la documentation-as-code appliquée à la data.
Modularité via Jinja2 et macros
dbt permet de factoriser via Jinja2 (templates) et macros. Au lieu de copier-coller la même logique dix fois, vous créez une macro réutilisable. Transformer des dates? Normaliser des noms de colonnes? Appliquer une logique métier complexe? Une macro une fois, utilisée partout.
Les tests custom génériques : définir une règle métier une fois, l'appliquer à 50 colonnes sans duplication. dbt Packages (librairies open-source de macros) accélèrent le développement. dbt-utils, dbt-expectations. La modularité réduit de 40% le temps de développement de nouvelles tables.
CI/CD natif pour la production de confiance
dbt Cloud offre CI/CD native : chaque pull request déclenche les tests sur un schéma éphémère, validant les changements avant production. Le merging automatique en production se fait qu'après succès des tests. L'historique de chaque modification est enregistré.
La migration depuis du legacy se fait progressivement. Refondre 5-10% des modèles par sprint. Puis les autres. Jamais un big-bang qui paralyserait. Les premiers mois forment les équipes à la philosophie dbt, à Jinja2, aux tests. Puis l'accélération s'enclenche. Après 6-12 mois, l'équipe double sa vélocité grâce à la réutilisabilité et l'automatisation.
Le vrai changement: culture
Refondre avec dbt c'est pas un projet IT, c'est une transformation de la culture données. Code versionnée, tests, documentation vivante, CI/CD natif. Une équipe data adoptant dbt gagne 40% en productivité et réduit la dette technique de 80%.
C'est l'investissement le plus rentable pour une data team qui veut passer de l'ad hoc à la production robuste. Et c'est industriel - c'est de la vraie production.