Architecture ETL : composants, patterns et choix techniques pour votre projet data
23 juin 2020
23 juin 2020
Mis à jour : mai 2025 · Lecture : 12 min
L’architecture ETL définit la manière dont les flux de données sont organisés entre vos sources, vos zones de traitement et vos systèmes cibles. Bien conçue, elle garantit fiabilité, performance et évolutivité. Mal dimensionnée, elle devient le principal frein à votre stratégie data.
Une architecture ETL n’est pas un choix de logiciel. C’est un choix structurant qui engage votre organisation sur plusieurs années.
Une architecture ETL complète s’articule autour de cinq composants principaux. Comprendre le rôle de chacun est indispensable avant de choisir des outils ou de dimensionner une infrastructure.
Ce sont tous les systèmes qui produisent les données à collecter : ERP, CRM, bases de données relationnelles (Oracle, MySQL, PostgreSQL, SAP), fichiers plats (CSV, XML, JSON), messages EDI, API REST, flux IoT, pages web, réseaux sociaux, plateformes e-commerce.
La diversité des sources est le premier défi architectural. Chaque source impose ses contraintes : protocole de connexion, format de données, volumétrie, fréquence de mise à jour, disponibilité. L’architecture doit prévoir autant de connecteurs que de types de sources, sans impacter les performances des systèmes sources; ceux-ci continuent de fonctionner pour leurs usages opérationnels.
Pour les sources très nombreuses ou très volumineuses, les architectures recourent au MPP (Massively Parallel Processing) : plusieurs connexions simultanées vers différentes bases, traitées en parallèle pour réduire les temps d’extraction.
C’est le composant chargé d’aller chercher les données depuis les sources. Il gère deux modes fondamentaux :
C’est le cœur de l’architecture ETL – et sa partie la plus complexe. Il applique l’ensemble des règles de transformation définies par les équipes métier et data :
La complexité de ce composant est souvent sous-estimée en phase de conception. Les règles de transformation s’accumulent avec le temps et peuvent devenir difficiles à maintenir si elles ne sont pas documentées et gouvernées dès le départ.
Elle mérite une section à part entière. Voir section 2.
C’est la destination finale des données transformées. Les principaux systèmes cibles sont :
La zone de staging (ou zone d’atterrissage) est une aire de stockage intermédiaire où les données extraites sont déposées avant d’être transformées. Elle est absente de beaucoup d’architectures ETL simplifiées. Et c’est souvent une erreur.
Pourquoi elle est indispensable :
Ce qu’elle contient :
Des données brutes, non transformées, dans leur format d’origine. Elle n’est pas destinée à être interrogée directement par les outils d’analyse; c’est une zone technique, pas une zone de consommation.
Dans les architectures modernes, la zone de staging est souvent implémentée sur un service de stockage objet cloud : peu coûteux, scalable et découplé des systèmes sources.
Le choix entre traitement par batch et traitement en streaming est l’une des décisions architecturales les plus structurantes. Il conditionne la latence des données disponibles en analyse, les ressources nécessaires et la complexité de l’infrastructure.
Les données sont collectées, transformées et chargées par lots, à intervalles planifiés : toutes les nuits, toutes les heures, plusieurs fois par jour.
| Avantages | Inconvénients |
| Simple à implémenter et à maintenir | Latence : les données ne sont disponibles qu’après le prochain batch |
| Adapté aux gros volumes | Inadapté aux cas d’usage temps réel |
| Coût infrastructure maîtrisé | Pics de charge sur les fenêtres d’exécution |
| Bien outillé (ETL classiques, schedulers) | Rejeux complexes en cas d’échec partiel |
Cas d’usage typiques : alimentation nightly d’un data warehouse, reporting mensuel, consolidation de données RH ou financières, migration de données.
Les données sont traitées en continu, au fil de leur production. Chaque événement est capturé, transformé et mis à disposition quasi instantanément.
| Avantages | Inconvénients |
| Données disponibles en quelques secondes | Plus complexe à concevoir et opérer |
| Adapté aux cas d’usage temps réel | Coût infrastructure plus élevé |
| Détection d’anomalies à chaud | Gestion des événements tardifs ou désordonnés |
| Adapté aux flux IoT et événementiels | Courbe d’apprentissage plus steep |
Cas d’usage typiques : détection de fraude, supervision industrielle (IoT), personalisation temps réel, alerting opérationnel.
La majorité des architectures data en production combinent les deux patterns selon les flux :
Cette approche est connue sous le nom d’architecture Lambda (batch + streaming en parallèle) ou d’architecture Kappa (streaming unifié avec rejeu possible).
Une architecture ETL sans orchestration est une architecture fragile. L’orchestration est le système qui planifie, séquence, surveille et relance les traitements.
Les architectures data modernes s’appuient sur des orchestrateurs open source très répandus ou sur des services cloud natifs. Les solutions ETL propriétaires intègrent souvent leur propre scheduler, plus simple mais moins flexible pour des architectures complexes.
Tout pipeline ETL doit produire des logs détaillés à chaque étape : nombre de lignes extraites, nombre de lignes transformées, nombre de lignes rejetées, temps d’exécution, erreurs rencontrées. Ces journaux sont indispensables pour :
La supervision de la montée en charge est un travail continu. Les volumes de données augmentent, les sources se multiplient : les administrateurs ETL doivent auditer régulièrement les temps d’exécution et envisager la parallélisation des traitements quand les fenêtres de batch deviennent trop longues.
La transformation numérique multiplie les sources de données et les volumes : IoT (capteurs industriels, objets connectés), OpenData, plateformes e-commerce, réseaux sociaux, pages web, flux événementiels. Les données non structurées (images, logs, textes, flux vidéo) représentent aujourd’hui la majorité des données produites en entreprise.
Une architecture ETL conçue pour des volumes modestes peut se retrouver rapidement dépassée. La scalabilité doit être anticipée dès la conception, pas ajoutée en urgence quand les performances se dégradent.
Les leviers techniques pour passer à l’échelle :
Les architectures data ont significativement évolué depuis les ETL traditionnels des années 2000. Voici les patterns qui structurent les projets data en 2024-2025.
Popularisée dans les architectures data cloud modernes, l’architecture Medallion organise les données en trois couches progressives de qualité :
| Couche | Contenu | Usage |
| Bronze | Données brutes, telles qu’extraites des sources | Audit, rejeu, archivage |
| Silver | Données nettoyées, dédupliquées, harmonisées | Analyses intermédiaires, data science |
| Gold | Données agrégées, prêtes pour la consommation métier | BI, reporting, tableaux de bord |
Cette approche remplace la staging zone unique par une progression structurée. Elle facilite la gouvernance (on sait à quel niveau de qualité se trouvent les données) et le débogage (on peut retracer une anomalie jusqu’à la donnée brute).
Le data lakehouse est une architecture hybride qui cherche à combiner les avantages du data lake (stockage économique, flexibilité des formats, support des données non structurées) et du data warehouse (performance analytique, transactions ACID, gestion des schémas).
Il repose sur des formats de fichiers ouverts avec capacités transactionnelles : Delta Lake, Apache Iceberg, Apache Hudi. Les principales plateformes cloud d’analyse de données s’appuient sur ces formats pour proposer des expériences lakehouse.
Quand c’est pertinent : quand vous avez besoin à la fois de stocker de grands volumes de données brutes et d’en exposer une partie structurée aux outils de BI, sans maintenir deux infrastructures séparées.
Dans une architecture ELT cloud-native, les données sont d’abord chargées brutes dans l’entrepôt cloud, puis transformées à l’intérieur de ce système grâce à sa puissance de calcul native. Des outils de transformation SQL dédiés sont devenus le standard de facto pour orchestrer ces transformations directement dans l’entrepôt.
Différence clé avec l’ETL classique : la transformation ne se fait plus dans un moteur ETL externe, mais directement dans l’entrepôt. Cela simplifie l’architecture (moins de composants), tire parti de la scalabilité du cloud, et rend les transformations plus accessibles aux équipes data analytics (SQL plutôt que code propriétaire).
ETL classique ou ELT cloud-native ? Les deux ont leur place. L’ETL classique reste pertinent quand les transformations sont complexes, quand les données doivent être filtrées avant stockage (conformité, coût), ou quand l’infrastructure existante est on-premise. L’ELT cloud-native s’impose pour les architectures full-cloud avec des volumes importants et des équipes orientées SQL.
Le marché des outils ETL s’est profondément transformé avec le cloud. Quatre grandes catégories coexistent.
Installées sur les serveurs de l’entreprise, sous licence. Elles offrent un contrôle total sur les données et l’infrastructure, avec des interfaces graphiques (GUI) permettant de modéliser les flux sans coder. Adaptées aux environnements régulés (finance, santé, industrie) où la souveraineté des données est critique.
Tenor propose dans cette catégorie sa solution DEX, déployée on-premise et intégrée aux principaux ERP, TMS, WMS et logiciels métiers.
Hébergées et opérées par le fournisseur, accessibles par abonnement. Elles éliminent la gestion d’infrastructure et offrent une scalabilité native. Le modèle économique est à l’usage : volume de données traitées ou nombre de connecteurs actifs. Adaptées aux organisations souhaitant un time-to-value rapide sans investissement infrastructure initial.
Libres de droits, déployées et maintenues par l’entreprise. Elles offrent une grande flexibilité et évitent les coûts de licence, mais requièrent des compétences techniques solides pour l’installation, la maintenance et les montées de version. Plusieurs solutions open source matures existent sur ce segment, couvrant aussi bien l’ingestion que l’orchestration des pipelines.
Des outils qui ne font pas l’ETL eux-mêmes mais orchestrent et supervisent des pipelines composés de différents outils. Indispensables dans les architectures data modernes pour gérer les dépendances, planifier les exécutions et superviser la qualité. Plusieurs solutions open source très répandues couvrent ce besoin, complétées par des services managés proposés par les fournisseurs cloud.
| Critère | On-premise propriétaire | SaaS cloud | Open source |
| Souveraineté des données | Maximale | Dépend du contrat | Totale |
| Coût initial | Élevé (licence) | Faible (abonnement) | Faible (infra seulement) |
| Coût à l’échelle | Prévisible | Variable selon volume | Infrastructure + maintenance |
| Compétences requises | Formation outil | Faibles | Élevées |
| Flexibilité | Moyenne | Moyenne | Maximale |
| Time to value | Long | Court | Moyen |
Il n’existe pas d’architecture ETL universelle. Le bon choix dépend de plusieurs paramètres à évaluer conjointement.
Les questions à se poser avant de choisir :
Le volume de données : quelques Go par jour ou plusieurs To ? Le volume conditionne le dimensionnement de l’infrastructure et le choix entre batch et streaming.
La fréquence de rafraîchissement : les données doivent-elles être disponibles en temps réel, toutes les heures, ou une fois par nuit ? Plus la latence exigée est faible, plus l’architecture est complexe et coûteuse.
Le nombre et la diversité des sources : trois sources homogènes ou cinquante sources hétérogènes (ERP legacy, API modernes, flux IoT, fichiers) ? La diversité des sources multiplie les connecteurs à maintenir.
La sensibilité des données : données personnelles (RGPD), données financières réglementées, données industrielles confidentielles ? La souveraineté et la traçabilité peuvent imposer une architecture on-premise.
L’infrastructure existante : système d’information majoritairement on-premise ou déjà fortement cloud ? Une architecture ETL doit s’intégrer dans l’existant, pas le remplacer intégralement.
Les compétences disponibles : une équipe data mature avec des profils data engineering, ou une DSI généraliste ? Les solutions SaaS avec interfaces graphiques réduisent la barrière technique; les solutions open source demandent des compétences pointues.
Le bon dimensionnement dès le départ évite deux écueils fréquents : une architecture sur-dimensionnée (coûteuse et complexe pour des besoins modestes) et une architecture sous-dimensionnée (qui devient un goulot d’étranglement dès que les volumes augmentent).
L’architecture ETL est le cadre technique mais deux dimensions complémentaires méritent leur propre approfondissement :
Tenor accompagne les entreprises dans la définition et la mise en œuvre de leurs architectures data depuis plus de trente ans. Contactez nos experts pour cadrer votre projet · Découvrez nos webinaires