Diagramme d'architecture médaillon : couches bronze, argent et or

Toute plateforme de données finit par devenir un marécage : cinq tables appelées orders, personne ne sait laquelle la finance utilise, et un tableau de bord cassé parce que quelqu'un a corrigé un bug en amont. L'architecture médaillon est une réponse simple à ce désordre. Elle organise un lakehouse en trois couches, bronze, argent et or, chacune avec un contrat clair sur le niveau de confiance de ses données et sur qui peut les utiliser.

L'idée est populaire parce qu'elle est facile à expliquer, et souvent mal appliquée pour la même raison. Cet article couvre ce que chaque couche contient et ce qu'elle ne doit pas contenir, la circulation des données entre elles, les contrôles de qualité, le retraitement, la gouvernance, les pièges courants et les cas où vous n'avez pas besoin du pattern, avec un diagramme à adapter.

Les trois couches en un coup d'œil

Le nom vient de Databricks, dont la documentation décrit les couches comme brute, validée et enrichie. En pratique :

Lisez les couches comme un contrat de qualité plutôt que comme un nombre d'étapes de traitement. Le bronze promet l'exhaustivité, l'argent l'exactitude, et l'or l'utilité pour un public nommé.

Bronze : tout garder, ne rien changer

C'est en bronze que les données brutes arrivent : fichiers du stockage objet, topics Kafka, flux de change data capture issus des bases opérationnelles, exports d'outils SaaS. Les règles :

• Ajout seul. Ne mettez jamais à jour ni ne supprimez d'enregistrements bronze dans le cadre du traitement normal.
• Analyse minimale. Databricks recommande de stocker la plupart des champs en bronze sous forme de chaînes, de variant ou de valeurs binaires, pour qu'un changement de schéma inattendu en amont ne fasse pas perdre de données.
• Ajoutez des métadonnées : heure d'ingestion, système source, nom de fichier ou offset de topic. Vous en aurez besoin pour le débogage et les rejeux.
• Conservez assez longtemps pour reconstruire. La rétention en bronze définit jusqu'où vous pouvez recalculer l'argent et l'or après une correction de bug.

Le bronze contient tout, y compris des données personnelles que vous regretterez peut-être d'avoir copiées. Limitez l'accès aux pipelines et envisagez de tokeniser ou de chiffrer les champs sensibles dès l'ingestion. Le diagramme de cartographie des données RGPD aide à suivre où circulent les données personnelles.

Argent : rendre les données exactes

L'essentiel de l'effort d'ingénierie se concentre sur l'argent :

• Analysez et typez les champs, normalisez les horodatages en UTC et standardisez les unités et les codes.
• Dédupliquez les enregistrements arrivés deux fois, ce qui arrive avec toute source au moins une fois.
• Appliquez les changements. Pour les sources de change data capture, fusionnez insertions, mises à jour et suppressions dans une table d'état courant.
• Harmonisez les clés pour qu'un client ait le même identifiant, qu'il vienne du CRM ou du système de facturation.
• Mettez en quarantaine au lieu de supprimer. Les lignes qui échouent à la validation vont dans une table de quarantaine avec la raison, là où quelqu'un peut les voir.

Un merge argent typique avec Delta Lake ou Apache Iceberg en Spark SQL ne garde que la dernière version de chaque commande :

MERGE INTO silver.orders AS t
USING (
  SELECT * FROM (
    SELECT *, ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY updated_at DESC) AS rn
    FROM bronze.orders_raw
    WHERE _ingested_at > '2026-11-01T00:00:00Z'
  ) WHERE rn = 1
) AS s
ON t.order_id = s.order_id
WHEN MATCHED AND s.updated_at > t.updated_at THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

Les règles de qualité de données ont leur place à cette frontière. Les pipelines Databricks, par exemple, les déclarent comme des expectations qui avertissent, suppriment les lignes fautives ou font échouer la mise à jour :

CREATE OR REFRESH STREAMING TABLE silver_payments (
  CONSTRAINT positive_amount EXPECT (amount > 0) ON VIOLATION DROP ROW,
  CONSTRAINT known_currency EXPECT (currency IN ('USD', 'EUR', 'GBP')) ON VIOLATION DROP ROW
)
AS SELECT * FROM STREAM(bronze_payments);

Quel que soit l'outil, rendez les règles visibles et comptez les lignes qu'elles rejettent.

Or : rendre les données utiles

Les tables or sont construites pour des consommateurs : un schéma en étoile pour le reporting financier, le chiffre d'affaires quotidien par région pour le tableau de bord de la direction, des features clients pour un modèle d'attrition. Chaque table or devrait avoir un propriétaire, une définition documentée et un objectif de fraîcheur. Les définitions d'indicateurs comme « client actif » ou « revenu net » ont leur place ici, écrites une fois, et non réimplémentées dans chaque tableau de bord.

L'or est aussi l'endroit où l'on dénormalise et agrège pour la vitesse. L'argent garde le détail ; l'or répond aux questions.

Batch, streaming ou les deux

Les couches n'imposent pas de latence. Chaque étape peut tourner en batch nocturne, en job incrémental horaire ou en flux continu avec checkpoints. Beaucoup d'équipes diffusent en streaming des sources vers le bronze et l'argent, pour que les données soient à jour en quelques minutes, et rafraîchissent les agrégats or à un rythme adapté à la fréquence de consultation. Traitez de manière incrémentale partout où c'est possible : ne lire que les nouvelles données bronze depuis la dernière exécution, c'est ce qui garde les coûts stables quand les volumes grandissent.

Retraitement et historique

Comme le bronze est immuable, un bug dans la logique de l'argent se rattrape : corrigez le code, reconstruisez depuis le bronze les partitions argent concernées, puis reconstruisez l'or. Les formats de table comme Delta Lake et Iceberg ajoutent des snapshots, pour interroger une table telle qu'elle était hier, auditer un changement ou annuler un mauvais chargement. Prévoyez-le dès le départ : gardez les transformations déterministes et partitionnez les tables pour que reconstruire un mois ne signifie pas tout reconstruire.

Gouvernance par couche

Placez chaque couche dans son propre schéma du catalogue, par exemple ops.bronze, ops.silver et ops.gold, l'organisation qu'utilise Databricks dans son propre exemple. Attribuez ensuite l'accès par couche : les pipelines écrivent le bronze, les ingénieurs et les analystes lisent l'argent, et la plupart de l'entreprise ne lit que l'or. Le lignage entre couches répond à la question que tout le monde pose pendant un incident : quels tableaux de bord dépendent de cette source cassée ?

Pièges

• Faire de trois une règle. Certaines sources demandent plus d'étapes, d'autres moins. C'est le contrat qui compte, pas le nombre d'étapes.
• De la logique métier en argent. L'argent doit être réutilisable par de nombreux consommateurs. La logique qui sert un seul rapport relève de l'or.
• L'or comme fourre-tout. Sans propriétaires, l'or se remplit de tables ponctuelles que personne n'entretient. Passez-les en revue et retirez-les.
• Tout copier trois fois. De gros jeux de données bruts stockés sous trois formes coûtent cher. Limitez l'argent aux colonnes et à l'historique réellement utiles.
• Sauter la quarantaine. Des lignes supprimées en silence, c'est ainsi que les chiffres dérivent sans que personne ne s'en aperçoive.

Quand le médaillon est superflu

Si vos données tiennent sans peine dans un entrepôt cloud et viennent d'une poignée de sources, vous n'avez peut-être pas besoin de lakehouse du tout. La convention dbt courante staging, intermediate et marts exprime la même idée de raffinement progressif à l'intérieur d'un seul entrepôt :

Les noms comptent moins que la discipline : des données brutes conservées intactes, une version propre de chaque entité, et des tables dédiées avec des propriétaires.

Le diagramme médaillon

Comment le lire :

• Les sources à gauche : des données de changement de Postgres, des événements de Kafka et un export du CRM.
• Trois cadres colorés représentent les couches. Le bronze contient des fichiers bruts, l'argent des tables nettoyées et un stock de quarantaine, l'or des tables métier.
• Les arêtes entre les cadres sont des étapes de pipeline, étiquetées selon ce qu'elles font : analyse, déduplication, merge, agrégation.
• Les consommateurs à droite : des tableaux de bord BI et un feature store pour le machine learning lisent uniquement l'or.
• Le bloc Markdown liste le contrat de chaque couche.

Dessiner des plateformes de données lisibles

• Colorez les couches. Bronze, argent et or se retiennent justement parce qu'ils sont visuels ; utilisez les couleurs.
• Étiquetez chaque étape avec son opération, pas seulement une flèche. « Dédupliquer et fusionner » indique à un relecteur où chercher un bug.
• Montrez qui lit quoi. L'accès par couche est une décision de conception, et le diagramme doit montrer clairement que les tableaux de bord ne lisent jamais le bronze.
• Faites figurer le chemin de quarantaine. Il montre aux relecteurs où vont les données rejetées.

Le pipeline plus large autour du lakehouse est traité dans le diagramme d'architecture de pipeline de données, les sources de streaming dans le diagramme d'architecture Kafka, et les consommateurs ML dans le diagramme d'architecture MLOps.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Ajoutez comme sources un nœud Postgres et un nœud Kafka du pack Données, ainsi qu'un Système externe du pack Modèle C4 pour le CRM.
3. Ajoutez trois nœuds Cadre du pack Base nommés Bronze, Silver et Gold, colorés en conséquence.
4. Dans le bronze, ajoutez un Magasin d'objets du pack Données pour les fichiers bruts. Dans l'argent, ajoutez un nœud Entrepôt de données pour les tables nettoyées et un Magasin d'objets pour la quarantaine. Dans l'or, ajoutez un autre nœud Entrepôt de données pour les tables métier.
5. Ajoutez comme consommateurs une Boîte du pack Base pour les tableaux de bord BI et un Magasin de caractéristiques du pack ML.
6. Étiquetez les arêtes avec chaque étape et ajoutez un bloc Markdown du pack Base avec les règles des couches.

L'exemple utilise 13 nœuds de diagramme et reste dans les limites de l'offre Free.

FAQ

Qu'est-ce que l'architecture médaillon ? Une façon d'organiser un lakehouse en trois couches de qualité croissante : le bronze pour les données brutes telles que reçues, l'argent pour les données nettoyées et harmonisées, et l'or pour des tables métier prêtes à l'emploi, construites pour des usages précis.

Quelle est la différence entre l'argent et l'or ? L'argent contient des données exactes et réutilisables au niveau de détail, une table par entité ou type d'événement. L'or contient des tables mises en forme pour un usage, comme des agrégats, des schémas en étoile ou des features ML, avec un propriétaire et des définitions.

Faut-il parfois modifier les données bronze ? Pas dans le cadre du traitement normal. Le bronze est en ajout seul pour que vous puissiez tout reconstruire en aval. Les exceptions sont les demandes légales d'effacement et les limites de rétention, qui ont besoin de leur propre processus.

L'architecture médaillon est-elle réservée à Databricks ? Non. Le nom vient de Databricks, mais le pattern fonctionne avec n'importe quel lakehouse ou entrepôt : Delta Lake, Apache Iceberg, Snowflake ou BigQuery, avec Spark, dbt ou d'autres outils.

Faut-il toujours trois couches ? Non. Utilisez autant d'étapes que vos sources l'exigent. L'essentiel est une copie brute intacte, une version propre de chaque entité et des tables dédiées avec des propriétaires.

Commencez gratuitement — un siège, sans carte bancaire.