Un comité de direction où le directeur financier, le responsable commercial et le DSI présentent chacun un chiffre d’affaires trimestriel différent : nous observons cette situation dans la majorité des organisations dotées d’un décisionnel informatique hétérogène. Le problème ne vient presque jamais d’un outil défaillant. Il vient de données sources incohérentes propagées sans contrôle dans la chaîne analytique.
Lignage des données dans le décisionnel informatique : tracer la divergence
Avant de corriger un écart entre deux tableaux de bord, il faut pouvoir remonter la chaîne de transformation qui l’a produit. Le lignage (data lineage) cartographie chaque donnée depuis sa source opérationnelle jusqu’à l’indicateur restitué, en passant par les couches d’extraction, de transformation et de chargement.
Sans cette traçabilité, chaque équipe construit ses propres règles de calcul dans des feuilles de calcul ou des requêtes ad hoc. Le CA « net » du contrôle de gestion exclut les avoirs, celui du commerce non. Les deux sont techniquement corrects, mais leur coexistence crée un conflit de chiffres en comité.
Nous recommandons de documenter le lignage au niveau du champ, pas du flux. Chaque métrique publiée dans un rapport décisionnel doit renvoyer à une définition unique, un propriétaire identifié et une règle de calcul versionnée. C’est précisément ce que les cadres réglementaires récents formalisent sous le terme de fitness for purpose : la preuve documentée qu’une donnée est adaptée à l’usage qui en est fait, et non simplement « de bonne qualité » au sens générique.
Source unique de vérité : architecture et gouvernance data quality
Le concept de source unique de vérité (single source of truth) est souvent réduit à un entrepôt de données centralisé. En pratique, la centralisation technique ne suffit pas si la gouvernance ne suit pas.
Propriétaires, intendants, gardiens : trois rôles distincts
Une gouvernance opérationnelle repose sur une séparation claire des responsabilités. Le propriétaire de la donnée (data owner) est un responsable métier qui valide la définition et les règles d’usage. L’intendant (data steward) surveille la qualité au quotidien et traite les anomalies. Le gardien (data custodian), côté IT, gère le stockage, les accès et la sécurité technique.
Quand ces rôles sont confondus ou non attribués, personne ne se sent responsable d’un écart. Le problème est remonté au DSI qui n’a pas la légitimité métier pour trancher la définition d’un indicateur, puis il stagne.
Métriques de qualité et processus de remédiation
Maintenir des métriques de qualité mesurables (taux de complétude, taux de doublons, fraîcheur des données) est une pratique que les régulateurs commencent à exiger dans certains secteurs. L’approche la plus efficace que nous observons combine :
- Un contrôle automatisé à chaque étape du pipeline ETL, avec des seuils d’alerte définis par le propriétaire métier et non par l’équipe technique seule
- Un processus de remédiation documenté qui précise qui corrige, dans quel délai, et comment l’anomalie est tracée jusqu’à résolution
- Une remontée périodique des problèmes persistants au niveau de la direction, pour débloquer les arbitrages que les équipes opérationnelles ne peuvent pas résoudre seules
Les problèmes de data quality non escaladés deviennent des chiffres contradictoires en comité. Ce lien de cause à effet est direct, mais rarement formalisé dans les processus de gouvernance.
Analyse décisionnelle : réconcilier les chiffres entre métiers
La contradiction entre rapports provient le plus souvent de trois mécanismes que nous identifions de façon récurrente.
Le premier est la divergence de périmètre. Deux équipes extraient des données sur des périmètres différents (entités juridiques incluses ou exclues, devises converties à des taux différents) sans le documenter. Le résultat est arithmétiquement juste des deux côtés, mais incomparable.
Le deuxième est la latence asynchrone. Le datawarehouse est rafraîchi la nuit, mais un tableau de bord métier interroge une base opérationnelle en temps réel. Les chiffres divergent mécaniquement en cours de journée, ce qui crée de la méfiance vis-à-vis du système décisionnel informatique dans son ensemble.
Le troisième est l’absence de référentiel partagé pour les dimensions d’analyse. Quand la nomenclature produit du CRM diffère de celle de l’ERP, aucune jointure ne produit un résultat fiable. Le nettoyage se fait alors manuellement, dans des fichiers parallèles qui deviennent eux-mêmes des sources non gouvernées.
Réconciliation technique : par où commencer
Nous recommandons de traiter d’abord les référentiels partagés (clients, produits, entités) avant d’investir dans un nouvel outil de visualisation. Un tableau de bord sophistiqué connecté à des référentiels incohérents ne fait qu’emballer le problème dans une interface plus agréable.
La mise en place d’un master data management, même partiel sur les trois ou quatre référentiels les plus critiques, réduit la majorité des écarts constatés en restitution. C’est un chantier de gouvernance avant d’être un chantier technique.
Conformité réglementaire et reporting : la data quality comme obligation
La pression réglementaire transforme la qualité des données d’un sujet technique interne en une obligation auditable. Le RGPD impose déjà qu’une donnée personnelle inexacte soit corrigée ou supprimée. Une donnée personnelle de mauvaise qualité est aussi une donnée non conforme.
Au-delà du RGPD, les régulateurs sectoriels durcissent leurs attentes. L’EMA a publié un cadre opérationnel pour évaluer la qualité des données de vraie vie avant usage réglementaire. Ce cadre impose une logique d’évaluation structurée fondée sur plusieurs dimensions de qualité, et non sur un score unique. Les entreprises doivent pouvoir démontrer comment les données ont été capturées, transformées et contrôlées.
Dans le secteur financier, les projets de directives récentes exigent une structure de gouvernance explicite avec des rôles dédiés, une logique de source unique de vérité et des métriques de qualité remontées au niveau du conseil d’administration. La traçabilité de bout en bout devient un prérequis prudentiel, pas un luxe méthodologique.
Pour les équipes décisionnelles, cette évolution signifie que les pipelines de données doivent intégrer nativement des contrôles de qualité documentés et auditables. Un rapport réglementaire construit sur des données dont le lignage n’est pas prouvé expose l’entreprise à un risque de non-conformité, indépendamment de l’exactitude apparente du chiffre final.
Mettre fin aux chiffres contradictoires n’est pas un projet ponctuel de nettoyage de base de données. C’est un changement de posture : chaque indicateur publié dans un outil de décisionnel informatique doit être rattaché à une source identifiée, une règle documentée et un responsable nommé. Les organisations qui formalisent ces trois éléments constatent que les débats en comité portent enfin sur l’interprétation des chiffres, et non sur leur fiabilité.