Le service financier demande le chiffre d'affaires par code de réduction sur les deux dernières années. Dans une entreprise, c'est une petite modification SQL suivie d'une reconstruction, car chaque ligne de commande jamais chargée reste dans une table brute. Dans une autre, le job nocturne n'a jamais conservé la colonne de réduction : quelqu'un modifie le job et ré-extrait deux ans d'historique depuis la production.
La différence tient à l'endroit où tourne la transformation. L'ETL (extract, transform, load) met les données en forme sur un moteur distinct avant qu'elles n'atteignent l'entrepôt. L'ELT (extract, load, transform) copie les données brutes dans l'entrepôt et les met en forme sur place avec du SQL. Ce choix détermine votre facture de calcul, la fraîcheur des données, la facilité à modifier la logique et l'endroit où finissent les données personnelles.
Cet article détaille les deux pipelines, les compare, montre où l'ETL gagne encore et l'hybride courant, et se termine par un schéma côte à côte.
Comment fonctionne un pipeline ETL
En ETL, un moteur de transformation se place entre les sources et l'entrepôt. Une exécution nocturne :
- Extrait les lignes nouvelles et modifiées, avec une requête sur une colonne
updated_atou depuis un flux de change data capture. - Transforme ces lignes sur le moteur : nettoyer les valeurs, supprimer les doublons, joindre les données de référence, masquer les données personnelles et remodeler le résultat en tables de faits et de dimensions.
- Charge le résultat dans l'entrepôt avec des insertions ou des merges.
Le moteur peut être Informatica, SQL Server Integration Services (SSIS), un job Spark ou un script Python. Les extractions brutes restent souvent dans une zone de staging que le job vide après une exécution réussie : l'entrepôt ne peut donc pas répondre à une question que le job n'avait pas anticipée.
Comment fonctionne un pipeline ELT
En ELT, c'est l'entrepôt qui fait le travail de transformation :
- Extraction et chargement. Un loader tel que Fivetran ou Airbyte copie les tables sources dans un schéma
rawpresque sans modification, en ajoutant des colonnes de métadonnées comme_fivetran_syncedou_airbyte_extracted_atqui enregistrent la date de synchronisation de chaque ligne. - Transformation. Des modèles SQL, généralement gérés avec dbt, lisent les tables brutes et construisent des tables nettoyées et jointes dans d'autres schémas.
- Service. Les outils de BI interrogent les tables finales, généralement appelées marts.
L'ELT s'est répandu avec les entrepôts cloud qui séparent le stockage du calcul, comme BigQuery et Snowflake : les copies brutes coûtent peu à conserver et la capacité de transformation évolue avec l'entrepôt. Comme chaque ligne chargée reste disponible, vous pouvez corriger un modèle, ajouter une colonne ou définir une nouvelle métrique et reconstruire à partir de l'historique sans toucher à la source.
ETL vs ELT : comparaison
| ETL | ELT | |
|---|---|---|
| Où tourne la transformation | Un moteur distinct, avant l'entrepôt | Dans l'entrepôt, en SQL |
| Ce qui arrive dans l'entrepôt | Uniquement des tables modélisées | Des tables brutes, puis des tables modélisées |
| Données brutes conservées | Rarement ; les extractions sont vidées | Oui, dans un schéma raw |
| Nouvelles colonnes source | Ignorées tant que personne ne les mappe | Le loader peut les ajouter aux tables brutes ; les modèles les utilisent une fois le SQL modifié |
| Modification de la logique métier | Modifier le job, ré-extraire l'historique | Modifier le SQL, reconstruire depuis le brut |
| Coût de calcul | Serveurs ou clusters du moteur, plus l'entrepôt | Calcul de l'entrepôt à chaque exécution de modèle, plus le stockage brut |
| Données personnelles | Masquées avant d'arriver | Arrivent telles quelles, sauf si le loader les masque |
| Fraîcheur | Mise à jour à la fin de tout le job | Données brutes selon le planning du loader ; marts à l'exécution des modèles |
| Outils typiques | Informatica, SSIS, AWS Glue, Spark | Fivetran ou Airbyte, dbt, et BigQuery, Snowflake, Redshift ou Databricks |
Les plannings comptent plus que l'acronyme : la synchronisation par défaut de Fivetran s'exécute toutes les six heures, ce qui est moins frais qu'un job ETL horaire.
Quand l'ETL gagne encore
- Les données personnelles ne doivent pas arriver brutes. Si des adresses e-mail ou des numéros de carte en clair ne doivent jamais atteindre l'entrepôt, masquez-les avant le chargement. Les politiques de masquage de l'entrepôt ne changent pas ce qui est stocké : le Dynamic Data Masking de Snowflake, une fonctionnalité de l'édition Enterprise, masque les valeurs en clair au moment de la requête.
- La cible ne sait pas transformer. Un entrepôt hérité à capacité fixe, un index de recherche ou un dépôt de fichiers chez un partenaire attendent des données finies.
- Un enrichissement que le SQL gère mal, comme des appels d'API par ligne, du géocodage, l'analyse de PDF ou le scoring par modèle, convient souvent mieux à Python ou Spark.
- Du streaming à faible latence. Apache Flink ou Kafka Streams transforment les événements quelques secondes après leur apparition ; le schéma d'architecture Kafka montre d'où ils lisent.
- Un volume que vous ne voulez pas conserver. 10 000 capteurs à une mesure par seconde produisent 864 millions de lignes par jour (10 000 × 86 400). Des moyennes à une minute calculées avant le chargement ramènent ce chiffre à 14,4 millions (10 000 × 1 440), soit 60 fois moins.
L'hybride courant
En pratique, de nombreux pipelines ELT incluent une petite transformation avant le chargement, parfois appelée EtLT. Ne transformez en vol que ce qui ne doit jamais arriver brut ; faites tout le reste dans l'entrepôt, où c'est versionné, testé et facile à reconstruire.
Pour les données personnelles, le hachage de colonnes de Fivetran hache une colonne pendant la synchronisation avec SHA-256 et un sel propre à chaque destination, si bien que les e-mails hachés restent joignables ; le blocage de données supprime une colonne entièrement. Les mappings d'Airbyte peuvent hacher ou chiffrer des champs par flux. Quel que soit l'outil, préférez un hachage salé : un SHA-256 simple d'une adresse e-mail peut être comparé à une liste d'adresses connues. Deux autres réserves : le hachage ne couvre que les synchronisations futures, l'historique demande donc une nouvelle synchronisation, et un hachage salé est pseudonyme, pas anonyme. Selon le RGPD, les données pseudonymisées restent des données personnelles (considérant 26). Cet article n'est pas un avis juridique ; lisez le texte officiel avec votre équipe vie privée et tenez une cartographie des données des flux de données personnelles.
ELT avec des modèles SQL en couches
Le guide de structure de projet de dbt décrit trois couches qui fonctionnent avec n'importe quel outil SQL :
| Couche | Rôle | Matérialisée en | Lue par |
|---|---|---|---|
| Staging | Un modèle par table source, comme stg_shop__orders : renommer, convertir les types, passer des centimes aux dollars ; ni jointures ni agrégations |
Vues | Autres modèles |
| Intermediate | Étapes dédiées, comme agréger les lignes de commande en commandes | Modèles éphémères, ou vues dans un schéma séparé | Autres modèles |
| Marts | Une table large par entité métier, comme les commandes ou les clients | Tables ou modèles incrémentaux | Outils de BI et analystes |
Les lakehouses reprennent la même idée sous les noms bronze, silver et gold ; voir le schéma d'architecture medallion.
dbt fournit quatre tests de données génériques, unique, not_null, accepted_values et relationships, et toute requête qui renvoie des lignes en échec peut devenir un test. Les contrôles de fraîcheur détectent un loader arrêté sans bruit. Une seule définition de source déclare les deux :
sources:
- name: shop
schema: raw_shop
config:
loaded_at_field: _fivetran_synced
freshness:
warn_after: {count: 12, period: hour}
error_after: {count: 24, period: hour}
tables:
- name: orders
columns:
- name: id
data_tests:
- unique
- not_null
dbt source freshness (ou dbt freshness dans dbt v2) émet un avertissement quand la valeur _fivetran_synced la plus récente a plus de 12 heures et signale une erreur après 24.
Orchestration et qualité des données
Un orchestrateur exécute les étapes dans l'ordre. Dans Airflow, un DAG (des tâches avec dépendances et un planning) déclenche la synchronisation du loader, l'attend, puis lance dbt. L'intégration dbt de Dagster transforme chaque modèle dbt en asset, une table qui doit exister, si bien qu'un mart peut dépendre directement de la table qu'écrit une synchronisation Fivetran.
Dans les deux cas, dbt build garde les mauvaises données hors des tableaux de bord : il exécute modèles, tests, snapshots et seeds dans l'ordre du DAG, et un test en échec fait sauter tout ce qui est en aval. Ajoutez des contrôles de fraîcheur et une alerte vers l'équipe responsable, et les données fausses comme les données anciennes apparaissent avant qu'un décideur ne les remarque.
Le Reverse ETL, qu'Airbyte appelle data activation, va dans l'autre sens : il copie les données modélisées de l'entrepôt vers des outils comme un CRM ou un support desk. Au moment de la rédaction (novembre 2026), Hightouch le propose comme produit autonome, et Fivetran (qui a racheté Census) et Airbyte l'intègrent à l'ingestion.
Le schéma ETL vs ELT
Contenu du diagramme
- ETL: extract, transform, then load
- ELT: extract, load, then transform in the warehouse
- Warehouse
- Orders DB (Postgres)
- Transform engine (Spark, SSIS)
- fct_orders
- BI dashboards
- Loader (Fivetran, Airbyte)
- raw.orders (as loaded)
- dbt models: staging, intermediate
- marts.fct_orders
- raw rows
- cleaned, conformed rows
- SQL queries
- raw rows, PII hashed
- raw tables
- built tables
Comment le lire :
- Deux couloirs, mêmes extrémités : la même base de commandes Postgres et les mêmes tableaux de bord BI. Seul le milieu change.
- L'ambre marque la transformation : un moteur distinct avant l'entrepôt en ETL, le cadre des modèles dbt dans l'entrepôt en ELT.
- Les cadres de l'entrepôt montrent ce qui est stocké. Celui de l'ETL ne contient que
fct_orders; celui de l'ELT contientraw.orderstel que chargé, les modèles etmarts.fct_orders. - L'arête violette est l'hybride : le loader hache les données personnelles avant que les lignes n'arrivent.
- Le bloc Markdown liste l'ordre d'exécution de l'ELT, les seuils de fraîcheur et le schéma lu par la BI.
Dessiner clairement des schémas ETL et ELT
- Placez la transformation là où elle tourne. Dessiner la transformation de l'ELT hors de l'entrepôt cache son principal coût et son principal risque.
- Dessinez l'entrepôt comme une frontière. Raw, staging et marts dans un même cadre sont des schémas d'un seul système, pas des bases séparées.
- Étiquetez les arêtes avec ce qui circule (lignes brutes, lignes hachées, tables construites) et le planning quand il compte.
- Indiquez où les données personnelles sont masquées et où elles existent encore en clair.
- Montrez les couches, pas chaque modèle. Une table d'exemple par couche suffit ; le lignage relève de la documentation générée par dbt.
- Séparez le flux de contrôle. Dessinez les déclencheurs de l'orchestrateur en arêtes pointillées pour que personne ne les confonde avec des données.
Le schéma d'architecture de pipeline de données montre un pipeline complet avec CDC, Kafka et un entrepôt.
Le construire dans Archboard
- Connectez-vous avec Google ou GitHub et créez un diagramme.
- Ajoutez deux nœuds Cadre du pack Base, l'un au-dessus de l'autre, pour les couloirs ETL et ELT, et un Cadre imbriqué pour l'entrepôt dans chaque couloir, à la même position horizontale.
- Dans le couloir ETL, ajoutez un nœud Postgres du pack Données, une Boîte Base pour le moteur de transformation, un nœud Entrepôt de données du pack Données pour
fct_ordersdans le cadre de l'entrepôt, et une Boîte Base pour la BI. Étiquetez les arêtes : raw rows, cleaned and conformed rows, SQL queries. - Dans le couloir ELT, ajoutez un nœud Postgres et une Boîte Base pour le loader. Dans le cadre de l'entrepôt, ajoutez des nœuds Entrepôt de données pour
raw.ordersetmarts.fct_orders, avec une Boîte Base pour les modèles dbt entre eux. Terminez par une Boîte Base pour la BI et étiquetez les arêtes de la même façon. - Colorez les deux boîtes de transformation en ambre et l'arête sortante du loader en violet. Ajoutez des notes Texte Base sous les nœuds qui demandent une explication et une courte légende des couleurs.
- Ajoutez un bloc Markdown du pack Base avec l'ordre d'exécution et les seuils de fraîcheur.
Si le pipeline existe déjà sous forme d'organigramme Mermaid, collez-le dans l'outil Mermaid vers diagramme modifiable pour obtenir un premier brouillon. L'exemple utilise 15 nœuds de diagramme et reste dans les limites de l'offre Free.
FAQ
Quelle est la différence entre ETL et ELT ? L'endroit où tourne la transformation. L'ETL transforme les données sur un moteur distinct et ne charge que le résultat. L'ELT charge d'abord les données brutes dans l'entrepôt et les transforme sur place avec du SQL, si bien que la copie brute reste disponible pour les reconstructions.
L'ETL est-il dépassé ? Non. L'ELT est le choix par défaut habituel sur les entrepôts cloud, mais l'ETL reste adapté quand les données personnelles doivent être masquées avant d'arriver, quand la cible ne sait pas transformer, et pour l'enrichissement lourd ou le streaming à faible latence.
dbt est-il un outil ETL ? dbt couvre le T de l'ELT. Il exécute des modèles SQL et des tests dans votre entrepôt mais n'extrait ni ne charge de données ; c'est le rôle d'un loader comme Fivetran ou Airbyte.
L'ELT coûte-t-il moins cher que l'ETL ? Cela dépend du volume et des habitudes. L'ELT supprime le moteur distinct mais facture chaque exécution de modèle en calcul d'entrepôt et stocke des copies brutes. Les modèles incrémentaux maintiennent les coûts bas ; les reconstructions complètes horaires de grandes tables, non.
Qu'est-ce que le reverse ETL ? Copier des données modélisées de l'entrepôt vers des outils opérationnels comme un CRM. Il doit lire depuis les marts, s'exécuter selon un planning et recevoir les mêmes tests et la même responsabilité que n'importe quel autre pipeline.