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.
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", "fiable" et "métier" dans les mêmes tables.
Bronze
Pour faire simple, la couche Bronze sert à une seule chose : ne rien perdre.
Tu ingères la donnée comme elle arrive, en ajoutant le strict minimum pour pouvoir le reload et l'auditer comme par exemple ajouter une date d’ingestion, la source, fichier/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.
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....
À la fin, tu as une table “stock” fiable, réutilisable.
Gold
Là, tu exposes des tables prêtes à consommer, avec les indicateurs attendus, par exemple :
- Stock actuel par jour et par magasin et par produit
- Top produits en tension (stock faible)
- etc...
Erreurs à éviter (celles qui te coûtent cher)
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.
