Accueil Databricks La station spatiale : l'architecture Medallion au cœur de la mission Lakehouse

La station spatiale : l'architecture Medallion au cœur de la mission Lakehouse

L'architecture Medallion constitue un modèle de conception majeur dans le développement moderne des plateformes de données et sert de référence pour l'organisation logique des données au sein d'un Data Lakehouse unifié. Ce terme a été popularisé par Databricks vers 2019 et introduit peu après la publication de Delta Lake en tant que composant central de la vision « Lakehouse » en pleine évolution. Depuis son introduction, ce terme s'est imposé dans l'ensemble du secteur.

Imaginez une station spatiale : ce n'est pas un bloc monolithique, mais un système conçu avec précision, composé de modules spécialisés – chacun ayant une mission clairement définie, chacun dépendant du suivant. C'est exactement ainsi que fonctionne l'architecture Medallion. Ses trois couches – Bronze, Silver et Gold – sont les modules de la station spatiale. Chaque niveau renforce la fiabilité, la densité sémantique et la valeur commerciale des données, sans pour autant perdre le lien avec les données brutes d'origine.

Table des matières

Tout comme dans une véritable station spatiale, chaque module remplit une fonction clairement définie – et aucun module ne se substitue à un autre. L'architecture Medallion impose donc une séparation stricte des responsabilités techniques entre ses trois couches principales :

Le niveau Bronze constitue la station d'accueil de la station spatiale : c'est là que convergent tous les flux de données entrants – qu'ils proviennent de bases de données transactionnelles, d'applications SaaS externes, de files d'attente de messages en temps réel telles que Kafka ou de téléchargements de fichiers. Le principe de base : tout capturer, rien ne transformer. Une reproduction fidèle à l'original, sans exception. Les données sont écrites exactement telles qu’elles se présentent dans le système source, en conservant les structures d’origine, les données semi-structurées imbriquées et les schémas. Afin de garantir une traçabilité complète et un retraitement ultérieur, des métadonnées système sont ajoutées à chaque enregistrement lors de son insertion, telles que des horodatages d’ingestion, des identifiants de processus et des identifiants du système source. Les tables Bronze sont généralement de type « append-only » et immuables, c'est-à-dire qu'une fois les données écrites, elles ne sont plus modifiées. Elles servent de source unique de vérité à partir de laquelle toutes les couches en aval peuvent être systématiquement recréées à tout moment, sans avoir à interroger à nouveau les systèmes sources opérationnels.

Dans le laboratoire de traitement de la station spatiale, les données brutes fournies sont mises en ordre. Le niveau Silver transforme le flux de données brutes en une vue d'entreprise harmonisée, conforme et homogène. Les transformations appliquées ici sont déterministes et standardisées, et se concentrent sur :

  • Harmonisation et perfectionnement des schémas
  • Déduplication des enregistrements redondants
  • Normalisation des conventions de dénomination et des formats de données
  • Traitement/correction des valeurs manquantes ou erronées
  • Mise en relation de différentes bases de données afin d'offrir une vue d'ensemble intégrée

Conformément au paradigme moderne de l'ingénierie des données, la couche Silver privilégie généralement une approche ELT. Seul un nettoyage « juste suffisant » est appliqué afin de présenter une vue cohérente des entités métier centrales (telles que des vues conformes des clients, des transactions ou des produits). Elle utilise fréquemment la troisième forme normale (3NF) ou des architectures Data Vault afin de permettre une intégration aussi complète que possible, l’auditabilité et la mise en place de premières mesures d’assurance qualité. Cela garantit qu’en cas de réutilisation des données, les défauts de qualité ne se multiplient pas dans différents cas d’utilisation.

Le centre de commande est le cœur de la station spatiale – le lieu d'où sont prises les décisions. Le niveau Gold agrège les données préparées par le module Silver et les met à disposition pour des usages spécifiques. Ce niveau est explicitement optimisé pour les accès en lecture et adapté au reporting, à la BI en libre-service ainsi qu'aux modèles d'apprentissage automatique. Les tables Gold appliquent des logiques métier complexes, des calculs et des agrégations. Afin de maximiser les performances des requêtes et de minimiser le besoin de jointures de tables lors de l'exécution, les données sont généralement dénormalisées. Le niveau Gold utilise souvent des schémas en étoile selon Kimball (avec des tables de faits et de dimensions fortement structurées) ou des data marts optimisés pour la vitesse d'exécution selon Inmon.

L'interaction entre les modules : le principe de l'architecture multi-sauts

Les données transitent par la station spatiale module par module – c'est pourquoi on parle également d'architecture multi-sauts. Cela présente l'avantage de produire, pour chaque flux de données, un résultat intermédiaire explicite pouvant être utilisé pour d'autres processus, ce qui permet potentiellement d'éviter ou de réduire la duplication des logiques métier. De plus, cela permet une séparation des responsabilités (separation of concerns), grâce à laquelle chaque couche prend en charge un ensemble de tâches nettement plus homogène.

À chaque couche ou à chaque « saut », la charge de travail consacrée aux données augmente, tant en termes de capacités de calcul que de ressources en personnel de développement. C’est pourquoi les efforts doivent être de plus en plus justifiés au fur et à mesure que les données circulent, idéalement par des cas d’utilisation durables et rentables ainsi qu’une large base d’utilisateurs des données. Alors que seules quelques personnes spécialisées (par exemple des ingénieurs de données) ont accès aux données Bronze, certains analystes (avancés) peuvent déjà accéder aux données Silver.

 

Medallion : bien plus qu'un simple terme marketing

L'architecture multicouche qui se cache derrière le terme « Medallion » n'est pas tout à fait nouvelle. Les plateformes de données modernes ont adopté une approche de raffinement à plusieurs niveaux qui existe déjà depuis au moins la fin des années 1990. Par le passé, les architectes d’entrepôts de données ont créé des frontières physiques similaires et ont désigné les niveaux successifs comme des couches de « données brutes » (« d’intégration » ou « traitées ») et de « présentation » (« affinées »).

Cette architecture posait toutefois souvent le problème suivant : elle était gérée et développée par une équipe centrale, et les utilisateurs ne pouvaient accéder qu'aux résultats finaux (data marts).

Cela a entraîné un goulot d'étranglement au sein de l'équipe centrale chargée du développement des nouvelles exigences, et par conséquent de longs délais d'attente pour les parties prenantes. Cette situation a favorisé la constitution de bases de données distinctes (silos) au sein des services métier. En effet, ces derniers n'avaient souvent pas besoin de données traitées à 100 %, surtout lorsqu'il s'agissait de lancer des preuves de concept (PoC) ou d'autres projets expérimentaux. Des données un peu moins traitées valaient souvent bien mieux que de ne disposer d’aucune donnée. L’architecture Medallion modernise cette pratique de longue date et l’optimise spécifiquement pour la mise à l’échelle décentralisée et les formats de stockage ouverts de l’ère des lakehouses natifs du cloud.

2. Planification des ressources à bord : capacité de stockage et coût total de possession

Une idée fausse courante en matière de budgétisation est la suivante : « Trois couches impliquent un triplement des coûts de stockage (Raw * 3). » Cette vision isolée est réductrice et ne tient pas compte du comportement physique des flux de données structurés ni de la rentabilité globale d'une architecture cloud moderne.

Pourquoi le volume de données diminue au fil du temps

En effet, le volume de stockage physique diminue considérablement à chaque étape de transformation.

  • Bronze sert de réservoir brut et stocke le flux non filtré de données d'entrée (par exemple, des signaux de température IoT enregistrés toutes les secondes sur plusieurs mois).
  • Silver consolide le flux CDC. Au lieu de conserver chaque modification historique, les doublons sont supprimés et les états sont regroupés de manière simplifiée.
  • Gold enregistre des indicateurs hautement agrégés et condensés au niveau horaire, quotidien ou par itinéraire.

Le profil de stockage se présente donc comme une pyramide : dans la pratique, les tables d'or de très haute pureté représentent souvent moins de 5 % du volume initial de bronze. Il ne s'agit donc en aucun cas d'un triplement systématique du volume.


Analyse du coût total de possession : stockage vs. ressources informatiques et personnel

Une analyse isolée du coût des disques durs ne tient pas compte des véritables facteurs qui déterminent le coût total de possession (TCO):

  1. L'espace de stockage ne coûte pas cher : le stockage objet dans le cloud (par exemple Azure Blob Storage ou AWS S3) représente un coût négligeable, à environ 0,02 USD par gigaoctet et par mois.
  2. La puissance de calcul est extrêmement coûteuse : si les analystes BI et les data scientists devaient exécuter leurs requêtes à chaque fois directement sur des données brutes non nettoyées de niveau Bronze, cela entraînerait à chaque exécution des coûts de calcul considérables liés au filtrage temporaire, à la conversion de types et à la déduplication. L'architecture Medallion permet de réaliser des économies en n'effectuant les transformations standard gourmandes en ressources de calcul qu'une seule fois lors du passage vers la couche Silver et en conservant ces résultats.
  3. Préserver les ressources humaines : lorsque les données sont déjà disponibles sous une forme clairement structurée dans Silver et Gold, il n'est plus nécessaire de réécrire de manière répétitive des logiques de nettoyage SQL dans les systèmes en aval. Cela permet aux ingénieurs en analyse de données et aux utilisateurs métier de gagner un temps de travail précieux.
  4. Résilience et sécurité grâce à la redondance : la mise en place délibérée de ces couches garantit une grande fiabilité. En cas d'erreur de transformation ou de défaillance d'un système source, le pipeline peut être reconstitué de manière indépendante et historiquement correcte à partir du niveau Bronze, tandis que les applications en aval continuent de fonctionner sans interruption sur la base des niveaux Silver et Gold.

Le guide Databricks d'Andreas & Yvonne

Vous voulez toutes les informations importantes en un coup d'œil ? 

Téléchargez dès maintenant le guide gratuit de SAP Databricks !

3. Taux de mission : traitement par lots ou flux de données en temps réel

L'architecture Medallion a été initialement conçue pour le traitement par lots. Même en 2026, le traitement par lots quotidien ou horaire reste la norme incontestée dans les entreprises : il suffit amplement pour plus de 90 % de tous les scénarios opérationnels (tels que les rapports financiers, les rapprochements de stocks et les décomptes SLA).

Pour les cas d'utilisation qui exigent impérativement une vitesse en temps réel (par exemple, l'alerte immédiate sur l'itinéraire via GPS en cas d'écarts de température pendant le trajet), il n'est toutefois pas nécessaire de rejeter cette architecture. Le traitement en temps réel est intégré de manière pragmatique dans le processus global en tant que complément ciblé :

  • Le flux IoT alimente en continu la table Bronze via des pipelines de streaming allégés.
  • Alors que les tables standard sont mises à jour par lots, les exigences en temps réel peuvent s'appuyer directement sur ces mêmes tables physiques grâce à des vues matérialisées incrémentielles ou à des micro-lots structurés. L'architecture reste ainsi homogène et facile à maintenir, sans introduire de complexité inutile dans les scénarios qui ne nécessitent pas de traitement en temps réel.

4. Intégration autorisée : Medallion s'associe à Data Mesh

Dans les plateformes de données d'entreprise modernes, la transition entre l'architecture Medallion et le paradigme Data Mesh(organisation décentralisée des données par domaine métier) est fluide. Ces concepts ne s'opposent pas ; ils sont parfaitement compatibles.

Historiquement, les données des entrepôts de données étaient généralement structurées selon des responsabilités logiques (par exemple, des espaces de stockage distincts pour les finances, le marketing, les ressources humaines ou la logistique). Cette structuration classique correspond exactement au principe de propriété de domaine du Data Mesh.

Couche Bronze vs. Produit de données aligné sur la source

Si l'on ne considère pas la couche Bronze d'un domaine comme un simple dépôt passif de données, mais que l'on y applique dès ce stade des opérations de base fondamentales et non commerciales (telles qu'une conversion formelle au format Delta, une déduplication technique ou l'attribution de métadonnées globales), la différence avec un produit de données aligné sur la source (Source-Aligned Data Product) disparaît de facto. Cela vaut d'autant plus si l'on tient compte du fait qu'une architecture Medallion ne doit pas nécessairement être gérée par une équipe informatique centrale, mais peut être exploitée de manière décentralisée au sein des domaines.

Gold-Layer vs. produit de données orienté consommateur

La différence entre les data marts classiques, les résultats de la couche « Gold » ou les produits de données orientés consommateur ( Consumer-Aligned Data Products ) est purement terminologique. Tous désignent des données prêtes à l'emploi, riches sur le plan sémantique et optimisées pour l'utilisation finale.

La différence fondamentale ne réside pas dans le résultat final, mais dans la philosophie de mise à disposition. Dans les approches classiques des entrepôts de données, les utilisateurs métier n'avaient accès qu'aux « gold marts » finaux, ce qui engendrait les goulots d'étranglement bien connus au niveau du développement informatique. L’architecture Medallion dans le Lakehouse brise ce cloisonnement en accordant aux utilisateurs avancés et aux data scientists un accès en lecture ciblé aux résultats intermédiaires nettoyés (la couche Silver). Cela combine la flexibilité d’un Data Mesh décentralisé avec la fiabilité structurelle d’une plateforme de données classique.

5. Conclusion et recommandations architecturales

L'architecture Medallion est bien plus qu'un simple système de classification théorique : elle constitue le fondement pragmatique de l'évolutivité, de la confiance et de la rentabilité dans l'écosystème moderne des données.

Nous formulons trois recommandations pour votre feuille de route architecturale :

  1. Pas d'accès direct aux données brutes : interdisez aux services opérationnels l'accès à la couche Bronze afin d'éviter l'apparition d'un « shadow IT » et de chiffres clés contradictoires.
  2. Mettre Silver à disposition en tant que plateforme d'innovation : mettez la couche Silver optimisée à la disposition de vos analystes expérimentés et de vos data scientists pour des PoC expérimentaux, afin d'éliminer définitivement le goulot d'étranglement informatique central qui existait auparavant.
  3. Planification holistique des coûts : considérez les coûts de stockage et de calcul comme un tout. La redondance délibérée des couches intermédiaires persistantes réduit considérablement vos coûts cloud en évitant les calculs en double.

Votre architecture est unique – Prenons le temps d'en discuter CTA

La structuration de vos flux de données est déterminante pour la performance et l'adoption de votre plateforme BI et IA. Ensemble, nous analysons votre environnement SAP actuel et concevons une station spatiale qui tiendra le coup, même si la mission dure plus longtemps que prévu.

Votre stratégie en matière de données est personnalisée – vos conseils devraient l'être également.

Le choix entre ces méthodes dépend de nombreux facteurs : votre environnement système existant, vos objectifs commerciaux et votre culture en matière de données. Il n'existe pas de réponse standard.

Discutons ensemble, sans engagement, de la solution qui vous convient le mieux.

N'hésitez pas à nous contacter pour un entretien individuel.

 
 

Publié par :

Dr. Andreas Wagner

Responsable Customer Success

autor:IN

Cet article vous a-t-il plu ?

Cet article vous a-t-il été utile ?

Cliquez sur une étoile pour évaluer !

Note moyenne : 4,7 /5.
Nombre d'avis : 29

Aucun vote pour l'instant ! Soyez la première personne à noter ce post !

INFORMATIONS

Plus d'informations

Glossaire SAP Sapphire 2026 : Joule, agents IA et « Autonomous Enterprise » expliqués simplement

Joule, agents IA, entreprise autonome, protocole A2A : tous les nouveaux termes SAP présentés lors du salon Sapphire 2026 en un coup d'œil. Consultez dès maintenant le glossaire s-peers.
Wiki Big Query SAP Warehousing

Google BigQuery vs SAP BW : comparaison de deux solutions d'entrepôt de données

Cet article Wiki présente deux solutions leaders pour la gestion et l'analyse des données dans le monde moderne axé sur les données : Google...
Transformation par l'IA et économie comportementale : pourquoi les gens ne veulent (souvent) pas changer

Transformation par l'IA et économie comportementale : pourquoi les gens ne veulent (souvent) pas changer

Dans ce wiki, Yvonne explique, sous l'angle de l'économie comportementale, pourquoi les changements sont si difficiles à mettre en œuvre dans les entreprises. Pourquoi les gens agissent-ils...
Facteurs de réussite de l'adoption de l'IA - gestion du changement

Quels sont les véritables moteurs de l'adoption de l'IA dans les entreprises ? 6 facteurs qui déterminent le succès ou l'échec.

Ce wiki explique pourquoi le changement échoue rarement à cause de la technologie, mais plutôt en raison de schémas psychologiques, et comment...
Gestion du changement informatique

La psychologie dans la gestion du changement : 6 biais qui freinent l'adoption (et 6 mesures pour y remédier)

Ce wiki explique pourquoi le changement échoue rarement à cause de la technologie, mais plutôt en raison de schémas psychologiques, et comment...
Gestion du changement informatique

Gestion du changement informatique : définition, processus et bonnes pratiques

Les entreprises ne tirent parti que de moins d'un tiers des avantages escomptés de la transformation numérique, non pas parce que la technologie fait défaut, mais parce que...

Qu'est-ce que la FP&A ? Définition, processus clés et avenir du pilotage d'entreprise

Les entreprises ne sont pas pilotées par des rapports, mais par de meilleures décisions. La FP&A (Financial Planning & Analysis) est la fonction stratégique...