Si tu t'intéresses un peu à la data, tu as forcément déjà vu passer le schéma Bronze / Silver / Gold. C'est surtout Databricks qui a popularisé ces noms et qui a mis l’étiquette “Medallion” dessus, mais en réalité le principe existe depuis longtemps, juste sous d'autres formes comme par exemple (extract → transform → load) ou (raw → cleaned → curated).

D'ailleurs, il y a un débat sur le mot "architecture". Certains vont dire que ce n'est pas une architecture, mais plutôt un modèle, certain vont dire que c'est plutôt un pattern ou une structure... bref peu importe. Le vrai sujet n'est pas vraiment le terme.

Le plus important, c'est de comprendre ce que ça veut dire concrètement, et surtout ce que ça change quand tu construis une stack data et donc savoir où stocker le brut, où fiabiliser, et où exposer une donnée réellement prête à être consommée par le métier.

Architecture en médaillon

L'architecture Médaillon, c'est juste une façon claire d'organiser une plateforme data ou tu assumes que la donnée passe par des états (bronze, silver, gold). Donc tu ne mélanges jamais "brut", et "métier" dans les mêmes tables.

Bronze

Pour faire simple, la couche Bronze sert à une seule chose, conserver toutes les données brutes sans rien perdre.

Tu ingères la donnée comme elle arrive, en ajoutant le strict minimum pour pouvoir le reloader et l'auditer comme par exemple ajouter une date d’ingestion, la source, le offset si besoin. Donc l'objectif est de faire des contrôles de base (schéma) pour isoler les cas invalides, sans transformer la donnée.

Pourquoi c'est indispensable ? Parce que le jour où tu dois corriger une règle, reconstruire une période, ou comprendre un bug, tu veux pouvoir repartir de ce que tu as reçu, pas d'une version déjà "nettoyée". Et si un jour tu dois faire un full reload mais que la source ne te donne plus l'historique, tu seras très content d'avoir ton brut stocké proprement.

En bref Bronze, c'est : “voilà exactement ce que j'ai reçu.”

Silver

Silver, c'est là où tu passes du brut à du fiable.

Ici tu fais tout ce qui rend la donnée propre et stable : typage (dates, nombres…), formats standard, suppression des doublons, lignes invalides, règles de cohérence, valeurs manquantes gérées… bref, la base.

Le but de Silver, ce n'est pas le reporting mais d'avoir une donnée réutilisable pour plusieurs usages, sans refaire les mêmes corrections partout.

Et souvent, c'est aussi ici que tu gères l'incrémental car tu ne fais pas juste un append. Tu prends le delta (les nouvelles lignes, les mises à jour, parfois les suppressions) et tu mets à jour la table correctement.

Si tu dois arbitrer où mettre ton énergie, c'est ici. Parce qu'une Silver solide te fait gagner du temps partout dans la BI, data science ...

Gold

Gold, c'est ce que le métier consomme.

Ici, tu assumes la partie business donc les KPI, agrégats, tables prêtes pour les dashboards BI (qlik sense, power bi ...), bref des datasets qui ont un sens clair (sales, finance, marketing…) et une définition stable.

L'idée, c'est que la BI et les analyses doivent pointer sur cette zone, pas sur du brut ou du semi-propre. Comme ça, tout le monde a les mêmes chiffres, avec les mêmes règles.

Et c'est aussi là que tu commences à raisonner en data product car une table Gold n'est pas “juste une table finale”. C'est un produit data, avec un périmètre clair, un owner, une définition (glossaire), et une qualité attendue.

Tableau comparatif Bronze vs Silver vs Gold

Couche But Transformations Qualité attendue
Bronze Conserver le brut + audit Minimales (métadonnées d’ingestion) Contrôles de base (schéma, champs)
Silver Rendre fiable + réutilisable Typage, standardisation, dédoublonnage, gestion des nulls, incrémental etc... Stable et cohérente
Gold Servir le métier Agrégats, KPI, datasets orientés usages Ready pour la BI + définitions stables

Exemple concret

Comme d'habitude dans les articles du blog, y'a pas mieux d'un exemple pour comprendre le concept. On prend un cas simple, dans le quel chaque magasin envoie l'état de stock (produit, quantité) plusieurs fois par jour.

L’objectif reste le même : Bronze = je garde tout, Silver = je fiabilise, Gold = je sers le métier.

Bronze

Tu stockes les fichiers tels qu’ils arrivent en ajoutant le strict minimum pour auditer comme par exemple date d'ingestion, source.
Si un fichier est incomplet ou mal formé, tu le mets de côté, tu ne casses pas toute l'ingestion.

Silver

Tu mets au propre :

  • Produits et magasins bien identifiés (mapping des codes)
  • Quantités en nombre, dates au bon format
  • Suppression des doublons (si le même fichier arrive deux fois)
  • Si le magasin renvoie une mise à jour, tu prends la plus récente
  • etc....

Gold

Là, tu exposes des tables prêtes à consommer, avec les indicateurs attendus, par exemple une table gold qui contient le stock actuel par jour et par magasin et par produit.

Erreurs à éviter (celles qui te coûtent cher)

Erreurs à éviter

Comme pour n'importe quel outil, une mauvaise utilisation peut vite le transformer en problème. Et ce que je liste ici, ce ne sont que quelques exemples parmi les plus fréquents.

La première erreur, c'est d'ignorer la conformité des données et donc pas de contrôle de schéma, pas de règles de base, pas de checks qualité sur ce qui entre en raw. Et c'est simple ==> mauvaise data en entrée = mauvaise data en sortie.

Deuxième erreur : mélanger Silver et Gold. Quand les équipes dupliquent les règles “métier” dans la Silver, ou quand la Gold devient une Silver bis, tu finis avec de la donnée dupliquée.. et des chiffres qui varient d'un dashboard à l'autre.

Troisième erreur et d'ignorer metadata et lineage. Sans traçabilité, tu ne sais plus d'où vient un chiffre, qui l'a transformé, ni quand ça a changé. Et sans gouvernance (accès, règles, périmètre), tu risques d'exposer des données sensibles ou instables.

Il ne faut pas oublier que les trois couches ne sont pas une religion. Si une transformation est légère et stable, elle peut très bien rester en Silver sans forcément créer une Gold dédiée. L'objectif, c'est la clarté et la qualité et donc pas systématiquement créer trois niveaux pour chaque source, même quand ce n'est pas nécessaire.

Si tu as d'autres points de vigilance, n'hésite pas à les partager en commentaire.

Implémenter Bronze/Silver/Gold dans Snowflake

Si tu veux passer du modèle à la pratique dans Snowflake, ces articles t’aident :

FAQ

Est-ce qu'il faut toujours 3 couches ?

Non. Comme mentionné dans ma conclusion, les trois couches ne sont pas une religion et si les transformations sont légères et stables, tu peux rester en Silver sans créer une Gold dédiée.

Où mettre les règles métier ?

En général, en Gold pour garder une Silver réutilisable et éviter la duplication.

Est-ce que Bronze doit être append-only ?

Idéalement oui car Bronze sert d'audit et log. Tu ajoutes des métadonnées, mais sans transformation.

Peut-on avoir plusieurs Gold ?

Oui car souvent une Gold par domaine métier (sales, finance, marketing etc...), avec des définitions stables.