dbt et l'ETL : ce que dbt remplace vraiment, et ce qu'il faut garder

Le monde a changé, pas vos pipelines

En 2010, stocker un gigaoctet sur le cloud coûtait environ 0,14 $. En 2025, ce même gigaoctet coûte moins de 0,02 $ sur S3 : une chute de plus de 85 % en quinze ans. Côté puissance de calcul, le changement est encore plus radical : les data warehouses cloud comme Snowflake, BigQuery ou Databricks offrent une capacité de traitement quasi illimitée, facturée à la seconde

Ce double basculement (stockage devenu trivial, calcul devenu élastique) a rendu obsolète l’hypothèse fondamentale sur laquelle reposent tous les ETL traditionnels

Les ETL comme Talend, Informatica ou SSIS ont été conçus dans les années 2000, quand le stockage coûtait cher et les serveurs de base de données avaient une capacité fixe. La logique était simple : transformer les données avant de les charger dans le warehouse, pour ne stocker que ce qui est strictement nécessaire. D’où le sigle ETL : Extract, Transform, Load

Le problème, c’est que cette logique a des conséquences lourdes. Les transformations se font dans un outil propriétaire, avec une interface graphique opaque, une logique non versionnée, des tests impossibles à automatiser, et une documentation qui vit dans la tête du développeur ETL qui a construit le job il y a trois ans, et qui a quitté l’entreprise depuis

Pourtant, la majorité des ETI françaises continuent d’utiliser ces outils. Pas par choix éclairé, mais par inertie. Le coût de la dette technique s’accumule silencieusement : maintenance chronophage, erreurs non détectées, analystes dépendants d’une équipe d’ingénierie data surchargée

L’analogie est celle du tri postal : vous aviez l’habitude de trier votre courrier avant de le mettre dans la boîte aux lettres, parce que la boîte était petite. Aujourd’hui, la boîte est illimitée. Pourquoi continuez-vous à trier dehors, sous la pluie ?

ETL vs ELT : ce qui change vraiment

Le modèle ELT (Extract-Load-Transform) inverse la séquence. On extrait les données des sources, on les charge telles quelles dans le data warehouse cloud, puis on les transforme à l’intérieur du warehouse en SQL. C’est un changement de paradigme, pas juste un réordonnancement de lettres

Critère	ETL traditionnel	ELT moderne
Modèle	Transformer avant de charger	Charger d’abord, transformer dans le warehouse
Lieu de transformation	Serveur ETL dédié	Data warehouse cloud (Snowflake, BigQuery, Databricks)
Langage	GUI propriétaire + scripts	SQL standard
Versionnement	Limité ou inexistant	Git natif (code SQL + YAML)
Tests automatisés	Manuels ou absents	Intégrés (dbt test, CI/CD)
Documentation	Word, Confluence, ou rien	Générée depuis le code (docs-as-code)
Coût de licence	50-500K€/an (Talend, Informatica)	Gratuit (dbt Core) ou ~100$/user/mois (dbt Cloud)
Profil nécessaire	Développeur ETL spécialisé	Analyste SQL + culture Git

Le changement le plus profond n’est pas technique, il est organisationnel. Avec un ETL, les transformations sont entre les mains d’une équipe d’ingénierie data spécialisée. Les analystes métier déposent des tickets, attendent des semaines, et reçoivent un résultat qu’ils ne peuvent ni vérifier ni modifier

Avec l’ELT et dbt, les analystes (rebaptisés analytics engineers) écrivent eux-mêmes les transformations en SQL, dans un repo Git, avec des tests et de la documentation. L’ingénieur data passe du rôle de développeur à celui d’architecte : il conçoit la plateforme, les conventions, les garde-fous, et laisse les équipes métier avancer en autonomie

C’est exactement le même mouvement que le Platform Engineering dans le monde logiciel : passer de “l’équipe ops fait tout” à “l’équipe plateforme fournit les rails, les développeurs avancent seuls”

Le modèle ELT déplace la transformation dans le warehouse, encore faut-il un outil pour l’y exécuter proprement, avec du versionnement, des tests et de la documentation. C’est exactement le vide que dbt a comblé

dbt : pourquoi c’est devenu le standard

dbt (data build tool) a été créé en 2016 par Fishtown Analytics, une société de conseil data de Philadelphie. À l’origine, c’est un outil interne : un framework en ligne de commande pour gérer les transformations SQL dans un data warehouse. Fishtown Analytics est devenu dbt Labs en 2021, a levé plus de 400 millions de dollars, et revendique aujourd’hui plus de 57 000 organisations utilisatrices. En 2025, dbt Labs a fusionné avec Fivetran pour former le leader de l’infrastructure data ouverte

Comment un outil open-source est-il devenu le standard de facto de la transformation de données ? En résolvant élégamment quatre problèmes que personne n’avait vraiment adressés

SQL natif. dbt ne vous demande pas d’apprendre un nouveau langage. Vous écrivez du SQL : le langage que chaque analyste connaît déjà. dbt y ajoute du templating (Jinja) pour les cas dynamiques, mais 90 % d’un projet dbt est du SQL pur

Git-native. Chaque modèle dbt est un fichier .sql dans un repo Git. Les transformations sont versionnées, auditables, reviewées en pull request. Fini les jobs ETL modifiés en production sans trace

Tests intégrés. dbt permet de tester ses données avec la même rigueur que du code applicatif : unicité des clés, absence de valeurs nulles, cohérence référentielle, règles métier personnalisées. Les tests s’exécutent automatiquement dans la pipeline CI/CD

Documentation auto-générée. Les descriptions des modèles et des colonnes vivent dans des fichiers YAML, à côté du code SQL. dbt docs generate produit un site statique navigable avec un graphe de dépendances complet : la cartographie de votre patrimoine data, toujours à jour

Pour illustrer, voici un modèle dbt simple qui transforme des commandes brutes en un fait agrégé par mois :

-- models/marts/fct_commandes_mensuelles.sql

with commandes as (
    select * from {{ ref('stg_erp__commandes') }}
),

aggregation as (
    select
        date_trunc('month', date_commande) as mois,
        count(*) as nombre_commandes,
        sum(montant_ttc) as chiffre_affaires,
        count(distinct client_id) as clients_actifs
    from commandes
    where statut = 'validee'
    group by 1
)

select * from aggregation

Ce modèle est versionné, testé, documenté, et s’exécute directement dans votre warehouse en quelques secondes. Comparez avec le job Talend équivalent : un diagramme de flux avec 15 composants, non versionné, non testé, et dont la logique est enfouie dans des paramètres de boîtes noires

Ce que dbt n’est pas : dbt ne fait pas l’extraction (E) ni le chargement (L). Il ne se connecte pas à vos sources de données. Il ne remplace pas Fivetran, Airbyte ou Stitch. Il ne remplace pas non plus votre orchestrateur (Airflow, Dagster). dbt est la couche T (Transform) et rien d’autre. Cette focalisation est précisément ce qui fait sa force

Savoir ce que dbt fait bien ne suffit pas, la vraie question est de savoir si votre organisation est prête à l’adopter, et sous quelle forme

Matrice de décision : quand migrer, quand rester

La migration vers dbt n’est pas un impératif universel. Votre contexte détermine la bonne approche. Nous proposons quatre scénarios basés sur nos retours terrain

Scénario 1 : PME, moins de 5 sources, équipe Data junior

Recommandation : dbt Core + warehouse cloud, le quick win. Vous n’avez pas encore d’ETL en place, ou vous utilisez des scripts SQL manuels et des exports Excel. C’est le cas idéal pour démarrer directement avec dbt

Effort estimé : 2-4 semaines pour un premier mart fonctionnel. Budget : quasi nul (dbt Core est gratuit, le warehouse cloud facture à l’usage). Risque principal : sous-estimer le besoin de conventions dès le départ, un projet dbt sans structure devient vite un plat de spaghettis SQL

Scénario 2 : ETI, ETL Talend ou Informatica en place, équipe mixte

Recommandation : migration progressive par domaine métier. Vous avez un ETL qui fonctionne, mais dont la maintenance consomme 50-60 % du temps de votre équipe data. La migration se fait domaine par domaine : on commence par un périmètre métier visible (finance, supply chain), on construit les modèles dbt correspondants, on valide en parallèle, puis on décommissionne les jobs ETL

Effort estimé : 3-6 mois pour 3-5 domaines. Budget : 80-150K€ (accompagnement + montée en compétences). Risque principal : la cohabitation prolongée ETL + dbt, qui génère un double coût de maintenance si le décommissionnement traîne

Scénario 3 : Grand compte, pipelines critiques réglementaires

Recommandation : approche hybride (ETL pour l’ingestion, dbt pour la transformation). Vos pipelines d’ingestion sont critiques, certifiés, et ne doivent pas être perturbés. En revanche, la couche de transformation est un terrain idéal pour dbt : elle bénéficie du versionnement, des tests, et de la documentation sans toucher à l’ingestion

Effort estimé : 6-12 mois pour l’ensemble du périmètre. Budget : 150-300K€. Risque principal : la résistance au changement des équipes ETL existantes, qui voient dbt comme une menace plutôt qu’un complément

Scénario 4 : Startup data-native, équipe moderne

Recommandation : dbt dès le départ, pas de dette. Vous construisez votre data platform from scratch. Aucune raison d’introduire un ETL traditionnel. Le stack moderne (Fivetran/Airbyte pour l’ingestion + Snowflake/BigQuery pour le warehouse + dbt pour la transformation) est plus rapide à mettre en place, moins cher, et plus facile à recruter

Effort estimé : 2-4 semaines pour les fondations. Budget : 5-15K€/mois (infra cloud + outils). Risque principal : négliger la structuration du projet dbt parce que “on est une startup, on ira vite”, la dette technique data s’accumule aussi vite que la dette logicielle

Ces scénarios ne sont pas théoriques. Voici ce que donne une migration ELT concrète, sur un périmètre représentatif de ce que nous voyons chez les ETI françaises

Retour terrain : migration ETL → dbt pour un acteur de l’économie circulaire

Nous avons accompagné un éco-organisme français de 200 personnes dans la migration de ses pipelines data vers dbt. Le contexte est représentatif de ce que nous observons chez de nombreuses ETI

L’existant : 15 sources de données (ERP, CRM, fichiers opérateurs, portails déclaratifs), des jobs SQL manuels exécutés par cron, des scripts Python pour les cas complexes, et 3 analystes qui passaient la majorité de leur temps en maintenance. Aucun test, aucune documentation, aucune traçabilité des transformations

Le diagnostic : 60 % du temps de l’équipe data était consacré à la maintenance et au débogage de pipelines existants. Les analystes métier attendaient en moyenne 2 semaines pour obtenir un nouveau rapport. Les erreurs de données étaient découvertes par les métiers, souvent lors de réunions de direction : le pire moment possible

La solution : migration progressive sur 4 mois vers dbt Core + Snowflake. Le premier mois a été consacré aux fondations : mise en place de Snowflake, initialisation du projet dbt avec des conventions strictes (naming, layers, tests), et migration du domaine pilote (collecte). Les trois mois suivants ont couvert progressivement les domaines restants

Les résultats :

Métrique	Avant	Après	Variation
Temps maintenance/semaine	3,5 jours	0,5 jour	-86 %
Couverture de tests	0 %	92 %	N/A
Time-to-insight (nouveau rapport)	2 semaines	2 jours	-86 %
Incidents data/mois	8	1	-88 %
Autonomie analystes (modèles créés sans aide)	0 %	75 %	N/A

Le détail de cette mission est disponible sur notre page cas client Éco-organisme

Les résultats sont là, mais chaque migration que nous avons accompagnée a aussi révélé des erreurs récurrentes qu’il vaut mieux connaître avant de se lancer

Les 4 pièges de la migration ETL → dbt

1. Vouloir tout migrer d’un coup. La tentation du big bang est forte, surtout quand l’ETL existant est douloureux. Mais migrer 200 jobs en une fois, c’est garantir 3 mois de double maintenance et un risque d’erreur maximal. Procédez domaine par domaine. Chaque domaine migré produit un résultat visible et réduit la charge de l’ancien outil

2. Reproduire la logique ETL dans dbt. Le réflexe naturel est de traduire chaque job Talend en modèle dbt. C’est une erreur. L’architecture ELT est fondamentalement différente : profitez de la migration pour repenser vos transformations, simplifier les jointures, et adopter le modèle en layers (staging → intermediate → marts). Si vous reproduisez la même logique, vous reproduisez les mêmes problèmes

3. Négliger la formation des équipes. Savoir écrire du SQL ne suffit pas pour utiliser dbt efficacement. Le versionnement Git, les tests, la documentation YAML, le templating Jinja, ces compétences s’acquièrent. Prévoyez 2 à 4 semaines de montée en compétences par analyste, avec un accompagnement terrain, pas juste un tutoriel en ligne

4. Oublier le décommissionnement de l’ancien outil. Chaque mois de cohabitation ETL + dbt est un mois de double maintenance et de double coût de licence. Définissez un plan de décommissionnement dès le kick-off, avec des dates cibles par domaine. Le jour où le dernier job ETL est éteint est le jour où le ROI de la migration se concrétise

Conclusion

L’ETL traditionnel a rendu des services considérables pendant deux décennies. Mais le monde dans lequel il a été conçu (stockage cher, calcul limité, équipes centralisées) n’existe plus. Le modèle ELT, avec dbt comme couche de transformation, est devenu le standard pour une raison simple : il est plus rapide à mettre en place, moins cher à opérer, et plus facile à recruter

La question n’est plus “faut-il migrer vers dbt ?” mais “quand et comment ?”. La réponse dépend de votre contexte, et la matrice ci-dessus vous donne un point de départ

Si vous avez un ETL qui consomme plus de temps qu’il n’en fait gagner, la migration vers dbt n’est pas un projet d’innovation, c’est un projet de bon sens économique

Nobori accompagne les ETI dans la modernisation de leurs pipelines data. Découvrir notre offre Data

Sources et méthodologie

• dbt Labs, “State of Analytics Engineering” (2024) : adoption dbt, profil des analytics engineers, tendances ELT
• Gartner, “Magic Quadrant for Data Integration Tools” (2025) : positionnement Informatica, Talend/Qlik, tendances du marché
• Snowflake, BigQuery, Databricks : pricing public et benchmarks de performance
• Retours d’expérience Nobori : données issues de nos missions d’accompagnement data auprès d’ETI (métriques avant/après anonymisées)

Les métriques du retour terrain (éco-organisme) sont issues de mesures réelles effectuées pendant la mission. Les estimations budgétaires et les timelines par scénario sont basées sur nos observations terrain sur une dizaine de missions de migration ETL → dbt réalisées entre 2023 et 2026

Pour aller plus loin

• Découvrez notre comparatif dbt Cloud vs dbt Core pour choisir le bon modèle de déploiement
• Consultez notre guide Data Mesh vs Data Lakehouse pour situer dbt dans une architecture data plus large
• Explorez notre expertise Data et nos approches d’industrialisation des plateformes data en entreprise