L'ETL : Extract, Transform, Load
L'ETL (Extract, Transform, Load) est le paradigme historique du pipeline de données. Apparu dans les années 1970-1980 avec les premiers entrepots de données sur site (Teradata, Oracle), il suit une logique simple : extraire les données depuis les sources, les transformer dans un espace intermédiaire (staging area), puis les charger dans l'entrepot de destination sous une forme propre et structurée.
La transformation est le coeur du processus : nettoyage des valeurs nulles ou incohérentes, agrégation, jointures entre tables, application des règles métier, normalisation des formats de date et de devise, changement de format. Tout se fait avant que la donnée atterrisse dans le Data Warehouse. L'entrepot ne recoit que des données propres, structurées et prets a l'emploi analytique.
Architecture et outils ETL traditionnels
Dans une architecture ETL classique, un serveur de transformation intermédiaire (ETL server ou staging area) prend en charge tout le travail de transformation avant que les données soient ecrites en base cible. Les outils historiques comme Informatica PowerCenter, IBM DataStage, Talend Open Studio ou Microsoft SSIS encapsulent cette logique dans des interfaces graphiques drag-and-drop et des connecteurs preconfigures pour des centaines de sources.
Cette approche impose un effort de conception en amont considérable : chaque règle de transformation, chaque jointure, chaque nettoyage doit être spécifie avant que les données arrivent en production. La lisibilite est un avantage réel — on sait exactement ce qui entre dans l'entrepot et sous quelle forme — mais la rigidite est un frein important lorsque les besoins analytiques évoluent rapidement ou lorsqu'un nouveau cas d'usage nécessite d'acceder a des colonnes non prévues initialement.
Les limites de l'ETL face aux besoins modernes
Le principal talon d'Achille de l'ETL est sa fragilite face aux changements de schema : si une source ajoute, renomme ou supprime une colonne, le pipeline peut casser silencieusement ou rejeter des données sans alerter les équipes en temps réel. Chaque évolution nécessite une intervention manuelle sur les mappings de transformation, ce qui créé une dette technique et des goulots d'etranglement.
L'ETL empêche également les Data Scientists et les Analysts d'acceder aux données brutes : seules les données transformées selon les règles définies par l'équipe Data Engineering sont disponibles. Si une question analytique necessitait une colonne filtrée en amont, il fallait attendre une évolution du pipeline. C'est précisément ce verrou que l'ELT a brise.
L'ETL a ete conçu a une epoque ou le stockage etait cher et les serveurs limites en puissance de calcul. Charger des données brutes non transformées dans un entrepot Oracle ou Teradata aurait ete du gaspillage — d'ou la transformation systématique en amont. Le cloud a renverse cette contrainte économique.
L'ELT : Extract, Load, Transform
L'ELT (Extract, Load, Transform) inverse l'ordre des opérations : on extrait les données depuis les sources, on les charge directement dans l'entrepot ou le lac de données dans leur état brut, non transforme, puis on les transforme en place via SQL ou des frameworks comme dbt. Cette approche est née avec le cloud et les data warehouses modernes a partir des années 2010.
Le changement fondamental est que le data warehouse lui-même devient le moteur de transformation. BigQuery (Google), Snowflake, Amazon Redshift ou Databricks SQL offrent une puissance de calcul elastique, un stockage columnar compresse quasi gratuit et des optimiseurs de requetes SQL extremement performants. Transformer des terabytes de données en SQL directement dans Snowflake est aujourd'hui plus rapide, plus reproductible et moins couteux que de le faire sur un serveur ETL intermédiaire.
Les avantages structurels de l'ELT
La preservation des données brutes est l'avantage le plus sous-estime de l'ELT. En chargeant les données sources sans transformation dans une couche raw, on créé un historique immuable de tout ce qui a ete recu. Si les règles métier changent dans six mois — nouvelle définition du chiffre d'affaires, nouveau calcul de churn — on peut rejouer les transformations sur l'historique sans re-extraire les sources ni negocier des accès avec les équipes système.
La flexibilité pour les équipes analytiques est également un avantage decisif. Les Data Scientists et les Analysts peuvent acceder aux données brutes pour leurs propres analyses exploratoires, sans attendre qu'un pipeline ETL soit reconfigure par l'équipe Data Engineering. Cette autonomie change profondément la dynamique entre les équipes et accélère les cycles d'iteration analytique.
Les trois couches de l'ELT : raw, staging et mart
L'ELT moderne s'organise en couches successives. La couche raw (ou bronze dans la nomenclature lakehouse) contient les données exactement telles qu'elles ont ete recues des sources : aucune modification, aucun filtre. C'est le journal immuable du pipeline. La couche staging (ou silver) contient les données nettoyees, deduplicuees, avec les types corriges et les valeurs aberrantes traitées. La couche mart (ou gold) contient les tables analytiques agrégées, prets a l'emploi pour les dashboards et les rapports.
Cette separation en couches, popularisée par le framework dbt et l'architecture medallion de Databricks, permet a chaque équipe de travailler au bon niveau d'abstraction : les Data Engineers maintiennent les couches raw et staging, les Analysts construisent les marts métier. Les dépendances entre couches sont explicites, testées et documentées automatiquement via le lineage dbt.
L'adoption d'architectures ELT-first s'est nettement accentuée avec la democratisation des entrepots cloud (Snowflake, BigQuery, Redshift), qui rendent la transformation de gros volumes bien plus abordable qu'avec des outils ETL traditionnels. L'ampleur exacte de cette bascule varie fortement selon les secteurs et la taille des organisations : les chiffres precis d'adoption circulant dans certains rapports d'analystes doivent être pris avec prudence et verifies aupres de la source originale avant d'être cites.
Les 5 différences fondamentales entre ETL et ELT
Au-dela de l'ordre des opérations, ETL et ELT different sur cinq dimensions qui impactent directement les choix d'architecture, de tooling, d'organisation des équipes et de structure des coûts. Comprendre ces dimensions permet de justifier un choix en entretien ou en comite d'architecture.
1. Lieu de la transformation
Dans un pipeline ETL, la transformation se produit dans un système externe au data warehouse : un serveur dedie, un cluster Spark on-premise ou une machine virtuelle. Ce système intermédiaire doit être dimensionne, maintenu et monitore indépendamment. Dans un pipeline ELT, la transformation a lieu directement dans le data warehouse via SQL ou un moteur de calcul intègre — il n'y a pas de système de transformation a maintenir séparément.
2. Conservation des données brutes
L'ETL ne conserve pas les données brutes dans l'entrepot : seules les données transformées selon les règles définies sont stockées. Si une règle de transformation etait erronée, il faut re-extraire depuis la source. L'ELT charge d'abord les données brutes dans une couche raw, ce qui permet de rejouer les transformations sur l'historique complet et de répondre a des questions analytiques qui n'etaient pas prévues au moment de la conception du pipeline.
3. Vitesse de mise en production
L'ETL impose de specifier toutes les transformations avant le chargement, ce qui allonge le cycle de développement et nécessite de coordonner plusieurs équipes. Avec l'ELT et dbt, un Data Analyst peut ecrire une nouvelle transformation en SQL, l'integrer dans un modèle dbt documente et teste, et la déployer en heures plutot qu'en jours. Cette agilite est l'un des facteurs clés de l'adoption massive de l'ELT.
4. Structure des coûts
Les solutions ETL traditionnelles ont des coûts de licence élevés (Informatica PowerCenter, IBM DataStage) et nécessitent des serveurs de staging dédiés a dimensionner et maintenir. L'ELT exploite la puissance de calcul elastique du cloud data warehouse : les coûts sont directement liés a l'usage, diminuent avec la compression columnar et le stockage objet, et il n'y a pas de serveur intermédiaire a provisionner. La separation compute/storage de Snowflake et BigQuery permet de scaler indépendamment les coûts de traitement et de stockage.
5. Confidentialite et sécurité des données
L'ETL a un avantage sur ce point precis : les données sensibles peuvent être masquees, pseudonymisées ou filtrées avant d'entrer dans l'entrepot. Seules les données conformes au besoin analytique sont chargées. Avec l'ELT, les données brutes sont chargées intégralement dans la couche raw — il faut s'assurer que cette couche est correctement sécurisée via Row Level Security, que les politiques de data masking sont appliquées dans les vues de la couche staging, et que seules les tables mart sont exposées aux utilisateurs finaux.
dbt est souvent appele 'outil ETL' par raccourci mais c'est inexact : dbt gere uniquement la couche Transform (T) et l'effectue directement dans le data warehouse — c'est un outil ELT pur. De même, Spark peut s'utiliser dans les deux paradigmes selon comment il est deploye. L'outil ne détermine pas le paradigme : c'est l'architecture qui compte.
Les outils clés du pipeline data moderne
La modern data stack s'est structurée autour de cinq catégories d'outils qui couvrent l'ensemble du pipeline ELT : ingestion, stockage, transformation, orchestration et traitement distribue. Ces outils sont complémentaires et constituent aujourd'hui la référence de l'industrie.
Ingestion : Fivetran, Airbyte, Stitch
Ces outils gerent l'extraction et le chargement (les deux premiers E et L de l'ELT), sans transformation. Fivetran est le leader du marche avec des connecteurs preconfigures et maintenus pour des centaines de sources (Salesforce, HubSpot, bases SQL, APIs REST, événements applicatifs). Airbyte est l'alternative open-source avec une communaute très active et la possibilité de creer des connecteurs custom. Stitch (rachat Talend) est une option plus légère, adaptée aux petites équipes. Ces outils gerent automatiquement la replication incrementale, les evolutions de schema, la gestion des erreurs de connexion et la deduplication.
Transformation : dbt (data build tool)
dbt est devenu le standard de facto de la couche de transformation ELT. Il permet d'ecrire des transformations en SQL pur, de les documenter avec des descriptions YAML, de les tester (unicite, valeurs nulles, integrite referentielle) et de les versionner dans Git comme du code applicatif. dbt transforme le data warehouse en moteur d'exécution et génère un lineage automatique de toutes les transformations, visible dans l'interface dbt Docs. La version Cloud (dbt Cloud) ajoute l'orchestration, la collaboration d'équipe et les environnements de développement/production.
Cloud data warehouse : Snowflake, BigQuery, Redshift
Le cloud data warehouse est le moteur qui rend l'ELT possible. Snowflake a impose l'architecture separation compute/storage : on peut scaler la puissance de calcul indépendamment du volume stocke, et payer a l'usage. BigQuery (Google) propose un modèle serverless avec paiement a la requete et une intégration native avec l'écosystème Google Cloud. Amazon Redshift Serverless et Databricks SQL completent ce paysage. Ces plateformes offrent du SQL ANSI avec des extensions analytiques avancées (fonctions de fenetrage, PIVOT, QUALIFY) qui remplacent avantageusement les transformations qui necesitaient autrefois du code Python ou Java dans un pipeline ETL.
Orchestration : Apache Airflow, Prefect, Dagster
L'orchestration coordonne l'exécution des pipelines dans le bon ordre, au bon moment, avec la bonne gestion des dépendances et des erreurs. Apache Airflow, créé par Airbnb en 2014, est le standard open-source avec ses DAGs (Directed Acyclic Graphs) définis en Python. Il est puissant mais complexe a opérer. Prefect et Dagster sont des alternatives plus modernes avec une meilleure observabilite native, une gestion fine des dépendances de données et une interface de monitoring plus accessible. Astronomer (Airflow cloud) et Prefect Cloud proposent des versions managées.
Traitement distribue : Apache Spark
Pour les transformations sur de très grands volumes (terabytes a pétaoctets), Spark reste le standard du traitement distribue. Il s'intègre dans les architectures ELT pour les étapes de pre-processing qui depassent les capacités SQL natives des cloud warehouses : jointures de tables avec des milliards de lignes, deduplication complexe, machine learning feature engineering, traitement de données semi-structurées (JSON imbriques, logs applicatifs). PySpark est l'API Python la plus utilisée. Spark on Databricks ou Amazon EMR est la configuration la plus courante en production.
Un pipeline data souvent rencontre en production associe : Fivetran (ingestion) + Snowflake ou BigQuery (stockage et calcul) + dbt Core (transformation) + Airflow ou dbt Cloud (orchestration). Cette combinaison couvre une large part des besoins analytiques courants et revient régulièrement dans les entretiens Data Engineering, même si le choix des outils depend fortement du contexte et du volume de données de chaque organisation.
CDC, chargement incremental et architecture medaillon
Maîtriser les principes ETL et ELT est nécessaire mais insuffisant en production. Les pipelines réels doivent gerer des volumes qui croissent en permanence, des sources qui évoluent et des SLA de fraicheur exigeants. Trois patterns complémentaires répondent a ces contraintes : le Change Data Capture, le chargement incremental et l'architecture medaillon.
CDC — Change Data Capture : capturer les changements en temps réel
Le Change Data Capture (CDC) est une technique d'ingestion qui capture uniquement les lignes modifiées dans une base source (insertions, mises a jour, suppressions) plutot que de recharger l'intégralité de la table a chaque exécution. Le CDC s'appuie sur les logs de transaction de la base source (WAL PostgreSQL, binlog MySQL, redo log Oracle) pour détecter les changements au fil de l'eau.
Debezium est le standard open-source du CDC : il lit les logs de transaction et publie les événements de changement dans un topic Kafka, qui peut être consomme par le pipeline ELT. Fivetran et Airbyte proposent des connecteurs CDC natifs qui abstraient cette complexité. Le CDC est indispensable pour les pipelines en quasi-temps-réel, pour synchroniser des sources transactionnelles a fort volume, et pour capturer les suppressions de lignes que le chargement incremental classique ne détecte pas.
Chargement incremental vs full refresh
Le chargement incremental consiste a ne charger que les nouvelles données ou les données modifiées depuis la dernière exécution, en filtrant sur un timestamp de modification (updated_at) ou un identifiant croissant. C'est la stratégie par defaut pour les tables qui croissent en taille : recharger 500 millions de lignes a chaque run journalier est couteux et lent ; ne charger que les 50 000 nouvelles lignes prend quelques secondes.
Le full refresh rechargement complet de la table a chaque exécution reste pertinent pour les tables de petite taille (referentiels, dimensions), les tables sans colonne de timestamp fiable, ou lorsque la logique métier impose de recalculer toutes les valeurs. Dans dbt, le choix entre incremental et full refresh se declare dans la configuration du modèle avec le paramètre materialized : 'incremental' ou 'table'. Les modèles incrementaux utilisent un predicat unique_key pour gerer la deduplication.
Architecture medaillon : bronze, silver, gold
L'architecture medaillon, popularisée par Databricks pour les lakehouses, organise les données en trois couches successives qui correspondent a des niveaux croissants de qualité et de transformation. La couche bronze contient les données brutes telles qu'elles arrivent des sources : aucune modification, format natif, historique complet. La couche silver contient les données nettoyees et conformisées : deduplication, types corriges, valeurs aberrantes traitées, jointures entre entités. La couche gold contient les agregats métier prets a l'emploi analytique : tables de faits et dimensions, KPI calcules, tables pre-agrégées pour les dashboards.
Cette nomenclature bronze/silver/gold est devenue le vocabulaire standard des architectures de données modernes, qu'elles soient basées sur un lakehouse (Delta Lake, Iceberg) ou un cloud data warehouse (Snowflake, BigQuery). Elle correspond exactement aux trois couches raw/staging/mart de dbt, avec une terminologie differente. La valeur de cette architecture est de rendre les dépendances entre couches explicites, de faciliter le debug (on sait ou chercher quand une anomalie apparait) et de permettre a chaque équipe de travailler au bon niveau d'abstraction.
Un full refresh sur une table de plusieurs milliards de lignes peut prendre des heures et générer des coûts importants sur Snowflake ou BigQuery (facturation a la donnée scannée). Avant de configurer un modèle dbt en 'table' plutot qu'en 'incremental', vérifier le volume et la fréquence de rafraichissement. La règle pratique : full refresh pour les tables de moins d'un million de lignes, incremental au-dela.
Comment choisir entre ETL et ELT
Le choix entre ETL et ELT ne se fait pas en abstrait — il depend de votre infrastructure existante, du volume et de la sensibilité des données, des exigences réglementaires et des competences de votre équipe. Voici les critères concrets qui orientent ce choix dans la réalité des projets.
Quand privilégier l'ETL
L'ETL reste pertinent dans plusieurs situations précisément definissables. Premierement, les infrastructures on-premise sans cloud data warehouse : si votre entrepot est un Oracle ou un SQL Server sur site, vous n'avez pas accès a la puissance de calcul elastique qui rend l'ELT attractif. Deuxiemement, les obligations réglementaires strictes sur les données personnelles (RGPD, HIPAA, PCI-DSS) qui imposent que le masquage ou la pseudonymisation soit effectue avant tout chargement en base analytique. Troisiemement, les integrations avec des systèmes legacy qui imposent un format de sortie très spécifique que seul un outil ETL configure peut produire de façon fiable.
Quand privilégier l'ELT
L'ELT est le bon choix dans la majorite des projets greenfield en 2026 : stack 100 % cloud avec Snowflake, BigQuery ou Redshift, besoin de flexibilité analytique pour que les Data Scientists accedent aux données brutes, équipe qui maîtrise SQL et dbt, volumes importants qui beneficient de la puissance de calcul elastique du cloud warehouse, et souhait de versionner les transformations dans Git comme du code. L'ELT est également préférable lorsque les règles métier évoluent fréquemment : il est bien plus rapide de modifier un modèle dbt que de reconfigurer un pipeline ETL.
L'approche hybride ETL+ELT en pratique
En pratique, la plupart des organisations matures combinent les deux paradigmes. Un pipeline ETL léger gere les données sensibles (anonymisation ou tokenisation avant chargement dans la couche raw), tandis que le reste du flux adopte l'ELT avec Fivetran et dbt. Les équipes qui migrent d'un legacy ETL vers une modern data stack le font progressivement : elles gardent les pipelines ETL existants pour les flux stables et migrent les nouveaux cas d'usage vers l'ELT. L'objectif a terme est souvent d'éliminer le serveur ETL intermédiaire et de tout centraliser dans le data warehouse.
La stratégie la plus efficace pour migrer d'une architecture ETL vers l'ELT est de commencer par les nouveaux cas d'usage (greenfield ELT) plutot que de migrer les pipelines existants. Cela permet de valider l'approche sans risquer la production existante. Les flux ETL legacy sont maintenus le temps de la transition et remplaces progressivement quand les pipelines ELT équivalents sont stables et documentés.
Consolider ETL et ELT avec la répétition espacée
Les concepts de data engineering sont denses et spécifiques. Savoir definir ETL et ELT en entretien est une chose ; comprendre les implications architecturales de chaque choix, connaitre les outils associés et savoir justifier une décision technique en comite en est une autre. La répétition espacée (algorithme FSRS) est idéale pour ancrer ces distinctions dans la mémoire a long terme sans les confondre.
Le deck 'Pipelines ETL/ELT et orchestration' de Memia couvre les définitions, les outils (dbt, Fivetran, Airflow, Spark), les patterns avances (CDC, incremental, medaillon), les critères de choix et les questions d'entretien classiques sur le sujet. Chaque carte est formulée pour tester la compréhension et non la simple memorisation.
Les questions ETL vs ELT en entretien portent rarement sur les définitions — elles testent la capacité a justifier un choix architectural selon un contexte donne. Les meilleures cartes sont des cartes 'scénario' : 'Vous avez une base transactionnelle PostgreSQL a 500M lignes, un budget cloud, et besoin de données fraicheur H-1. Quelle architecture choisissez-vous et pourquoi ?' Creer ces cartes de scénario après avoir maîtrise les définitions.
Approfondir le cluster Data & IA
Questions fréquentes sur ETL et ELT
Quelle est la différence principale entre ETL et ELT ?
La différence est le moment et le lieu de la transformation. En ETL, les données sont transformées dans un système intermédiaire avant d'être chargées dans l'entrepot — seules les données transformées sont stockées. En ELT, les données brutes sont chargées en premier dans une couche raw, puis transformées directement dans le data warehouse via SQL ou dbt. L'ELT préserve l'historique brut et permet de rejouer les transformations.
Pourquoi l'ELT a-t-il remplace l'ETL dans les architectures modernes ?
L'ELT s'est impose grâce au cloud : les data warehouses comme BigQuery, Snowflake et Redshift offrent une puissance de calcul elastique et un stockage columnar peu couteux. Transformer en place dans le warehouse est devenu plus rapide et moins couteux que de maintenir un serveur ETL intermédiaire. L'ELT offre aussi plus de flexibilité : les règles de transformation sont versionnées dans Git via dbt et les données brutes sont preservées pour les analyses exploratoires.
dbt est-il un outil ETL ou ELT ?
dbt est un outil ELT pur : il gere uniquement la couche Transform (T) et l'effectue directement dans votre data warehouse via SQL. Il ne se charge pas de l'extraction ni du chargement — ces étapes sont gérées par des outils dédiés comme Fivetran ou Airbyte. dbt est souvent appele 'outil ETL' par abus de langage mais c'est architecturalement incorrect.
Qu'est-ce que le CDC (Change Data Capture) ?
Le Change Data Capture est une technique qui capture uniquement les lignes modifiées dans une base source (insertions, mises a jour, suppressions) en lisant les logs de transaction (WAL PostgreSQL, binlog MySQL). Plutot que de recharger une table entiere a chaque exécution, le CDC ne transmet que les changements — ce qui réduit le volume transfere et permet une ingestion quasi-temps-réel. Debezium est le standard open-source ; Fivetran et Airbyte proposent des connecteurs CDC natifs.
Qu'est-ce que l'architecture medaillon (bronze, silver, gold) ?
L'architecture medaillon organise les données en trois couches de qualité croissante. Bronze : données brutes telles qu'elles arrivent des sources, aucune modification, historique complet. Silver : données nettoyees, deduplicuees, types corriges, jointures effectuées. Gold : agregats métier prets a l'emploi pour les dashboards et rapports, avec KPI calcules. Cette nomenclature correspond aux couches raw/staging/mart de dbt avec une terminologie differente, popularisée par Databricks pour les architectures lakehouse.
Quelle est la différence entre dbt Core et dbt Cloud ?
dbt Core est la version open-source en ligne de commande : elle gere les transformations SQL, les tests et la documentation. Elle est gratuite et s'exécute dans votre propre infrastructure. dbt Cloud est la version managée avec une interface web, l'orchestration des jobs, des environnements developeur/production séparés, la collaboration d'équipe et un IDE SQL intègre. Pour les petites équipes, dbt Core avec Airflow suffit ; pour les équipes data de taille moyenne ou grande, dbt Cloud simplifie considérablement les opérations.
Airflow peut-il orchestrer a la fois des pipelines ETL et ELT ?
Oui. Apache Airflow est un orchestrateur générique qui peut exécuter n'importe quel type de tache : appels d'outils ETL traditionnels, jobs Spark, requetes SQL directes, workflows dbt, scripts Python. Il coordonne l'ordre et le timing des executions sans imposer un paradigme particulier. Les DAGs Airflow definissent les dépendances entre taches et garantissent que les transformations dbt ne s'exécutent qu'une fois l'ingestion Fivetran terminée.
L'ETL est-il plus sur que l'ELT pour les données sensibles ?
L'ETL a un avantage sur ce point : les données peuvent être masquees ou pseudonymisées avant d'entrer dans l'entrepot, ce qui limite l'exposition des données brutes. Avec l'ELT, les données brutes sont chargées intégralement dans la couche bronze ou raw — il faut implementer le masquage dans les politiques d'accès a cette couche (Row Level Security, Dynamic Data Masking Snowflake) et s'assurer que seules les vues de la couche gold sont accessibles aux utilisateurs finaux.
Qu'est-ce que le chargement incremental dans dbt ?
Le chargement incremental (materialized = 'incremental' dans dbt) consiste a ne traiter que les nouvelles lignes ou les lignes modifiées depuis la dernière exécution, plutot que de recalculer la table entiere. On filtre sur un timestamp (updated_at) ou un id croissant. C'est la stratégie de référence pour les tables volumineuses : traiter 50 000 nouvelles lignes plutot que 500 millions a chaque run journalier réduit drastiquement les coûts de calcul et le temps d'exécution.
Peut-on faire du ETL avec Spark ?
Oui, Spark est souvent utilise dans des architectures ETL pour des transformations complexes sur de grands volumes. Spark peut lire depuis de multiples sources (S3, bases SQL, Kafka), transformer via PySpark DataFrames ou Spark SQL, et ecrire vers un data warehouse ou un data lake. Il est particulièrement adapte aux transformations qui depassent les capacités SQL natives du cloud warehouse : feature engineering ML, traitement de données semi-structurées, deduplication de très grandes tables. Spark on Databricks ou Amazon EMR est la configuration la plus courante.
Guide Data Engineering : pipelines, lakehouse et gouvernance