ELT — Extract, Load, Transform

Définition complète

ELT signifie Extract, Load, Transform — extraction, chargement, transformation. C'est le pattern de pipeline de données dominant pour les architectures analytiques modernes sur cloud. À la différence de son prédécesseur ETL (Extract, Transform, Load), ELT ne transforme pas les données dans un environnement de staging intermédiaire avant leur chargement : il charge d'abord les données brutes dans l'entrepôt, puis effectue toutes les transformations à l'intérieur de l'entrepôt en utilisant sa puissance de calcul native.

L'émergence d'ELT est directement liée à l'évolution du coût du calcul analytique. Jusqu'au milieu des années 2010, le stockage et le calcul dans un entrepôt de données étaient coûteux — il était donc rationnel de transformer les données en amont pour ne charger que ce dont on avait besoin, dans un format déjà prêt à l'emploi. L'arrivée des entrepôts cloud élastiques — Snowflake, BigQuery, Amazon Redshift — a changé l'équation : le calcul en entrepôt est devenu suffisamment bon marché pour que transformer directement dans l'entrepôt soit plus efficace, plus flexible et plus facile à maintenir que de multiplier les environnements de transformation en amont.

ELT préserve également les données brutes dans leur état original, ce qui est fondamental pour deux raisons opérationnelles majeures : la capacité de reprocesser l'historique lorsque les règles métier évoluent, et la possibilité de construire de nouveaux modèles analytiques sur des données passées sans avoir besoin de re-extraire depuis les systèmes sources.

Comment implémenter un pipeline ELT

Un pipeline ELT se décompose en trois étapes distinctes, chacune assurée par une catégorie d'outils spécialisée.

Ce stack — souvent appelé "Modern Data Stack" — s'est imposé comme l'architecture analytique de référence entre 2018 et 2024. Il combine la fiabilité de l'ingestion managée, la flexibilité de la transformation SQL versionnable, et la puissance de calcul élastique des entrepôts cloud.

Exemple concret

Prenons l'exemple d'une entreprise SaaS B2B française avec 450 clients, utilisant Stripe pour la facturation, Salesforce comme CRM, et HubSpot pour le marketing. L'équipe data souhaite construire un tableau de bord opérationnel consolidant MRR, pipeline commercial et coût d'acquisition client (CAC) en un seul endroit.

Avec ELT, Fivetran extrait en continu les données de Stripe (transactions, abonnements, remboursements), Salesforce (opportunités, comptes, activités), et HubSpot (leads, campagnes, coûts marketing) et les charge dans Snowflake sous forme brute. Ces tables brutes — raw.stripe.subscriptions, raw.salesforce.opportunities, raw.hubspot.campaigns — arrivent dans Snowflake avec leur schéma d'origine, sans modification.

dbt prend ensuite le relais : des modèles SQL versionné dans Git transforment ces tables brutes en métriques opérationnelles nettes. Un modèle mrr_monthly calcule le MRR, le New MRR, le Churn MRR et l'Expansion MRR mois par mois depuis les données Stripe. Un modèle cac_by_channel joint les dépenses HubSpot aux nouvelles acquisitions Salesforce pour calculer le CAC par canal. Ces modèles sont rafraîchis toutes les heures via Dagster, et les erreurs de qualité de données déclenchent une alerte Slack immédiate.

En juillet, les règles de comptabilisation du MRR changent : l'équipe décide de passer d'une comptabilisation en date d'encaissement à une comptabilisation en date de début d'abonnement. Avec ELT, les données Stripe brutes sont toujours disponibles dans Snowflake. Il suffit de modifier le modèle dbt mrr_monthly et de reprocesser l'historique complet depuis 2021. L'ensemble de l'exercice prend environ 45 minutes. Avec un pipeline ETL classique, cette migration aurait nécessité une re-extraction complète depuis Stripe — des semaines de travail, avec un risque important de perte de données historiques.

Analyse approfondie

L'avantage le plus sous-estimé d'ELT est la séparation nette entre l'ingestion et la transformation. Dans un pipeline ETL classique, les règles de transformation sont souvent mélangées au code d'extraction — des scripts Python monolithiques qui extraient, nettoient et chargent en une seule passe. Cela crée une dette technique importante : modifier une règle métier implique de toucher au code d'ingestion, avec un risque de régresser la fiabilité de l'extraction. ELT sépare proprement ces responsabilités : les outils d'ingestion (Fivetran, Airbyte) gèrent l'extraction et le chargement de manière fiable et déclarative ; dbt gère la transformation en SQL pur, testé, documenté et versionné.

La montée en puissance de dbt est indissociable du succès d'ELT. dbt a transformé la transformation de données d'une activité réservée aux ingénieurs en une pratique accessible aux analystes maîtrisant le SQL. En permettant à des analystes de définir des modèles, des tests et de la documentation dans un framework Git-natif, dbt a aligné les pratiques de l'ingénierie data sur celles du développement logiciel : revues de code, tests automatisés, déploiement continu. C'est cette combinaison — entrepôts cloud élastiques + dbt — qui a précipité l'adoption massive d'ELT entre 2018 et 2022.

ELT a également une implication importante sur la gouvernance des données. Puisque les données brutes sont conservées dans l'entrepôt, les équipes peuvent construire une lignée de données complète et auditable : depuis la table brute source jusqu'aux métriques finales consommées par les tableaux de bord. Cette traçabilité est essentielle pour la conformité RGPD — être capable de répondre à "d'où vient ce chiffre ?" — et pour diagnostiquer les anomalies dans les rapports opérationnels. Sans cette lignée, le data warehouse devient une boîte noire où personne ne sait pourquoi un chiffre a changé.

Les limites d'ELT méritent d'être reconnues. ELT n'est pas toujours le bon choix. Pour les cas nécessitant un traitement de flux en temps réel avec une latence inférieure à la seconde (détection de fraude, personnalisation en temps réel), les architectures de streaming (Apache Kafka, Apache Flink) complètent ou remplacent ELT. Pour les données soumises à des contraintes strictes de résidence — certaines données médicales ou bancaires ne peuvent pas quitter un périmètre géographique précis avant transformation — ETL peut rester obligatoire. Enfin, pour les organisations avec des environnements on-premise legacy et des entrepôts commerciaux anciens, la migration vers ELT cloud peut représenter un projet pluriannuel avec des contraintes techniques et organisationnelles significatives.

L'évolution actuelle d'ELT se concentre sur deux axes. D'une part, la convergence avec les architectures lakehouse : les formats de tables ouverts (Apache Iceberg, Delta Lake) permettent d'appliquer les principes ELT à des données stockées dans des data lakes sur object storage (S3, GCS), avec les propriétés ACID d'un entrepôt traditionnel. D'autre part, le développement du Reverse ETL comme complément indispensable : une fois les données transformées dans l'entrepôt, des outils comme Hightouch et Census les renvoient vers les outils opérationnels (Salesforce, HubSpot, Zendesk), fermant ainsi la boucle entre analyse et action.

Erreurs fréquentes dans la mise en oeuvre d'ELT

• ✗

  Transformer dans les outils d'ingestion plutôt que dans l'entrepôt : Fivetran et Airbyte permettent des transformations légères au moment de l'ingestion. Utiliser cette fonctionnalité pour des transformations métier complexes reproduit les problèmes de l'ETL — la logique métier est mélangée à la couche d'ingestion, invisible dans Git, non testée. Réservez les transformations dans l'outil d'ingestion au strict minimum (renommage de colonnes, cast de types) ; tout le reste appartient à dbt, dans l'entrepôt.

• ✗

  Ne pas séparer les couches de modélisation dbt : un anti-pattern courant consiste à construire des modèles dbt qui mélangent nettoyage des données brutes, jointures métier et agrégations finales dans une seule couche. La pratique correcte est de respecter une architecture en couches : staging (nettoyage des tables brutes, une table source par modèle), intermediate (jointures et enrichissements), marts (agrégations finales exposées aux outils de BI). Sans cette séparation, la maintenance des pipelines devient rapidement ingérable à mesure que le nombre de sources croît.

• ✗

  Ignorer les tests de qualité des données dbt : dbt intègre nativement des tests de qualité — unicité, non-nullité, valeurs acceptables, intégrité référentielle — qui peuvent être déclarés en quelques lignes YAML. Ne pas les implémenter dès le départ conduit à découvrir les problèmes de qualité des données dans les tableaux de bord plutôt qu'à la source, au moment où leur impact opérationnel est déjà visible. Des pipelines ELT sans tests de qualité génèrent une dette de confiance coûteuse à rembourser.

Comment Fairview s'intègre avec votre stack ELT

Fairview est conçu pour se connecter directement à votre entrepôt de données existant — Snowflake, BigQuery, Redshift — et consommer les modèles dbt que vous avez déjà construits. Si vous avez un modèle mrr_monthly ou un mart customer_health, Fairview peut les exploiter immédiatement sans re-transformation. Pour les équipes qui n'ont pas encore de stack ELT en place, Fairview se connecte directement aux sources opérationnelles — Stripe, Salesforce, HubSpot — et gère l'ingestion et la transformation de manière autonome. Dans les deux cas, le tableau de bord opérationnel Fairview présente vos métriques clés — MRR, CAC, pipeline, marge de contribution — mises à jour en continu, avec des alertes configurables sur les anomalies et les franchissements de seuil.

Questions fréquentes