Number.Round : arrondir un nombre dans Power Query

Number.Round arrondit un nombre. Sans autre paramètre, elle arrondit à l’entier le plus proche, et non à deux décimales comme on le lit parfois. Sur une valeur nulle, elle rend null plutôt qu’une erreur.

Number.Round(
    number as nullable number,
    optional digits as nullable number,
    optional roundingMode as nullable number
) as nullable number

C’est le point qui surprend, et celui qui explique le plus souvent un écart de quelques centimes entre un rapport et une extraction comptable.

Number.Round(2.5)   // 2, et non 3
Number.Round(3.5)   // 4
Number.Round(1.234) // 1
Number.Round(1.56)  // 2

Quand la valeur tombe exactement au milieu, Power Query ne monte pas systématiquement : il choisit l’entier pair. C’est l’arrondi dit du banquier, RoundingMode.ToEven. Sur un grand volume de montants, il a l’avantage de ne pas gonfler le total, puisque les cas limites montent et descendent à parts égales. Mais il ne correspond pas à la règle apprise à l’école, ni à celle appliquée par la plupart des logiciels de gestion.

Pour retrouver le comportement attendu, il faut le demander explicitement :

Number.Round(2.5, 0, RoundingMode.AwayFromZero)   // 3
Number.Round(1.2345, 3, RoundingMode.Up)          // 1.235
Number.Round(1.2345, 3, RoundingMode.Down)        // 1.234

Notre règle sur les montants destinés à un usage comptable : ne jamais laisser le mode par défaut implicite. On écrit le mode, même quand il correspond à ce qu’on veut, pour que la relecture six mois plus tard ne laisse aucun doute.

Table.TransformColumns(
    Source,
    {{"Montant", each Number.Round(_, 2, RoundingMode.AwayFromZero), type number}}
)

Une question revient toujours : faut-il arrondir dans la requête ou à l’affichage ? Les deux, mais pas pour la même raison. On arrondit à l’affichage quand il s’agit seulement de lisibilité, et la donnée sous-jacente reste intacte. On arrondit dans la requête quand la valeur arrondie devient la vérité, par exemple parce qu’elle doit correspondre au centime près à une facture émise.

L’erreur consiste à arrondir dans la requête puis à sommer : la somme des arrondis n’égale pas l’arrondi de la somme, et l’écart grandit avec le nombre de lignes. Quand le total doit tomber juste, on somme les valeurs exactes et on arrondit le résultat.

Pourquoi Number.Round(2.5) renvoie-t-elle 2 ?

Parce que le mode par défaut est RoundingMode.ToEven, l’arrondi au pair le plus proche. Pour obtenir 3, il faut écrire Number.Round(2.5, 0, RoundingMode.AwayFromZero).

Quelle différence avec Number.RoundUp et Number.RoundDown ?

Number.RoundUp et Number.RoundDown arrondissent toujours dans la même direction, quel que soit le chiffre suivant. Number.Round arrondit au plus proche et n’utilise son mode que pour départager les cas d’égalité. Pour un plafond ou un plancher, prenez les premières ; pour un arrondi classique, la seconde.

Faut-il arrondir en Power Query ou en DAX ?

En Power Query quand l’arrondi fait partie de la donnée elle-même : le calcul est fait une fois au chargement. En DAX quand il ne concerne que la restitution d’une mesure. Attention toutefois : ROUND en DAX n’applique pas l’arrondi du banquier, ce qui peut créer un écart entre deux calculs censés donner la même chose.

Combien de décimales Number.Round conserve-t-elle par défaut ?

Aucune : l’arrondi se fait à l’entier le plus proche. La croyance selon laquelle le défaut serait deux décimales est fausse. Number.Round(123.456) rend 123.

• Number.Abs : la valeur absolue, souvent utilisée juste avant un arrondi dans les analyses d’écart.
• Table.RowCount : compter les lignes d’une table.
• La référence complète Power Query et DAX.

Sources — documentation officielle de l’éditeur, consultée le 22 août 2026 : Number.Round, Number.RoundDown, Number.RoundUp.