DAX ou Power Query : où placer vos transformations Power BI ?

Trois couches, trois responsabilités à expliciter

Power Query enregistre des étapes de préparation, avec le langage M en arrière-plan. DAX s’utilise dans le modèle pour des mesures et d’autres objets calculés. SQL permet de préparer et d’interroger les données dans les systèmes compatibles. Une même opération peut parfois s’écrire dans plusieurs couches.

Choisissez la couche qui rend la règle compréhensible, testable et maintenable. Si trois rapports doivent partager une classification client, la copier dans trois fichiers augmente le risque de divergence. Si le calcul dépend d’un filtre choisi à l’écran, une valeur figée en amont ne suffit pas.

Référence technique : Microsoft : présentation de Power Query ; Microsoft : bases de DAX

Une grille de décision par exemple

Cette grille est un point de départ. Le mode de connexion, la source et les contraintes de performance peuvent changer le choix. Écrivez pourquoi une transformation est placée dans une couche avant de multiplier les variantes.

Mesure et colonne calculée ne rendent pas le même service

Une mesure DAX est évaluée lors de la requête dans son contexte de filtre. En mode Import, une colonne calculée DAX produit des valeurs stockées lors du traitement du modèle. Une colonne ajoute donc des valeurs au niveau des lignes, tandis qu’une mesure répond à une agrégation demandée.

Pour une marge globale, partez de la somme du chiffre d’affaires et de la somme des coûts, puis calculez leur différence. Pour un taux, divisez les agrégats pertinents. Ne choisissez pas une colonne uniquement parce qu’elle ressemble à une formule Excel : demandez à quel niveau la réponse doit être calculée.

Référence technique : Microsoft : bases de DAX

Un exemple qui rend l’erreur visible

Dans un jeu fictif, une vente de 100 euros produit 50 euros de marge ; une vente de 900 euros en produit 90. La moyenne simple des taux, 50 % et 10 %, vaut 30 %. La marge globale vaut pourtant 140 sur 1 000, soit 14 %. Les deux calculs sont corrects pour deux questions différentes.

Si le métier demande la marge globale, une mesure fondée sur les montants est adaptée. Si la question porte sur le taux moyen par dossier, il faut définir ce dossier et son poids. La technique vient après cette définition. Documentez un contre-exemple de ce type dans la recette.

Taux global =
DIVIDE(
    SUM(Ventes[Marge]),
    SUM(Ventes[MontantNet])
)

Le query folding mérite une vérification

Quand la source et les transformations le permettent, Power Query peut déléguer une partie du traitement à la source : c’est le query folding. Il ne s’applique pas automatiquement à toute connexion ou à toute étape. Sa présence doit être vérifiée avec les outils disponibles pour votre scénario.

Avant de réécrire une transformation complexe, observez le temps d’actualisation, le volume transféré et le traitement effectué à la source. Déplacer une règle sans mesure peut seulement déplacer le problème. Conservez une version de référence et vérifiez aussi l’égalité des résultats.

Référence technique : Microsoft : vue d’ensemble du query folding

Une règle partagée doit avoir un endroit de référence

Pour chaque règle importante, notez sa définition, son propriétaire, son emplacement et son test. Le but est de savoir où modifier le calcul quand le métier change. Une documentation qui décrit une ancienne version sans pointer vers l’implémentation entretient la confusion.

Le comparatif Power BI et Excel aide à organiser les usages complémentaires. Si vos règles sont dispersées entre outils, notre expertise Data Engineering permet de cadrer leur préparation et leur partage.