La stack ELT moderne : comprendre dbt, ingestion et orchestration

La stack ELTELTELT (Extract, Load, Transform) is a data integration pattern where raw data is loaded into a target system first, then transformed inside it using the platform's compute power.Voir la définition complète → moderne repose sur une division du travail précise entre trois fonctions : ingérer les données brutes, les transformertransformerA Transformer is a neural network architecture that uses self-attention to process sequences in parallel, powering most modern language and generative AI models.Voir la définition complète → en modèles analytiques, et coordonner l'ensemble dans le temps. Ces trois fonctions font souvent l'objet d'une confusion persistante, y compris dans des organisations qui ont déjà déployé les outils correspondants. Un CDO qui ne distingue pas clairement ces couches aura du mal à diagnostiquer les pannes, à évaluer les coûts, ou à recruter les profils adaptés.

Pourquoi cette architecture intéresse particulièrement le CDO

La décision d'architecture data n'est pas une affaire de détail technique. Elle détermine la vélocité à laquelle les équipes peuvent livrer de nouveaux modèles analytiques, le coût réel de la plateforme, et la capacité à auditer les transformations, ce qui devient un enjeu de gouvernance non négligeable dans un contexte réglementaire de plus en plus exigeant.

Avant l'ELT moderne, le paradigme dominant était l'ETLETLETL (Extract, Transform, Load) is a data integration process that pulls data from sources, reshapes it into a consistent format, and writes it into a target system.Voir la définition complète → : transformer les données avant de les charger dans l'entrepôt. Cette approche concentrait la logique dans des outils spécialisés comme Informatica ou des scripts SQLSQLSales Qualified Lead: a prospect the sales team has validated as ready for direct outreach and a proposal, having passed clear qualification criteria.Voir la définition complète → maintenus en dehors de tout système de versioning. Résultat : des pipelines fragiles, difficiles à tester, et dont la documentation était souvent inexistante ou obsolète.

L'ELT moderne inverse ce principe. On charge les données brutes dans un entrepôt analytique comme BigQuery, Snowflake ou Databricks, qui dispose de la puissance de calcul nécessaire pour effectuer les transformations directement en SQL. La logique métier vit dans des fichiers de code versionnés, testés et documentés. C'est ce renversement qui explique l'émergence de dbt comme outil central de la stack.

Comment cela fonctionne concrètement

Prenons un exemple concret : une entreprise de e-commerce qui veut alimenter un tableau de bord sur la marge par catégorie produit à partir de données issues de Shopify, de son ERP et de son outil logistique.

La couche d'ingestion a pour seul rôle de copier les données brutes depuis les sources vers l'entrepôt, sans les modifier. Des outils comme Fivetran ou Airbyte maintiennent des connecteurs préconfigurés pour des centaines de sources. Fivetran, par exemple, gère automatiquement les évolutions de schémamaUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.Voir la définition complète → côté source, ce qui évite des ruptures de pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Voir la définition complète → à chaque mise à jour du système source. Cette couche ne contient aucune logique métier. Elle répond à une question simple : les données sont-elles arrivées, et sont-elles conformes au schéma attendu ?

La couche de transformation, c'est là qu'intervient dbt (développé par dbt Labs). dbt permet aux data analysts d'écrire des transformations en SQL, organisées sous forme de modèles chaînés avec des dépendances explicites. Chaque modèle est un fichier `.sql` stocké dans un dépôt Git. On peut y associer des tests automatiques (une colonne ne doit pas contenir de valeurs nulles, une clé étrangère doit correspondre à un identifiant existant) et de la documentation inline. Dans notre exemple e-commerce, un modèle `orders_enriched` jointurerait les commandes Shopify avec les coûts d'achat de l'ERP et les frais de livraison issus de la logistique, pour produire une table de marges prête à être consommée par le tableau de bord.

Ce qui change fondamentalement avec dbt, c'est que la transformation devient un artefact d'ingénierie logicielle : elle est versionnée, testable, rejouable, et auditable. Un auditeur interne ou un régulateur peut tracer la provenance d'un chiffre jusqu'à la source brute.

La couche d'orchestration coordonne l'exécution de l'ensemble. Apache Airflow reste la référence open source la plus répandue. Des alternatives comme Prefect ou Dagster proposent une expérience développeur plus moderne et une meilleure observabilité native. L'orchestrateur détermine l'ordre d'exécution des tâches, gère les dépendances entre elles, et déclenche des alertes en cas d'échec. Dans notre exemple, il s'assure que Fivetran a terminé l'ingestion des données Shopify avant de lancer le modèle dbt correspondant, et que le tableau de bord n'est rafraîchi qu'une fois les transformations terminées.

Les dépendances entre couches

La confusion fréquente consiste à croire que dbt "orchestre" les pipelines. dbt gère les dépendances entre modèles SQL à l'intérieur de sa propre couche, mais il ne sait pas si l'ingestion s'est terminée correctement avant d'être lancé. C'est l'orchestrateur qui porte cette responsabilité. Les faire travailler ensemble demande une configuration explicite, et c'est souvent là que les pipelines se fragilisent dans les premières implémentations.

Quand adopter cette stack, et quand s'en méfier

Cette architecture fonctionne bien dans plusieurs configurations : des volumes de données conséquents qui justifient la puissance d'un entrepôt cloud, des équipes data capables d'écrire du SQL et d'utiliser Git, et une organisation où plusieurs domaines métier partagent les mêmes tables de référence.

Elle a des limites réelles. Le coût d'entrée est substantiel : la combinaison Fivetran + Snowflake + dbt Cloud représente facilement plusieurs dizaines de milliers d'euros annuels pour une PME, avant même d'inclure le temps d'implémentation. Fivetran lui-même, en tant qu'éditeur, présente ses tarifs comme proportionnels à la valeur délivrée, mais des retours d'expérience indépendants, notamment publiés sur des forums comme dbt Slack ou des blogs d'ingénierie comme celui de Notion, soulignent que les coûts peuvent devenir difficiles à prévoir à mesure que les volumes augmentent.

Par ailleurs, cette stack suppose une maturité organisationnelle. Une équipe data de deux personnes dans une entreprise de cinquante salariés n'a probablement pas besoin d'Airflow. Un script Python planifié avec un cron job peut suffire, et sa simplicité est un avantage.

La gouvernance est aussi un angle souvent sous-estimé. dbt génère un catalogue de données automatique à partir des descriptions inline, mais cela ne remplace pas une politique de définition des métriques. Si deux équipes définissent la "marge nette" différemment dans deux modèles distincts, le catalogue sera beau mais les chiffres resteront incohérents.

La stack ELT moderne est une architecture qui a fait ses preuves dans des environnements de données complexes, avec des équipes structurées. Son adoption doit être précédée d'un diagnostic honnête des capacités internes et d'une évaluation du coût total, pas seulement des licences. Le CDO qui choisit ces outils sans avoir répondu à ces questions au préalable risque de construire une infrastructure sophistiquée sur des fondations organisationnelles insuffisantes.