Votre rapport Power BI dit +23 %. Voici pourquoi ce chiffre est peut-être faux.

7 avril 2026 | Non classé

Il y a un type d’erreur en analytique qui ne déclenche aucune alarme. Pas de message d’erreur. Pas de cellule rouge. Juste un chiffre qui a l’air parfaitement raisonnable, et qui est quand même faux.

Le +23 % de croissance dans votre rapport Power BI en fait peut-être partie. Pas parce que quelqu’un a manipulé les données. Pas parce que votre modèle est mal structuré. Mais parce que la comparaison temporelle sous-jacente est silencieusement bancale.

C’est ça, le problème avec l’intelligence temporelle en DAX : quand elle fonctionne bien, personne ne la remarque. Quand elle fonctionne mal, tout le monde applaudit des chiffres qui ne veulent rien dire.

Ce qu’on entend par « intelligence temporelle »

L’intelligence temporelle (ou *time intelligence* en DAX) désigne la capacité à comparer des données à travers le temps de manière fiable, cette année par rapport à l’année dernière, le mois en cours par rapport au mois précédent, le cumulatif depuis le début de l’exercice.

Ce n’est pas une fonctionnalité magique. C’est une logique que vous devez configurer correctement, avec les bons fondements en place. Et ces fondements, c’est la table de dates.

La table de dates : pas optionnelle, pas négociable

Tout le monde a entendu qu’une table de dates est « recommandée ». La réalité est plus directe : sans table de dates bien configurée, vos calculs temporels en DAX sont non fiables par définition.

Voici ce que ça veut dire concrètement.

Power BI a besoin d’une table avec une colonne de dates contiguës, pas de trous, pas de doublons, une ligne par jour calendaire, couvrant au minimum la plage complète de vos données de transaction, idéalement avec quelques années de marge. Cette table doit être marquée comme « table de dates » dans le modèle, et reliée à vos tables de faits via une relation active sur la colonne date.

Sans ça, des fonctions comme `SAMEPERIODLASTYEAR` ou `TOTALYTD` vont parfois fonctionner, parfois produire des résultats étranges, et presque jamais vous avertir de la différence.

La bonne nouvelle : créer une table de dates robuste dans Power Query prend moins de quinze minutes. La mauvaise : la plupart des modèles d’entreprise qu’on audite n’en ont pas une.

Les trois fonctions que tout le monde utilise (et souvent mal)

SAMEPERIODLASTYEAR : la comparaison année sur année

C’est la fonction la plus utilisée en intelligence temporelle. Elle retourne la même période que la sélection actuelle, mais décalée d’un an. En apparence simple. En pratique, c’est là que les erreurs les plus coûteuses se cachent.

Syntaxe DAX:Ventes N-1 = CALCULATE( [Total Ventes], SAMEPERIODLASTYEAR('Calendrier'[Date]) )

Cas d’utilisation concret :

Vous gérez les ventes d’un réseau de cliniques vétérinaires au Québec. Votre rapport mensuel montre les ventes de mars 2024 versus mars 2023.

Ventes Mars 2024 = 142 800 $ Ventes Mars 2023 (N-1) = 118 200 $ Croissance = +20,8 %

Jusqu’ici, tout va bien. Le problème surgit quand votre analyste filtre par « trimestre en cours » au 15 mars. `SAMEPERIODLASTYEAR` va alors comparer le 1er janvier au 15 mars 2024 avec le 1er janvier au 15 mars 2023, ce qui est correct. Mais si votre table de dates s’arrête au 31 décembre 2023, la fonction n’a pas de données de référence pour la période N-1 complète. Résultat : un zéro silencieux, ou pire, une valeur partielle présentée comme complète.

Erreur classique : utiliser SAMEPERIODLASTYEAR sur une colonne date provenant directement de la table de faits, sans passer par une table de dates distincte. La fonction fonctionne techniquement, mais sans la continuité calendaire garantie, le moteur DAX peut sauter des jours manquants et fausser le dénominateur de la comparaison.

DATEADD : la flexibilité, avec ses pièges

DATEADD est la version modulaire de la comparaison temporelle. Elle vous permet de décaler une période de N jours, mois, trimestres ou années, vers l’avant ou vers l’arrière.

Syntaxe :

Ventes Mois Précédent = CALCULATE( [Total Ventes], DATEADD('Calendrier'[Date], -1, MONTH) )

Cas d’utilisation concret :

Vous analysez la performance d’une chaîne de magasins de plein air au Québec. Votre direction veut voir les ventes du mois en cours versus les trois mois précédents, pour détecter une tendance de fond sans se faire piéger par la saisonnalité.

Ventes Mois Actuel (décembre) = 384 000 $ Ventes M-1 (novembre) = 291 000 $ Ventes M-2 (octobre) = 267 000 $ Ventes M-3 (septembre)= 249 000 $

DATEADD avec -1, MONTH compare décembre 2024 à novembre 2024, ce qui semble logique. Mais en décembre, vous avez 31 jours. Novembre en a 30. Si vous êtes au 15 décembre et que votre rapport est en temps réel, `DATEADD` va comparer 15 jours de décembre à… 30 jours complets de novembre? Ou à 15 jours de novembre?

La réponse dépend du contexte de filtre actif. Et c’est précisément là que les équipes perdent confiance dans leurs chiffres.

La règle pratique : quand vous utilisez DATEADD pour des comparaisons partielles (mois non terminé, trimestre en cours), encapsulez toujours votre mesure dans un `CALCULATE` avec un filtre explicite sur les dates disponibles. Sinon, vous comparez des périodes de longueurs différentes sans le savoir.

Ventes M-1 (comparaison juste) = CALCULATE( [Total Ventes], DATEADD('Calendrier'[Date], -1, MONTH), DATESMTD('Calendrier'[Date]) )

TOTALYTD : le cumulatif depuis le début de l’année

TOTALYTD calcule le total depuis le 1er janvier jusqu’à la date sélectionnée. Ou depuis le début de votre exercice fiscal, si vous le précisez. C’est la mesure préférée des rapports de direction — et l’une des plus mal configurées.

Syntaxe :

Ventes YTD = TOTALYTD( [Total Ventes], 'Calendrier'[Date] )

Avec exercice fiscal (ex. : 1er avril au 31 mars) :

Ventes YTD Fiscal = TOTALYTD( [Total Ventes], 'Calendrier'[Date], "03-31" )

Cas d’utilisation concret :

Vous travaillez avec une entreprise de distribution dont l’exercice fiscal se termine le 31 mars. Nous sommes en novembre 2024. Le rapport de direction affiche un YTD de 2,1 M, ce qui semble encourageant comparé aux 1,8 M de l’an dernier à pareille date.

Sauf que personne n’a configuré la date de fin d’exercice dans TOTALYTD. Le calcul par défaut repart du 1er janvier, pas du 1er avril. Vous comparez donc 10 mois d’un exercice à 10 mois d’un exercice différent, mais les deux périodes ne commencent pas au même moment dans le cycle d’affaires de l’entreprise.

-- Ce que le rapport affiche (incorrect) Ventes YTD (janvier à novembre 2024) = 2 100 000 $ Ventes YTD (janvier à novembre 2023) = 1 800 000 $ → +16,7 %

-- Ce que le rapport devrait afficher (fiscal, avril à novembre) Ventes YTD Fiscal 2024-2025 (avril à novembre) = 1 640 000 $ Ventes YTD Fiscal 2023-2024 (avril à novembre) = 1 510 000 $ → +8,6 %

La croissance réelle de l’exercice fiscal est de 8,6 %. Le rapport en annonçait 16,7 %. Personne n’avait menti. La formule avait juste oublié quand commençait l’année.

Le tableau de bord qui valide votre intelligence temporelle

Avant de publier un rapport avec des comparaisons temporelles, trois vérifications s’imposent.

1. Votre table de dates est-elle marquée et connectée?
Dans Power BI Desktop : clic droit sur la table → « Marquer comme table de dates » → confirmer la colonne date. Vérifier que la relation avec la table de faits est active.

2. Vos mesures YTD utilisent-elles la bonne date de fin d’exercice?
Si votre organisation ne fonctionne pas sur l’année calendaire, le paramètre de fin d’exercice dans TOTALYTD n’est pas facultatif. Confirmez la date avec votre équipe comptable.

3. Vos comparaisons partielles sont-elles équitables?
Si vous êtes au 20 du mois et que vous comparez au mois précédent, est-ce que vous comparez 20 jours à 20 jours, ou 20 jours à 30 jours? Ajoutez un filtre DATESMTD si nécessaire.

Ce que ça change, concrètement

L’intelligence temporelle en DAX n’est pas un sujet pour les experts en syntaxe. C’est un sujet pour quiconque prend des décisions basées sur des tendances, ce qui, dans la plupart des organisations, inclut à peu près tout le monde autour de la table de direction.

Un +23 % peut être une vraie bonne nouvelle. Ça peut aussi être le résultat d’une table de dates qui s’arrête trop tôt, d’un exercice fiscal ignoré, ou d’un DATEADD qui compare des mois de longueurs différentes sans que personne ne l’ait demandé.

La différence entre les deux, c’est dix minutes de configuration et une habitude de validation. Pas grand-chose, pour des chiffres sur lesquels vous allez prendre des décisions à six chiffres.

Vous voulez qu’on audite la logique temporelle de vos rapports Power BI existants? C’est exactement le genre de travail qu’on fait – Maverick Analytik