Power Query (Préparer les données) 25–30% des questions
L'éditeur de transformation de données — la première étape de tout projet Power BI
Transformations essentielles
→Supprimer les colonnes/lignes avant le chargementclic
→Append vs Merge — empiler vs joindreclic
→Pivot / Unpivot — restructurer les donnéesclic
→Typage des colonnes — texte, nombre, dateclic
Connexion aux sources
→Sources de données supportées (fichiers, BDD, cloud)clic
→Import vs DirectQuery — performance vs fraîcheurclic
→Paramètres de requête dynamiquesclic
Langage M (bases)
→Lire et comprendre les snippets Mclic
→Éditeur avancé et étapes appliquéesclic
Modélisation des données 25–30% des questions
Le schéma en étoile, les relations et les hiérarchies — le cœur d'un bon modèle Power BI
Schéma en étoile
→Tables de faits (mesures) vs tables de dimensions (attributs)clic
→Relations et cardinalité — 1:N, 1:1, N:Nclic
→Relations actives vs inactives (USERELATIONSHIP)clic
Optimisation du modèle
→Supprimer les colonnes inutiles du modèleclic
→Hiérarchies et drill-downclic
→Table de dates — obligatoire pour Time Intelligenceclic
DAX (Data Analysis Expressions) 25–30% des questions
Le langage de formules de Power BI — mesures, colonnes calculées et contexte de filtre
Mesures vs Colonnes calculées
Mesure = CALCULATE( SUM(Ventes[Montant]), Filtre )
Colonne = Ventes[Marge] = Ventes[Prix] - Ventes[Coût]
Colonne = Ventes[Marge] = Ventes[Prix] - Ventes[Coût]
→Mesure = dynamique · Colonne calculée = statiqueclic
→CALCULATE — modifier le contexte de filtreclic
Fonctions Time Intelligence
→TOTALYTD, SAMEPERIODLASTYEAR, DATEADDclic
→ALL / ALLEXCEPT — supprimer les filtresclic
Fonctions itératives
→SUMX, AVERAGEX, COUNTX — itération ligne par ligneclic
→FILTER — filtrage avancé dans CALCULATEclic
Visualisations & Rapports 20–25% des questions
Choisir le bon visuel, formater et optimiser les rapports pour l'utilisateur final
Choix du visuel
→Quel visuel pour quel type de donnéesclic
→Slicers vs filtres de page/rapportclic
→Drill-through vs Drill-downclic
Formatage & UX
→Mise en forme conditionnelle (couleurs, icônes)clic
→Signets (bookmarks) et boutons de navigationclic
Sécurité & Déploiement 10–15% des questions
Row-Level Security, workspaces, apps et gestion des accès
Row-Level Security (RLS)
→Rôles RLS — créer dans Desktop, assigner dans Serviceclic
→RLS dynamique avec USERPRINCIPALNAME()clic
Workspaces & Apps
→Workspace (collaboration) vs App (distribution)clic
→Actualisation planifiée et Gatewayclic
→Actualisation incrémentielle (Incremental Refresh)clic
Pièges classiques à l'exam
Les erreurs les plus fréquentes — lis-les au moins 2x avant de passer
Confondre mesure et colonne calculée
DAX — le piège le plus fréquent
Réponse incorrecte : créer une colonne calculée pour le total des ventes par catégorie
Réponse correcte : créer une mesure SUM(Ventes[Montant]) — le total change dynamiquement selon les filtres
Les colonnes calculées sont évaluées au chargement et stockées en mémoire. Elles ne réagissent PAS aux filtres des visuels. Si une valeur doit changer quand l'utilisateur filtre, clique ou sélectionne, c'est une mesure. Règle simple : si tu as besoin de SUM, COUNT, AVERAGE → mesure.
Oublier de marquer la table de dates
Modélisation — bloque toute la Time Intelligence
Réponse incorrecte : créer une table de dates avec CALENDARAUTO() et utiliser directement TOTALYTD
Réponse correcte : créer la table ET la marquer comme table de dates (Mark as Date Table) avec la colonne de dates continues
TOTALYTD, SAMEPERIODLASTYEAR et toutes les fonctions Time Intelligence nécessitent une table marquée comme table de dates. Sans ça, les résultats sont incorrects ou des erreurs apparaissent. La table doit couvrir une année complète sans trous.
Utiliser des relations bidirectionnelles partout
Modélisation — performance et ambiguïté
Réponse incorrecte : activer la direction "Both" sur toutes les relations pour que les filtres se propagent dans les deux sens
Réponse correcte : utiliser "Single" par défaut et "Both" uniquement quand c'est nécessaire (N:N ou scénario spécifique)
Les relations bidirectionnelles créent des chemins de filtre ambigus quand il y a plusieurs chemins entre deux tables. Résultat : performances dégradées et résultats imprévisibles. L'exam recommande "Single" sauf cas justifié.
Confondre RLS Desktop et RLS Service
Sécurité — processus en 2 étapes
Réponse incorrecte : assigner des utilisateurs aux rôles RLS dans Power BI Desktop
Réponse correcte : créer les rôles (filtres DAX) dans Desktop, assigner les utilisateurs dans le Service (powerbi.com)
Power BI Desktop permet de créer et tester les rôles RLS (avec "View as Role"). Mais l'assignation des utilisateurs se fait dans le Service Power BI, au niveau du dataset. C'est un processus en 2 étapes que l'exam teste régulièrement.
Faire des transformations en DAX au lieu de Power Query
Performance — erreur d'architecture
Réponse incorrecte : créer une colonne calculée DAX pour concaténer prénom + nom
Réponse correcte : fusionner les colonnes dans Power Query avant le chargement
Les transformations de texte, de type, de fusion de colonnes doivent se faire dans Power Query. Les colonnes calculées DAX consomment de la mémoire et sont recalculées à chaque refresh. Power Query fait la même chose une seule fois à l'import.
Comparatifs visuels
Les distinctions les plus fréquemment testées à l'exam
Import vs DirectQuery — Quel mode de connexion ?
📦 Import
Données chargées en mémoire dans le fichier .pbix
Performances très rapides (tout est en RAM)
Toutes les fonctions DAX disponibles
Données pas en temps réel (rafraîchissement planifié)
Taille limitée par la mémoire (1 Go Pro, 10 Go Premium)
⚡ DirectQuery
Requêtes envoyées à la source en temps réel
Performances dépendantes de la source
Certaines fonctions DAX non supportées
Données toujours à jour
Pas de limite de taille (données restent sur la source)
Import = performance + DAX complet · DirectQuery = fraîcheur temps réel
Mesure vs Colonne calculée — Quand utiliser quoi ?
📐 Mesure
Évaluée dynamiquement à chaque interaction
Réagit aux filtres, slicers et drill-down
Ne consomme pas de mémoire au repos
Utilisable dans les visuels (Valeur)
SUM, COUNT, AVERAGE, CALCULATE → mesure
📊 Colonne calculée
Évaluée une fois au chargement
Ne réagit pas aux filtres des visuels
Stockée en mémoire (consomme de la RAM)
Utilisable dans les slicers, filtres, axes, légendes
Concaténation, catégorisation, calcul par ligne → colonne
Mesure = agrégation dynamique · Colonne calculée = attribut par ligne
Workspace vs App — Développement vs Distribution
🔧 Workspace
Espace de collaboration pour l'équipe BI
Rapports, datasets et dataflows en développement
Accès : membres, contributeurs, administrateurs
Modifications visibles immédiatement
Environnement de travail interne
📱 App
Package distribué aux utilisateurs finaux
Rapports et dashboards en lecture seule
Accès : par groupes de sécurité ou individus
Mises à jour contrôlées (publish)
Interface simplifiée pour les consommateurs
Workspace = équipe qui crée · App = utilisateurs qui consomment
Glossaire complet
Tous les termes clés à maîtriser avant l'exam — clique pour les définitions
DAX
Data Analysis Expressions — langage de formules de Power BI pour créer des mesures et des colonnes calculées.
CALCULATE, SUM, FILTER, ALL, SUMX sont les fonctions DAX les plus courantes à l'exam.
Power Query (M)
Éditeur ETL intégré à Power BI pour connecter, nettoyer et transformer les données avant le chargement.
Le langage M est généré automatiquement. L'Éditeur Avancé permet de voir et modifier le code.
CALCULATE
Fonction DAX qui évalue une expression dans un contexte de filtre modifié. La plus importante de DAX.
CALCULATE(SUM(Ventes[Montant]), Geo[Pays]="France") = total des ventes françaises quel que soit le filtre actif.
Star Schema
Modèle de données recommandé avec une table de faits centrale entourée de tables de dimensions liées par des clés.
Faits_Ventes au centre, Dim_Date, Dim_Produit, Dim_Client autour. Relations 1:N des dimensions vers les faits.
RLS
Row-Level Security — restreint l'accès aux données au niveau des lignes selon l'utilisateur connecté via des filtres DAX sur les rôles.
Rôle "Manager France" avec filtre [Pays]="France". L'utilisateur ne voit que les données françaises dans tous les visuels.
Gateway
Service installé sur une machine pour connecter Power BI Service aux sources de données on-premises (SQL Server, fichiers réseau, etc.).
Pas nécessaire pour les sources cloud (Azure SQL, SharePoint Online, Dataverse). Obligatoire pour SQL Server local.
Dataflow
Entité Power Query hébergée dans le cloud (Power BI Service) qui centralise les transformations de données réutilisables entre plusieurs datasets.
Un dataflow prépare les données une fois → plusieurs rapports se connectent au même dataflow → cohérence garantie.
USERPRINCIPALNAME()
Fonction DAX qui retourne l'email (UPN) de l'utilisateur actuellement connecté. Utilisée dans les filtres RLS dynamiques.
Filtre RLS : [Email] = USERPRINCIPALNAME() → chaque utilisateur ne voit que ses propres données.
Incremental Refresh
Mécanisme qui ne rafraîchit que les données nouvelles ou modifiées au lieu de tout recharger. Configuré via les paramètres RangeStart/RangeEnd.
Table de 50M de lignes. Refresh complet = 2h. Incrémentiel (30 derniers jours) = 5 min.
Bookmark (Signet)
Capture l'état d'une page de rapport (filtres, visibilité, sélections). Combiné avec des boutons pour créer une navigation interactive.
Signet "Vue synthèse" + Signet "Vue détails". Deux boutons pour basculer entre les deux vues sur la même page.
Drill-through
Navigation contextuelle vers une page de détails. L'utilisateur clique sur un point de données et atterrit sur une page filtrée automatiquement.
Clic droit sur "Produit X" → Drill-through → page "Détails produit" filtrée automatiquement sur Produit X.
Composite Model
Modèle qui combine Import et DirectQuery dans le même fichier. Les tables de dimensions en Import (rapide) et les faits en DirectQuery (temps réel).
Dim_Produit en Import (petite table, change rarement). Faits_Ventes en DirectQuery (millions de lignes, temps réel).
ALL()
Fonction DAX qui supprime tous les filtres d'une table ou colonne. Utilisée dans CALCULATE pour obtenir des totaux globaux (% du total, ratio).
% = DIVIDE(SUM(Ventes[Montant]), CALCULATE(SUM(Ventes[Montant]), ALL(Ventes))). ALL supprime les filtres pour le dénominateur.
USERELATIONSHIP()
Active une relation inactive dans une expression DAX. Utilisée quand deux tables sont liées par plusieurs colonnes (ex: DateVente + DateLivraison).
Ventes par DateLivraison = CALCULATE(SUM(Ventes[Montant]), USERELATIONSHIP(Ventes[DateLivraison], Dim_Date[Date]))
Performance Analyzer
Outil de diagnostic intégré à Power BI Desktop qui mesure le temps de rendu, les requêtes DAX et les requêtes DirectQuery pour chaque visuel.
Un visuel met 5 secondes → Performance Analyzer montre que la requête DAX prend 4.8s → optimiser la mesure.