Business intelligence : construire des tableaux de bord avec des données fiables

Un tableau de bord peut être rapide, élégant et faux.

Une jointure multiplie le chiffre d’affaires, une date déplace les ventes d’un mois et une définition différente des clients actifs rend deux services incompatibles. La business intelligence devient fiable lorsque les données, les règles de calcul et les contrôles sont aussi solides que la présentation.

Le premier objectif n’est donc pas de multiplier les graphiques. Il est de rendre une décision explicable : quel chiffre observe-t-on, sur quel périmètre, à quelle date, avec quelles limites ? Les exemples de ce dossier sont fictifs et servent à tester les mécanismes de calcul.

Commencer par une décision et un contrat de mesure

Un responsable ne cherche pas forcément un tableau de ventes complet. Il peut vouloir détecter une baisse de marge, répartir une capacité ou connaître le retard de facturation. Chacune de ces décisions demande des données, une fréquence et une précision différentes.

Choisissez un premier cas et écrivez une fiche d’indicateur. Elle doit donner son nom, sa formule, son périmètre, sa source, sa fréquence et son responsable. Ajoutez les exclusions : annulations, devis, taxes, avoirs ou opérations internes selon le besoin.

« Chiffre d’affaires » peut désigner des commandes signées, des factures émises ou un montant reconnu selon des règles comptables. Ces éléments ne sont pas interchangeables. Un graphique de commandes doit être nommé comme tel, même si le montant ressemble au chiffre présenté par la comptabilité.

La date retenue compte aussi : création de commande, émission, livraison ou encaissement. Conservez plusieurs dates lorsque le parcours le nécessite. Écraser toutes les étapes dans un champ « date » rend les rapprochements difficiles.

Le contrat de mesure doit rester accessible aux lecteurs. Une infobulle ou une courte note peut expliquer l’unité, le périmètre et la dernière actualisation. L’élégance de l’interface ne doit pas masquer la convention utilisée.

Le grain d’une table détermine ce que l’on peut additionner

Le grain décrit ce que représente une ligne. Une table peut contenir une ligne par commande, par ligne de commande, par facture ou par paiement. Ces niveaux se ressemblent visuellement mais produisent des calculs différents.

Imaginez une commande de 300 euros avec trois lignes. Une table de lignes peut contenir 100, 80 et 120 euros : leur somme est correcte. Si elle répète le total de commande de 300 euros sur chaque ligne, additionner ce champ donne 900 euros.

Le problème ne vient pas du graphique. Il vient de la signification du champ dans la table. Donnez aux colonnes des noms explicites et documentez ce qui est répétable. Les montants au niveau commande doivent rester calculés à ce niveau ou être alloués selon une règle justifiée.

Un modèle en étoile distingue généralement des tables de faits, contenant les événements ou mesures, et des dimensions qui fournissent le contexte : client, produit, calendrier. La documentation technique de Microsoft décrit notamment cette séparation et l’importance d’un grain cohérent.

Cela ne rend pas le modèle automatiquement juste. Il faut encore contrôler les clés, les relations et les changements dans les dimensions. Une architecture reconnue ne corrige pas une définition métier absente.

La jointure qui double les ventes

Considérons deux commandes : A vaut 100 euros, B vaut 200 euros. Chaque commande possède deux événements de suivi. Une jointure directe entre commandes et événements produit quatre lignes. Le montant de chaque commande apparaît deux fois, et une somme naïve atteint 600 euros au lieu de 300.

Le risque augmente lorsqu’on relie plusieurs tables de détail.

Une commande avec trois articles et deux paiements peut produire six combinaisons si la jointure ne respecte pas les grains. Les valeurs répétées restent plausibles individuellement, ce qui rend l’erreur moins visible.

Une solution consiste à agréger chaque détail au niveau attendu avant la jointure. Par exemple, regrouper les paiements par commande puis relier ce résultat à la table des commandes. Un comptage distinct peut résoudre un nombre de commandes, mais ne corrige pas automatiquement une somme monétaire.

Voici un exemple SQL minimal pour rapprocher commandes et paiements sans multiplier le montant des commandes. Les colonnes et les tables sont fictives ; le montant des paiements est agrégé avant la jointure.

WITH paiements_par_commande AS (
    SELECT commande_id, SUM(montant) AS montant_paye
    FROM paiements
    GROUP BY commande_id
)
SELECT c.id, c.total,
       COALESCE(p.montant_paye, 0) AS montant_paye
FROM commandes AS c
LEFT JOIN paiements_par_commande AS p
       ON p.commande_id = c.id;

Le choix de remplacer une absence de paiement par zéro est ici intentionnel. Il n’autorise pas à remplacer toutes les valeurs inconnues par zéro dans les autres tables. Le SQL doit exprimer une règle métier, pas simplement faire disparaître les cases vides.

Après chaque jointure importante, comparez le nombre de lignes, les identifiants distincts et les sommes avant et après. Une variation n’est pas toujours une erreur, mais elle doit avoir une explication attendue.

Les dates et les fuseaux changent le résultat

Un événement enregistré à 23 h 30 UTC peut appartenir au jour suivant en heure de Paris. Pour un tableau journalier, la convention doit préciser si la date correspond au stockage technique ou au calendrier métier. Stocker un instant et calculer sa date locale évite certains mélanges.

Le fuseau Europe/Paris n’est pas un décalage fixe toute l’année. Les changements d’heure rendent insuffisante une conversion systématique « ajouter une heure ». Utilisez les règles de fuseau prévues par les outils et testez les périodes de changement.

Pour filtrer une journée d’événements, une borne de début incluse et une borne de fin exclue évitent les ambiguïtés liées à la dernière fraction de seconde. Le détail dépend du type de date et du système utilisé, mais la convention doit être explicite.

Distinguez aussi le moment de l’événement du moment de son arrivée dans l’entrepôt. Une facture émise hier peut être reçue aujourd’hui. Si le tableau ne tient compte que de la date d’import, il peut déplacer l’activité d’une période à l’autre.

Pour les données tardives, choisissez une règle de recalcul. Les périodes récentes peuvent être réactualisées automatiquement ; les périodes closes peuvent exiger une correction identifiée. Affichez la version ou la date de clôture lorsque les décisions reposent sur des résultats figés.

Zéro, inconnu et non applicable ne racontent pas la même chose

Une marge égale à zéro est une information. Une marge inconnue parce que le coût manque en est une autre. Convertir les deux en zéro fabrique un résultat apparemment complet mais incorrect.

Dans une simulation, deux produits sont vendus : le premier rapporte 100 euros et coûte 70 euros ; le second rapporte 200 euros, mais son coût n’est pas disponible. La marge connue est de 30 euros sur un périmètre incomplet. Afficher 230 euros de marge totale en supposant un coût nul pour le second produit serait trompeur.

Présentez le taux de complétude ou le montant non calculable à côté du résultat. Cela permet au lecteur d’évaluer la limite avant de prendre une décision. Un tableau de bord peut être utile malgré une donnée manquante, à condition de rendre cette absence visible.

Les règles de valeurs manquantes doivent être définies par champ. Une absence de paiement peut valoir zéro dans un rapprochement donné ; une absence de date de livraison ne signifie pas livraison au début du calendrier. Une valeur « non applicable » peut nécessiter une catégorie séparée.

Prévoyez également les divisions par zéro. Un taux calculé sur aucune observation doit être présenté comme non calculable, et non comme une performance de zéro ou cent pour cent.

Les ratios doivent être recalculés au bon niveau

Deux équipes ont des taux de conversion de 50 % et 10 %. La première a signé un client sur deux opportunités, la seconde dix sur cent. La moyenne simple des taux vaut 30 %, mais le taux global est de 11 / 102, soit environ 10,78 %.

La moyenne simple répond à une question sur les équipes pondérées de façon égale.

Le taux global répond à une question sur l’ensemble des opportunités. Les deux peuvent être calculés, mais leurs intitulés doivent distinguer ces significations.

Le même problème concerne les paniers moyens, les marges en pourcentage et les délais. Conservez les numérateurs et dénominateurs pour recalculer le ratio au niveau demandé. Une colonne de pourcentages seule ne suffit pas toujours.

Certains indicateurs ne sont pas additifs dans le temps. Un stock quotidien ne se somme pas pour obtenir le stock mensuel. Le nombre de clients distincts chaque jour ne se somme pas non plus pour obtenir les clients distincts du mois.

Notre dossier sur les métriques de prospection applique cette vigilance aux cohortes et au coût d’acquisition. Le principe est identique : respecter l’unité d’observation et le périmètre de calcul.

Construire des contrôles qui détectent les erreurs utiles

Une chaîne de données doit vérifier sa fraîcheur, ses volumes et ses règles. Un import peut réussir techniquement tout en récupérant seulement une partie des enregistrements. Contrôler uniquement le code de sortie ne détecte pas cette situation.

Les seuils ne doivent pas être copiés sans contexte. Une activité très saisonnière peut varier fortement d’un jour à l’autre. Une baisse de volume peut être normale un dimanche et inquiétante un jour ouvré.

Pour le rapprochement comptable ou commercial, définissez les écarts attendus : taxes, avoirs, arrondis, dates ou périmètres. Un objectif d’égalité absolue entre deux chiffres définis différemment mobilise du temps sans améliorer la qualité.

Conservez les résultats des contrôles et leur traitement. Un écart accepté doit être expliqué par une règle, pas effacé pour remettre le tableau au vert. La traçabilité transforme la correction ponctuelle en apprentissage exploitable.

Actualisation et droits d’accès font partie du produit

Un graphique actualisé chaque nuit peut suffire pour un pilotage mensuel. Il sera inadapté à une opération qui exige une réponse en quelques minutes. L’actualisation doit suivre le besoin de décision, avec un coût et une charge maîtrisés.

Affichez la dernière actualisation complète, et éventuellement l’état des sources. Un tableau qui mélange une source fraîche et une autre vieille de trois jours peut être plus trompeur qu’un tableau uniformément ancien.

Les droits d’accès doivent être vérifiés sur les données, les rapports et les exports. Restreindre un onglet visible ne garantit pas que les informations sous-jacentes soient protégées dans tous les modes d’accès. Testez avec un compte représentatif, pas uniquement avec l’administrateur.

Pour des données clients ou salariés, limitez les informations au besoin et au public concerné. Une segmentation agrégée peut suffire. Un export détaillé exige une justification et un accès approprié. La facilité de partage ne doit pas remplacer cette décision.

Tester une évolution comme une modification métier

Une nouvelle règle de qualification, un changement de taxe ou une nouvelle dimension peut affecter les séries historiques. Écrivez les cas attendus et testez-les sur un petit jeu de données dont les résultats sont connus.

Ce jeu doit inclure les cas difficiles : annulation, avoir, paiement partiel, doublon, valeur manquante, changement de date et plusieurs événements pour une même opération. Tester uniquement le parcours simple laisse les erreurs habituelles sans contrôle.

Le dossier sur la facturation électronique distingue notamment document, statut et validation métier. Ces distinctions sont importantes dans un tableau de facturation : un document transmis n’est pas automatiquement un document accepté ou encaissé.

Avant diffusion, comparez l’ancienne et la nouvelle version, expliquez les écarts et faites valider les règles par le responsable de l’indicateur. Si la définition change, signalez-le dans l’historique. Une rupture de série peut être une conséquence de méthode, pas un changement d’activité.

Attribuez enfin la maintenance. Quelqu’un doit surveiller les sources, traiter les alertes et répondre aux questions sur les chiffres. Sans cette responsabilité, la confiance se dégrade au premier résultat incompréhensible.

Le tableau de bord le plus convaincant est celui dont un lecteur peut remonter d’un chiffre à une définition, une source et un contrôle. La qualité d’une BI se mesure à cette capacité d’explication, avant de se mesurer au nombre de visualisations.

Prévoyez également le retrait des indicateurs devenus inutiles. Un rapport rarement consulté mobilise pourtant des actualisations, des accès et une maintenance. Avant de le conserver, demandez quelle décision il soutient encore. Archivez sa définition et les résultats nécessaires, puis retirez les traitements associés après vérification des dépendances. Cette gestion du cycle de vie libère du temps pour les mesures réellement utilisées et réduit le nombre de chiffres divergents que les équipes doivent expliquer. La sobriété du catalogue peut ainsi renforcer la confiance dans les rapports restants.