🎯 Situation

Un client m'a envoyé un fichier Power BI le mois dernier. Une seule table. 47 colonnes. Données de ventes, données clients, données produits, données régions — tout dans la même feuille plate, exportée depuis leur ERP chaque lundi matin.

Ça fonctionnait. Les visuels se chargeaient. Les chiffres étaient justes. Mais à chaque ajout d'un nouveau slicer ou d'un visuel, le rapport ralentissait un peu plus. Après deux ans d'ajout de colonnes, il était devenu impossible à maintenir.

👉 Le modèle était une table plate — le point de départ le plus naturel, et l'une des erreurs de modélisation les plus fréquentes en Power BI.

La solution était un star schema. Pas parce que c'est une case à cocher dans les bonnes pratiques — mais parce que le moteur de Power BI est spécifiquement conçu pour tourner dessus.

⚠️ Challenge

Quand on connecte des données à Power BI pour la première fois, on travaille généralement avec ce qu'on a : une grande table issue d'un export Excel ou d'une vue SQL. Ça paraît propre et simple. Mais à mesure que le modèle grossit, les limites apparaissent.

📈 Table plate

  • Facile à comprendre au premier coup d'œil
  • Un export, un chargement, c'est fait
  • Pas de relations à gérer
  • Familière — ressemble à Excel

❌ Ce qui finit par casser

  • Données dupliquées partout — même nom client répété sur chaque ligne de vente
  • Fichier très lourd — VertiPaq compresse mal sans structure
  • DAX lent — les mesures itèrent sur des millions de lignes redondantes
  • Difficile à maintenir — ajouter un attribut implique de toucher toute la table
  • Les filtres sur des valeurs répétées sont coûteux et imprévisibles

La table plate n'est pas mauvaise parce qu'elle est mal structurée visuellement. Elle est mauvaise parce que le moteur de stockage de Power BI — VertiPaq — est orienté colonnes et optimisé pour la compression. Il performe au maximum quand chaque colonne a une faible cardinalité et des valeurs propres, non répétées.

🔍 Ce qu'est vraiment un star schema

Un star schema a deux types de tables :

  • Une table de faits — les transactions. Chaque ligne est un événement : une vente, une commande, une entrée de log. Elle contient des valeurs numériques (montants, quantités) et des clés étrangères (des IDs pointant vers les dimensions).
  • Plusieurs tables de dimensions — le contexte. Clients, produits, dates, régions, commerciaux. Chaque ligne est unique. Pas de doublons.

La table de faits se connecte à chaque table de dimension via une relation unique. C'est l'étoile — un centre, plusieurs branches.

Avant : une table plate de 47 colonnes et 2 millions de lignes — NomClient répété 2 millions de fois, CatégorieProduit répétée 2 millions de fois.

Après : une table de faits de 8 colonnes (IDs + montants) et des tables de dimensions avec des valeurs uniques. Mêmes données, une fraction du poids, des filtres qui s'exécutent en millisecondes.

VertiPaq compresse extrêmement bien les valeurs répétées — mais seulement si elles sont dans une colonne dédiée à faible cardinalité. "Canada" répété dans une dimension Région de 5 lignes se compresse à presque rien. "Canada" répété 2 millions de fois dans une table de faits, non.

✓️ Comment aborder la migration

Pas besoin de tout reconstruire depuis zéro. La plupart des tables plates peuvent être transformées en star schema en quelques étapes :

  • Identifier le grain — qu'est-ce que représente une ligne ? Une vente ? Une ligne de commande ? C'est ta table de faits.
  • Extraire les colonnes descriptives — nom client, catégorie produit, région, commercial → chacun devient une dimension avec un ID unique
  • Ne garder que les IDs et les métriques dans la table de faits — ClientID, ProduitID, RégionID, Montant, Quantité, Date
  • Créer les relations dans Power BI — faits vers chaque dimension, un-à-plusieurs, sens unique
  • Toujours ajouter une table de dates dédiée — ne jamais utiliser directement une colonne date de la table de faits pour la time intelligence

Dans le cas client cité plus haut : la table plate de 47 colonnes est devenue une table de faits de 7 colonnes + 5 tables de dimensions. Le temps de chargement du rapport est passé de 9 secondes à moins de 2.

💡 Synthèse

Le star schema n'est pas un concept avancé réservé aux data engineers. C'est la structure de base qui permet à Power BI de fonctionner comme prévu.

Trois choses à retenir :

  • Les tables plates sont un point de départ, pas une destination — elles fonctionnent bien à petite échelle, puis deviennent un problème quand les données grandissent
  • Les gains de performance sont structurels — aucune optimisation DAX ne compense complètement un dataset mal modélisé
  • Le star schema facilite aussi l'écriture du DAX — les filtres se propagent naturellement des dimensions vers les faits, ce qui est exactement la façon dont CALCULATE et les relations sont conçus pour fonctionner

Si ton rapport Power BI est lent et que ton DAX semble correct, le modèle est presque toujours le vrai problème. Commence par là avant d'optimiser quoi que ce soit d'autre.

👉 Un bon modèle rend le DAX facile. Un mauvais modèle rend le DAX impossible.

Corrige les fondations d'abord.