Rares sont les organisations qui manquent de données. Beaucoup, en revanche, manquent de décisions prises grâce à elles. Le scénario se répète : une plateforme est choisie, des flux sont raccordés, des tableaux de bord sont livrés — puis l'usage s'étiole en quelques semaines. Chacun arrive en réunion avec ses propres chiffres, et la discussion porte sur la fiabilité de l'indicateur plutôt que sur l'arbitrage à rendre. Ce n'est presque jamais un problème d'outil, mais un problème de définitions, de responsabilités, de qualité et d'usage. Autrement dit, de gouvernance.
Pourquoi tant de tableaux de bord finissent en friche
Quand nous auditons un patrimoine décisionnel, les mêmes causes reviennent — aucune n'est technique.
- Le besoin n'a jamais été formulé comme une décision. On a demandé « un suivi de l'activité », pas « ce que nous devons trancher chaque mois ».
- Les définitions divergent. Trois directions comptent un « client actif » de trois manières, et chacune a de bonnes raisons.
- La donnée arrive trop tard au regard du rythme réel de la décision, ce qui pousse les équipes à reconstruire leurs propres fichiers.
- Personne n'est responsable de corriger une anomalie signalée : le rapport reste faux, devient suspect, puis meurt.
- Rien n'est décommissionné. Le patrimoine grossit, la confiance baisse, et chercher le bon rapport coûte plus cher que l'analyse.
Un tableau de bord que personne n'ouvre n'est pas un livrable : c'est une dette. Il consomme de la maintenance, entretient le doute et repousse la décision qu'il devait servir.
Diagnostiquer la maturité avant d'outiller
Avant d'engager une plateforme ou une refonte, nous recommandons un diagnostic court — quelques semaines, pas un semestre — qui répond à des questions volontairement simples. Quelles décisions récurrentes sont réellement prises, et à quelle fréquence ? Sur quelles données reposent-elles aujourd'hui ? Qui répond quand un chiffre est contesté ? Quelle part du parc de rapports est consultée chaque mois ?
Ce diagnostic couvre quatre dimensions : les usages, les données et leur qualité, l'organisation et les rôles, l'architecture et les outils. L'ordre n'est pas indifférent : une organisation qui démarre par l'architecture obtient une infrastructure impeccable au service d'usages jamais clarifiés. Le résultat n'est pas une note de maturité, c'est un choix — le premier cas d'usage à traiter, celui dont la valeur peut être démontrée en quelques mois et dont le succès financera la suite.
Gouverner sans bureaucratiser
La gouvernance a mauvaise presse, et parfois à raison. Réduite à un comité mensuel, un référentiel que personne ne lit et un formulaire d'habilitation à cinq visas, elle produit exactement ce qu'elle prétend combattre : des contournements. La bonne gouvernance ne se mesure pas au volume de procédures, mais au nombre de désaccords qu'elle permet de trancher vite. Une règle utile est celle qui donne une réponse là où il y avait discussion sans fin : quelle est la définition officielle de cet indicateur, qui l'a validée, qui peut la faire évoluer.
Les rôles qui portent la donnée
Trois rôles structurent l'ensemble. Le data owner, responsable métier, est comptable de la définition, de la qualité et des règles d'accès d'un domaine — clients, contrats, ressources humaines. Le data steward opère au quotidien : il documente, contrôle, corrige et fait le lien avec les équipes techniques. Le sponsor métier porte l'usage, arbitre les priorités et rend visible la valeur produite.
Pourquoi ces rôles échouent si souvent
Ils échouent rarement par incompétence, mais parce qu'ils sont attribués sans temps et sans mandat : une ligne ajoutée à une fiche de poste déjà pleine, sans décharge, sans autorité pour imposer une définition à une direction voisine. Nommer un data owner sans moyens de trancher revient à créer un responsable de ce qu'il ne contrôle pas. Nous recommandons de formaliser trois choses dès la nomination : le périmètre exact, le temps alloué — même modeste, mais réel et inscrit dans la charge — et le pouvoir de décision associé.
La qualité de la donnée et le coût du silence
La qualité n'est pas une notion vague : elle se décompose en critères mesurables. La complétude (les champs indispensables sont-ils renseignés ?), la fraîcheur (l'écart entre le fait et sa disponibilité est-il compatible avec la décision ?), la cohérence (les mêmes entités portent-elles les mêmes valeurs d'un système à l'autre ?) et la traçabilité (sait-on d'où vient un chiffre et quelles transformations il a subies ?).
Le vrai danger n'est pas l'erreur : c'est le silence sur l'erreur. Une donnée dont on connaît le taux d'incomplétude reste exploitable, avec les précautions qui s'imposent. Une donnée présentée comme fiable alors qu'elle ne l'est pas produit des décisions coûteuses et, à la première déconvenue, ruine la confiance dans l'ensemble du dispositif. Nous conseillons d'instaurer une revue de qualité périodique et courte, sur quelques indicateurs, avec des seuils annoncés et des anomalies affichées plutôt que masquées. Publier une note de qualité à côté d'un indicateur n'affaiblit pas la décision : elle la rend lucide.
Du dictionnaire à la modélisation orientée usage
Catalogue et dictionnaire de données
Le catalogue recense les jeux de données disponibles, leur propriétaire, leur origine, leur fréquence de mise à jour et leur sensibilité. Le dictionnaire, lui, fixe le sens : définition métier de chaque indicateur, formule, périmètre, exclusions. Deux objets distincts et complémentaires, qui n'ont de valeur que tenus à jour par les data stewards et accessibles sans démarche préalable — un dictionnaire enfermé dans un fichier partagé n'existe pas.
Partir de la décision, pas de la source
La tentation la plus courante consiste à modéliser ce que les systèmes savent produire. La démarche inverse est plus exigeante et bien plus rentable : partir de la décision à prendre, en déduire les questions puis les indicateurs nécessaires, et seulement ensuite remonter aux sources. Cette inversion réduit le périmètre, écarte les développements sans destinataire et donne un critère clair pour arbitrer les demandes. Elle conduit à une règle que nous défendons systématiquement : un indicateur unique de référence par domaine, une définition officielle, un propriétaire. Les variantes restent possibles, mais nommées comme telles.
Architecture et protection : servir l'usage, sans dogme
Entrepôt de données, lac de données, approche produit-données : le débat technologique occupe souvent le devant de la scène alors qu'il devrait venir en dernier. Un entrepôt structuré convient à des indicateurs stables et à un besoin de cohérence forte. Un lac trouve son intérêt sur des données hétérogènes ou exploratoires. L'approche produit-données — chaque domaine expose des jeux de données documentés et supportés comme un service — répond surtout à la congestion d'une équipe centrale. Aucune n'est une solution en soi, et beaucoup d'organisations les combinent. Le seul critère qui vaille reste la nature des usages à servir et la capacité réelle des équipes à exploiter ce qui sera construit.
La sécurité et la minimisation, en revanche, ne se négocient pas et ne s'ajoutent pas après coup. Ne collecter que ce qui sert un usage identifié, restreindre les accès au juste nécessaire, pseudonymiser dès que l'analyse le permet, définir des durées de conservation et les appliquer : ces principes réduisent le risque réglementaire autant que la surface d'exposition en cas d'incident. Ils rejoignent les obligations de protection des données personnelles, sujet assez vaste pour mériter son propre traitement — retenons qu'une gouvernance crédible et une conformité solide reposent sur les mêmes fondations : savoir quelles données existent, pourquoi et pour qui.
Faire vivre l'usage, et par où commencer
L'adoption est la seule preuve qu'un dispositif fonctionne, et elle se construit délibérément : former les utilisateurs à la lecture des indicateurs autant qu'à l'outil, inscrire la donnée dans des rituels de décision existants — un comité qui ouvre systématiquement sur le même tableau de bord — et accepter de décommissionner les rapports morts. Elle suppose surtout de mesurer l'usage réel : consultations, profils des utilisateurs, rapports jamais ouverts depuis six mois. Rarement mise en place, cette mesure est pourtant l'un des indicateurs de pilotage les plus utiles d'une démarche data.
S'il ne fallait retenir qu'une chose : ne lancez pas un programme data, lancez une décision. Choisissez un domaine, nommez son propriétaire avec un vrai mandat, définissez son indicateur de référence, mesurez sa qualité et son usage pendant un trimestre. Ce cycle court apprend à votre organisation ce qu'aucune plateforme ne lui enseignera. Si le sujet est ouvert chez vous, la prochaine étape utile tient en un entretien d'une heure pour identifier ce premier cas d'usage.
