Pourquoi les dashboards ne soutiennent pas vraiment la décision

Parfois les règles de conception sont suivies (une décision par dashboard, les bonnes métriques, les comparaisons, le signal de fraîcheur) et la typologie est respectée (forme direction pour usage direction, forme opérationnelle pour usage opérationnel), et le dashboard échoue malgré tout. Les chiffres sont corrects. La page se charge. Quelqu’un l’a construit avec soin. Et pourtant, six mois plus tard, il ne change aucune décision que l’équipe prend.

Cet article porte sur les modes d’échec spécifiques qui survivent à la discipline de conception. Ce sont les schémas qui expliquent pourquoi un dashboard qui paraît juste sur chaque checklist se fait quand même ignorer, ou pire, se fait approuver-mais-pas-utiliser. Les reconnaître tôt est ce qui sépare les dashboards qui survivent à leur premier trimestre de ceux qui deviennent silencieusement de la décoration dans un outil de BI.

Il s’associe à l’article sur la discipline de conception de dashboards, qui couvre les règles ; ici, l’angle est sur les modes d’échec que les règles seules n’empêchent pas.

Le dashboard est bien conçu. Les métriques sont claires. Les comparaisons sont honnêtes. Mais l’équipe qui l’ouvre ne décide en réalité pas la chose que le dashboard est censé soutenir. Le dashboard porte sur la marge trimestrielle, et l’équipe décide d’allocation de pipeline. Le dashboard porte sur la rétention utilisateur, et l’équipe décide quelle fonctionnalité livrer le sprint suivant.

Le décalage est rarement intentionnel. Le dashboard a été construit quand l’équipe pensait qu’elle allait être confrontée à cette décision, la décision a bougé ou se prenait déjà ailleurs, et le dashboard est resté, bien construit mais hors sujet. La correction, c’est de revisiter la décision que le dashboard prétend soutenir et de demander aux personnes qui sont supposées l’utiliser : décidez-vous réellement cela, à cette cadence, avec ce type d’input. Si la réponse honnête est non, le dashboard doit être redessiné autour de ce qu’elles décident, ou retiré.

La métrique sur le dashboard est sans ambiguïté la bonne. Chiffre d’affaires, temps de réponse, taux de conversion, peu importe le chiffre dont la décision dépend réellement. Mais la comparaison à côté ne correspond pas à la manière dont l’équipe pense la métrique.

Le dashboard affiche le chiffre d’affaires contre l’an dernier. L’équipe raisonne en « contre le plan du trimestre », parce que l’an dernier n’est plus pertinent depuis un changement de stratégie. Le dashboard affiche le temps de réponse en moyenne quotidienne. L’équipe raisonne en p95 par région, parce que la moyenne cache les cas qui déclenchent réellement les escalades. Le dashboard affiche la conversion contre une référence historique. L’équipe la compare à la dernière campagne.

Quand la comparaison est fausse, la métrique devient quelque chose que l’utilisateur doit re-ancrer mentalement à chaque lecture, et le dashboard cesse d’être plus rapide que poser la question par e-mail. La correction est petite : changer la comparaison. La partie difficile, c’est de remarquer que c’est la comparaison qui pose problème et non la métrique.

Le dashboard identifie correctement qu’un problème existe. Les tickets s’accumulent. Le chiffre d’affaires sur le segment X baisse. Le système approche un indicateur de saturation. L’utilisateur lit la page, est d’accord qu’il y a un problème, et ensuite n’a nulle part où aller depuis le dashboard.

L’enregistrement actionnable (quels tickets, quels clients, quels serveurs) vit dans un autre système. Passer du chiffre titre du dashboard au travail qu’il implique demande un changement d’onglet, un filtre manuel, parfois un message Slack pour demander la liste à l’équipe data. Le dashboard fait remonter le problème et s’arrête juste avant de laisser l’utilisateur agir, donc avec le temps, les utilisateurs cessent de consulter le dashboard jusqu’à ce que quelqu’un leur dise qu’il y a un problème, moment auquel le dashboard ne fait que confirmer ce qu’ils savent déjà.

La correction, c’est de concevoir le chemin vers l’action dans le dashboard lui-même : un clic qui amène l’utilisateur dans la file, un lien qui ouvre la fiche client, un filtre qui exporte la liste affectée. Un dashboard qui fait remonter un problème sans permettre la réponse est un demi-outil.

Le dashboard a été spécifié dans un groupe de travail à huit parties prenantes, dont chacune a demandé la métrique la plus pertinente pour sa fonction. Le résultat est une longue page avec la métrique de chacun, approuvée par tous, défendue par personne. Après la célébration du lancement, les réunions sur le dashboard s’arrêtent. Les métriques qui étaient « essentielles » pour une partie prenante sont consultées une fois par trimestre ; les autres ne le sont pas du tout.

Le schéma est reconnaissable. Chaque métrique a été ajoutée par quelqu’un, mais aucune personne unique ne peut défendre le dashboard dans son ensemble. Personne n’est responsable de retirer les métriques qui ne sont plus pertinentes, de resserrer la conception à mesure que la décision évolue, d’expliquer les anomalies quand elles apparaissent. La correction, c’est de nommer un propriétaire unique avec l’autorité de retirer des métriques que d’autres personnes ont demandées, et d’accepter que le dashboard résultant sera plus petit et politiquement moins inclusif que la version comité, ce qui est une fonctionnalité, pas un défaut.

Le dashboard existe, les métriques sont justes, la conception est propre. La vraie décision se prend dans un fil Slack, dans un tableur que quelqu’un exporte une fois par semaine, dans une conversation de couloir, dans une chaîne d’e-mails avec captures d’écran en pièce jointe. Le dashboard est la source de vérité officielle sur le papier ; la source de vérité qui marche, celle à partir de laquelle les décisions se prennent réellement, est ailleurs.

C’est le mode d’échec le plus démoralisant pour l’équipe qui a construit le dashboard, parce que le dashboard est « juste » et inutilisé. La cause est généralement que la surface du dashboard (un outil de BI, une URL séparée, un login) ne correspond pas au moment où la décision se prend. La correction est rarement d’améliorer le dashboard ; c’est de livrer la même information sur la surface où la décision se prend réellement. Un digest e-mail hebdomadaire. Un message Slack qui poste les chiffres titre tous les lundis. Un embed dans l’outil opérationnel que l’équipe utilise déjà. Le médium doit correspondre au moment.

Le dashboard a été lancé correctement. Il a été utilisé. Il a changé des décisions. Puis le métier a bougé, l’équipe a bougé, les questions ont bougé, et le dashboard est resté exactement le même. Six mois plus tard, les métriques continuent d’être calculées, la page continue de se charger, mais le lien avec les décisions actuelles s’est érodé.

Les dashboards vieillissent. Les décisions qu’ils soutiennent changent de forme, les comparaisons qui étaient justes l’an dernier sont fausses cette année, les métriques qui comptaient à l’époque ne sont pas celles qui comptent maintenant. Un dashboard qui n’est pas relu périodiquement ne reste pas utile par inertie ; il devient poliment ignoré. La correction, c’est une revue éditoriale trimestrielle, où le propriétaire demande pour chaque métrique : quelqu’un décide-t-il encore sur cette base. Les métriques qui ne peuvent pas se justifier sont retirées ; le dashboard reste affûté, ou est retiré et remplacé.

Les dashboards n’échouent pas parce qu’ils sont mal présentés. Ils échouent parce qu’ils répondent à des questions que personne ne pose, parce qu’ils comparent la métrique à la mauvaise chose, parce qu’ils font remonter des problèmes sur lesquels l’utilisateur ne peut pas agir depuis la page, parce qu’ils sont possédés par tout le monde et donc par personne, parce qu’ils livrent sur une surface qui ne correspond pas au moment de la décision, ou parce qu’ils restent figés pendant que les décisions autour d’eux évoluent. Chacun de ces échecs est invisible au lancement et évident six mois plus tard, quand le dashboard est « toujours là » mais ne change plus rien.

Le contexte plus large, dont la discipline de conception et la typologie de dashboards qui empêchent une partie mais pas la totalité de ces échecs, est rassemblé dans le cluster systèmes de données et performance. Et lorsque la question passe de « nous avons des dashboards mais les décisions ne changent pas » à « nous reconnaissons le mode d’échec et il nous faut maintenant quelqu’un pour les redessiner autour de la vraie décision, de la vraie comparaison et du vrai moment d’action », c’est exactement ce sur quoi mon accompagnement analyse de données et aide à la décision est centré.