Data engineering self-hosted 2026 : Airbyte, dbt, Dagster, Iceberg
Meta-description : Construisez une data platform complète sans payer Fivetran ni Snowflake : Airbyte pour l’ingestion, dbt-core pour les transformations, Dagster pour l’orchestration, Apache Iceberg comme format de table ouvert — self-hébergé sur un VPS Hetzner à 20 €/mois, adapté aux PME d’Afrique de l’Ouest.
Introduction : la data platform accessible aux PME francophones
En 2026, la capacité à analyser ses données n’est plus un luxe réservé aux grandes entreprises : c’est une nécessité concurrentielle. Pourtant, pour une PME à Dakar, Abidjan ou Cotonou, les solutions SaaS dominantes du marché sont financièrement inaccessibles. Fivetran facture en dollars américains selon le nombre de lignes ingérées — une startup e-commerce avec 10 millions d’événements mensuels dépasse rapidement 1 000 USD/mois uniquement pour la synchronisation des données. Snowflake, positionné comme entrepôt de données de référence, ajoute une couche de coût supplémentaire avec sa tarification à la seconde de calcul, qui surprend dès les premières semaines d’usage intensif. Looker, Databricks, Matillion — la liste des outils dont les prix s’affichent en centaines de dollars mensuels est longue, et aucun n’est conçu avec l’économie d’une PME francophone d’Afrique de l’Ouest à l’esprit.
La bonne nouvelle, c’est que l’écosystème open-source a mûri au point de rendre obsolète cette dépendance au SaaS premium. En 2026, il est tout à fait possible de construire une data platform de niveau production — capable d’ingérer des dizaines de sources, de transformer des millions de lignes, d’orchestrer des pipelines complexes et de stocker des données au format ouvert et interopérable — sur un seul VPS à 20 euros par mois. Ce pilier vous présente l’architecture complète : Airbyte pour l’ingestion, dbt-core pour les transformations SQL, Dagster pour l’orchestration des pipelines, Apache Iceberg comme format de table moderne, et Meltano comme alternative Singer-native. Vous trouverez également une section dédiée à l’adaptation de cette stack au contexte spécifique de l’Afrique de l’Ouest, avec des exemples concrets sur Wave, CinetPay, et la conformité OHADA.
Ce guide s’adresse aux data engineers, développeurs backend et responsables technique de PME qui veulent reprendre le contrôle de leur infrastructure de données sans exploser leur budget. Chaque outil est présenté avec son rôle précis dans l’architecture, ses avantages, ses limites, et un lien vers le tutoriel pratique correspondant dans ce cluster. L’objectif : que vous puissiez démarrer votre première data platform self-hosted d’ici la fin de votre lecture.
Pourquoi self-héberger son data stack en 2026
La question du self-hosting n’est pas simplement une question de coût, même si c’est souvent le déclencheur initial. C’est une décision architecturale qui touche à la souveraineté des données, à la maîtrise technique et à la capacité d’adaptation long terme de votre organisation.
Sur le plan économique, la différence est éloquente. Une stack self-hosted complète — Airbyte, dbt-core, Dagster, MinIO pour le stockage objet et Metabase pour la visualisation — tient confortablement sur un Hetzner CX41 à 20 €/mois. Avec une petite marge pour les sauvegardes et un second serveur de développement, on reste en dessous de 50 €/mois tout compris. Face à cela, la combinaison Fivetran + Snowflake + Looker atteint facilement 3 000 à 5 000 USD/mois pour une équipe data de taille modeste. Pour une PME dont le budget IT total est de 10 000 euros annuels, l’équation est sans appel.
Sur le plan de la souveraineté, héberger ses données en Europe (Hetzner Falkenstein) ou, idéalement, dans une région de stockage proche de l’Afrique de l’Ouest, signifie que vous n’êtes pas soumis aux conditions générales d’un éditeur américain qui peut changer sa politique de rétention des données, augmenter ses tarifs ou être racheté. Avec Apache Iceberg comme format de stockage, vos données restent dans des fichiers Parquet standards lisibles par n’importe quel moteur analytique — DuckDB, Spark, Trino, StarRocks — sans aucun vendor lock-in.
Sur le plan de la compétence, opérer sa propre stack data est un investissement dans l’équipe. Les data engineers qui maîtrisent Airbyte, dbt et Dagster sont opérationnels sur n’importe quelle architecture moderne, qu’elle soit on-premise ou cloud-native. Cette maîtrise est un actif qui reste même si vous décidez un jour de migrer vers le cloud. À l’inverse, des équipes formées uniquement sur des outils SaaS fermés se retrouvent dépendantes d’une UI propriétaire et perdent leur valeur dès que l’éditeur change d’interface ou de modèle économique.
Enfin, le self-hosting n’est plus synonyme de complexité ingérable. En 2026, Airbyte se déploie en deux commandes Docker Compose. dbt-core s’installe avec pip. Dagster propose une UI web complète et un mode de déploiement containerisé bien documenté. L’époque où self-héberger un data pipeline nécessitait une équipe de cinq ingénieurs est révolue : un data engineer compétent peut maintenir cette stack seul, avec des astreintes raisonnables.
Les 5 briques fondamentales de la data stack open-source
La stack que nous allons décrire suit le modèle ELT (Extract, Load, Transform), devenu la norme de l’industrie depuis que les entrepôts de données modernes sont suffisamment puissants pour transformer les données en leur sein plutôt que de le faire en amont. L’extraction et le chargement sont confiés à Airbyte, la transformation à dbt-core, l’orchestration à Dagster, le stockage au format Apache Iceberg, et Meltano comme alternative ou complément pour les besoins Singer-spécifiques.
Airbyte — ingestion universelle
Airbyte est devenu en quelques années la référence open-source de l’ingestion de données. Son modèle repose sur des connecteurs standardisés : chaque source (base de données, API, fichier plat) et chaque destination (entrepôt de données, data lake) est représentée par un connecteur Docker qui s’exécute de manière isolée. À l’heure où ce guide est écrit, le catalogue officiel dépasse 350 connecteurs — des bases de données classiques comme PostgreSQL, MySQL et MongoDB, aux APIs SaaS comme Stripe, Shopify, Google Analytics, en passant par des sources moins communes comme les fichiers S3, FTP ou même des feeds RSS.
Ce qui distingue Airbyte de ses concurrents open-source, c’est son mode de synchronisation incrémental. Plutôt que de re-télécharger l’intégralité des données à chaque exécution, Airbyte maintient un curseur de position (un timestamp, un identifiant d’enregistrement, un numéro de séquence) et ne récupère que les nouvelles lignes ou les lignes modifiées depuis la dernière synchronisation. Cette fonctionnalité, appelée CDC (Change Data Capture) pour les bases de données, est critique pour maintenir des pipelines performants sur des tables de plusieurs dizaines de millions de lignes.
En termes de déploiement, Airbyte OSS se lance avec Docker Compose en quelques minutes. La version Community Edition inclut l’UI web complète, le scheduling de connexions, les logs de synchronisation et les alertes basiques. Pour des besoins plus avancés (SSO, RBAC, support prioritaire), Airbyte Cloud et Airbyte Enterprise existent, mais pour une PME qui démarre, la version OSS couvre 95 % des besoins.
Un point important à comprendre : Airbyte est un extracteur-chargeur, pas un transformateur. Son rôle s’arrête à déposer les données brutes dans la destination — en général une base PostgreSQL de staging ou un bucket objet. La transformation vient ensuite avec dbt-core. Cette séparation des responsabilités est une force : elle rend chaque composant indépendamment remplaçable et testable.
dbt-core — transformations SQL modernes
dbt (data build tool) a révolutionné la façon dont les data engineers écrivent et organisent leurs transformations de données. L’idée centrale est simple mais puissante : transformer des données, c’est écrire du SQL — et le SQL mérite les mêmes bonnes pratiques que n’importe quel code applicatif (versioning, tests, documentation, modularité).
dbt-core, la version entièrement open-source sous licence Apache 2.0, permet de définir des modèles SQL sous forme de fichiers .sql organisés en couches logiques. La convention habituelle suit le schéma staging → intermediate → mart : les modèles de staging nettoient et renomment les données brutes issues d’Airbyte, les modèles intermédiaires combinent et enrichissent les données à mi-chemin, et les marts exposent les tables finales aux outils de visualisation. Cette organisation n’est pas imposée par le framework — c’est une convention de la communauté, documentée dans le guide de bonnes pratiques dbt (le fameux dbt style guide).
L’une des fonctionnalités les plus utiles de dbt est son système de tests natif. En quelques lignes YAML, vous pouvez déclarer que la colonne user_id ne doit jamais être nulle, que les valeurs de status appartiennent à un ensemble fini, ou que la combinaison (order_id, product_id) est unique. Ces tests s’exécutent après chaque build et bloquent le pipeline si une assertion est violée — c’est l’équivalent des tests unitaires pour votre entrepôt de données.
dbt-core supporte en 2026 les principaux adaptateurs : PostgreSQL (via dbt-postgres), DuckDB (via dbt-duckdb, parfait pour les environnements locaux légers), BigQuery, Snowflake, Redshift, et même Apache Iceberg via dbt-spark ou dbt-trino. Pour une stack self-hosted, l’adaptateur PostgreSQL ou DuckDB est la solution de départ idéale — simple, robuste et sans infrastructure supplémentaire.
Dagster — orchestration moderne orientée assets
Si Airbyte ingère et dbt transforme, quelqu’un doit décider quand et dans quel ordre ces opérations s’exécutent. C’est le rôle de l’orchestrateur. Pendant des années, Apache Airflow a dominé cet espace, mais il souffre de limitations architecturales qui se font sentir dès que le volume de pipelines augmente : modèle de tâches procédural difficile à tester, couplage fort entre le code et le scheduler, observabilité limitée nativement.
Dagster, lancé en 2018 et arrivé à maturité en 2024-2026, propose une approche radicalement différente basée sur le concept de Software-Defined Assets. Plutôt que de définir des tâches (ce que fait Airflow), Dagster vous demande de définir des actifs de données — des tables, des fichiers, des modèles ML — et leurs dépendances. L’orchestrateur infère automatiquement l’ordre d’exécution à partir du graphe de dépendances entre actifs. Cette inversion de perspective a des conséquences importantes : vos pipelines sont intrinsèquement documentés (chaque actif décrit ce qu’il produit), testables unitairement (chaque actif est une fonction Python pure), et observables (Dagster sait à tout moment quelle version d’un actif est fraîche ou périmée).
L’intégration de Dagster avec dbt est particulièrement soignée : le package dagster-dbt permet de charger automatiquement tous les modèles dbt comme des actifs Dagster, avec leur graphe de dépendances, leurs tests et leur documentation. En pratique, cela signifie que votre pipeline Dagster peut déclencher Airbyte pour ingérer les données, puis exécuter les modèles dbt dans le bon ordre, puis déclencher un refresh Metabase — le tout avec une visibilité complète dans l’UI Dagster sur ce qui a réussi, échoué, ou nécessite une re-exécution.
Dagster se déploie via Docker Compose ou Helm (Kubernetes) et propose une UI web moderne avec un graphe de dépendances interactif, des logs structurés par run, des alertes configurables et un catalogue d’actifs consultable. Pour commencer, le mode dagster dev en développement local suffit avant de passer en production.
Apache Iceberg — le format de table ouvert qui change tout
Apache Iceberg est moins connu du grand public que les trois outils précédents, mais c’est peut-être le plus structurellement important. Iceberg est un format de table ouvert pour les data lakes — une spécification qui définit comment organiser des fichiers Parquet (ou ORC, Avro) dans un système de fichiers ou un stockage objet (MinIO, S3, GCS) de manière à ce qu’ils se comportent comme une vraie table relationnelle, avec les propriétés ACID, la gestion des transactions, et l’évolution du schéma.
Avant Iceberg (et son concurrent Delta Lake de Databricks), un data lake était en pratique un ensemble de fichiers Parquet dans un bucket S3 — difficile à mettre à jour, impossible à requêter de manière transactionnelle, sans historique fiable. Iceberg résout ces problèmes fondamentaux : il supporte les insertions, mises à jour et suppressions au niveau ligne (via les delete files de la spec v2), l’évolution du schéma sans réécriture complète, les requêtes de voyage dans le temps (time travel), et le partitionnement dynamique sans migration de données.
En 2026, la spec Apache Iceberg v2 est supportée par l’ensemble des moteurs analytiques majeurs : Apache Spark, Trino, Flink, DuckDB, StarRocks, Doris, et même des services cloud comme AWS Athena et Google BigQuery Omni. Cette interopérabilité est la promesse centrale d’Iceberg : vos données stockées au format Iceberg peuvent être lues et écrites par n’importe quel moteur, aujourd’hui et demain, sans conversion. C’est l’antithèse du vendor lock-in de Snowflake.
Pour une stack self-hosted, Iceberg s’utilise typiquement avec MinIO comme stockage objet compatible S3, et un catalogue REST (le catalogue Iceberg REST standard) ou Apache Polaris pour gérer les métadonnées. La combinaison MinIO + Iceberg + DuckDB ou Trino forme un lakehouse complet sans aucun coût de licence.
Meltano — l’alternative Singer-native pour les équipes Python-first
Meltano occupe une niche complémentaire à Airbyte dans l’écosystème d’ingestion open-source. Là où Airbyte propose une UI graphique et des connecteurs Docker prêts à l’emploi, Meltano est un framework CLI et Python qui orchestre des extracteurs et loaders conformes au protocole Singer. Singer est un standard ouvert (initialement créé par Stitch, avant que la société soit rachetée) qui définit comment un programme doit émettre des données structurées vers stdout et comment un loader doit les consommer depuis stdin — une architecture de pipelines composables extrêmement légère.
Meltano brille particulièrement dans deux situations. Première situation : vous avez besoin de créer un extracteur personnalisé pour une source qui n’existe pas dans le catalogue Airbyte — par exemple, l’API interne de votre application métier ou une API locale comme Wave API pour les transactions Mobile Money. Le Meltano Singer SDK vous permet de créer un extracteur Python fonctionnel en quelques heures, avec authentification, pagination, gestion des curseurs et sérialisation automatique — ce qui prendrait plusieurs jours à développer from scratch. Deuxième situation : votre équipe est très à l’aise avec Python et préfère gérer les pipelines via des fichiers de configuration YAML et un CLI plutôt qu’une interface graphique. Dans ce cas, Meltano s’intègre naturellement dans un workflow GitOps.
Meltano 3.x supporte également l’orchestration via un plugin Airflow ou Dagster intégré, la gestion des environnements (dev/staging/prod) et le suivi des états de synchronisation. Pour les équipes qui souhaitent construire leur propre catalogue de connecteurs internes, Meltano Hub est la solution de référence.
Architecture lakehouse moderne : comment les 5 briques s’assemblent
Le terme lakehouse désigne une architecture qui combine les avantages du data lake (stockage de données brutes à faible coût, dans des formats ouverts) et de l’entrepôt de données (transactions ACID, schémas définis, performances analytiques). C’est précisément ce que réalise notre stack self-hosted.
Voici comment les données circulent dans l’architecture complète. La première couche est l’ingestion : Airbyte (ou Meltano pour les sources personnalisées) extrait les données de toutes vos sources — bases de données applicatives, APIs tierces, fichiers CSV, flux d’événements — et les charge dans une zone de staging. Pour une stack légère, ce staging peut être un schéma PostgreSQL dédié (raw_data). Pour une stack plus avancée, ce staging est un bucket MinIO structuré en fichiers Parquet.
La deuxième couche est la transformation : dbt-core lit le staging, applique les modèles SQL en cascade (staging → intermediate → mart) et écrit les résultats dans des tables de destination. Avec l’adaptateur dbt-postgres, ces tables vivent dans PostgreSQL. Avec dbt-spark ou dbt-trino, elles prennent la forme de tables Iceberg dans MinIO — c’est là qu’on entre dans le vrai lakehouse.
La troisième couche est l’orchestration : Dagster supervise l’ensemble du flux. Un schedule Dagster déclenche la synchronisation Airbyte à intervalles réguliers (toutes les heures pour les données transactionnelles, une fois par jour pour les données moins volatiles). Lorsque la synchronisation est terminée, Dagster déclenche automatiquement le build dbt. Si un test dbt échoue, Dagster le signale dans son UI et envoie une alerte Slack ou email. L’historique complet des exécutions, les durées, les volumes de lignes traitées — tout est visible dans le catalogue d’actifs Dagster.
La quatrième couche est la consommation : les marts dbt sont exposés à Metabase (BI open-source) pour les rapports métier, à DuckDB pour les analyses ad hoc des data analysts, et potentiellement à des notebooks Jupyter via SQLAlchemy pour les data scientists. Aucun de ces outils ne nécessite de licence commerciale.
Ce qui rend cette architecture particulièrement robuste, c’est que chaque brique est remplaçable indépendamment. Si demain vous souhaitez remplacer Airbyte par Meltano pour une source particulière, cela ne touche pas dbt ni Dagster. Si vous décidez de migrer de PostgreSQL vers un cluster Trino pour les requêtes analytiques, vous changez l’adaptateur dbt sans modifier vos modèles SQL. Si Dagster ne convient plus à votre équipe, vous pouvez le remplacer par Prefect 3 ou Airflow sans toucher à votre couche de données. Cette modularité est le principal avantage de construire avec des standards ouverts plutôt qu’une suite SaaS intégrée.
Tableau comparatif : stack self-hosted vs solutions SaaS
| Critère | Stack self-hosted (Airbyte + dbt + Dagster + Iceberg) | SaaS premium (Fivetran + dbt Cloud + Orchestrator + Snowflake) |
|---|---|---|
| Coût mensuel estimé (PME, 50M lignes/mois) | 20–50 € (VPS + stockage) | 2 000–5 000 USD |
| Souveraineté des données | Totale — données sur votre serveur | Données chez l’éditeur (USA, GDPR à vérifier) |
| Vendor lock-in | Nul — formats ouverts (Parquet, Iceberg) | Fort — formats propriétaires, APIs fermées |
| Courbe d’apprentissage | Modérée (2–4 semaines pour un data engineer) | Faible (UI guidée, support inclus) |
| Maintenance opérationnelle | Requiert des compétences DevOps (mises à jour, monitoring) | Gérée par l’éditeur (SLA garantis) |
| Scalabilité horizontale | Possible (Kubernetes, scale out Trino) mais à configurer | Automatique (serverless scaling) |
| Nombre de connecteurs | 350+ (Airbyte), extensible (Singer/Meltano SDK) | 600+ (Fivetran), certifiés et maintenus |
| Observabilité native | Dagster UI, dbt docs, logs structurés | Dashboards intégrés, alerting managé |
| Conformité réglementaire | À construire (OHADA, UEMOA — données locales) | SOC2, ISO 27001 (périmètre USA/Europe) |
| Idéal pour | PME, startups, équipes tech autonomes, contexte Afrique | Grands comptes, équipes data sans DevOps |
Tutoriels du cluster data engineering
Ce pilier est le hub du cluster thématique data engineering self-hosted. Chacun des tutoriels suivants approfondit une brique spécifique avec un guide pas-à-pas opérationnel. Si vous débutez, commencez par le tutoriel Airbyte pour avoir vos premières données ingérées, puis enchaînez avec dbt-core avant de passer à l’orchestration Dagster.
- — Déploiement Docker Compose, configuration des connecteurs PostgreSQL et API REST, première synchronisation complète, monitoring des jobs.
- — Installation, premier projet dbt, couches staging/intermediate/mart, tests generics et singuliers, génération de la documentation HTML.
- — Définition d’assets, intégration dagster-dbt, schedules, sensors, gestion des erreurs et re-runs partiels.
- — Installation MinIO, création du catalogue Iceberg REST, écriture de tables Iceberg avec Spark ou DuckDB, time travel et schema evolution.
Adaptation au contexte ouest-africain
Construire une data platform en Afrique de l’Ouest en 2026 présente des contraintes spécifiques que les tutoriels occidentaux ignorent systématiquement. Cette section aborde chacune d’elles avec des solutions concrètes et testées.
Choix du VPS et connectivité
Le premier choix est celui du serveur. Pour une stack complète (Airbyte + dbt + Dagster + Metabase), le minimum viable est un serveur avec 16 Go de RAM et 4 vCPU. Le Hetzner CX41 — 8 vCPU, 16 Go RAM, 160 Go NVMe SSD, réseau 1 Gbps — répond exactement à ce besoin pour environ 20 €/mois (tarif 2026, région Falkenstein Allemagne). Si vous avez besoin de plus de stockage pour votre data lake Iceberg, ajoutez un volume Hetzner Block Storage à 0,052 €/Go/mois — un volume de 500 Go coûte 26 €/mois supplémentaires. La latence depuis Dakar ou Abidjan vers Falkenstein est généralement de 50 à 80 ms, acceptable pour des jobs de batch qui s’exécutent en arrière-plan. Pour les requêtes analytiques interactives, cette latence peut se ressentir dans l’UI Metabase — dans ce cas, une mise en cache Metabase agressive ou un proxy Redis devant les requêtes fréquentes compense.
La bande passante est souvent le goulot d’étranglement pour l’ingestion de données depuis des sources locales. Si votre application métier est hébergée localement au Sénégal et que vous devez synchroniser vers un VPS européen, Airbyte compresse les données en transit et supporte les reprises de synchronisation en cas d’interruption. Configurez des plages de synchronisation pendant les heures creuses (nuit) pour profiter des meilleures débits disponibles.
Ingestion des sources Mobile Money locales
L’une des spécificités majeures des PME ouest-africaines est leur dépendance aux plateformes de Mobile Money — Wave, CinetPay, Orange Money, MTN MoMo, Moov Money — pour les paiements. Ces plateformes n’ont pas de connecteurs Airbyte officiels, mais leur architecture API REST est standardisée et parfaitement intégrable via le Meltano Singer SDK.
Un pipeline typique pour une startup e-commerce sénégalaise ressemble à ceci : l’extracteur Meltano appelle l’API Wave ou CinetPay toutes les heures, récupère les nouvelles transactions, et les charge dans une table PostgreSQL de staging (raw_wave_transactions). Un modèle dbt de staging nettoie les champs, normalise les devises (FCFA vers une représentation centimes pour éviter les erreurs d’arrondi), et enrichit chaque transaction avec les métadonnées client de votre base applicative. Les modèles marts agrègent ensuite les revenus par jour, par canal de paiement, par région — et Metabase expose ces données aux équipes commerciales sous forme de tableaux de bord actualisés toutes les heures.
Pour CinetPay, l’API de consultation des transactions est documentée sur la plateforme développeur CinetPay et supporte la pagination par curseur de date — idéal pour l’ingestion incrémentale. Pour Wave, l’API Wave Business est accessible sur invitation pour les marchands certifiés.
Gouvernance des données et conformité OHADA
L’OHADA (Organisation pour l’Harmonisation en Afrique du Droit des Affaires), qui regroupe 17 États membres dont le Sénégal, la Côte d’Ivoire, le Mali et le Bénin, impose des règles comptables et de conservation des données financières. L’Acte Uniforme OHADA sur le droit commercial général prévoit des délais de conservation des documents commerciaux de 10 ans. Dans le contexte d’une data platform, cela signifie que vos tables de faits financières (transactions, factures, paiements) doivent être archivées et non modifiables au-delà d’un certain âge.
Apache Iceberg répond parfaitement à cette exigence grâce à ses snapshots immuables et son historique de versions consultable. Chaque write sur une table Iceberg crée un nouveau snapshot sans modifier les données précédentes — vous pouvez à tout moment requêter l’état de votre table financière à une date passée précise, ce qui est exactement ce qu’exige un audit OHADA. Une politique de snapshot expiration configure Iceberg pour ne supprimer les anciens snapshots qu’après le délai légal de rétention.
ML Feature Store pour Mobile Money
Pour les équipes plus avancées qui développent des modèles de machine learning — détection de fraude sur les transactions Wave, scoring de crédit alternatif basé sur l’historique Mobile Money, prédiction du churn — la stack Iceberg constitue un excellent point de départ pour un feature store léger. Les features (agrégats par utilisateur sur 7/30/90 jours, ratios de transactions, fréquences par tranche horaire) sont calculées par des modèles dbt et stockées dans des tables Iceberg partitionnées par date. Feast, le feature store open-source, supporte Apache Iceberg comme offline store depuis la version 0.34 — ce qui permet de servir les features d’entraînement et d’inférence depuis la même infrastructure, sans duplication de données.
Erreurs fréquentes à éviter
| Erreur | Symptôme observé | Cause racine | Solution |
|---|---|---|---|
| Ingérer sans schéma de destination stable | dbt échoue à chaque ajout de colonne en source | Airbyte en mode overwrite recrée la table à chaque sync, effaçant les colonnes ajoutées manuellement | Passer en mode append-dedup dans Airbyte ; gérer l’évolution du schéma via les migrations dbt ou Iceberg schema evolution |
| Lancer dbt sans tests | Des données corrompues alimentent les tableaux de bord sans alerte | Absence de tests de qualité des données dans les modèles staging | Ajouter systématiquement des tests not_null, unique et accepted_values sur toutes les clés primaires et colonnes critiques |
| Orchestrer avec des crons système au lieu de Dagster | Impossible de savoir quelle sync a échoué, pas de re-run partiel | Utilisation de crontab pour déclencher les synchronisations Airbyte | Migrer vers Dagster avec des sensors qui détectent la fin de sync Airbyte avant de déclencher dbt |
| Stocker les credentials en clair dans le code | Fuite de clés API lors d’un git push public accidentel | Variables d’environnement hardcodées dans les fichiers de configuration dbt ou Dagster | Utiliser un fichier .env gitignored, ou un gestionnaire de secrets (HashiCorp Vault, Doppler, ou les secrets Dagster en production) |
| Ne pas monitorer l’espace disque | Le VPS tombe à 3h du matin avec un disque plein | Accumulation de logs Airbyte et de snapshots Iceberg non expirés | Configurer une alerte Netdata ou Prometheus à 80 % d’occupation ; automatiser l’expiration des snapshots Iceberg via une tâche Dagster hebdomadaire |
| Construire toute la stack en une seule fois | Le projet est abandonné après 3 semaines face à la complexité | Vouloir déployer Airbyte + dbt + Dagster + Iceberg + Metabase simultanément | Démarrer avec Airbyte → PostgreSQL → dbt → Metabase (stack la plus simple). Ajouter Dagster en semaine 3, Iceberg en semaine 6 seulement quand la stack de base tourne en production |
| Ignorer la déduplication en ingestion incrémentale | Les métriques métier sont gonflées de doublons | Airbyte en mode append pur ré-ingère parfois les mêmes lignes si le curseur n’est pas correctement configuré | Utiliser le mode append-dedup avec une clé primaire déclarée ; ajouter un test dbt unique sur la clé primaire de chaque table staging |
FAQ
- Q : Airbyte OSS est-il vraiment gratuit, ou y a-t-il des fonctionnalités cachées derrière un paywall ?
- R : Airbyte OSS (Community Edition) est gratuit et open-source sous licence MIT/ELv2. La version payante — Airbyte Cloud et Airbyte Enterprise — ajoute des fonctionnalités d’entreprise comme le SSO, le RBAC avancé, les SLA de support et certains connecteurs Premium. Pour une PME avec une équipe data de 1 à 5 personnes, la Community Edition couvre la quasi-totalité des besoins. La liste exacte des fonctionnalités par tier est maintenue sur
airbyte.com/pricing. - Q : Quelle est la différence entre dbt-core et dbt Cloud ? Dois-je payer pour utiliser dbt en production ?
- R : dbt-core est entièrement open-source (Apache 2.0) et inclut toutes les fonctionnalités de transformation, de test et de documentation. dbt Cloud est une offre SaaS qui ajoute un IDE web, un scheduler managé, une CI/CD intégrée et du support. Pour une stack self-hosted, dbt-core suffit largement — vous utilisez votre propre orchestrateur (Dagster) pour le scheduling et votre propre Git pour la CI/CD. Il n’y a aucune raison de payer dbt Cloud si vous êtes à l’aise avec la CLI.
- Q : Pourquoi Dagster plutôt qu’Apache Airflow, qui est plus connu ?
- R : Airflow reste une solution valide et très répandue, mais il a été conçu à une époque où le paradigme dominant était les tâches procédurales. Dagster, avec son modèle d’assets, est architecturalement mieux adapté aux pipelines data modernes orientés données. Concrètement : les pipelines Dagster sont plus faciles à tester unitairement, l’observabilité est meilleure (vous savez exactement quels assets sont à jour ou périmés), et l’intégration avec dbt est plus native. Cela dit, si votre équipe maîtrise déjà Airflow, la migration n’est pas obligatoire — le choix de l’orchestrateur est souvent une question de culture d’équipe autant que de technique.
- Q : Apache Iceberg est-il nécessaire dès le départ, ou peut-on commencer avec PostgreSQL ?
- R : Il est fortement recommandé de commencer avec PostgreSQL. Iceberg ajoute une couche de complexité (catalogue de métadonnées, stockage objet MinIO, moteur de requête compatible) qui n’est pas justifiée si votre volume de données est inférieur à quelques centaines de Go. PostgreSQL avec dbt-postgres est suffisant pour la plupart des PME jusqu’à plusieurs dizaines de millions de lignes par table. Migrez vers Iceberg lorsque vous ressentez les limitations de PostgreSQL : requêtes analytiques trop lentes, coût de stockage trop élevé, ou besoin de time travel. L’architecture en couches de la stack facilite cette migration future.
- Q : Comment gérer les pannes de courant fréquentes en Afrique de l’Ouest dans le contexte d’une data platform ?
- R : Votre VPS Hetzner est en Europe avec une alimentation redondante — les pannes de courant locales ne l’affectent pas. Ce qui peut être impacté, c’est votre connexion Internet depuis le bureau, qui interrompt temporairement la supervision des pipelines. La solution : configurer des alertes email ou Slack dans Dagster qui vous notifient des succès et échecs. Pour les sources de données qui tournent localement (serveur d’application on-premise), prévoir un buffer — une file d’attente Redis ou un fichier de log local — qui stocke les événements pendant la coupure et les réémet dès que la connexion est rétablie.
- Q : Est-il possible d’utiliser cette stack avec un budget encore plus réduit, par exemple 10 €/mois ?
- R : Pour 10 €/mois, vous pouvez démarrer avec un Hetzner CX31 (4 vCPU, 8 Go RAM) et exécuter uniquement dbt-core + Metabase + PostgreSQL — sans Airbyte ni Dagster. L’ingestion serait gérée par des scripts Python ou des crons Meltano légers, et l’orchestration par des crons système simples. C’est une stack viable pour une première expérience, avec les limitations d’observabilité que cela implique. Dès que vos besoins augmentent (plusieurs sources, équipe de 2+ personnes), le saut vers le CX41 à 20 €/mois s’impose pour avoir Airbyte et Dagster confortablement.
- Q : Comment sécuriser la data platform en production (authentification, réseau, sauvegardes) ?
- R : Les points essentiels sont : (1) exposer uniquement les ports nécessaires via un pare-feu UFW — Dagster UI et Airbyte UI derrière un reverse proxy Caddy ou Nginx avec HTTPS ; (2) accès SSH par clé uniquement, jamais par mot de passe ; (3) sauvegardes automatisées avec Restic vers un bucket Hetzner Object Storage chiffré, déclenchées quotidiennement ; (4) rotation des credentials Airbyte et PostgreSQL tous les 3 mois ; (5) pour les données financières OHADA, considérer un chiffrement au repos des volumes Hetzner. Ces pratiques couvrent les exigences de base pour une PME — une certification formelle (ISO 27001, SOC2) nécessiterait une démarche plus structurée.
Pour aller plus loin
Ce pilier pose les fondations conceptuelles et architecturales de votre data platform self-hosted. La mise en pratique se fait dans les tutoriels satellites du cluster — commencez par le tutoriel d’installation Airbyte, qui vous amènera à vos premières données ingérées en moins d’une heure.
- Documentation officielle Airbyte : docs.airbyte.com — architecture, quickstart Docker Compose, catalogue de connecteurs.
- Documentation dbt-core : docs.getdbt.com — guide de démarrage, référence des modèles, best practices du style guide communautaire.
- Documentation Dagster : docs.dagster.io — concepts Software-Defined Assets, tutoriel officiel, intégrations Airbyte et dbt.
- Spécification Apache Iceberg : iceberg.apache.org/spec — spec v2 complète, format des fichiers, protocoles de catalogue.
- Documentation Meltano SDK : docs.meltano.com — création d’extracteurs Singer, orchestration, Hub de connecteurs.
- Formations ITSkillsCenter : Retrouvez nos formations pratiques sur l’infrastructure data, le DevOps et le développement backend adaptées au contexte ouest-africain sur itskillscenter.io.
Mots-clés secondaires SEO : data pipeline open-source, ELT moderne, entrepôt de données PME, data lakehouse self-hosted, dbt tutoriel français, orchestration pipeline Dagster, format Parquet Iceberg, data engineering Sénégal Côte d’Ivoire, alternative Fivetran gratuit, Meltano Singer connecteur personnalisé.