Test technique Power BI : corriger un modèle et expliquer une mesure DAX

Un test technique Power BI devient difficile quand un chiffre plausible répond à la mauvaise question. Un taux de 70 % peut être calculé sans erreur de syntaxe et rester faux pour le besoin métier. Pour vous préparer, partez d’un petit jeu de données, annoncez ce que représente chaque ligne, puis justifiez le dénominateur avant de choisir le visuel.

Ce guide propose un exercice original de demandes acceptées, avec deux CSV, une requête DAX et des résultats à comparer. Il complète le guide PracHub sur les mesures DAX et les totaux. Les mécanismes attribués à Microsoft sont des faits officiels ; les données et les conseils de préparation sont notre proposition pédagogique. Aucun témoignage candidat n’étaye ici un format, une durée ou un barème d’employeur.

Poser la question métier avant d’importer

Le cas fictif est le suivant : une équipe compare les demandes reçues par plusieurs canaux et les acceptations correspondantes. Elle veut le taux d’acceptation par mois, puis la contribution de chaque canal aux acceptations de ce même mois. Ces deux questions utilisent des dénominateurs différents. Écrivez-les séparément, même si les deux résultats seront affichés en pourcentage.

Dans notre jeu, une acceptation appartient aux demandes du même mois. C’est une hypothèse du cas, pas une règle universelle de reporting. Si les demandes de janvier peuvent être acceptées en février, demandez si l’on suit une cohorte de demandes ou des événements calendaires. Le quotient des acceptations de février par les demandes de février ne répondrait pas automatiquement à la première question.

Précisez aussi l’unité : nous comptons des demandes, pas des personnes uniques. Une personne qui dépose plusieurs demandes pourrait donc contribuer plusieurs fois. Si l’interlocuteur demande ensuite un taux par utilisateur, il faudra des identifiants et une règle de déduplication ; changer le titre du graphique ne suffira pas. Vous saurez ainsi quels identifiants demander avant de calculer un taux par utilisateur.

Deux CSV pour faire apparaître le mauvais total

Le dossier d’exercice à télécharger contient requests.csv, channels.csv, les formules, la requête de contrôle et un programme de vérification indépendant. Les cinq lignes de faits sont volontairement assez petites pour permettre un calcul à la main. Le grain attendu est un couple mois/canal unique.

En janvier, A atteint 50 % et B atteint 90 %. Leur moyenne simple vaut 70 %. Mais A représente neuf dixièmes des demandes : le taux global est (450 + 90) / (900 + 100), soit 54 %. Le poids de chaque taux vient de son nombre de demandes. La moyenne simple donnerait ici au petit canal le même poids qu’au grand.

Février apporte un deuxième contrôle : A atteint 10 % et B atteint 50 %, mais les volumes sont inversés. La moyenne simple tombe à 30 %, alors que le taux pondéré vaut 46 %. Sur l’ensemble des mois, 1 000 acceptations pour 2 000 demandes donnent 50 %. Le total général de 50 % ne suffit pas à valider le rapport : il faut aussi retrouver 54 % en janvier et 46 % en février.

Corriger le modèle avant de multiplier les mesures

La documentation officielle du schéma en étoile distingue les dimensions servant au filtrage et au regroupement des faits à résumer. Pour cet exercice, notre choix de modèle est une table FactRequests, une dimension DimChannel contenant A, B et C, et une dimension DimMonth contenant janvier à avril. Avril n’a volontairement aucun fait.

Importez les deux CSV, puis créez DimMonth avec la définition fournie dans model.dax. Utilisez du texte pour les clés mois et canal, des entiers pour les deux comptes. Configurez deux relations actives de un à plusieurs, à sens unique : chaque dimension filtre les faits. Aucune relation directe ne relie les dimensions. Vérifiez les clés réellement utilisées, pas seulement les traits du diagramme.

Avant toute mesure, cherchez les doublons de canal dans la dimension, les couples mois/canal répétés et les canaux inconnus dans les faits. Notre contrat interdit aussi une acceptation négative ou supérieure au nombre de demandes. Ces règles découlent des hypothèses de l’exercice. Dans un autre domaine, une même ligne pourrait être légitimement répétée ; il faudrait alors redéfinir le grain au lieu de supprimer des lignes arbitrairement.

Une matrice dont tous les canaux affichent le même nombre peut signaler que le filtre n’arrive pas aux faits. Inspectez la relation, sa direction et le champ utilisé dans le visuel. Reconstituez d’abord une cellule connue, janvier A : 900 demandes et 450 acceptations. Ajouter une relation bidirectionnelle sans expliquer le chemin attendu rendrait le diagnostic plus difficile.

Recalculer le taux dans chaque contexte

Créez les définitions suivantes séparément comme mesures, après avoir nommé les tables conformément au dossier. Il ne s’agit pas de quatre colonnes calculées à ajouter aux cinq lignes.

Demandes = SUM(FactRequests[Requested])
Acceptees = SUM(FactRequests[Accepted])
Lignes = COUNTROWS(FactRequests)
Taux = DIVIDE([Acceptees], [Demandes])

La documentation officielle de Microsoft décrit SUM comme une somme de colonne et DIVIDE comme une division qui renvoie par défaut BLANK lorsque le dénominateur est nul. Notre mesure assemble les comptes dans le contexte courant, puis effectue le quotient. Elle ne somme pas les pourcentages des lignes affichées.

Dans une matrice, testez janvier, février, chaque canal et le total. Pour janvier A, attendez 50 % ; pour janvier tous canaux, 54 %. Le total demande un nouveau calcul. Ce comportement est précisément celui que souhaite notre question métier. Si l’on voulait mesurer la performance du « canal moyen », avec chaque canal pesant autant, on définirait une autre métrique et on la nommerait autrement.

Gardez les comptes visibles à côté du taux pendant la validation. Un pourcentage seul peut cacher un dénominateur trop petit, une ligne absente ou un filtre oublié. Le format en pourcentage intervient après le calcul : 0,54 devient 54 %. Arrondir les taux par canal avant de les agréger ajouterait une autre source d’écart, sans réparer le mauvais poids.

Avec CALCULATE, défendre le filtre retiré

La définition officielle de CALCULATE porte sur l’évaluation dans un contexte de filtre modifié. REMOVEFILTERS retire les filtres des tables ou colonnes indiquées. Dans notre modèle proposé, la part du canal A parmi les acceptations de janvier conserve le mois et retire seulement le canal au dénominateur.

PartAccepteesTousCanaux =
DIVIDE(
    [Acceptees],
    CALCULATE([Acceptees], REMOVEFILTERS(DimChannel))
)

La cellule janvier A contient 450 acceptations. Le dénominateur attendu est 540, toutes les acceptations de janvier : la part vaut cinq sixièmes, environ 83,33 %. Ce résultat n’est pas son taux d’acceptation de 50 %. Il décrit sa contribution au volume accepté, pas la probabilité qu’une de ses demandes soit acceptée.

Si vous retirez aussi DimMonth, le dénominateur devient 1 000 et la part passe à 45 %. Le calcul répond alors à une autre question : la contribution de janvier A aux acceptations de tous les mois. Pour la demande initiale, ce serait une erreur de périmètre. Énoncez le filtre conservé et celui retiré avant d’écrire la formule.

Cette explication suppose que la matrice et les segments utilisent DimChannel et DimMonth. Si le canal provient directement de FactRequests, enlever le filtre de DimChannel ne promet pas d’enlever ce filtre sur les faits. Notez que le segment utilise DimChannel[Label] et que les lignes de mois utilisent DimMonth[Month]. La formule, les relations et le visuel forment ensemble le cas à vérifier.

Séparer zéro, mois vide et défaut d’import

Mars C possède une ligne contenant zéro demande et zéro acceptation. Avril ne possède aucune ligne. Le taux est BLANK dans les deux cas, mais les situations sont différentes. Mars représente une observation explicite sans activité ; avril peut représenter une absence attendue, un chargement incomplet ou simplement un mois hors période. Le jeu seul ne décide pas de son interprétation métier.

Exposez donc les comptes et le nombre de lignes pendant le diagnostic. La documentation de COUNTROWS précise que la fonction renvoie BLANK pour une table sans ligne. Une ligne à zéro reste une ligne. Remplacer tous les BLANK par zéro trop tôt effacerait cette distinction. Activez l’affichage des éléments sans données sur le mois si nécessaire pour examiner avril dans la matrice.

Ajoutez ensuite un test de filtre : sélectionnez janvier A, puis janvier tous canaux, puis février. Les comptes doivent changer conformément aux lignes du CSV. Un total toujours identique pourrait provenir d’un filtre retiré trop largement. Un taux vide malgré des demandes positives appelle un autre diagnostic : types, colonne visée, import ou relation. Expliquez quel contrôle permet de départager ces hypothèses.

Ce qui a été exécuté, et ce qui reste à vérifier

La requête virtual-fixture-checks.dax a été exécutée dans le moteur DAX hébergé de DAX.do. Ses 18 assertions passent : sommes, moyenne simple, taux pondéré, parts arithmétiques et distinction BLANK/zéro. Elle construit ses cinq lignes avec DATATABLE, puis utilise notamment FILTER, SUMX, AVERAGEX et DIVIDE. La comparaison numérique accepte un écart inférieur à 1e-12 ; ISBLANK distingue explicitement une valeur vide de zéro.

Le programme Python fourni passe aussi 25 vérifications avec des fractions exactes et des contrôles de données. Il rejette notamment un canal inconnu et une clé de dimension répétée. C’est un oracle indépendant des comptes, pas un interpréteur DAX. Les contrôles Python ne prouvent pas l’exécution du moteur Power BI.

L’import des CSV, les relations physiques et les mesures CALCULATE de ce modèle personnalisé n’ont pas été exécutés dans Power BI pendant cette préparation. Le dossier téléchargeable contient les sources et les résultats virtuels ; il ne contient aucun PBIX dont les relations auraient été validées. Le README décrit les résultats attendus et l’étape restante : ouvrir le modèle, vérifier ses relations et enregistrer les cellules de contrôle. Ne transformez pas les 18 assertions virtuelles en preuve de propagation des filtres.

Expliquer une correction sans réciter une formule

Pour vous entraîner, présentez une cellule erronée et commencez par la question qu’elle devait résoudre. Montrez ensuite deux lignes sources, le compte attendu et la cause isolée. Une réponse possible pour notre cas serait : « Le 70 % donne le même poids aux deux canaux. Je calcule 540 acceptations sur 1 000 demandes, donc 54 %, puis je vérifie février pour éviter une correction qui fonctionnerait seulement en janvier. »

Préparez une relance distincte sur les 83,33 % : cette fois, vous devez expliquer la part dans les acceptations du mois et justifier le retrait du canal. Enfin, annoncez la limite de validation si vous n’avez pas ouvert le modèle. Votre partenaire peut alors demander la cellule janvier A et vérifier avec vous si le dénominateur reste 540.

Les cinq questions PracHub suivantes servent à pratiquer les comptes, les populations et les dénominateurs. Ce sont des exercices de statistiques ou de SQL ; elles ne sont pas présentées comme des sujets Power BI effectivement posés par votre futur employeur, ni comme une prédiction de test.

Reprenez ensuite le guide PracHub sur les totaux DAX : choisissez une mesure, annoncez son grain et inventez un contre-exemple qui fait échouer une agrégation naïve. Votre livrable utile est une correction accompagnée de ses contrôles, suffisamment claire pour qu’une autre personne puisse la reproduire.

Sources and Further Reading

• Microsoft Learn : schéma en étoile dans Power BI
• Microsoft Learn : CALCULATE
• Microsoft Learn : REMOVEFILTERS
• Microsoft Learn : DIVIDE
• Microsoft Learn : SUM
• Microsoft Learn : COUNTROWS
• DAX.do : environnement de requêtes DAX de SQLBI