Un exemple concret d’utilisation d’UDF dans DAX

Introduction

La fonctionnalité des fonctions définies par l’utilisateur a été introduite en tant que première version d’aperçu avec la version de septembre 2025.

Cette fonctionnalité nous permet d’encapsuler la logique métier dans des fonctions, qui peuvent être appelées comme n’importe quelle autre fonction standard.

Dans cet article, je vais montrer comment utiliser cette fonctionnalité avec un exemple concret : calculer une prévision basée sur les taux d’inflation.

Vous verrez comment créer une fonction simple et gérer un scénario plus complexe.

Scénario

Imaginons une entreprise qui souhaite prévoir ses revenus avec une simulation d’inflation.

Ils souhaitent simuler l’impact de différents taux d’inflation sur leur revenu mensuel.

Par souci de simplicité, nous ignorons la saisonnalité et utilisons le dernier montant de ventes mensuel connu pour calculer les revenus futurs pour le reste de l’année.

L’utilisateur doit être capable de définir un taux d’inflation et de voir comment les chiffres changent.

Préparer le modèle de données

Maintenant, cela dépend si je commence avec un nouveau fichier Power BI et charge les données ou si j’ajoute cette fonctionnalité à un fichier existant.

La première chose à faire est d’activer la fonctionnalité Aperçu :

Vous pourriez être obligé de redémarrer Power BI Desktop après l’avoir activé.

Pour un fichier Power BI existant, nous devons définir le niveau de compatibilité correct pour créer des fonctions définies par l’utilisateur (UDF).

Vous pouvez soit créer une fonction factice, qui mettra automatiquement à niveau le niveau de compatibilité, soit utiliser Éditeur tabulaire pour le régler à au moins 1702 :

Vous pouvez saisir 1702 dans le champ marqué et l’enregistrer.

Je montrerai comment créer un UDF simple plus tard dans cet article.

Veuillez consulter la documentation Microsoft pour en savoir plus sur la création d’une nouvelle UDF dans Power BI Desktop. Vous pouvez trouver le lien dans la section références à la fin de cet article.

Ajout de la sélection de tarifs

Comme l’utilisateur doit pouvoir sélectionner le taux d’inflation, j’ajoute un paramètre au modèle de données :

Après avoir cliqué sur « Plage numérique » je remplis le formulaire :

Puisque je souhaite contrôler le pourcentage, j’ai défini la plage entre -0,02 et 0,05, ce qui correspond à -2 % à 5 %.

Après quelques secondes, le nouveau slicer a été automatiquement ajouté à la page du rapport.

Mais il n’affiche que les nombres décimaux.
Je dois changer le format des nombres pour voir les pourcentages :

Maintenant, le slicer affiche le numéro selon les besoins :

Il est maintenant prêt à être utilisé.

Écrivez la première fonction

Tout d’abord, créons un UDF pour renvoyer le taux sélectionné.

Je préfère l’écrire dans Tabular Editor, car son éditeur DAX est beaucoup plus rapide que Power BI Desktop.

Mais vous pouvez également le créer dans la vue Requête DAX dans Power BI Desktop.

Dans l’éditeur tabulaire, je vais sur le nœud Fonctions, je fais un clic droit dessus et je sélectionne « Nouvelle fonction définie par l’utilisateur » :

Maintenant, je peux définir un nom.

Pour ce premier, j’ai défini « ReturnRate ».

Voici le code de la fonction :

(
    Rate : DECIMAL VAL
)

=>
Rate

Entre parenthèses, je définis le paramètre Input.

Après le => je peux saisir le code DAX de la fonction.

Dans ce cas, je renvoie le paramètre Input.

Maintenant, je crée une mesure pour utiliser cette fonction :

Get Inflation rate = ReturnRate([Inflation rate Value])

La mesure [Inflation rate Value] a été créé lorsque j’ai créé le paramètre pour sélectionner le taux d’inflation.

Lorsque j’ajoute une carte et que je lui attribue la nouvelle mesure, je vois la valeur sélectionnée dans le slicer :

OK, c’est une fonction élémentaire, mais c’est uniquement pour illustrer son fonctionnement.

Écrivez la vraie fonction

Vous avez peut-être remarqué le mot-clé VAL dans la définition du paramètre.

Comme vous pouvez le lire plus en détail dans les deux articles ci-dessous, nous disposons de deux modes pour passer des paramètres :

• VAL : Passer le contenu du paramètre tel quel.
• EXPR : transmettez le paramètre sous forme d’expression, qui peut être utilisée dans la fonction comme une mesure habituelle.

Dans la fonction suivante, j’utilise les deux.

Voici le code complet de la fonction MonthlyInflation:

(
    Rate : DECIMAL VAL
    ,InputVal : EXPR
)
=>

VAR CurrentMonth =  MAX( 'Date'[MonthKey] )

VAR LastMonthWithData = CALCULATE(
                                LASTNONBLANK( 'Date'[MonthKey]
                                    , InputVal
                                )
                            , ALLEXCEPT( 'Date', 'Date'[Year] )
                        )
                        
VAR LastValueWithData = CALCULATE(InputVal
                                        ,ALLEXCEPT('Date', 'Date'[Year])
                                        ,'Date'[MonthKey] = LastMonthWithData
                                    )
                            
VAR MonthDiff = CurrentMonth - LastMonthWithData
VAR Result = IF(MonthDiff<=0
                    ,InputVal
                    ,(1 + ( Rate * MonthDiff ) ) * LastValueWithData
                    )

                                    
RETURN
    Result

Le premier paramètre de la fonction est comme avant.

Le deuxième paramètre sera l’expression de la mesure d’entrée.

Dans la fonction, je peux utiliser le nom du paramètre pour modifier le contexte du filtre et d’autres choses. Je dois définir le paramètre comme EXPR quand j’ai besoin de travailler de cette manière au sein de la fonction.

La fonction effectue les étapes suivantes :

1. J’obtiens la MonthKey la plus élevée et la stocke dans la variable CurrentMonth
   Le contenu est le mois du contexte de filtre actuel sous la forme numérique AAAAMM.
2. J’obtiens le dernier mois de l’année en cours avec une valeur du paramètre d’entrée (mesure) et je le stocke dans la variable LastMonthWithData
3. Je soustrais le mois en cours du dernier mois avec des données pour obtenir la différence. Ce sera le facteur pour calculer le taux d’inflation. Le résultat est stocké dans la variable MonthDiff
4. Si MonthDiff est inférieur ou égal à 0, alors le contexte de filtre (Mois) contient une valeur de la variable d’entrée
5. Sinon, le contexte du filtre (Mois) est dans le futur, et nous pouvons calculer le résultat.

Ce que je fais ici, c’est multiplier le taux d’inflation sélectionné par le nombre de mois depuis le dernier mois avec les données (LastMonthWithData).

Désormais, je peux créer une mesure pour calculer dynamiquement la prévision mois par mois en fonction du taux d’inflation sélectionné :

Online Sales With Inflation =
    MonthlyInflation([Inflation rate Value], [Sum Online Sales])

Voici le résultat pour un taux d’inflation de 3 % :

Les mois marqués en bleu contiennent des données réelles et les mois marqués en rouge sont calculés en fonction du taux d’inflation sélectionné.

La beauté est que je peux transmettre n’importe quelle expression DAX à la mesure que je souhaite.

Par exemple, je peux ajouter les ventes en ligne aux ventes au détail :

La mesure pour cela est la suivante :

Total Sales With Inflation =
    MonthlyInflation([Inflation rate Value], [Sum Online Sales] + [Sum Retail Sales])

Eh bien, c’est très simple.

Je sais que le calcul est très simpliste, mais j’ai utilisé cet exemple pour montrer ce qui peut être fait avec les UDF.

À quoi ça sert ?

Alors, c’est ça le but des UDF ?

La plupart des choses présentées ici peuvent également être réalisées avec des groupes de calcul.

Eh bien, c’est vrai.

Mais utiliser une FDU est beaucoup plus simple que d’utiliser un élément de calcul.

De plus, nous pouvons écrire des UDF indépendantes du modèle et les réutiliser dans plusieurs modèles.

Jetez un oeil à Étendre Power BI avec DAX Lib.

Il s’agit d’une collection croissante de UDF indépendantes du modèle contenant une logique qui peut être utilisée dans n’importe quel modèle de données.

Les autres points de différenciation entre les FDU et les éléments de calcul sont :

• Les FDU ne peuvent pas être regroupées, mais les éléments de calcul peuvent être regroupés dans des groupes de calcul.
• Les éléments de calcul n’ont pas de paramètres.
• UDF peut être directement appelé comme n’importe quelle autre fonction DAX.

Essayez-le pour en savoir plus sur les possibilités des UDF.

Conclusion

sont un excellent ajout à l’ensemble d’outils de Power BI et Fabric.

Je suis sûr qu’il deviendra de plus en plus important de savoir comment travailler avec les FDU, à mesure que leur potentiel deviendra plus évident au fil du temps.

Comme nous n’en sommes qu’aux premiers stades de l’introduction de cette fonctionnalité, nous devons rester à l’écoute pour voir ce que Microsoft fera ensuite pour l’améliorer.

Il existe certaines restrictions dans cette fonctionnalité. Vous les trouvez ici : Considérations et limites des fonctions définies par l’utilisateur DAX.

Il y a suffisamment de place à l’amélioration.

Voyons ce qui va suivre.

Références

Ici, la documentation Microsoft pour les fonctions définies par l’utilisateur : Utilisation des fonctions définies par l’utilisateur DAX (préversion) – Power BI | Microsoft Apprendre.

Il s’agit de l’article SQL BI qui explique la fonctionnalité en détail : Présentation des fonctions définies par l’utilisateur dans DAX – SQLBI.

Une collection d’UDF gratuits et indépendants du modèle : Étendre Power BI avec DAX Lib.

Comme dans mes articles précédents, j’utilise l’exemple de jeu de données Contoso. Vous pouvez télécharger gratuitement l’ensemble de données ContosoRetailDW depuis Microsoft. ici.

Les données Contoso peuvent être utilisées librement sous la licence MIT, comme décrit dans ce document. J’ai modifié l’ensemble de données pour déplacer les données vers des dates contemporaines.