Qu’est-ce que l’architecture medallion ? Couches Bronze, Silver et Gold expliquées

Architecture medallion vs. pipelines ETL traditionnels

Dans un entrepôt de données avec des pipelines d’extract-transform-load (ETL) classiques, vous devez définir le schéma des données en amont. Si le format ou le schéma évolue, le système échoue sauf ajustement manuel. 

Dans une architecture extract-load-transform (ELT) basée sur medallion, vous stockez d’abord les données brutes, au lieu de les transformer à la volée et d’enregistrer uniquement le résultat final. Cette différence rend l’approche medallion à la fois robuste et flexible : vous pouvez conserver les données brutes telles quelles et décider plus tard comment les utiliser. 

Pour une comparaison détaillée des deux concepts, nous vous recommandons de lire notre guide ETL vs ELT.

Autre atout : la nature agnostique de l’architecture medallion. Bronze, Silver et Gold sont des étapes logiques, pas des technologies liées à un éditeur. Vous pouvez l’implémenter avec différents systèmes de stockage, moteurs de traitement et formats de table, selon votre plateforme et vos exigences de charge.

Comment fonctionnent les couches Bronze, Silver et Gold dans une architecture medallion ?

Les trois couches s’enchaînent logiquement, chacune s’appuyant sur la précédente.

Couche Bronze : les données brutes comme point de reprise

C’est là que les données brutes atterrissent telles quelles : bases relationnelles, applications SaaS comme Salesforce, topics Kafka d’événements en temps réel, API REST, exports CSV ou flux d’objets connectés. L’ingestion est souvent gérée par des outils comme Fivetran pour la capture des changements ou Databricks Auto Loader pour les fichiers déposés dans un stockage objet.

Les données Bronze contiennent généralement des erreurs, incohérences et doublons ; elles ne doivent donc jamais être utilisées directement à des fins métier. Cela dit, cette couche est très précieuse comme point de reprise à partir duquel régénérer Silver ou Gold.

L’importance de cette couche tient à son empreinte : elle enregistre chaque événement ou transaction d’ingestion. Elle contient souvent des métadonnées utiles, telles que les horodatages d’ingestion, l’origine des données et divers identifiants. L’objectif est de stocker les données aussi brutes et complètes que possible, afin de rejouer les pipelines aval avec la même source pour diagnostiquer les anomalies.

Couche Silver : la couche « contrat »

La couche Silver transforme les données brutes en données propres et structurées. Exemples de transformations de nettoyage essentielles entre Bronze et Silver :

• Filtrer les colonnes inutiles
• Dédupliquer les enregistrements
• Corriger les incohérences
• Gérer les valeurs manquantes
• Standardiser les données
• Joindre et fusionner différents jeux de données

Cette couche applique aussi une contrainte de schéma, garantissant le respect d’une structure prédéfinie et l’évolution du schéma. 

C’est également ici que vous mettez en place des contrôles de qualité. Par exemple, des règles pour signaler ou rejeter des transactions métier en échec ou des valeurs aberrantes. C’est la première étape d’amélioration de la qualité au fil des étapes.

Comme cette étape modifie les données, il est essentiel d’utiliser des outils de traçabilité comme dbt pour suivre les transformations de Bronze à Silver. Les contrôles qualité s’implémentent souvent avec des tests dbt, Great Expectations ou Soda, tandis que la gouvernance est assurée via un catalogue de données tel que Databricks Unity Catalog ou Collibra.

Pour apprendre à transformer des données « sales » en jeux Silver conformes, nous vous conseillons notre cours Cleaning Data in Python.

Couche Gold : des sorties prêtes pour le métier

La couche finale stocke des données au niveau de qualité maximal. Ces données très affinées servent au reporting dans Power BI, Tableau ou Looker, sont consommées par des applications analytiques aval, ou alimentent des modèles de machine learning via un feature store comme Feast ou Databricks Feature Store.

Puisque les données sont déjà nettoyées, on se concentre ici sur leur transformation en véritable actif métier. Selon le cas d’usage (rapports financiers, tableaux de bord marketing, systèmes d’alerte, entraînement ML, …), les transformations après Silver garantissent que Gold contient exactement l’information nécessaire.

C’est ici que vous créez des KPI, appliquez des formules métier spécifiques, ou agrégez en hebdomadaire, mensuel ou trimestriel pour un reporting planifié. Alors que Bronze et Silver restent souvent communs, les opérations en Gold sont plus souples et adaptées à l’usage visé.

Comment reconstruire Silver et Gold à partir de Bronze ?

Conserver les données brutes en Bronze ne paie que si vous pouvez effectivement les réutiliser, ce qui arrive dès qu’un élément en amont ou en aval change. Le coût d’un changement dépend de sa position dans la chaîne. 

• Une modification du schéma source implique de rejouer Bronze vers Silver puis Gold. 
• Une évolution d’une définition métier (p. ex. nouvelle règle de revenu, autre fenêtre d’agrégation) implique seulement de reconstruire Gold à partir d’un Silver déjà validé.

Dans aucun des cas vous ne retournez au système source. C’est ce qui rend possibles les corrections historiques, la source ne détenant plus nécessairement les données dans l’état d’origine.

Cela signifie aussi que vous pouvez changer une définition de métrique sans relancer l’ingestion, raison pratique pour laquelle les équipes avec de nombreux consommateurs Gold maintiennent des couches séparées.

Où s’inscrit l’architecture medallion dans un data lakehouse ?

Un data lakehouse offre le stockage objet économique d’un lac et les garanties transactionnelles d’un entrepôt. Il ne dit rien de l’agencement interne des tables. C’est là que medallion intervient : le lakehouse est le substrat de stockage, et Bronze, Silver et Gold sont la manière de le diviser en catalogues, schémas et tables assortis de garanties de qualité différentes.

En pratique, cette division est souvent physique. Sur Databricks, vous pouvez avoir trois schémas dans un catalogue Unity Catalog, et sur Microsoft Fabric, un lakehouse avec des tables Bronze et Silver alimentant un entrepôt Gold. Même modèle, plomberie différente.

Les formats de table ouverts garantissent la tenue des couches face aux lectures/écritures concurrentes. Delta Lake, Apache Iceberg et Apache Hudi offrent notamment :

• Transactions ACID
• Évolution de schéma
• Versionnage de l’état des tables
• Contrôle de concurrence
• Évolution de partitions
• Time travel

Le versionnage est crucial pour le comportement de relecture évoqué ci-dessus. De simples fichiers Parquet conservent la source, mais sans historique transactionnel pour revenir en arrière : un mauvais run Silver écrase le bon, sans point de comparaison. Delta Lake suit les changements via un journal des transactions, tandis qu’Apache Iceberg représente l’état des tables par snapshots.

Rien de tout cela n’est obligatoire. Medallion est un modèle logique, et nombre d’équipes l’exécutent sur des schémas Postgres ou de simples préfixes S3 avec dbt par-dessus. Vous perdez juste le retour arrière à moindre coût.

Architecture medallion vs data mesh

On les compare souvent à tort, en pensant qu’elles se concurrencent. Elles répondent à des questions différentes : data mesh décide qui possède les données, et l’architecture medallion décide comment ce propriétaire les affine.

Data mesh confie la responsabilité des données aux équipes de domaine (ventes, finance, supply chain…), qui publient des données comme des produits et en assurent qualité, découvrabilité, traçabilité et gouvernance. Deux éléments cimentent le tout : une infrastructure en libre-service donnant les mêmes outils à chaque domaine, et une gouvernance fédérée fixant des standards à l’échelle de l’entreprise sans retirer la propriété aux domaines.

L’architecture medallion est ce qu’une équipe de domaine exécute dans son périmètre. Une équipe supply chain propriétaire des données d’expédition garde les événements bruts en Bronze, les enregistrements validés en Silver, et publie en Gold des jeux prêts pour l’analyse, consommables par d’autres domaines. Le mesh définit le contrat à la frontière Gold ; tout l’amont relève de l’équipe.

Un bémol : des couches Bronze par domaine signifient que chaque domaine porte ses coûts d’ingestion et de stockage, et que des dimensions partagées (client, produit…) se reconstruisent souvent à plusieurs endroits. Les partisans du mesh diront que c’est le prix de la propriété. C’est un coût réel, à chiffrer avant de s’engager.

Atouts et limites de l’architecture medallion

Medallion vous apporte la réutilisation et la récupérabilité, au prix d’un surcoût de stockage, de latence et de nombre de pipelines. L’intérêt de ce compromis dépend presque entièrement du nombre de consommateurs.

La latence est le point le plus souvent sous-estimé. Chaque couche correspond généralement à un job planifié : un pipeline batch en trois couches exécuté toutes les heures peut laisser Gold avec deux heures de retard sur la source. Acceptable pour un rapport hebdomadaire de revenus, insuffisant pour une alerte opérationnelle : d’où le fait que l’alerte lise souvent directement en Silver sans attendre Gold.

Le stockage est la première crainte évoquée, mais c’est souvent le moindre problème. Bronze vit dans un stockage objet bon marché, et la duplication est réelle mais contenue. Le nombre de pipelines est ce qui fait mal : trois couches pour vingt tables sources, ce sont soixante éléments susceptibles d’échouer à 3 h du matin.

Face à cela, la mauvaise qualité des données a sa propre facture. IBM rapportait en 2026 que 43 % des COO citaient la qualité des données comme priorité n°1, sur la base de recherches de 2025 de son Institute for Business Value. Plus d’un quart des organisations de cette étude signalaient des pertes annuelles liées à la qualité dépassant 5 millions de dollars.

La question n’est donc pas de savoir si une architecture medallion coûte plus cher qu’un pipeline unique — c’est le cas. La question est de savoir si vous ne payez pas déjà l’alternative en réunions de réconciliation et en tableaux de bord auxquels personne ne fait confiance.

Quand utiliser l’architecture medallion ?

Medallion est rentable quand les mêmes données nettoyées servent plusieurs consommateurs. C’est le meilleur prédicteur, devant le volume, la taille de l’équipe ou le nombre de sources.

Utilisez l’architecture medallion lorsque :

• Plusieurs équipes ou charges lisent les mêmes données. Nettoyez et standardisez une fois en Silver, puis construisez autant de jeux Gold que nécessaire pour la BI, le reporting ou l’entraînement de modèles.
• Des questions métiers différentes exigent des vues différentes des mêmes données. La finance veut le revenu reconnu mensuel, les ventes les bookings quotidiens par commercial. Les deux partent d’une table Silver, sans dupliquer l’ingestion.
• Vos sources se contredisent. Silver est l’endroit où vous rapprochez un ID de compte Salesforce d’un ID client du système de facturation, avant que l’aval ne doive deviner la source de référence.
• Vous devez justifier un chiffre. Séparer brut, validé et curé permet de remonter un chiffre contesté à travers chaque transformation, au lieu de le recalculer.
• La logique de transformation évolue souvent. Comme vu plus haut, la couche Bronze conservée permet de reconstruire sans revenir à la source.

Évitez si :

• Votre équipe data est réduite et la complexité des pipelines limitée.
• Les données proviennent d’une seule source avec peu de nettoyage/transformations.
• Une seule application ou équipe aval consomme les données.
• Vos besoins de reporting sont simples et ne justifient pas plusieurs couches de traitement.

Quand deux couches suffisent

Le schéma en trois couches est un défaut utile, pas une obligation. Avec un seul cas d’usage métier, Bronze + une couche combinée est souvent le bon choix : préserver le brut pour rejouer, puis faire nettoyage et logique métier en une étape.

Choisissez la forme qui correspond à vos consommateurs. Ce qu’il ne faut pas fusionner, c’est Bronze, car cette couche est irréplicable.

Si vous hésitez, bâtir deux couches et ajouter la troisième quand un deuxième consommateur arrive est une bonne voie. Ajouter Gold plus tard coûte bien moins cher que rétro-installer Bronze après six mois d’écrasement des données brutes.

Erreurs courantes lors des implémentations medallion

La plupart des problèmes ne sont pas architecturaux. Ce sont de petits compromis pris sous la pression des délais qui sapent la raison d’être des couches.

Transformer les données en Bronze

L’argument du rejouement repose sur une Bronze proche de ce qu’a réellement émis la source. Si vous appliquez une logique métier avant l’atterrissage, vous perdez l’état d’origine : plus de re-traitement possible, ni de piste d’audit.

Cela arrive souvent pour de bonnes raisons. On supprime une colonne jugée inutile pour économiser de la place, ou on force un champ d’horodatage brouillon à l’ingestion parce qu’il casse l’étape suivante. Six mois plus tard, la colonne « inutile » devient clé et les valeurs d’origine ont disparu. Gardez Bronze au plus près de la source, et mettez les correctifs en Silver.

Flouter la frontière Silver/Gold

Silver nettoie et standardise. Gold répond aux questions métier. Quand la logique des métriques fuit en Silver, chaque jeu Gold hérite d’une définition non souhaitée, et vous revenez au problème que medallion devait résoudre.

Le test est simple : si un utilisateur métier conteste un chiffre, cela relève de Gold. La déduplication est un sujet Silver. La définition d’un client actif ne l’est pas.

Considérer trois couches comme obligatoires

L’architecture medallion est un modèle logique, pas l’exigence que chaque pipeline comporte exactement trois couches physiques. Bronze, Silver et Gold représentent des stades logiques d’affinage, et chaque couche peut être mise en œuvre différemment selon la charge. 

Par exemple, une couche peut s’appuyer sur des tables matérialisées, des vues ou d’autres abstractions, plutôt que d’imposer une copie physique distincte. L’objectif est de créer des frontières utiles au fil du passage de l’état brut à un actif fiable pour le métier, pas de reproduire à l’identique le diagramme en trois couches.

Laisser Gold devenir un fourre-tout

C’est l’écueil le plus fréquent et le moins évoqué. Créer des jeux Gold coûte peu, et personne ne les supprime. Au bout d’un an, vous pouvez vous retrouver avec quarante tables, dont onze variantes du revenu mensuel, sans que l’on sache laquelle regarde le CFO.

Silver a une discipline naturelle car sa mission est claire. Gold non : il faut donc un propriétaire par jeu et l’acceptation de supprimer. Sans cela, vous finissez avec plusieurs versions concurrentes d’une même métrique — précisément ce que les couches devaient éviter.

Dernières réflexions

Ce que medallion vous donne vraiment, c’est un endroit à montrer quand on vous demande d’où vient un chiffre, et une copie des données d’origine quand la réponse s’avère erronée. Cela vaut le stockage et les jobs supplémentaires quand plusieurs équipes lisent les mêmes données. Quand une seule équipe est concernée, deux couches peuvent être plus adaptées et alléger la maintenance.

Pour replacer ce modèle dans son contexte, notre cours Understanding Modern Data Architecture couvre les plateformes et technologies des data stacks modernes. Notre Data Engineer career track va plus loin sur la construction et la maintenance de pipelines de production.