L'architecture medallion, expliquée avec mes mots (bronze, silver, gold)

Quand j’ai commencé à lire sur l’architecture medallion, la première question que je me suis posée était simple : pourquoi ne pas juste nettoyer les données une bonne fois et les mettre quelque part ? La réponse tient en un mot : traçabilité. Si on écrase les données brutes dès la première transformation, on perd la capacité de revenir en arrière quand une règle de nettoyage s’avère fausse six mois plus tard.

Le principe en trois couches

L’idée de l’architecture medallion est de séparer un pipeline en trois étapes, chacune avec un rôle précis.

Bronze. C’est la copie brute des données sources, telle quelle. Aucune transformation, aucune correction de type, aucun renommage de colonne. Sur mon projet autour du jeu de données DPE (diagnostics de performance énergétique) de l’ADEME, ça veut dire garder les noms de colonnes exactement comme ils apparaissent dans les CSV sources — espaces, casse incohérente entre les deux fichiers, tout. C’est contre-intuitif au début, mais c’est ce qui rend la couche bronze immuable et fiable comme point de référence.

Silver. C’est la couche où les données deviennent utilisables : typage correct, harmonisation des schémas, déduplication, jointures entre sources. Sur mon cas, les deux sources du DPE (logements neufs et logements existants) n’ont pas exactement le même schéma. La couche silver, c’est l’endroit où je fais converger ces deux schémas vers un format commun, en ne gardant que les colonnes pertinentes pour la suite plutôt que de tout dupliquer.

Gold. C’est la couche métier : des tables ou des vues agrégées, pensées pour un usage précis — dashboard, modèle ML, export. Une même couche silver peut alimenter plusieurs tables gold différentes selon les besoins.

Ce que ça change concrètement

Le vrai bénéfice, ce n’est pas la propreté du schéma final. C’est la reproductibilité. Si je découvre une erreur dans ma logique de nettoyage, je n’ai pas besoin de retélécharger les fichiers sources : je repars de la couche bronze, qui n’a jamais bougé, et je rejoue la transformation vers silver. Sur un pipeline avec des fichiers de plusieurs gigaoctets, cette différence compte.

Ça oblige aussi à documenter les décisions de transformation à un endroit précis (le passage bronze → silver) plutôt que de les éparpiller dans des scripts ad hoc. Pour moi qui découvre le sujet, écrire cette étape m’a forcé à formaliser des choix que j’aurais sinon pris “sur le moment” sans vraiment les justifier.

Où je bloque encore

Le partitionnement est le point sur lequel j’hésite le plus. Partitionner la couche silver par région ou par année de DPE optimise les requêtes Athena, mais le mauvais choix de clé de partition peut aussi créer des partitions trop petites ou trop déséquilibrées. Je n’ai pas encore assez de recul sur le volume réel de données par partition pour trancher définitivement — c’est le genre de décision que je referai probablement une fois que j’aurai des métriques de requêtes réelles sous les yeux.

Je détaillerai la mise en œuvre concrète (schémas PySpark, ingestion S3) dans un prochain article, et le projet complet est visible dans le portfolio.