Référence DAX · 7 min de lecture

Créer une colonne cumulée dans Power BI

Le cumul progressif d’Excel, transposé dans un moteur qui ne connaît pas la notion de cellule précédente. Avec la formule historique, et celle qu’on écrit aujourd’hui.

Mis à jour le

Dans Excel, un cumul se fait en additionnant la cellule du dessus. Power BI n’a pas de cellule du dessus : une ligne ne connaît pas sa voisine, et l’ordre d’affichage ne veut rien dire pour le moteur. Il faut donc lui donner un moyen explicite de dire « toutes les lignes qui viennent avant celle-ci ».

Ce moyen est une colonne qui ordonne les données : une date, ou un index numérique. Sans elle, le cumul est impossible à définir.

Étape 1

Disposer d’une colonne qui ordonne

Deux options, selon la nature des données.

Une colonne de date quand les lignes ont un sens chronologique, ce qui est le cas le plus fréquent. C’est la solution à préférer, parce qu’elle reste juste si des lignes sont ajoutées, supprimées ou rechargées dans un autre ordre.

Une colonne d’index sinon, ajoutée en Power Query par Ajouter une colonne, puis Colonne d’index. Attention : un index créé au chargement se recalcule à chaque actualisation. Si l’ordre de la source change, le cumul change aussi. On ne l’utilise que sur des données dont l’ordre est stable et signifiant.

Étape 2

La formule historique, avec EARLIER

C’est la formule que l’on trouve partout, et celle que vous êtes probablement venu chercher. Sur une table nommée Table, avec une colonne Colonne 1 à cumuler et une colonne index qui ordonne :

Cumul =
CALCULATE(
    SUM( 'Table'[Colonne 1] ),
    FILTER( 'Table', EARLIER( 'Table'[index] ) >= 'Table'[index] )
)

Le mécanisme mérite d’être compris plutôt que recopié. Dans une colonne calculée, DAX évalue la formule ligne par ligne. Quand FILTER parcourt à son tour la table, il ouvre un second parcours, et 'Table'[index] désigne alors la ligne du parcours intérieur. EARLIER permet de remonter d’un cran pour retrouver l’index de la ligne courante, celle pour laquelle on calcule.

La condition se lit donc : garder toutes les lignes dont l’index est inférieur ou égal à celui de la ligne en cours, puis en sommer les montants.

Étape 3

La version qu’on écrit aujourd’hui

EARLIER fonctionne toujours, mais il n’est plus la manière recommandée d’écrire ce calcul. Une variable capture la valeur de la ligne courante avant d’entrer dans le parcours intérieur, ce qui rend l’intention lisible sans avoir à raisonner sur des contextes imbriqués.

Cumul =
VAR IndexCourant = 'Table'[index]
RETURN
    CALCULATE(
        SUM( 'Table'[Colonne 1] ),
        FILTER( ALL( 'Table' ), 'Table'[index] <= IndexCourant )
    )

Deux différences avec la version historique. La variable dit explicitement ce qu’on capture, et n’importe quel lecteur comprend la formule sans connaître EARLIER. Et ALL garantit que le filtre part bien de la table entière, ce qui évite un cumul faussé si un filtre est déjà appliqué.

Sur une colonne de date plutôt qu’un index, le principe est identique :

Cumul =
VAR DateCourante = 'Ventes'[Date]
RETURN
    CALCULATE(
        SUM( 'Ventes'[Montant] ),
        FILTER( ALL( 'Ventes' ), 'Ventes'[Date] <= DateCourante )
    )
Le conseil

Dans un rapport, préférez une mesure

Une colonne calculée fige le cumul au chargement. Elle occupe de la mémoire sur chaque ligne, elle ne réagit à aucun filtre, et surtout elle donne un résultat faux dès que l’utilisateur filtre le rapport : le cumul reste celui qui a été calculé sur la table entière.

Une mesure, elle, se recalcule dans le contexte du visuel. Le cumul suit la sélection de l’utilisateur, ce qui est presque toujours ce qu’on veut.

La colonne calculée garde deux usages légitimes : quand la valeur cumulée doit servir d’axe, de segment ou de critère de tri, et quand elle constitue une donnée en soi, comme un solde progressif attaché à la ligne. En dehors de ces cas, la mesure gagne.

Pour les cumuls calculés en mesure, cumul annuel, total depuis l’origine, moyennes mobiles, les fonctions de temps de DAX offrent des écritures plus courtes et plus robustes. Elles supposent en revanche une vraie table de dates reliée au modèle et marquée comme telle, sujet que nous détaillons dans créer un calendrier dynamique.

Questions fréquentes

Ce qu’on nous demande sur les colonnes cumulées

Pourquoi mon cumul répète-t-il la même valeur sur plusieurs lignes ?

Parce que la colonne qui ordonne contient des valeurs en double. Si deux lignes portent la même date, elles obtiennent le même cumul, qui inclut les deux. Ajoutez un index pour départager, ou acceptez le cumul par date en regroupant d’abord.

Faut-il utiliser EARLIER ou une variable ?

Une variable. EARLIER reste pris en charge et vous le croiserez dans beaucoup de modèles existants, mais une formule écrite avec VAR se relit sans effort et se modifie sans risque de se tromper de contexte.

Peut-on cumuler par catégorie ?

Oui, en capturant aussi la catégorie dans une variable et en l’ajoutant à la condition du filtre : 'Table'[Catégorie] = CategorieCourante && 'Table'[index] <= IndexCourant. Chaque catégorie repart alors de zéro.

Le cumul est-il coûteux sur une grande table ?

Oui, parce que chaque ligne déclenche un parcours de la table. Sur quelques milliers de lignes le coût passe inaperçu ; sur plusieurs millions il devient sensible, et c’est un argument de plus en faveur de la mesure, qui ne calcule que ce que le visuel affiche.

À côté

Ce qu’on lit ensuite

Sources — documentation officielle de l’éditeur, consultée le 22 août 2026 : CALCULATE, FILTER, ALL.

Des cumuls qui ne suivent pas les filtres ?

Colonnes calculées là où il fallait des mesures, modèle sans table de dates : nous auditons la structure et remettons les calculs au bon endroit.

Demander un audit ou 01 83 64 60 25
01 83 64 60 25 Réserver un appel