Dans une migration Qlik vers Power BI, ce ne sont pas les graphiques qui posent problème : ce sont les calculs. Et parmi eux, le set analysis. Ces expressions entre accolades font la force de Qlik, mais elles n’ont pas d’équivalent direct en DAX. Les traduire ligne à ligne, c’est le meilleur moyen d’obtenir des chiffres faux sans s’en rendre compte.
Je conçois des applications Qlik depuis 2012 et je travaille sur Power BI depuis 2019. Voici les 6 traductions du set analysis en DAX que je rencontre le plus souvent, avec les pièges à connaître pour chacune.
Set analysis en DAX : deux logiques différentes
Qlik raisonne en sélections sur des champs : un set analysis modifie les sélections de l’utilisateur le temps d’un calcul. Power BI raisonne en contexte de filtre sur des tables : la fonction CALCULATE modifie ce contexte, et les filtres circulent le long des relations du modèle.
Conséquence pratique : avant de traduire la moindre expression, il faut un modèle Power BI propre, en étoile, avec une vraie table de dates. Sans elle, la plupart des exemples ci-dessous ne fonctionnent pas correctement.
Dans tous les exemples, on part d’une mesure de base, réutilisée partout :
CA = SUM ( Ventes[Montant] )1. Ignorer toutes les sélections
Cas typique : afficher le chiffre d’affaires total à côté du chiffre filtré, pour calculer une part.
Qlik :
Sum({1} Montant)
DAX :
CA total = CALCULATE ( [CA], REMOVEFILTERS () )Le piège : REMOVEFILTERS() sans argument retire tous les filtres du modèle, y compris les filtres de page et de rapport, ce qui surprend parfois les utilisateurs. La sécurité au niveau des lignes (RLS), elle, continue de s’appliquer. Pour ne retirer que les filtres d’une table, précisez-la : REMOVEFILTERS ( Produit ).
2. Ignorer la sélection d’un seul champ
Qlik :
Sum({<Région=>} Montant)
DAX :
CA toutes régions = CALCULATE ( [CA], REMOVEFILTERS ( Client[Région] ) )Le piège : en Qlik, Région= ne vide que ce champ. En DAX, si le rapport filtre aussi sur Client[Ville], ce filtre reste actif et restreint indirectement les régions. Pour ignorer toute la géographie, retirez les filtres sur les deux colonnes, ou sur la table Client entière.
3. Forcer une liste de valeurs
Qlik :
Sum({<Pays={'France','Belgique'}>} Montant)
DAX :
CA France Belgique =
CALCULATE ( [CA], Client[Pays] IN { "France", "Belgique" } )Comme en Qlik, la condition remplace la sélection de l’utilisateur sur le champ Pays. Si quelqu’un sélectionne l’Espagne dans un segment, la mesure affiche quand même France et Belgique.
4. Exclure une valeur en gardant la sélection
C’est l’erreur de traduction du set analysis en DAX la plus fréquente que je corrige. En Qlik, l’opérateur -= retire une valeur de la sélection en cours.
Qlik :
Sum({<Famille-={'Services'}>} Montant)
DAX (traduction fausse) :
CALCULATE ( [CA], Produit[Famille] <> "Services" )
DAX (traduction juste) :
CA hors services =
CALCULATE ( [CA], KEEPFILTERS ( Produit[Famille] <> "Services" ) )Pourquoi : sans KEEPFILTERS, CALCULATE remplace le filtre existant sur Famille. Si l’utilisateur a sélectionné « Matériel », la première version affiche toutes les familles sauf Services, donc bien plus que le matériel. KEEPFILTERS combine la condition avec la sélection, comme le fait Qlik.
5. Comparer avec l’année précédente
Qlik :
Sum({<Année={$(=Max(Année)-1)}>} Montant)
DAX :
CA année précédente =
VAR AnneePrecedente = MAX ( 'Date'[Année] ) - 1
RETURN
CALCULATE ( [CA], 'Date'[Année] = AnneePrecedente )La variable calcule l’année précédente dans le contexte de l’utilisateur, puis CALCULATE remplace le filtre sur l’année. Si votre table de dates est marquée comme telle, CALCULATE ( [CA], SAMEPERIODLASTYEAR ( 'Date'[Date] ) ) fait le même travail et respecte en plus la sélection d’un mois ou d’un trimestre.
6. Calculer un cumul depuis le début de l’année
Qlik :
Sum({<Année={$(=Max(Année))}, Mois=, NumMois={"<=$(=Max(NumMois))"}>} Montant)
DAX :
CA cumul annuel = TOTALYTD ( [CA], 'Date'[Date] )C’est là que le passage à Power BI fait gagner le plus de temps. En Qlik, chaque cumul demande une expression dédiée, souvent dupliquée dans plusieurs objets. En DAX, une table de dates et les fonctions de time intelligence (TOTALYTD, DATESYTD, SAMEPERIODLASTYEAR, DATEADD) remplacent des dizaines d’expressions. Pensez aussi à l’exercice fiscal : TOTALYTD accepte une date de fin d’exercice, par exemple TOTALYTD ( [CA], 'Date'[Date], "30/06" ).
Comment vérifier que la traduction est juste
Une mesure peut être juste ligne par ligne et fausse au total. Avant de valider une traduction du set analysis en DAX, je contrôle systématiquement :
- le total général, comparé à la même valeur dans Qlik ;
- plusieurs niveaux de détail : par mois, par produit, par client ;
- le comportement avec une sélection active sur le champ concerné, puis sur un champ voisin ;
- les cas limites : début d’année, mois sans vente, valeurs vides.
Pendant toute la recette, Qlik et Power BI tournent en parallèle. Chaque écart est expliqué, puis validé avec les utilisateurs métier. C’est la seule façon de garantir que le chiffre d’affaires affiché dans Power BI est bien celui que tout le monde connaissait dans Qlik.
Vous préparez une migration Qlik vers Power BI ?
Traduire le set analysis en DAX n’est qu’une partie du travail : il faut aussi repenser le modèle, réécrire les scripts de chargement dans Power Query et accompagner les utilisateurs. Je détaille ma démarche sur la page Migration Qlik vers Power BI.
Si vous voulez un premier avis sur vos applications Qlik ou sur un rapport Power BI déjà migré, je vous propose un diagnostic gratuit de 15 minutes en visio, sans accès à vos données. Pour en savoir plus sur le langage DAX, la documentation officielle de Microsoft est la référence.
Laisser un commentaire