Guide plateforme data

Architecture medallion

Bronze, Silver, Gold : le schéma qui permet d’ingérer vite des données brutes, de les nettoyer progressivement et de livrer des jeux de données prêts pour le métier. Ce guide montre comment l’appliquer sans sur-ingénierie.

22 min de lecturePour data & platform engineersAvec exemples de code

1. Qu’est-ce que l’architecture medallion ?

L’architecture medallion est un modèle qui structure votre lakehouse en trois couches progressives : Bronze (brut), Silver (nettoyée) et Gold (prête pour le métier). Chaque couche améliore la qualité des données et rapproche de la valeur business.

L’idée clé

Bronze

Brut, tel que reçu

Silver

Nettoyé, conformé

Gold

Prêt pour le métier

Pourquoi ne pas nettoyer une seule fois ?

Parce que les règles changent. Garder le brut en Bronze permet de retraiter quand la logique métier évolue. Les équipes qui sautent Bronze doivent souvent ré-ingérer quand on leur demande « les données avant ce filtre ».

Quand utiliser l’architecture medallion :

Multiples sources

Quand vous ingérez 10+ sources avec formats, schémas et qualités différentes.

Consommateurs variés

Quand les data scientists veulent du brut, les analystes du propre, et les dashboards des agrégats.

Exigences mouvantes

Quand la logique métier change souvent et que vous devez retraiter l’historique.

Besoins de conformité

Quand vous devez tracer, conserver la lignée et prouver l’état des données à tout moment.

Retours terrain

L’important n’est pas le nom mais le principe : ne jamais perdre le brut, améliorer la qualité par étapes, fournir la bonne abstraction au bon public. Vous pouvez appeler vos couches « raw/staging/marts » ou « landing/curated/consumption » : le pattern reste le même.

2. Les trois couches expliquées

Chaque couche a un rôle, un propriétaire et un niveau de qualité. Ce cadre rend l’architecture efficace.

CoucheObjectifNiveau de qualitéConsommateurs
🥉 BronzeDéposer le brut tel quelAucun – on garde toutData engineers, debug
🥈 SilverNettoyer, dédupliquer, conformer les schémasValidé, typé, cohérentData scientists, analystes avancés
🥇 GoldAgrégats et métriques métierValidé métier, documentéDashboards, rapports, apps

Principes clés pour chaque transition :

🥉→🥈

Bronze vers Silver

Nettoyer et conformer

Retirer les doublons, caster les types, appliquer le schéma, filtrer les enregistrements invalides, standardiser les formats (dates, devises, codes).

🥈→🥇

Silver vers Gold

Agrégations et enrichissement

Joindre les tables liées, calculer les métriques métier, appliquer la logique métier, créer des modèles dimensionnels, optimiser pour les patterns de requêtes.

Astuce

Ne sautez pas Silver

Aller directement de Bronze à Gold est tentant, mais Silver est là où vit la qualité. Sans Silver, la logique de nettoyage est recopiée partout en Gold : les changements deviennent coûteux et risqués.

3. Focus sur la couche Bronze

Bronze est votre « data lake » au sens strict : tout atterrit ici tel que reçu. L’objectif est durabilité et traçabilité, pas propreté.

Bronze doit contenir

  • • Données brutes telles que reçues (JSON, CSV, Parquet)
  • • Métadonnées d’ingestion (timestamp, fichier source, batch ID)
  • • Écritures append-only (jamais de mise à jour/suppression)
  • • Partitionnement par date d’ingestion
  • • Rétention longue (mois à années)

Bronze ne doit pas contenir

  • • Enforcement de schéma (laisser entrer le mauvais)
  • • Transformations
  • • Logique de déduplication
  • • Logique métier ou calculs
  • • Accès pour les utilisateurs métier

Structure d’une table Bronze :

Exemple : schéma de table Bronze orders

-- Bronze: raw_orders
CREATE TABLE bronze.raw_orders (
  -- Ingestion metadata
  _ingested_at      TIMESTAMP,
  _source_file      STRING,
  _batch_id         STRING,
  
  -- Raw payload (store as-is)
  raw_payload       STRING,  -- JSON string, unparsed
  
  -- Or if structured:
  order_id          STRING,  -- Not validated yet
  customer_id       STRING,
  order_date        STRING,  -- Could be any format
  amount            STRING,  -- Could have currency symbols
  status            STRING
)
PARTITIONED BY (_ingested_at::DATE)

Ajouter des métadonnées d’ingestion

Timestamp, fichier source, batch ID. Indispensable pour le debug et le retraitement.

Utiliser l’append-only

Jamais de UPDATE ou DELETE en Bronze. Une correction = un nouvel enregistrement avec nouveau timestamp.

Partitionner par date d’ingestion

Facilite le retraitement ciblé et la gestion de la rétention.

Rester économique

Formats compressés (Parquet, ORC) et stockage froid pour les partitions anciennes.

4. Focus sur la couche Silver

Silver est là où le travail réel se fait. C’est votre source de vérité entreprise pour des données propres et validées.

Responsabilités de la couche Silver :

1

Enforcement de schéma

Caster les types, imposer NOT NULL, valider les formats. Les enregistrements invalides vont dans une table de quarantaine.

2

Déduplication

Retirer les doublons. Utiliser les clés métier + timestamp pour conserver la dernière version.

3

Standardisation

Normaliser les dates en ISO, les devises en base, les codes aux valeurs standard.

4

Contrôles qualité

Tests automatiques : taux de null, unicité, intégrité référentielle, plages de valeurs.

Exemple : transformation Silver orders (dbt)

-- models/silver/orders.sql
WITH source AS (
  SELECT * FROM {{ source('bronze', 'raw_orders') }}
  WHERE _ingested_at >= CURRENT_DATE - INTERVAL '7 days'
),

deduplicated AS (
  SELECT *,
    ROW_NUMBER() OVER (
      PARTITION BY order_id 
      ORDER BY _ingested_at DESC
    ) as row_num
  FROM source
),

cleaned AS (
  SELECT
    -- Cast and validate types
    CAST(order_id AS BIGINT) AS order_id,
    CAST(customer_id AS BIGINT) AS customer_id,
    
    -- Standardize date format
    TO_DATE(order_date, 'YYYY-MM-DD') AS order_date,
    
    -- Clean amount (remove currency symbols)
    CAST(REGEXP_REPLACE(amount, '[^0-9.]', '') AS DECIMAL(10,2)) AS amount,
    
    -- Normalize status to uppercase
    UPPER(TRIM(status)) AS status,
    
    -- Keep lineage
    _ingested_at,
    _batch_id
  FROM deduplicated
  WHERE row_num = 1
    AND order_id IS NOT NULL
)

SELECT * FROM cleaned

Retours terrain

Silver est la couche où beaucoup d’équipes sous-investissent. Elles courent vers Gold et recopient la logique de nettoyage partout. Investissez dans Silver : cela paie sur chaque modèle en aval.

5. Focus sur la couche Gold

Gold est là où vit la valeur métier. Ce sont les tables réellement requêtées par les parties prenantes. Pensez modèles dimensionnels, métriques et agrégats orientés usage.

Patterns fréquents en Gold :

Modèles dimensionnels (star schema)

Tables de faits (événements, transactions) entourées de dimensions (clients, produits, temps). Optimisé pour la BI et l’ad hoc.

Exemple :

fact_orders ← dim_customers, dim_products, dim_date

Métriques pré-agrégées

Rollups journaliers/hebdomadaires/mensuels pour les tableaux de bord. Requêtes plus rapides, coûts moindres.

Exemple :

daily_revenue_by_region, weekly_active_users, monthly_churn_rates

Feature tables (ML)

Features pré-calculées pour les modèles de machine learning. Correctes en point-in-time, versionnées.

Exemple :

customer_features, product_embeddings, user_activity_signals

Exemple : table de faits Gold (dbt)

-- models/gold/fact_orders.sql
WITH orders AS (
  SELECT * FROM {{ ref('silver_orders') }}
),

customers AS (
  SELECT * FROM {{ ref('dim_customers') }}
),

products AS (
  SELECT * FROM {{ ref('dim_products') }}
)

SELECT
  -- Surrogate key
  {{ dbt_utils.generate_surrogate_key(['o.order_id']) }} AS order_key,
  
  -- Foreign keys to dimensions
  c.customer_key,
  p.product_key,
  d.date_key,
  
  -- Degenerate dimensions
  o.order_id,
  o.status,
  
  -- Measures
  o.quantity,
  o.unit_price,
  o.quantity * o.unit_price AS line_total,
  o.discount_amount,
  
  -- Audit columns
  o._ingested_at AS source_loaded_at,
  CURRENT_TIMESTAMP AS dbt_loaded_at

FROM orders o
LEFT JOIN customers c ON o.customer_id = c.customer_id
LEFT JOIN products p ON o.product_id = p.product_id
LEFT JOIN {{ ref('dim_date') }} d ON o.order_date = d.date_day

Principe Gold

Optimiser pour les requêtes

Partitionner sur les colonnes de filtre fréquentes (date, région). Cluster sur les clés de jointure.

Principe Gold

Documenter la logique métier

Chaque table Gold doit décrire clairement ses métriques.

Principe Gold

Versionner avec soin

Les changements en Gold peuvent casser les dashboards. Utilisez versioning sémantique ou alias.

6. Modèles d’implémentation

L’architecture medallion fonctionne sur toute plateforme moderne. Voici comment l’implémenter avec les stacks courants.

PlateformeBronzeSilver/GoldFormat
DatabricksUnity CatalogDelta Lake + dbtDelta
SnowflakeBase RAWdbt + SnowflakeTables natives
BigQueryDataset raw_dbt + BQTables natives
AWS (Open)S3 + GlueSpark + dbtIceberg/Hudi

Structure dossiers/base :

# Convention de nommage typique
catalog/
├── bronze/
│   ├── raw_orders
│   ├── raw_customers
│   ├── raw_products
│   └── raw_events
├── silver/
│   ├── orders           # Commandes nettoyées
│   ├── customers        # Clients nettoyés
│   ├── products         # Produits nettoyés
│   └── events           # Événements nettoyés
├── gold/
│   ├── dim_customers    # Dimension : clients
│   ├── dim_products     # Dimension : produits
│   ├── dim_date         # Dimension : date
│   ├── fact_orders      # Fait : commandes
│   └── agg_daily_sales  # Agrégat : ventes quotidiennes
└── quarantine/
    ├── orders_failed    # Enregistrements rejetés
    └── events_failed

Astuce

Séparer bases/schemas

Ne vous contentez pas de préfixes (raw_, silver_, gold_). Utilisez des bases ou schémas distincts pour appliquer droits d’accès, politiques de stockage et rétention propres à chaque couche.

7. Checklist de bonnes pratiques

Ne jamais supprimer en Bronze

Écritures append-only. Une correction = un nouvel enregistrement. Bronze est votre piste d’audit.

Investir dans Silver

La qualité vit ici. Déduplication, enforcement de schéma et standardisation doivent être solides.

Garder Gold simple

Les tables Gold doivent être faciles à requêter. Pré-joins, pré-agrégations, optimisation pour le consommateur.

Tout documenter en Gold

Chaque table Gold doit avoir : propriétaire, description, définition des colonnes, fréquence, SLA.

Traiter en incrémental

Ne traiter que le nouveau/changé. Les full refresh coûtent cher à l’échelle.

Mettre les données invalides en quarantaine

Ne pas supprimer silencieusement. Router vers une table de quarantaine pour investigation.

Tester à chaque couche

Tests qualité Bronze → Silver (schéma), Silver → Gold (règles métier), Gold (métriques).

Contrôler l’accès par couche

Bronze : data engineers. Silver : équipe data. Gold : utilisateurs métier et dashboards.

Retours terrain

Les équipes en difficulté voient souvent la medallion comme une migration ponctuelle, pas une architecture continue. Chaque couche doit avoir un owner, de la maintenance et des améliorations régulières.

8. Questions fréquentes

Qu’est-ce que l’architecture medallion ?

Un modèle qui organise les données en trois couches : Bronze (brut), Silver (nettoyé et conformé) et Gold (agrégats métier). Il améliore la qualité progressivement dans le lakehouse.

Quelle différence entre Bronze, Silver et Gold ?

Bronze : données brutes. Silver : données nettoyées, dédupliquées, conformées. Gold : agrégats et métriques métier pour dashboards et modèles ML.

Quand utiliser l’architecture medallion ?

Quand vous avez plusieurs sources, besoin d’améliorer la qualité par étapes, de supporter batch/streaming, ou de servir divers consommateurs.

Est-ce réservé à Databricks ?

Non. Le pattern fonctionne sur Snowflake, BigQuery, Redshift ou des stacks open source (Delta Lake, Apache Iceberg, Apache Hudi). Brut → Nettoyé → Agrégé reste valable partout.

Visualisez votre architecture medallion

Créez des diagrammes clairs montrant les couches Bronze, Silver et Gold. Documentez flux, transformations et ownership en quelques minutes.