Deux tableaux de bord, deux chiffres : quelle définition fait foi ?
Deux rapports donnent des résultats différents ? Comparez les définitions, les périmètres et les calculs avant de corriger votre reporting.
Publié le · À propos des dates
Mis à jour le
Le comité commence par une question simple : combien de clients sont actifs ? Deux équipes apportent deux réponses. Les extractions sont récentes, les calculs semblent corrects et chacune peut expliquer sa méthode. Pourtant, la discussion sur les actions à engager attendra.
Dans cette situation, refaire le tableau de bord risque de déplacer le problème. Il faut d’abord déterminer si les deux indicateurs mesurent réellement la même chose. Une donnée peut être techniquement exacte et répondre à une question différente de celle que le décideur croit poser.
Le point de vue Spark
Un indicateur devient utile lorsque sa définition, son périmètre et son responsable sont explicites. Nous recommandons de partir de la décision à prendre, puis de rendre le calcul reproductible. Le travail peut mobiliser un analyste BI, un data engineer ou un responsable métier ; leur rôle dépend de l’origine de l’écart.
1. Nommer la décision avant de rapprocher les chiffres
« Client actif » peut désigner un client ayant commandé, un client livré ou un client facturé. Les trois notions ont un intérêt. Elles servent cependant des décisions différentes : développer le portefeuille, organiser les opérations ou suivre les revenus.
Demandez au commanditaire ce qu’il ferait si l’indicateur montait ou baissait. Si la réponse reste vague, une précision supplémentaire du calcul ne résoudra pas le manque d’usage. À l’inverse, une décision claire permet de déterminer les événements et la période à retenir.
Il n’est pas toujours nécessaire d’imposer un chiffre unique à toutes les équipes. Deux mesures peuvent coexister si leurs noms rendent leur différence évidente. Le problème est de comparer deux chiffres présentés comme équivalents alors qu’ils ne le sont pas.
2. Décomposer l’écart en questions vérifiables
Avant de modifier une règle, réunissez les deux responsables de rapports autour d’un même échantillon. Travaillez sur les enregistrements qui expliquent l’écart, en respectant les droits d’accès aux données. Un rapprochement de totaux ne suffit pas à identifier la cause.
| Question | Ce qu’il faut comparer |
|---|---|
| Quel événement compte ? | Commande, livraison, facture, activation ou utilisation |
| À quel niveau compte-t-on ? | Groupe, société, établissement, compte ou utilisateur |
| Sur quelle période ? | Mois civil, période glissante, date de l’événement ou de sa réception |
| Quelles exclusions ? | Annulations, tests, comptes internes, doublons, statuts particuliers |
| Quelle fraîcheur ? | Heure de mise à jour et traitements encore en attente |
| Quel historique ? | Situation connue à l’époque ou rattachement actuel |
Cette grille est une proposition de travail Spark. Elle permet de séparer une divergence de définition, une erreur de transformation et un décalage de mise à jour. Ces trois problèmes n’appellent pas la même intervention.
3. Exemple fictif : des clients actifs qui ne se recoupent pas
Imaginons deux rapports préparés pour une réunion commerciale. Le premier compte les sociétés ayant passé une commande au cours du trimestre. Le second compte les établissements facturés pendant les quatre-vingt-dix derniers jours. L’un exclut les commandes annulées ; l’autre n’a pas encore intégré certains avoirs.
Il serait trompeur de décider que l’un des rapports est faux à partir de son seul total. Les équipes doivent d’abord aligner l’événement, la période et le niveau de regroupement. Elles peuvent ensuite isoler les anomalies restantes.
Pour piloter une campagne de réactivation, elles retiennent les sociétés sans commande sur une période définie. Pour suivre la facturation, elles conservent une autre mesure, nommée différemment. Elles documentent le lien entre les deux plutôt que de masquer la distinction derrière un même intitulé.
Cet exemple est illustratif. Il ne décrit pas une mission client Spark et ne constitue pas une recommandation de définition comptable.
4. Donner un responsable à la définition et un autre au fonctionnement
La définition métier doit être validée par une personne capable d’arbitrer son usage. L’équipe Data porte sa traduction dans les flux et les modèles. Le responsable du rapport vérifie que les filtres et les libellés exposés à l’utilisateur respectent cette définition.
Ces responsabilités peuvent être exercées par une petite équipe. L’enjeu est de savoir qui tranche lorsque deux besoins entrent en conflit, qui réalise la modification et qui constate que le résultat est acceptable.
Sur Power BI, Microsoft distingue notamment les faits, les dimensions et les mesures explicites ; le niveau de détail et les relations du modèle influencent les résultats. Ces mécanismes techniques soutiennent une définition partagée, mais ne choisissent pas à la place du métier ce que signifie « actif ». Voir la documentation Microsoft sur les modèles en étoile.
5. Que faire avec ces résultats ?
À la fin du rapprochement, classez le problème avant d’engager un chantier.
Si les définitions diffèrent, nommez les deux usages, désignez leur responsable et faites valider les critères. Le livrable attendu est une décision de définition, accompagnée d’exemples d’inclusion et d’exclusion.
Si le calcul est incorrect, confiez une correction ciblée à l’équipe BI ou Data. Conservez un jeu de cas de référence pour vérifier le résultat et prévenir le retour de l’erreur.
Si les données arrivent à des moments différents, rendez visible l’heure de mise à jour et vérifiez si le délai convient à la décision. L’affichage d’un chiffre ancien comme s’il était instantané crée une ambiguïté évitable.
Si plusieurs causes se cumulent, choisissez un indicateur prioritaire. Une reprise générale du reporting n’est justifiée que si le périmètre et les dépendances l’exigent. Un premier indicateur maîtrisé fournit déjà une base de travail pour les suivants.
Une fiche à utiliser au prochain comité
Préparez une page contenant la décision servie, le nom de la mesure, l’événement compté, la période, le niveau de détail, les exclusions, la fraîcheur attendue et les responsables. Ajoutez trois exemples : un cas inclus, un cas exclu et un cas limite à arbitrer.
Le critère de sortie peut être concret : deux personnes disposant des mêmes données et de cette fiche obtiennent le même résultat, ou expliquent précisément leur différence. Définissez une tolérance adaptée à l’usage ; il n’existe pas de seuil universel pertinent pour tous les indicateurs.
Retrouvez nos prochains points de vue Cloud, Data et Pilotage sur la page LinkedIn Spark Conseil.
Mobiliser la bonne expertise
Un besoin de définition appelle un échange entre le métier et la BI. Un défaut de flux peut nécessiter un data engineer. Un modèle difficile à faire évoluer peut demander un travail d’architecture Data. Spark accompagne ces besoins avec des consultants spécialisés et des interventions adaptées au périmètre.
Découvrir notre expertise Data · Préparer le choix d’un consultant senior
Pour approfondir la fiabilité au service d’un usage : Avant l’IA, rendre les données dignes de confiance.
