Architecture médaillon (bronze/silver/gold) : le pattern qui s’est imposé sur les lakehouses en 2026, et comment l’implémenter sans se planter

Pourquoi l’architecture médaillon s’est imposée sur les lakehouses en 2026

Si tu bosses sur un lakehouse en 2026, tu as forcément croisé l’architecture medallion bronze silver gold. En 260 recherches par mois en France (donnée DataForSEO Labs), c’est devenu le pattern dominant sur les plateformes modernes. Et la raison est simple: le data lake est devenu un swamp, le data warehouse classique ne scale plus sur tous les usages, et il fallait un cadre clair pour structurer la qualité progressive des données.

L’architecture médaillon est un pattern de modélisation en 3 couches progressives (bronze, silver, gold), chacune ajoutant un niveau de transformation, de qualité et d’activabilité. Popularisée par Databricks, elle est aujourd’hui copiée par Snowflake, BigQuery, Microsoft Fabric et même par l’écosystème open source (DuckLake, Iceberg, Delta).

Concrètement, voici ce que ça résout:

• Le data lake brut devenait un cimetière de fichiers JSON et Parquet inexploitables.
• Le data warehouse monolithique ne supportait ni le machine learning, ni le streaming, ni la donnée non-structurée.
• Le lakehouse est né de cette convergence, mais sans cadre, il reproduisait le chaos du lake.

La médaillon est ce cadre.

La vraie valeur n’est pas technique: c’est un contrat d’équipe. Quand tu dis « cette table est silver », tout le monde sait ce qu’elle contient et ce qu’elle ne contient pas. Quand tu dis « cette table est gold », tu sais qu’elle est activable par le métier. C’est ce qui rend le code lisible, le lineage traçable, et l’évolution des sources supportable.

Le rôle des trois couches en une phrase chacune

Bronze: la donnée brute, jamais touchée

Réplication fidèle des sources. Aucune transformation métier. Immuable. Sert de rejouable historique.

Silver: la donnée propre, agnostique, qui sépare les systèmes

Nettoyée, dédupliquée, standardisée. Modélisée système par système, sans croisement inter-sources. Aucune logique métier.

Gold: la donnée activable, orientée cas d’usage

Agrégations, KPIs, tables prêtes pour la BI, le reverse ETL et le machine learning. Une table = un cas d’usage.

Bronze: la couche des données brutes, celle qu’on ne touche jamais

La couche bronze layer raw est ton point d’entrée. Son rôle est simple: répliquer fidèlement les données sources dans ton warehouse, sans aucune transformation métier. Pas de validation, pas de jointure, pas de déduplication. Juste un dump brut, versionné, immuable.

Pourquoi cette rigueur? Parce que la bronze layer est ton filet de sécurité. Si une transformation silver se casse, si un modèle DBT introduit un bug, si un use case gold change de définition, tu peux toujours repartir de la raw data d’origine. C’est ton rejouable historique.

En pratique, la bronze contient:

• Des fichiers Parquet, Delta ou Iceberg stockés sur S3, ADLS ou GCS.
• Des métadonnées d’ingestion (timestamp, source d’origine, schéma brut).
• Des données partitionnées par date ou par source pour optimiser les lectures.
• Eventuellement du CDC (Change Data Capture) pour minimiser le volume réinjecté.

Les outils d’ingestion typiques:

• Batch: Fivetran, Airbyte pour les sources SaaS standards.
• Streaming: Auto Loader (Databricks), Kafka, Structured Streaming Spark pour les flux temps réel.
• CDC: Debezium, Airbyte CDC pour ne répliquer que les deltas.

Règle d’or: ne jamais modifier la bronze. Si tu as besoin de « corriger » une donnée, fais-le en silver ou en gold. La bronze reste un témoignage fidèle de ce que tes sources t’ont envoyé.

Silver: la couche propre, agnostique, qui sépare les systèmes

La couche silver layer est le coeur de l’architecture medallion. C’est ici que tu nettoies, dédupliques, standardises et modélises tes données. Mais avec une règle d’or documentée chez Swile et Ornicar: les systèmes sources ne se croisent pas en silver.

Concrètement, si tu as un système CRM et un système de facturation, tu auras:

• Un modèle silver pour le CRM (clients, contacts, opportunités).
• Un modèle silver pour la facturation (invoices, lignes de facture, paiements).
• Pas de jointure entre les deux à ce stade.

Pourquoi? Parce que chaque système évolue indépendamment. Si le CRM change de schéma, tu ne veux pas que ça casse tes modèles de facturation. Si la facturation ajoute un nouveau type de document, tu ne veux pas réécrire tes modèles CRM. La silver layer doit être agnostique: elle prépare la donnée pour le croisement, mais elle ne le fait pas encore.

Les transformations typiques en silver:

• Typage: forcer les types (string → timestamp, string → numeric).
• Normalisation: unités, formats de date, casse.
• Déduplication: identifier la ligne la plus récente via une clé métier.
• Conformage: renommer les colonnes selon des conventions stables (`birth_date` partout, pas `date_of_birth` à un endroit et `birth_date` à un autre).
• Nettoyage: valeurs nulles, codes erreur, formats incohérents.

DBT est l’outil de référence pour construire la silver. Tu écris du SQL, tu versionnes dans Git, tu testes automatiquement, tu déploies via CI/CD. Chez Cover (startup assurance belge), ça représente plus de 1000 modèles DBT en production.

Règle d’or: la silver layer ne contient aucune logique métier, aucun KPI, aucun croisement inter-sources. Si tu calcules un chiffre d’affaires, tu n’es pas en silver, tu es en gold.

Gold: la couche des KPIs, des dashboards COMEX et des modèles ML

La couche gold layer est la seule que le métier voit. C’est ici que tu croises les systèmes, que tu calcules des KPIs, que tu construis des tables prêtes pour la BI, le reverse ETL et le machine learning.

La règle d’or de la gold layer: une table = un cas d’usage. Si tu as besoin d’un dashboard COMEX sur le MRR, tu crées une table `gold_mrr_daily`. Si tu as besoin d’un modèle de churn, tu crées une table `gold_churn_features`. Pas de table « fourre-tout » avec 50 colonnes et 10 cas d’usage mélangés.

Pourquoi cette rigueur? Parce que:

• Les analysts savent exactement quelle table requêter pour quel use case.
• Le lineage est simple: la table gold dépend de quelques tables silver, traçables.
• L’évolution est plus facile: si le use case change, tu ne casses pas les autres tables gold.
• Les tests sont ciblés: tu valides un use case métier précis, pas une agregation générique.

Les sortants typiques de la gold layer:

• BI: Looker, Metabase, Omni, Tableau, Power BI.
• Reverse ETL: Hightouch, Census pour synchroniser les données dans Salesforce, HubSpot, etc.
• Machine learning: features engineering, datasets d’entraînement.
• Semantic layer: Cube, dbt Semantic Layer pour exposer des métriques standardisées.
• Livrables clients: cas Cover avec Revolut et Mastercard (voir section suivante).

Variante terrain: la couche gold comme livrable client (cas Cover)

Chez Cover (startup assurance belge, 1000+ modèles DBT en production), la gold layer a une particularité: ce sont des livrables clients contractuels. Pas du BI interne. Des fichiers de facturation, des reporting partenaires, des bordereaux qui sortent de l’entreprise et qui alimentent des clients comme Revolut ou Mastercard.

Concrètement, ça change trois choses:

1. 1 table gold = 1 délivrable contractuel. La table `gold_invoice_revolut_q3_2026` est un livrable précis, avec un schéma figé, testé unitairement. Si elle se casse, Revolut reçoit une donnée fausse.
2. Tests DBT ultra-précis. Chaque délivrable a ses propres tests: complétude, conformité au schéma, règles métier (montant HT = montant TTC – TVA, etc.). Une erreur ici sort de l’entreprise.
3. CI/CD obligatoire. Avec plus de 1000 modèles DBT, un workflow automatique avant mise en prod est non-négociable. Pas de déploiement manuel, pas de « ça marchera en prod ».

Et l’astuce technique qui change tout: la Row-Level Security BigQuery. Cover a remplacé N dashboards clients (un par partenaire) par 1 dashboard unique avec filtrage par colonne `partner`. Revolut ne voit que les lignes où `partner = ‘Revolut’`, Mastercard ne voit que les siennes.

-- Principe RLS BigQuery\n-- Table gold_invoice avec colonne "partner"\n-- Groupe user "revolut_analysts" → accès uniquement aux lignes partner = 'Revolut'\n-- Résultat : 1 maintenance au lieu de N

C’est exactement le niveau d’exigence qu’impose un contexte client-facing: la data quality n’est pas un nice-to-have, c’est une condition de survie commerciale.

Implémenter la médaillon sur les 5 plateformes qui comptent en 2026

En 2026, tu as 5 choix de plateformes majeurs pour implémenter une médaillon. Voici le comparatif honnête, basé sur les retours terrain et les sommets Databricks / Snowflake 2025.

Mon conseil honnête: les 3 grandes plateformes (Databricks, Snowflake, BigQuery) font exactement la même chose en 2026. Le choix dépend de ton écosystème existant (GCP, Azure, AWS), de l’appétence de tes équipes, et des intégrations natives dont tu as besoin. DuckLake est l’alternative open source à surveiller de près si tu veux réduire les coûts warehouse.

Les 5 anti-patterns qui plombent 90% des implémentations

Après avoir analysé des dizaines d’implémentations, voici les 5 anti-patterns qui plombent la majorité des projets médaillon. Si tu en repères un dans ton équipe, corrige-le avant qu’il ne coûte cher.

Anti-pattern 1: faire de la logique métier en silver

C’est le piège classique. Tu te dis « je vais calculer le chiffre d’affaires ici, ça sera plus simple ». Sauf que tu pollues la couche silver avec une logique qui dépend du métier, qui va évoluer, et qui va casser le lineage. La silver layer doit rester agnostique. Les KPIs vont en gold, pas avant.

Anti-pattern 2: modéliser bronze comme un schéma en étoile

La bronze n’est pas un modèle, c’est un dump. Si tu commences à créer des tables de faits et des tables de dimension en bronze, tu perds l’agilité. La bronze doit être proche du format source, partitionnée par date ou par source, avec un schéma aussi brut que possible.

Anti-pattern 3: tout rebuild en silver dès qu’une source change

Si une source change de schéma, ne rebuild pas toute la silver. Identifie l’incrément impacté, corrige-le, et garde l’historique. C’est tout l’intérêt de la bronze immuable: tu peux toujours comparer l’ancienne et la nouvelle validation sans perdre le rejouable.

Anti-pattern 4: 15 couches intermédiaires « au cas où »

Bronze, silver_cleaned, silver_enriched, silver_v2, gold_staging, gold_final, gold_v2_final… STOP. 3 couches, c’est 3 couches. Si tu as besoin d’une couche intermédiaire, c’est que tu n’as pas bien séparé les responsabilités. L’over-engineering génère de la dette, pas de la quality.

Anti-pattern 5: gouvernance absente, métadonnées de lineage non versionées, pas de tests sur silver

Tu as 1000 modèles DBT, zéro test, et tu ne sais pas qui a modifié quoi la semaine dernière. Bienvenue dans l’enfer de la dette technique. La governance n’est pas un luxe, c’est une condition de scalabilité. Tests sur silver, metadata versionnées, lineage tracé, alerting sur les échecs de pipeline.

Bronze, silver, gold: qui est responsable de quoi

L’architecture médaillon n’est pas qu’un pattern technique. C’est un contrat d’équipe. Et comme tout contrat, il faut définir qui est responsable de quoi.

Voici le modèle de responsabilité qui marche chez Swile (4 produits suivis en médaillon: titre restaurant, cadeau, mobilité, Swile Travel):

Ce modèle BI Core vs BI Activation évite le chaos organisationnel. Sans séparation claire, tu te retrouves avec 5 équipes qui construisent la même table gold de 3 façons différentes.

Le design médaillon aide à clarifier qui est responsable de quoi dans la chaîne de la donnée.

Coûts, performance et limites: ce que personne ne dit sur la médaillon

Soyons honnêtes: l’architecture médaillon a un coût. Et c’est ton job de le maîtriser.

Le vrai coût: on stocke 3 couches

Bronze + silver + gold = 3x le volume d’un warehouse monolithique. C’est le prix de l’immuabilité et de la séparation des responsabilités. Pour le justifier auprès de la finance, tu as trois arguments:

1. Réduction du Time to Insight: moins de temps perdu à comprendre la donnée, plus de temps à créer de la valeur.
2. Réduction des risques: tu peux rejouer l’historique, tu peux auditer, tu peux corriger sans casser.
3. Réduction de la dette technique: le code est plus lisible, le lineage est plus simple, l’onboarding est plus rapide.

Fréquence d’ingestion par couche

Règle empirique observée sur le terrain:

• Bronze: temps réel ou micro-batch (5-15 min) pour capturer les changements au plus tôt.
• Silver: horaire ou quotidien selon les volumes. Pas besoin de temps réel si le use case n’est pas temps réel.
• Gold: quotidien pour les dashboards COMEX, temps réel pour les use cas critiques (fraude, pricing dynamique).

Streaming vs batch: le bon compromis

Le streaming coûte cher (compute, storage, complexité). Le batch coûte moins cher mais a plus de latence. Le compromis gagnant en 2026: CDC (Change Data Capture) en bronze pour minimiser le volume réinjecté, puis transformations incremental en silver et gold.

Quand NE PAS adopter la médaillon

Soyons honnêtes: si tu as 2 data engineers, 3 sources SaaS, et un use case BI basique, la médaillon est overkill. Tu n’as pas besoin de 3 couches, tu n’as pas besoin de DBT avec 1000 modèles, tu n’as pas besoin de streaming. Commence par un warehouse simple, valide ton use case, puis complexifie si nécessaire.

Médaillon vs autres patterns: data mesh, star schema, data vault

L’architecture médaillon n’est pas exclusive. Elle coexiste avec d’autres patterns. Voici comment les articuler.

Médaillon vs data mesh

Le data mesh est un pattern d’architecture organisationnelle: les domaines métiers sont responsables de leurs propres données (data products, data contracts, federated governance). La médaillon est un pattern technique de structuration interne d’un domaine. Les deux sont complémentaires: tu peux avoir un data mesh où chaque domaine implémente sa médaillon en interne.

Médaillon vs star schema

Le star schema (table de fait + tables de dimension) est un pattern de modélisation. Il a sa place en gold, pas avant. Si tu fais du star schema en bronze, tu perds l’agilité. Si tu fais du star schema en silver, tu mélanges de la logique métier trop tôt. Le star schema est un model de sortie, pas un model de stockage intermédiaire.

Médaillon vs data vault

Le data vault est un pattern d’architecture conçu pour l’auditabilité et la traçabilité réglementaire (banque, assurance, santé). Plus complexe que la médaillon, il cible les grands groupes avec des contraintes de conformité fortes. La médaillon est plus simple, plus rapide à implémenter, et suffisante pour 90% des cas d’usage business.

Ma conviction: la médaillon n’est pas un remplacement du star schema, c’est un cadre de progression de la quality. Tu progresses du bronze (brut) vers le gold (activable), en passant par le silver (propre). Le star schema est une des formes que peut prendre la gold.

Checklist: implémenter la médaillon en 90 jours sans se planter

Tu veux te lancer? Voici la timeline réaliste basée sur les retours terrain (Modeo, Cover, Swile).

Jours 1-15: cadrage et choix plateforme

• Identifier les sources prioritaires (2-3 max pour démarrer).
• Choisir la plateforme (Databricks, Snowflake, BigQuery, Fabric, DuckLake) selon l’écosystème existant.
• Définir les conventions de nommage (préfixes, dossiers DBT, structure de fichiers).
• Identifier le premier use case (suivi financier MRR/ARR recommandé).

Jours 15-45: socle technique

• Setup du warehouse + ingestion (Fivetran, Airbyte, Auto Loader).
• Setup DBT avec tests + CI/CD.
• Setup orchestration (Airflow, Dagster, dbt Cloud).
• Construction des premières tables bronze et silver.

Jours 45-90: premier use case de bout en bout

• Construction des tables gold pour le use case MRR/ARR.
• Connexion BI (Looker, Metabase, Omni).
• Documentation minimale (README, lineage, owners).
• Validation par le métier (Finance, Direction).

Après 90 jours: empiler les use cases

Une fois le socle en place, les use cases suivants capitalisent sur la même base. Tu peux espacer de 6 à 12 mois entre chaque vague, selon les priorités business. Pas besoin de tout faire en même temps.

Conclusion: la médaillon, un contrat d’équipe plus qu’un pattern technique

L’architecture médaillon n’est pas un schéma de plus. C’est un contrat d’équipe. Bronze = brut, silver = propre et agnostique, gold = activable. Quand tout le monde respecte ces frontières, le code est lisible, le lineage est traçable, et l’évolution des sources est supportable.

En 2026, le vrai différenciant n’est pas de savoir si tu fais bronze/silver/gold. C’est de savoir qui construit quoi (BI Core vs BI Activation), avec quels tests (CI/CD, DBT tests), et avec quelle governance (metadata versionnées, lineage tracé). Le pattern est facile. L’exécution est ce qui sépare les plateformes qui scalent de celles qui s’enlisent.

Si tu veux creuser le sujet, j’ai une chaîne YouTube où je décortique des implémentations terrain (streaming médaillon, lakehouse multi-engines, convergence Delta/Iceberg). Et si tu veux suivre l’aventure, abonne-toi!

Si tu veux suivre l’aventure, abonne-toi !