• Accueil >
  • Les zones d’un Datalake : organiser ses données selon leur niveau de maturité

🔗 Les zones d’un Datalake : organiser ses données selon leur niveau de maturité

Dans une plateforme de données moderne, le Datalake joue un rôle fondamental. C’est un espace de stockage centralisé, capable de collecter, stocker et distribuer d’immenses volumes de données, sous des formats hétérogènes.

Mais pour tirer de la valeur de ce vaste lac de données, il est indispensable de structurer l’espace de stockage selon des logiques de qualité, de gouvernance et d’usage. C’est là qu’intervient le concept des zones du Datalake.

🧭 Pourquoi organiser le Datalake en zones ?

Les zones permettent de :

  • Gérer le cycle de vie des données

  • Appliquer des règles de qualité à chaque étape

  • Contrôler les droits d’accès selon le niveau de sensibilité

  • Faciliter le catalogage, la traçabilité et l’auditabilité

Cette organisation repose souvent sur l’architecture en médaillons (Medallion Architecture), popularisée par Databricks, mais aujourd’hui largement utilisée dans tous les environnements (cloud, on-premise, hybrides).


🪙 L’architecture en médaillons : Bronze, Silver, Gold (et au-delà)

1. 🟤 Bronze — Zone de dépôt brut (Raw Zone)

La zone Bronze est la porte d’entrée du Datalake. Elle stocke les données telles qu’elles sont ingérées, sans transformation ni validation, dans leur format brut.

🔧 Caractéristiques :

  • Données non modifiées

  • Stockage en formats originaux (JSON, CSV, XML, etc.)

  • Utilisée pour l’audit ou le retraitement

  • Souvent non accessible aux utilisateurs finaux

🛠️ Exemples d’outils d’ingestion :

  • AWS : Spark, S3 Transfer, Glue ETL, Kinesis Firehose

  • Azure : Data Factory, Event Hub

  • Cloudera : Nifi, Kafka, Sqoop


2. ⚪ Silver — Zone de données standardisées (Cleansed / Conformed Zone)

Dans la zone Silver, les données sont nettoyées, normalisées et structurées. Elles ont subi des opérations de qualité : suppression des doublons, typage cohérent, enrichissement basique, etc.

🔧 Caractéristiques :

  • Format standardisé : Parquet, ORC, ou Delta

  • Compatible avec la gouvernance : catalogage, traçabilité

  • Accès souvent ouvert à tous les utilisateurs data.

  • Organisation ouverte, mais souvent par domaine fonctionnel ou source

📚 Exemples d’outils :

  • AWS : Glue jobs, EMR , Athena

  • Azure : Synapse pipelines, Data Flow

  • Cloudera : Spark (CDP), Hive


3. 🟡 Gold — Zone de produits de données (Data Products / Business Layer)

La zone Gold contient les données de référence, prêtes à être utilisées par toute l’entreprise. Ces jeux de données sont curés, agrégés, validés et parfois modélisés selon des schémas métier.

🔧 Caractéristiques :

  • Données gouvernées avec des SLA

  • Haute qualité, haut niveau de confiance

  • Modélisation autour des entités métier : clients, ventes, stocks…

🛠️ Exemples d’outils de transformation :

  • AWS : EMR, DBT, Redshift

  • Azure : Databricks, Synapse

  • Cloudera : Spark, Hive, Impala


4. 🔵 Platinium — Zone analytique ou exploratoire

Certaines architectures ajoutent une quatrième zone : la zone Platinium. Elle contient des jeux de données orientés usages, souvent issus de la zone Gold, mais retravaillés pour répondre à un besoin spécifique : tableau de bord, modèle ML, exploration ad hoc, etc.

🔧 Caractéristiques :

  • Données prêtes à consommer par les utilisateurs métier

  • Filtrées, pivotées, agrégées selon des cas d’usage précis

  • Peut être temporaire ou persistante

  • Produite par des équipes BI, Analytics ou Data Science


🗺️ Exemple schématique des zones d’un Datalake

Voici un schéma typique :


🧠 En conclusion

Organiser son Datalake en zones est bien plus qu’un choix technique : c’est une démarche stratégique. Cela permet de :

✅ Structurer le cycle de vie des données
✅ Faciliter la gouvernance et la conformité
✅ Optimiser l’usage selon le profil des utilisateurs
✅ Réduire la dette technique et les redondances

Que vous soyez sur AWS, Azure, GCP, Cloudera ou autre, cette structuration en zones est une bonne pratique universelle pour faire évoluer une plateforme de données vers un modèle gouverné, évolutif et efficace.

Mehdi TAZI – CTO & Data Architect a BI-NEWVISION