Tests et fiabilité des chiffres

Ce thème mesure la confiance que l'on peut mettre dans un chiffre et la preuve qu'on en a. Il couvre la réconciliation avec la source, les tests de mesures par requêtes DAX (DAX Studio…

Guide≈ 7 min de lectureVérifiéLecture

En bref

Ce thème mesure la confiance que l'on peut mettre dans un chiffre et la preuve qu'on en a. Il couvre la réconciliation avec la source, les tests de mesures par requêtes DAX (DAX Studio, SSMS, API d'exécution de requêtes), les analyses statiques (Best Practice Analyzer de Tabular Editor), les tests de non-régression, les jeux de données de référence et la recette métier. Les tests de code généraux sont dans DL — tests ; la qualité de la donnée en amont dans PD — qualité.

Sur cette page

1. Pourquoi ce thème
2. Ce que mesure le thème
3. Les 5 niveaux
4. Jalons par niveau
5. Lecture détaillée par niveau
6. Atteinte partielle et notation
7. Passer au niveau suivant
8. Voir aussi

Niveau : 🟢→🔴 · Code thème : TST

1. Pourquoi ce thème#

Un rapport faux détruit plus de valeur qu'un rapport absent : la confiance se perd en une réunion et se regagne en six mois. Les erreurs BI sont silencieuses : une relation modifiée, un filtre oublié, un changement de grain en source produisent des totaux plausibles mais faux. Contrairement au code applicatif, on n'a pas d'exception ni de plantage : seul un test peut dire « ce chiffre est faux ». Un modèle sans test est un modèle dont on a peur.

2. Ce que mesure le thème#

Axe : du contrôle visuel ponctuel à une non-régression automatique qui bloque la livraison.
Indicateurs clés : part des mesures couvertes par un test ; part des livraisons précédées d'un jeu de tests complet ; nombre d'écarts de chiffres découverts par les utilisateurs plutôt que par l'équipe ; durée de détection.
Unités : %, nombre d'écarts/trimestre, heures.

3. Les 5 niveaux#

Niveau	Nom court	Promesse	Indicateur type (ordre de grandeur)
1	Coup d'œil	Le chiffre a été regardé par son auteur le jour de la livraison.	0 test conservé ; recette = capture d'écran
2	Contrôles notés	Chaque livraison majeure a un jeu de contrôles manuels écrits et signés.	Check-list renseignée ; écarts tracés
3	Requêtes rejouables	Un contrôle se rejoue à l'identique en quelques minutes par n'importe quel membre de l'équipe.	≥ 50 % des mesures clés couvertes par une requête
4	En pipeline	Une régression sur un chiffre clé arrête la livraison avant les utilisateurs.	≥ 80 % des mesures clés testées automatiquement ; BPA en pipeline
5	Garanti	Les écarts sont détectés en production avant les utilisateurs, et chaque incident ajoute un test.	0 écart découvert par un utilisateur sur 6 mois

4. Jalons par niveau#

ID	Jalon	Preuve vérifiable
BI-TST-1.1	L'auteur compare au moins un total à la source	Trace du contrôle
BI-TST-1.2	Un utilisateur métier a vu le rapport avant publication	Mention de relecture
BI-TST-1.3	Les écarts connus sont reconnus par écrit	Liste des écarts connus
BI-TST-2.1	Check-list de recette par rapport (totaux, filtres, périodes limites)	Check-list renseignée
BI-TST-2.2	Les données de contrôle ont une source de vérité (requête SQL, extraction de référence)	Requête de référence conservée
BI-TST-2.3	Écarts tolérés explicites (arrondis, décalages de fuseau, clôture)	Seuil écrit
BI-TST-2.4	Recette métier signée avant mise en production	Validation signée
BI-TST-3.1	Requêtes DAX de test conservées en dépôt (une par mesure clé)	Fichiers `.dax` versionnés
BI-TST-3.2	Valeurs attendues provenant de SQL indépendant, pas de la mesure elle-même	Comparaison croisée
BI-TST-3.3	Jeu de données de référence stable (jeu figé ou instantané)	Jeu documenté
BI-TST-3.4	Cas limites testés : période vide, filtre unique, total, début/fin d'année, valeurs nulles	Cas dans le jeu de tests
BI-TST-3.5	Best Practice Analyzer exécuté régulièrement sur le modèle	Rapport BPA
BI-TST-4.1	Les tests s'exécutent automatiquement (script ou pipeline)	Journal d'exécution
BI-TST-4.2	Un test en échec bloque la promotion (IND)	Politique de blocage
BI-TST-4.3	Tests de sécurité par rôle (voir RLS) inclus	Résultats par rôle
BI-TST-4.4	Tests de performance de référence inclus (PRF)	Seuils
BI-TST-4.5	Tests de schéma (colonnes attendues) avant rafraîchissement (ETL)	Alerte de schéma
BI-TST-5.1	Contrôles de réconciliation planifiés en production (source ↔ modèle)	Tableau des contrôles
BI-TST-5.2	Chaque incident débouche sur un test de non-régression	Lien incident ↔ test
BI-TST-5.3	Seuils d'alerte statistiques (écart inhabituel, rupture de tendance)	Alertes tracées
BI-TST-5.4	Couverture mesurée (mesures, cas limites, rôles) et publiée	Indicateur de couverture

5. Lecture détaillée par niveau#

🟢 Niveau 1 — Coup d'œil#

Signes : « ça a l'air bon », aucun test conservé, les chiffres ne sont comparés à rien.
Difficulté : 1/5 · Effort : 1/5.

🟢 Niveau 2 — Contrôles notés#

Signes : check-list écrite : total par mois = total SQL ; filtre « France » = somme des filtres régionaux ; un mois sans données ne plante pas. Les écarts sont notés et signés par le métier.
Gain : première trace ; recette partagée.
Limite : lent, manuel, rarement refait aux évolutions suivantes.
Difficulté : 2/5 · Effort : 2/5.

🟡 Niveau 3 — Requêtes rejouables#

Un test de mesure est une requête DAX avec un attendu indépendant :

// tests/Nb_Visites_Realisees.dax
DEFINE
    VAR vAttendu = 12345      // issu d'une requête SQL de référence, jeu figé 2026-09
EVALUATE
ROW (
    "Mesure",  [Nb Visites Réalisées],
    "Attendu", vAttendu,
    "OK",      [Nb Visites Réalisées] = vAttendu
)

Un second test vérifie la cohérence interne : somme par région = total ; total mensuel = total annuel.

EVALUATE
VAR vSomme = SUMX ( VALUES ( 'DIM_COMMERCIAL'[Region] ), [Nb Visites Réalisées] )
RETURN ROW ( "Somme", vSomme, "Total", [Nb Visites Réalisées],
             "OK", vSomme = [Nb Visites Réalisées] )

Signes : les requêtes sont en dépôt ; n'importe qui les lance dans DAX Studio, SSMS ou un script. Best Practice Analyzer (Tabular Editor) détecte des défauts de modèle (colonnes numériques résumées, relations bidirectionnelles, formats manquants, colonnes inutilisées) sans exécuter de calcul.
Gain : le test coûte des minutes, pas des heures.
Limite : exécution encore manuelle ; la dérive entre test et mesure n'est pas détectée automatiquement.
Difficulté : 3/5 · Effort : 3/5.

✅ Bonne pratique

L'attendu doit venir d'un chemin de calcul indépendant (SQL sur la source, pas la même logique recopiée en DAX). Un test qui reprend la même logique se trompe de la même façon.

⚠️ Piège

Symptôme : tous les tests passent, l'utilisateur voit un écart. Cause : tests faits sans filtre, sur un total ; l'écart n'apparaît qu'avec un filtre de segment ou sous un rôle RLS. Remède : tester les croisements fréquents (période × région) et chaque rôle.

🟡 Niveau 4 — En pipeline#

Signes : le pipeline (IND) charge le modèle de test, exécute les requêtes (API d'exécution de requêtes, XMLA, ou outil en ligne de commande), compare, publie le résultat. Un échec bloque la promotion. BPA tourne avec règles configurées (quelques règles « bloquantes », d'autres en avertissement).
Gain : la régression ne passe pas silencieusement.
Limite : tests flous (seuil trop laxiste) ou instables (jeu de données variable).
Difficulté : 4/5 · Effort : 4/5.

🧪 Exemple

Fil rouge SFA : après un renommage de colonne côté datamart, un test de schéma échoue avant déploiement ; sans lui, la mesure [Nb Visites Réalisées] aurait retourné 0 sans erreur (colonne introuvable gérée en BLANK dans le visuel).

💡 Astuce d'expert

Distingue trois familles de tests : justesse (valeur attendue), cohérence (invariants : somme des parties = total, N-1 de N = N-1 saisi), comportement (période vide, filtre exclu, rôle). Les invariants sont les plus robustes aux changements de jeu de données.

🔴 Niveau 5 — Garanti#

Signes : contrôles de réconciliation planifiés en production ; alertes sur rupture statistique (une région tombe à zéro) ; chaque incident ajoute un test ; la couverture (mesures, cas limites, rôles) est publiée.
Gain : l'équipe apprend de ses erreurs de façon systématique.
Limite : tests à entretenir ; faux positifs ; budget de maintenance.
Difficulté : 5/5 · Effort : 5/5.

🤖 IA

Un assistant génère un squelette de tests DAX par mesure et propose des cas limites que l'on oublie. Il ne peut pas fournir l'attendu : celui-ci vient du métier ou de SQL. Danger : tests auto-générés qui rejouent la mesure et « passent » toujours.

6. Atteinte partielle et notation#

Règle commune. Mesure par échantillon : parmi 10 mesures clés, combien ont une requête de test, un attendu indépendant, un déclenchement automatique ? « Un 5 partiel » : les réconciliations de production existent pour les 5 faits principaux (BI-TST-5.1 = 0,5), le lien incident ↔ test est tenu depuis 4 mois (5.2 = 1), pas d'alerte statistique (5.3 = 0), couverture suivie en interne mais non publiée (5.4 = 0,5).

7. Passer au niveau suivant#

Moyens possibles (facultatifs) :

Passage	Leviers possibles
1 → 2	Check-list de recette ; requêtes SQL de référence ; seuils d'écart
2 → 3	Fichiers `.dax` en dépôt ; jeu de données figé ; Tabular Editor/BPA
3 → 4	Exécuteur de tests (script PowerShell/Python) ; blocage de promotion ; tests de schéma et de rôles
4 → 5	Réconciliation planifiée ; alertes statistiques ; revue d'incident → test

Pièges :

Faux positif : une couverture à 90 % de tests qui rejouent la logique de la mesure.
Goodhart : viser un taux de couverture → tests triviaux (COUNTROWS > 0). Évalue la capacité des tests à échouer quand on casse volontairement quelque chose (test de mutation manuel).
Tester seulement le chemin heureux : les défauts vivent aux bords (premier jour, dernier jour, valeurs nulles, doublons de clé).
Le jeu de données de test non représentatif : cardinalités et volumes irréalistes cachent les problèmes de performance.

8. Voir aussi#

Thèmes voisins : DAX · MOD · IND · RLS · OPS
Autres matrices : DL — tests · PD — qualité des données · PD — recette et validation métier · PI — qualité et recette
Contenus : Checklist de projet reporting · Bonnes pratiques Power BI transverses · CI/CD pour la data · GDS et données SQL/BI

✻ Rédigé par Claude Sonnet 5.5