Guide complet : Implémenter Bronze-Silver-Gold dans Fabric DW

Combien d'équipes data passent des semaines à déboguer un dashboard cassé, sans jamais retrouver la source du problème ? La réponse est souvent la même : une architecture où chaque couche fait un peu de tout, et où plus personne ne sait qui est responsable de quoi.

C'est exactement le problème que résout la medallion architecture. Dans le premier article de cette série, vous avez choisi votre pattern. Place maintenant à l'implémentation concrète : comment remplir chaque couche, Bronze, Silver et Gold, dans Microsoft Fabric Data Warehouse (DW), avec des patterns T-SQL éprouvés.

Le principe fondateur à retenir : chaque couche a un seul job. La plupart des architectures medallion qui deviennent ingérables souffrent d'un mélange des responsabilités, comme nettoyer des données en Bronze ou laisser de la logique métier s'infiltrer en Gold. Ce guide vous montre comment éviter ces écueils.

Bronze : land it, don't touch it

Bronze a un seul job : ingérer toutes les données source dans leur forme brute originale, sans aucune logique métier ni nettoyage. L'idée est simple : "écrivez tout d'abord", pour préserver une copie source de vérité à laquelle vous pourrez toujours vous référer.

Structure et organisation du schéma Bronze

Dans Fabric DW, cela se traduit généralement par des tables de staging qui reflètent fidèlement la structure source, placées dans un schéma dédié comme Bronze.CustomerRaw. Ce nommage explicite évite toute ambiguïté : personne ne devrait confondre une table Bronze avec une table exploitable en reporting.

Si la source est un extrait relationnel, la table Bronze suit généralement les colonnes source. Si la source est semi-structurée, le parsing doit rester minimal, juste ce qu'il faut pour atterrir et tracer la donnée.

Patterns T-SQL pour le chargement

Fabric DW supporte plusieurs mécanismes d'ingestion : Data Factory Pipelines, Dataflows, COPY INTO, ingestion T-SQL, OPENROWSET, et des patterns basés sur Spark. Le chemin le plus courant et efficace reste la commande T-SQL COPY INTO pour charger en masse des fichiers depuis OneLake ou un stockage externe.

CREATE SCHEMA Bronze;
 
CREATE TABLE Bronze.CustomerRaw (
    CustomerID INT NULL,
    Name VARCHAR(100) NULL,
    Email VARCHAR(100) NULL,
    CreatedDate DATETIME2 NULL,
    RawFileName VARCHAR(255) NULL
);
 
COPY INTO Bronze.CustomerRaw
FROM 'https://<storage>/exports/customers/*.csv'
WITH (FILE_TYPE = 'CSV', FIRSTROW = 2, FIELDTERMINATOR = ',');

Bonnes pratiques pour une couche Bronze fiable

• Préservez la donnée brute : ne filtrez jamais les enregistrements "mauvais" en Bronze, tout le nettoyage se passe en Silver.
• Utilisez des chargements par lots, pas des insertions ligne par ligne. Les petites insertions créent de nombreux petits fichiers Delta et nuisent aux performances.
• Gardez une discipline de fichiers et de schéma. Gérez l'évolution du schéma en ajoutant des colonnes nullables plutôt qu'en supprimant de l'information source.
• Ajoutez des colonnes de métadonnées (horodatage d'ingestion, nom du fichier source) pour la traçabilité et l'audit.
• Automatisez les chargements récurrents avec des pipelines Fabric ou des scripts SQL planifiés.

Ce niveau de rigueur dans l'ingestion fait toute la différence quand on compare à une migration classique d'Excel vers Power BI, où l'absence de source brute rend souvent le débogage impossible.

Silver : Clean it once, for everyone

Le job de Silver est unique : prendre les données brutes de Bronze et appliquer nettoyage, validation et intégration. C'est ici que vous supprimez les doublons, standardisez les formats, gérez les valeurs manquantes ou invalides, joignez les sources liées, et appliquez les règles métier partagées.

Transformations T-SQL : CTAS, INSERT et MERGE

Dans Fabric DW, Silver est typiquement implémentée avec des transformations T-SQL depuis Bronze vers des tables Silver curées. Utilisez CTAS (CREATE TABLE AS SELECT) quand vous voulez matérialiser une table propre à partir d'une requête. Utilisez INSERT...SELECT ou MERGE quand le pattern est incrémental.

CREATE SCHEMA Silver;
 
CREATE TABLE Silver.CustomerCleaned AS
SELECT
    CustomerID,
    Name,
    IIF(Email NOT LIKE '%@%.%', NULL, Email) AS Email_Valid,
    CONVERT(DATETIME2(6), CreatedDate) AS CreatedDate
FROM (
    SELECT *,
        ROW_NUMBER() OVER (PARTITION BY CustomerID ORDER BY CreatedDate DESC) AS rn
    FROM Bronze.CustomerRaw
) AS t
WHERE rn = 1;

Le point de design important : Silver doit devenir la source unique de vérité pour les données nettoyées dans le pipeline. Vous pouvez garder une table Silver par source Bronze, ou combiner plusieurs entrées Bronze en une table Silver conforme, par exemple une table client consolidée.

Assurer la qualité et l'idempotence des transformations

Rendez vos transformations idempotentes, de sorte qu'elles puissent s'exécuter plusieurs fois sans endommager les données. Silver est la porte où les mauvaises données sont arrêtées, corrigées ou signalées. Cette rigueur de qualité rejoint les principes détaillés dans notre article sur l'importance de la qualité des données pour des visualisations impactantes.

Gérer l'incrémental avec MERGE

Utilisez MERGE pour les upserts incrémentaux quand des données arrivant en retard doivent mettre à jour Silver au lieu de forcer un rechargement complet. Utilisez des tables de staging ou temporaires quand la logique devient complexe : un SQL modulaire et simple est plus facile à maintenir.

Gold : Shape it for the question

Gold a un seul job : présenter des données prêtes pour le métier, que Power BI, les dashboards et l'analytique aval peuvent utiliser directement. C'est généralement là que vous modélisez en faits et dimensions, data marts, tables de reporting larges, ou résumés pré-agrégés.

Construire des vues et tables Gold optimisées

Dans Fabric DW, c'est là que l'entrepôt brille. Les tables Gold sont construites avec des transformations SQL depuis Silver, impliquant souvent des jointures, des champs calculés et des agrégations. Le gain : les auteurs de rapports et les utilisateurs métier n'ont pas besoin de répéter des transformations lourdes dans chaque modèle sémantique ou dashboard.

CREATE SCHEMA Gold;
 
CREATE OR ALTER VIEW Gold.v_Customer AS
SELECT
    CustomerID,
    Name,
    Email_Valid AS Email,
    CreatedDate
FROM Silver.CustomerCleaned;
 
CREATE TABLE Gold.DailySalesSummary AS
SELECT
    CAST(s.OrderDate AS date) AS OrderDate,
    COUNT(DISTINCT s.OrderID) AS TotalOrders,
    SUM(s.TotalAmount) AS TotalSalesAmount,
    COUNT(DISTINCT s.CustomerID) AS UniqueCustomers
FROM Silver.SalesCleaned AS s
GROUP BY CAST(s.OrderDate AS date);

Ce type de table pré-agrégée est particulièrement utile pour des cas comme un état locatif Yardi automatisé avec Power BI, où les utilisateurs finaux ont besoin de chiffres instantanés sans recalcul.

Modélisation analytique : étoile ou flocon ?

Si vous utilisez un schéma en étoile, définissez le bon grain pour les faits et utilisez des tables de dimensions propres. La question du choix entre étoile et flocon mérite d'être approfondie, c'est justement le sujet de notre guide sur le schéma en étoile vs schéma en flocon dans Power BI.

Sécurité et gouvernance en couche Gold

Une fois les tables ou vues Gold créées dans Fabric DW, elles sont directement interrogeables par les outils BI. Comme la donnée est propre, agrégée et modelée pour l'usage, les consommateurs peuvent traiter Gold comme la version de confiance de la vérité pour l'analytique.

Dès Gold, les données sensibles doivent être supprimées, masquées, ou protégées avec de la sécurité au niveau ligne ou colonne. Documentez la lignée, en particulier comment les champs Gold dérivent de Silver.

Checklist de mise en œuvre : cas d'usage et pièges courants

Avant de considérer votre architecture medallion comme terminée, passez en revue cette checklist par couche :

| Couche | Son unique job | Dans Fabric DW | À surveiller | |---|---|---|---| | Bronze | Préserver la donnée source brute | Tables de staging, COPY INTO, colonnes de métadonnées | Nettoyer trop tôt ; fichiers minuscules | | Silver | Nettoyer, valider et conformer | CTAS, INSERT...SELECT, MERGE, portes de qualité | Transformations non répétables | | Gold | Servir l'analytique de confiance | Faits, dimensions, marts, agrégations | Logique métier qui s'infiltre trop tard |

Pièges fréquents à éviter

• Faire migrer de la logique de nettoyage en Bronze "pour gagner du temps" : cela casse la traçabilité.
• Oublier d'encapsuler la logique de rafraîchissement Gold dans des procédures stockées, ce qui rend le pipeline difficile à opérer.
• Négliger la stratégie de rafraîchissement : Gold doit être reconstruite ou mise à jour de façon incrémentale selon un planning clair.
• Ignorer l'automatisation, qui est pourtant essentielle si vous souhaitez automatiser l'envoi de vos reportings avec Power Automate une fois vos tables Gold prêtes.

Cas d'usage typique en environnement financier

Pour les équipes finance, l'architecture medallion prend tout son sens lors de l'import de données financières dans Microsoft Fabric : Bronze capture les extraits ERP bruts, Silver applique les règles de rapprochement comptable, et Gold expose des tables de synthèse mensuelles directement consommables par les analystes.

Conclusion : valider votre architecture avec une health check

Retenez ce principe simple : la donnée circule de Bronze (brute) vers Silver (nettoyée) vers Gold (curée), et la discipline se trouve dans les flèches. Si vous pouvez pointer n'importe quelle table et dire à quel job unique elle sert, votre architecture medallion est saine.

Quand quelque chose casse en Gold, une couche Bronze propre et une couche Silver répétable vous permettent de recalculer depuis zéro, au lieu de faire de la rétro-ingénierie de logique métier à partir de rapports cassés.

C'est le deuxième article d'une série sur la medallion architecture avec Fabric Data Warehouse. Le prochain article explorera les bonnes pratiques spécifiques à Fabric DW qui gardent vos trois couches rapides, fiables et gouvernables.

Articles connexes

• Microsoft Fabric : Guide complet pour démarrer sa transformation data
• Architecture de données pour Power BI : du staging au modèle sémantique
• Notebooks Python vs. Dataflows dans Microsoft Fabric : C'est l'heure du choix !