Open Source 6 janvier 2026 15 min de lecture

Construire une plateforme de données souveraine : architecture et retour d'expérience

Découvrez comment construire une plateforme data souveraine avec MinIO, PostgreSQL, Airflow et Kubernetes. Architecture complète, choix techniques et bonnes pratiques pour le cloud privé.

Cloud PrivéMinIOPostgreSQLAirflowKubernetesSouveraineté

Nathan ML OPS

En bref : Une plateforme data complète (collecte, stockage, transformation, reporting) hébergée sur vos serveurs ou chez un hébergeur européen. Zéro dépendance au cloud américain, coûts prévisibles, empreinte carbone maîtrisée. Stack : MinIO, PostgreSQL, Airflow, K3s.

Introduction

Les données métier de votre entreprise sont dispersées dans plusieurs systèmes. Vos équipes passent du temps à consolider des exports manuels. Vos tableaux de bord Power BI attendent qu'on les alimente. Et tout ça tourne sur AWS ou Azure, avec des coûts qui augmentent, des questions sur la localisation des données qui restent sans réponse, et une empreinte carbone que personne ne sait vraiment mesurer.

Chez DataKhi, nous avons construit une plateforme de traitement de données entièrement hébergée sur l'infrastructure de notre client, sans aucune dépendance au cloud public. Cet article explique pourquoi et comment.

Pourquoi se passer du cloud public

Le problème juridique

Le CLOUD Act américain, adopté en 2018, autorise les autorités américaines à accéder aux données stockées par des entreprises américaines — y compris lorsque ces données sont physiquement hébergées en Europe. Si votre entreprise utilise AWS, Azure ou Google Cloud, vos données peuvent faire l'objet d'une réquisition américaine sans que vous en soyez informé.

Beaucoup d'entreprises pensent être protégées parce que leurs données sont dans un datacenter européen. C'est une confusion entre résidence et souveraineté. Ce qui compte, c'est l'immunité du fournisseur face aux lois extraterritoriales. Les initiatives "cloud souverain" des hyperscalers ne résolvent pas ce problème : la maison mère reste soumise au droit américain.

Le problème économique

Le cloud public facture à l'usage : compute, stockage, transfert réseau, requêtes API. Ces coûts sont difficilement prévisibles et peuvent exploser avec la croissance des volumes. Le vrai avantage du cloud privé n'est pas forcément l'économie brute, c'est la prévisibilité : vous savez exactement ce que coûte votre infrastructure.

Le problème environnemental

On l'oublie souvent : le réseau consomme énormément d'énergie. Chaque requête vers un datacenter distant, chaque transfert de données entre votre infrastructure et le cloud, chaque appel API — tout cela a un coût carbone. Les hyperscalers communiquent sur l'efficacité énergétique de leurs datacenters (PUE proche de 1.1), mais ils passent sous silence l'énergie consommée par le réseau pour y accéder. Faire transiter des données sur des milliers de kilomètres a un coût incompressible.

Un serveur local consomme-t-il plus qu'une VM dans un datacenter optimisé ? Probablement, par watt de calcul. Mais quand vos données restent sur place, vous éliminez les allers-retours réseau. Et surtout : vous y faites attention. La consommation d'un serveur physique dans vos locaux est visible, mesurable, concrète. Vous pouvez l'optimiser, la monitorer, décider consciemment de l'éteindre la nuit si les traitements sont terminés.

Dans le cloud, cette consommation est abstraite, noyée dans une facture mensuelle. Le modèle économique des hyperscalers pousse à la surconsommation : il est plus facile de provisionner large "au cas où" que d'optimiser finement. Résultat : des ressources allouées qui tournent à vide, des instances oubliées, des environnements de dev qui restent allumés le week-end. Sur votre propre infrastructure, chaque watt compte — et ça change la façon dont vous concevez vos systèmes.

L'architecture cible

Nous avons mis en place une architecture en couches :

Sources → Data Lake (MinIO) → Data Warehouse (PostgreSQL) → Analytics (Power BI)

Cette séparation permet de conserver les données brutes (si une règle métier change, on recalcule depuis l'origine), de tracer chaque transformation (on sait d'où vient chaque chiffre), et d'ajouter de nouvelles sources sans remettre en cause l'existant.

L'ensemble tourne sur un cluster Kubernetes léger (K3s), déployé via Ansible, avec un registry Docker privé. Aucune dépendance externe : même si Internet est coupé, le pipeline continue de fonctionner.

Les briques techniques

Stockage objet : MinIO

MinIO joue le rôle de data lake. C'est un système de stockage objet compatible avec l'API Amazon S3, mais que l'on installe sur ses propres serveurs.

Pourquoi MinIO : c'est aujourd'hui l'implémentation S3-compatible la plus complète du marché. Stable, éprouvée en production depuis des années, avec une communauté active. L'organisation des données en buckets et préfixes permet d'exploiter les wildcards avec Spark ou d'autres moteurs de traitement, ce qui simplifie considérablement les pipelines de données.

Fin décembre 2025, MinIO a annoncé le passage de son édition communautaire en mode maintenance. Concrètement, cela signifie une base stable et mature sur laquelle s'appuyer, avec des correctifs de sécurité maintenus. Pour une infrastructure de production, c'est plutôt rassurant : pas de breaking changes à gérer, pas de course aux nouvelles fonctionnalités.

Data Warehouse : PostgreSQL

PostgreSQL sert de data warehouse. C'est un choix qui peut surprendre dans un monde où les moteurs analytiques spécialisés se multiplient. Notre raisonnement s'inscrit dans la philosophie du manifeste "Choose Boring Technology" : chaque technologie a un coût d'apprentissage et de maintenance, et ce coût se paie sur la durée. Chaque service supplémentaire, c'est aussi un processus de plus qui tourne, de la RAM mobilisée, des cycles CPU consommés. Consolider sur PostgreSQL, c'est faire plus avec moins.

PostgreSQL est universel. Tout le monde le connaît, tout le monde sait l'opérer, tout le monde sait l'interroger. La documentation est exhaustive, les problèmes courants sont documentés depuis des années, et les compétences sont faciles à trouver sur le marché.

L'écosystème de plugins étend ses capacités : PostGIS pour le géospatial, pg_cron pour la planification, timescaledb pour les séries temporelles. Et si un jour les performances atteignent un plateau, on peut compléter avec un cache Redis ou ajouter un moteur analytique en lecture. PostgreSQL reste la source de vérité, le reste s'ajoute par-dessus.

Le schéma de données suit le modèle en étoile, classique en Business Intelligence : des tables de dimension reliées à des tables de faits, partitionnées par client. Ce modèle optimise les performances des requêtes analytiques et simplifie la création de rapports dans Power BI.

Orchestration : Apache Airflow sur K3s

Un pipeline de données, ce n'est pas juste des scripts. C'est une séquence de tâches avec des dépendances : la déduplication ne peut pas commencer avant que la collecte soit terminée, le chargement warehouse dépend du staging.

Apache Airflow orchestre cette séquence. Chaque pipeline est défini comme un graphe de tâches (DAG) en Python. Airflow planifie les exécutions, respecte les dépendances entre tâches, relance automatiquement les tâches en échec, et alerte en cas de problème. L'interface web permet de visualiser l'état des pipelines en temps réel.

Airflow tourne sur K3s, une distribution Kubernetes développée par Rancher Labs (aujourd'hui SUSE). K3s n'est pas une version "allégée" au sens de "limitée" — c'est une version plus compréhensible, plus maintenable, plus facile à installer et configurer. Un seul binaire de moins de 100 Mo, une installation en une commande, et une empreinte mémoire bien inférieure à un Kubernetes classique. Là où un cluster K8s standard consomme plusieurs gigaoctets de RAM rien que pour le control plane, K3s tourne confortablement avec 512 Mo. Rancher est fourni avec, ce qui donne d'emblée une interface de monitoring puissante pour visualiser l'état du cluster, les pods, les logs.

Chaque tâche du pipeline s'exécute dans son propre conteneur Docker, isolé des autres. Si une tâche plante ou consomme trop de mémoire, elle n'affecte pas les autres. Plusieurs clients peuvent être traités simultanément, chacun dans son conteneur.

Collecte : s'adapter aux sources existantes

Les sources de données en entreprise sont rarement homogènes. APIs REST, interfaces web sans export, fichiers Excel sur un partage réseau, Google Sheets collaboratifs, bases de données legacy — chaque système a sa logique.

L'approche retenue : un connecteur par source, encapsulé dans une tâche Airflow. Que la donnée vienne d'une API, d'un scraping web avec Playwright, d'un fichier SFTP ou d'un Google Sheet, le principe reste le même : extraire, convertir en Parquet, déposer dans le data lake. Le DAG orchestre l'ensemble et gère les dépendances.

Cette modularité permet d'ajouter une nouvelle source sans toucher au reste du pipeline. Il suffit d'écrire le connecteur et de l'intégrer au graphe de tâches.

Infrastructure as Code : Ansible

L'infrastructure n'est pas installée manuellement. Tout est décrit dans des fichiers de configuration, versionnés dans Git, et déployé automatiquement avec Ansible.

Un playbook Ansible décrit l'état souhaité de l'infrastructure : quels services installer, quelle configuration appliquer, quels secrets injecter. Cette approche apporte trois bénéfices majeurs.

La résilience d'abord : en cas d'incident majeur (panne matérielle, corruption), l'environnement complet peut être reconstruit en une commande sur une nouvelle machine. Pas de documentation obsolète à suivre, pas de "je ne me souviens plus comment c'était configuré".

La reproductibilité ensuite : on peut dupliquer l'infrastructure à l'identique pour un environnement de test, de développement, ou pour un nouveau client. Même configuration, même comportement garanti.

La scalabilité enfin : ajouter un nœud au cluster, déployer sur un nouveau site, répliquer l'infrastructure chez un autre hébergeur — tout se fait en modifiant quelques variables et en relançant le playbook. L'infrastructure devient du code, avec tous les avantages que cela implique : versioning, revue de code, rollback.

Le pipeline en pratique

Chaque matin, le pipeline se déclenche automatiquement. Voici ce qui se passe, illustré par notre cas client.

Le DAG commence par récupérer la liste des clients et leurs paramètres de connexion aux systèmes sources. Pour chaque client, les tâches de collecte s'exécutent en parallèle : un pod Kubernetes par client, par source. Les données brutes sont déposées dans le data lake au format Parquet.

Vient ensuite la phase de déduplication. Les extractions peuvent se chevaucher d'un jour à l'autre. Le pipeline identifie les doublons et ne conserve que la version la plus récente. Sortie : un fichier propre par jour et par client.

La transformation applique les règles métier. Les statuts techniques deviennent des catégories compréhensibles par les utilisateurs finaux. Ces règles sont codées explicitement, versionnées, testables. Elles reproduisent exactement la logique qui était auparavant enfouie dans des formules Excel ou des requêtes Power Query.

Le chargement warehouse alimente les tables PostgreSQL. Le chargement est idempotent : relancer le pipeline pour une date déjà traitée ne crée pas de doublons. Enfin, des agrégations pré-calculées accélèrent les tableaux de bord.

Le tout prend quelques minutes. Les tableaux de bord sont alimentés avec les données fraîches. En cas d'anomalie, une alerte est envoyée. L'équipe cliente peut suivre l'exécution via l'interface Airflow ou Rancher.

Extensions possibles

L'architecture décrite couvre le reporting batch quotidien. Selon les besoins, elle peut évoluer dans plusieurs directions.

Temps réel. Le pipeline actuel tourne une fois par jour. Pour du streaming ou de l'événementiel, on ajouterait Apache Kafka ou Redpanda comme broker de messages, avec des consumers qui alimentent le warehouse en continu. L'architecture en couches reste la même, seule la fréquence change.

Machine Learning. La stack est optimisée pour le reporting BI. Pour industrialiser des modèles ML, on ajouterait MLflow pour le tracking des expérimentations et le registry de modèles, potentiellement un feature store pour partager les features entre équipes. PostgreSQL reste la source de vérité, les modèles consomment les données via des vues ou des exports.

Haute disponibilité. L'architecture actuelle tourne sur un nœud unique. Pour de la haute disponibilité, K3s supporte nativement le mode multi-nœuds avec PostgreSQL ou etcd comme backend. MinIO peut être déployé en mode distribué sur plusieurs serveurs. L'Infrastructure as Code facilite ce passage à l'échelle.

Gouvernance avancée. Pour des besoins de catalogage, lignage et qualité de données, des outils comme Apache Atlas, DataHub ou Great Expectations s'intègrent naturellement à cette stack.

Reporting souverain. L'architecture exposant des connecteurs standards, vous pouvez y brancher n'importe quel outil de reporting ou d'analytique. Si vous souhaitez aller au bout de la démarche souveraine, des solutions open source et auto-hébergées existent pour le reporting et la visualisation de données. Une alternative aux outils cloud américains, hébergée sur la même infrastructure que vos données.

Pour qui cette approche

Cette architecture s'adresse aux organisations qui ont besoin de maîtriser leurs données : localisation, accès, coûts, impact environnemental. Elle convient particulièrement aux secteurs sensibles (santé, finance, secteur public), aux entreprises avec des volumes prévisibles, à celles qui privilégient l'indépendance technologique, et aux organisations engagées dans une démarche RSE qui veulent mesurer et réduire l'empreinte carbone de leur infrastructure numérique.

Elle demande des compétences pour opérer l'infrastructure — compétences qui peuvent être internalisées progressivement ou externalisées via un contrat de support. L'avantage de ces compétences : elles sont transférables. PostgreSQL, Airflow, Kubernetes s'appliquent à tous les contextes, contrairement à l'expertise sur un service propriétaire.

Conclusion

Construire une plateforme de données souveraine en 2025, ce n'est pas un retour en arrière. MinIO, PostgreSQL, Airflow, Kubernetes ne sont plus des projets expérimentaux : ils propulsent certaines des plus grandes infrastructures mondiales. La différence, c'est que vous pouvez les déployer sur vos machines, dans votre datacenter, sous votre contrôle.

Le principe reste le même que chez les géants du cloud : collecter, stocker, transformer, distribuer. Mais sur une infrastructure que vous maîtrisez, avec des coûts prévisibles, une empreinte carbone que vous pouvez mesurer et optimiser, et sans dépendance à des fournisseurs soumis à des juridictions qui ne sont pas les vôtres.

Besoin d'aide pour construire votre plateforme data souveraine ? Contactez nos experts pour discuter de votre projet.