Trois erreurs d'agrégation de données dans les systèmes BI

Pourquoi les systèmes BI mentent : Trois erreurs fatales d'agrégation de données

Les métriques dans les outils BI affichent souvent une précision illusoire. En pratique, dès que les données passent des transactions brutes aux marts pré-agrégés, des distorsions systématiques apparaissent — parfois de dizaines de pourcents. Ce n'est pas un bug ; c'est un compromis architectural entre vitesse et précision. Décomposons trois pièges mathématiques clés qui rendent l'analyse dangereuse pour la prise de décision.

Erreur un : Moyenne de moyennes — Une catastrophe mathématique

Ticket moyen, temps moyen de traitement des requêtes, coût moyen d'une commande — ces métriques ne sont pas additives. On ne peut pas simplement moyenner des valeurs déjà moyennées. Exemple classique : un système BI prend les tickets moyens par magasin pour janvier, février et mars, les additionne et divise par trois pour obtenir la valeur trimestrielle. La formule ressemble à ceci :

SELECT 
    region_name,
    EXTRACT(QUARTER FROM year_month) AS quarter,
    AVG(avg_receipt_amount) AS total_average_check
FROM dwh.store_monthly_aggregated
WHERE EXTRACT(QUARTER FROM year_month) = 1
GROUP BY region_name, EXTRACT(QUARTER FROM year_month);

Le problème, c'est que A/B + C/D ≠ (A+B)/(C+D). Un hypermarché avec 10 000 tickets par jour pèse autant dans le calcul qu'un kiosque avec 50 tickets. Un mois de ventes à pic est mis sur le même plan qu'un mois creuse. Dans les données réelles, cela conduit à des écarts de -6 % à +7 %. Dans le commerce de détail, où chaque point de pourcentage d'augmentation du ticket moyen représente des millions de roubles, de telles distorsions sont inacceptables. Le pire, c'est que quand une coïncidence de dénominateurs produit par hasard le bon résultat — l'erreur se fige dans le DWH comme « correcte ».

Erreur deux : Comptage distinct lors du changement de contexte de filtre

Le comptage d'objets uniques — clients, tickets, produits — s'effondre quand on change de niveau de détail. Imaginez trois transactions :

• Ticket #101 | Épicerie
• Ticket #101 | Boissons
• Ticket #102 | Boissons

Nombre réel de tickets uniques — 2. Mais si les données sont pré-agrégées par catégories :

• Épicerie : 1 ticket (#101)
• Boissons : 2 tickets (#101, #102)

Lors de l'effondrement de la hiérarchie dans Power BI ou un moteur SQL, DAX effectue une simple somme : 1 + 2 = 3. L'unicité est perdue. Le système a compté deux fois le ticket #101. Cette erreur fausse instantanément le ticket moyen, la conversion, le LTV — tout ce qui dépend du comptage d'entités uniques. L'utilisateur ne se rend même pas compte qu'il a changé de vue — et se retrouve avec des chiffres bidons.

Erreur trois : Mesures semi-additives et calendriers rigides

Soldes d'inventaire, soldes de comptes, nombre d'utilisateurs actifs — ce sont des métriques instantanées. Elles peuvent être additionnées dans l'espace (magasins, régions), mais pas dans le temps. Pour contourner cela, les développeurs utilisent des fonctions comme LASTNONBLANK en DAX ou NonEmpty en MDX :

Balance on konets perioda = 
CALCULATE (SUM('Inventory'[Balance]),
    LASTNONBLANK ('Calendar'[Date], 
        CALCULATE(SUM('Inventory'[Balance]))
    ))

Cela crée trois problèmes :

• Performance : Le moteur parcourt toutes les dates de la hiérarchie à chaque changement de filtre. Sur de gros volumes — ça gèle.
• Pannes en conditions réelles : Si le 30, la caisse enregistreuse ne transmet pas les données, le système affiche un solde nul le 31. Les marchandises « disparaissent » d'une valeur de centaines de milliers de roubles.
• Complexité du code : L'utilisateur doit être développeur. Avec plusieurs calendriers métier, les formules deviennent illisibles et fragiles.

Ce qui compte

• L'agrégation tue la précision. La pré-compression des données pour la vitesse est un compromis souvent accepté implicitement sans en saisir les conséquences.
• Les métriques non additives exigent les données brutes. Toute moyenne, médiane, comptage unique — doit être calculée à la volée à partir de l'ensemble des données.
• Les métriques instantanées ne tolèrent pas les frontières temporelles rigides. Le système doit trouver flexiblement la valeur courante, sans suivre aveuglément le calendrier.
• Les utilisateurs BI ne devraient pas écrire de DAX/MDX. L'architecture doit masquer la complexité, pas la déverser sur l'analyste.
• Les nouvelles plateformes abandonnent les pré-agrégations. Le lien dynamique des sources brutes à la volée est la seule voie vers une analyse mathématiquement précise.

Changement de paradigme : Analyse sans compromis

Les systèmes BI classiques sont construits sur une illusion : on peut pré-calculer tout ce dont l'entreprise a besoin. En réalité, les besoins métier changent constamment. Au lieu d'écrire des parades en DAX, les plateformes modernes travaillent directement avec les données brutes. Par exemple, pour calculer la « Couverture de stock » — le ratio inventaire/ventes — on peut combiner deux sources différentes : des milliards de lignes d'inventaire et des milliards de lignes de tickets. Au lieu de construire un mart rigide dans le DWH, le système lie dynamiquement les sources à chaque clic utilisateur, recalculant la métrique avec une précision mathématique. Le cœur même détermine les fenêtres temporelles, trouve les niveaux d'inventaire courants et charge en mémoire uniquement les données nécessaires. Ce n'est pas « plus rapide » ; c'est « correct ». Quand les dirigeants de banque ont vu pour la première fois le vrai temps de traitement des requêtes — sans distorsions des moyennes de moyennes — ils ont commencé à poser les bonnes questions. La chaîne de retail ne veut plus sacrifier le sens pour une limite de 5 millions de lignes. L'analyse doit être un fichier RAW, pas un JPEG. Seule cette approche préserve les détails et la capacité à affiner les insights. La technologie existe — il est temps de repenser notre architecture mentale.

— Editorial Team