IA & Automatisation · Power BI

Le total qui ne dit pas tout

Un classement, un pourcentage cumulé et un rapprochement budgétaire sans clé commune : trois façons de faire dire à un grand livre ce qu'un total, lui, ne montre jamais.

Dans le cadre de la rubrique « Je partage mes connaissances », je vous propose de refermer une question restée ouverte depuis le début de cette série sur l'analyse des charges : sur les dix-sept comptes du plan comptable, lesquels comptent vraiment, et où l'exercice est-il sorti du budget ? Un total seul ne répond à aucune des deux questions. Il faut le décomposer pour voir apparaître ce qu'il cache — et il cache toujours quelque chose.

Graphique des charges classées par montant décroissant, avec la courbe du pourcentage cumulé — Deux comptes sur huit franchissent la barre des 80 % de charges cumulées. Le troisième n'ajoute déjà presque rien.

Classer avant de peser

Un compte de charges n'a pas de rang par défaut : il faut le calculer, et le recalculer à chaque filtre posé sur la page. L'itérateur RANKX classe une table entière d'après une mesure, ligne par ligne, sans qu'aucune colonne triée n'existe nulle part dans le modèle :

Rang charge =
IF (
    NOT ISBLANK ( [Charges] ),
    RANKX ( ALL ( PlanComptable[Compte] ), [Charges], , DESC, Dense )
)

Le test NOT ISBLANK n'est pas une précaution de style. Sans lui, les neuf comptes de bilan — clients, fournisseurs, banque, amortissements — reçoivent eux aussi un rang, et viennent polluer un classement qui ne devrait porter que sur les charges.

Compte	Libellé	Charges 2026	Rang
641000	Rémunérations du personnel	45 000,00	1
645000	Charges de sécurité sociale	9 600,00	2
601000	Achats de matières premières	3 200,50	3
613000	Locations	3 200,00	4

Les rangs 3 et 4 tiennent à cinquante centimes d'écart. Le classement est juste, mais il ne tient à rien : le jour où deux comptes afficheront un montant strictement égal, Dense et Skip ne donneront plus le même rang au compte suivant. Le choix entre les deux se décide avant d'écrire la formule, pas après avoir constaté l'écart sur les données du mois.

Le double sens d'un pourcentage

Un rang dit qui est devant. Il ne dit pas de combien. La mesure du pourcentage du total répond à la deuxième question :

% du total des charges =
DIVIDE (
    [Charges],
    CALCULATE ( [Charges], REMOVEFILTERS ( PlanComptable ) )
)

REMOVEFILTERS porte ici sur la table PlanComptable, pas sur le calendrier : le dénominateur reste le total de l'exercice affiché, jamais celui des deux exercices confondus. Ajouter un second REMOVEFILTERS sur le calendrier casserait la somme à 100 % dans le tableau — la façon la plus rapide de perdre la confiance d'un lecteur qui additionne une colonne de pourcentages de tête.

Le pourcentage cumulé va un cran plus loin. Pour chaque compte, il rassemble tous les comptes dont la charge est au moins aussi élevée, en additionne les montants, puis divise par le total — un calcul qui reste juste même si le lecteur retrie le tableau dans l'autre sens, parce qu'il ne dépend d'aucun ordre d'affichage, seulement des montants eux-mêmes.

Compte	% du total	% cumulé
641000	68,61 %	68,61 %
645000	14,64 %	83,25 %
601000	4,88 %	88,13 %

Deux comptes sur huit dépassent 80 % : la rémunération du personnel et les charges sociales qui l'accompagnent mécaniquement. Les six comptes restants pèsent ensemble moins de 17 % de l'exercice — une décision de gestion prise isolément sur l'un d'eux ne changerait presque rien à l'équilibre global, alors qu'une décision sur le premier compte, elle, se voit immédiatement dans le résultat.

Une étiquette qui suit le nombre, pas l'inverse

Table des comptes avec une étiquette de poids calculée par SWITCH : poste majeur, significatif ou secondaire — L'étiquette n'est pas saisie à la main : elle se recalcule à chaque filtre, en même temps que le pourcentage qui la produit.

Classer un compte en « poste majeur » ou « poste secondaire » à la main tient un mois, jusqu'au prochain exercice où les montants auront bougé et où le classement sera resté figé dans une colonne qu'il faudra corriger partout. SWITCH ( TRUE (), … ) pose la même question à chaque ligne, avec la mesure en entrée plutôt qu'une valeur saisie :

Poids du poste =
VAR Part = [% du total des charges]
RETURN
SWITCH (
    TRUE (),
    ISBLANK ( Part ), BLANK (),
    Part > 0.20, "Poste majeur",
    Part >= 0.05, "Poste significatif",
    "Poste secondaire"
)

Les conditions se lisent dans l'ordre, et la première vraie l'emporte. Intervertir les deux seuils rangerait la rémunération du personnel parmi les postes « significatifs » alors qu'elle pèse plus des deux tiers de l'exercice à elle seule — une erreur d'ordre, pas de calcul, et c'est la plus difficile à repérer à la relecture parce que la formule reste syntaxiquement correcte.

Une réserve à connaître avant de s'enthousiasmer sur ce pattern : une mesure de ce type ne peut pas devenir un axe de découpage dans un visuel ni un segment, parce qu'elle est recalculée à chaque cellule et n'existe nulle part comme colonne stockée. Segmenter réellement demanderait une table de seuils reliée au modèle — un chantier pour un prochain article, pas pour celui-ci.

Rapprocher un budget qui n'a pas de clé

La table du budget n'a jamais été reliée au reste du modèle, et ce n'est pas un oubli. Elle est saisie ailleurs, à une granularité de fin de mois, sans identifiant technique commun avec le grand livre — une situation plus fréquente en entreprise qu'une relation propre entre deux tables. Créer une relation obligerait à fabriquer une table de correspondance qui n'existe pas naturellement. TREATAS fait le travail directement dans la mesure : il applique les valeurs d'une colonne comme filtre sur une autre colonne, sans qu'aucune relation n'existe entre les deux tables.

Budget alloue =
CALCULATE (
    SUM ( Budget[MontantBudget] ),
    TREATAS ( VALUES ( PlanComptable[Compte] ), Budget[Compte] ),
    TREATAS ( VALUES ( Calendrier[Date] ), Budget[Date] )
)

Ecart budget =
VAR Reel = [Charges]
VAR Alloue = [Budget alloue]
RETURN
IF (
    NOT ISBLANK ( Reel ) || NOT ISBLANK ( Alloue ),
    ( Reel + 0 ) - ( Alloue + 0 )
)

Le + 0 n'est pas cosmétique. Sans lui, un compte dépensé mais jamais budgété donnerait « 185,00 moins vide », c'est-à-dire vide — et l'anomalie disparaîtrait purement et simplement du rapport, remplacée par une case blanche qu'un lecteur pressé ne remarque même pas.

Un écart net proche de zéro n'est pas une preuve

Table de rapprochement budgétaire faisant apparaître un compte budgété non consommé et un compte consommé non budgété — Le total de l'écart vaut −14,50 € sur 65 600 € de budget. Le détail montre deux anomalies opposées qui se compensent presque exactement.

Compte	Charges	Budget alloué	Écart
606100	1 450,00	800,00	+650,00
601000	3 200,50	3 000,00	+200,50
627000	185,00	—	+185,00
621000	—	1 200,00	−1 200,00
Total	65 585,50	65 600,00	−14,50

Un tableau de bord qui n'affiche que la dernière ligne conclut à un exercice parfaitement tenu. Le détail dit autre chose. Le compte 621000, personnel extérieur, porte 1 200,00 € de budget et aucune écriture : une prestation prévue et jamais réalisée, ou une facture qui n'est simplement pas encore arrivée. Le compte 627000, services bancaires, porte 185,00 € de charges sans une seule ligne de budget en face : une dépense réelle, faible, mais totalement absente du prévisionnel.

Le premier de ces deux comptes ne pouvait apparaître dans aucun rapport construit à partir du seul grand livre, puisqu'il n'existe aucune écriture à y trouver. C'est la raison pour laquelle le tableau se construit sur le plan comptable — le référentiel des comptes possibles — et non sur les transactions effectivement passées : un axe d'analyse pris dans les transactions ne montre jamais ce qui aurait dû avoir lieu et qui n'a pas eu lieu.

Deux choses à retenir, et elles dépassent largement ce modèle : un écart net proche de zéro n'est pas une preuve de maîtrise, et un axe d'analyse doit toujours venir du référentiel, jamais des transactions elles-mêmes.

La série revient à son point de départ : dans le chiffre faux qui a l'air juste, une variable figée dans un CALCULATE renvoyait un résultat plausible et pourtant erroné — exactement le genre d'erreur silencieuse qu'un rapprochement mal construit, comme celui de cet article, produirait tout aussi facilement.

Versions : article rédigé d'après Power BI Desktop, mise à jour d'août 2026 (interface en français). Les fonctions DAX utilisées (CALCULATE, SUM, DIVIDE, ALL, REMOVEFILTERS, RANKX, SWITCH) sont disponibles dans les versions actuelles ; les noms de menus peuvent changer au fil des mises à jour mensuelles.