L'anti-dashboard

La plupart des dashboards sont des cimetières de données. Douze widgets, huit palettes, quatre horizons temporels, et zéro avis sur ce que l'utilisateur doit regarder en premier. L'équipe a appelé ça « data-driven » et l'a livré. L'utilisateur l'ouvre une fois, le parcourt comme un étranger, et ne le rouvre jamais.

L'anti-dashboard fait le pari inverse. Une question, une liste de priorités, une action. Tout ce qui n'alimente pas la prochaine décision est coupé, caché ou relégué sous la ligne de flottaison. Voici le plaidoyer pour ce pari, les marques qui gagnent avec lui, et cinq règles pour tenir la ligne.

Un dashboard sert à décider, pas à stocker de la donnée

Un dashboard n'est pas un endroit où ranger des chiffres. C'est un endroit où prendre des décisions. Si l'écran ne répond pas à « que dois-je faire maintenant », c'est de la décoration avec une librairie de graphiques par-dessus.

La plupart des équipes produit esquivent cette question parce qu'y répondre exige un avis. Un mur de widgets a la sécurité du buffet. Personne n'est blâmé pour avoir livré toutes les métriques, seulement pour en avoir choisi une. Alors l'équipe n'en choisit aucune, et l'utilisateur paie en attention.

L'inbox de Linear ne livre pas toutes les issues d'un coup. Elle trie par priorité, puis par SLA, et l'écran est assez court pour être vraiment vidé. La vue projet de Vercel n'affiche pas 20 choses au-dessus de la ligne de flottaison. Elle montre la timeline des déploiements et l'URL, et c'est toute la question que se pose un développeur. Les deux équipes ont choisi un camp.

Les cinq modes d'échec

Tout dashboard qui rate le test du « que dois-je faire maintenant » échoue d'une de cinq façons reconnaissables. Chacune est en production en ce moment même.

Le cimetière Salesforce. Douze widgets que personne n'ouvre, dans une grille 4x3 parce que c'est ce qui tenait sur le wireframe. Ils existent parce que quelqu'un les a demandés une fois et que personne n'avait l'autorité d'en supprimer un. L'attention donnée à tout est de l'attention volée à chaque chose.

Le carrousel de métriques. Six KPI dans une bande horizontale, chacun avec un nombre, un pourcentage, un minuscule sparkline. Pas de contexte, pas de comparaison, pas d'action recommandée. L'utilisateur se sent vaguement informé et n'agit sur rien.

La vue œil de Sauron. Chaque événement, chaque ligne de log, chaque webhook, en temps réel, qui défile. Rien n'est mis en avant, tout se brouille. Des données en temps réel sans priorisation, c'est du bruit sous chronomètre.

Le dashboard à monter soi-même. Glisse un widget. Configure une requête. Enregistre la mise en page. Regrette-le le lendemain matin. Demander à l'utilisateur de concevoir son propre dashboard, c'est lui demander de faire le travail de l'équipe produit.

Le dashboard de vanité pour dirigeants. Les chiffres montent, tous les graphiques sont verts, chaque trimestre est dans les clous. Aucune décision n'en découle parce qu'aucune n'est requise. Le dashboard existe pour finir en capture d'écran dans un deck de board.

Un grand dashboard répond à une seule question

L'anti-dashboard commence par la question, pas par les widgets. Qu'est-ce que l'utilisateur vient chercher en ouvrant cet écran ? Écris-le en une phrase. Tout ce qui est à l'écran y répond, ou mérite sa place en dessous.

La home de Stripe Dashboard répond à « comment va le business aujourd'hui ». Le revenu du jour, la comparaison avec hier, et les trois choses qui demandent un humain : un paiement échoué, un litige, une demande de vérification. Le reste de Stripe est à un clic.

Le panneau projet de Cursor répond à « où en étais-je et que faisais-je ». L'arborescence de fichiers d'un côté, le dernier prompt en haut, l'éditeur au centre. Pas de télémétrie, pas de graphiques d'usage. L'écran, c'est le travail.

Cron et Notion Calendar répondent à « et ensuite ». Le prochain événement est en haut de la journée, la semaine en dessous. Pas de scroll infini, pas de heat map mensuelle qui se bat pour l'attention. L'avis, c'est que le prochain événement compte plus que la forme du mois.

Le coup Raycast : un dashboard n'a pas à ressembler à un dashboard

Raycast en est la version la plus pure. La barre de recherche EST le dashboard. Pas de widgets, juste un champ unique. Tape quelques caractères et la bonne chose remonte.

La leçon n'est pas « construis une barre de recherche ». La leçon, c'est qu'un dashboard n'a pas à être une mise en page de cartes. La home de GitHub, ce sont les pull requests qui vous sont assignées, point. La home de Notion, ce sont vos trois derniers documents et rien d'autre. Superhuman s'ouvre sur une inbox de tri où zéro est atteignable, parce que le produit a été pensé autour de l'idée qu'une boîte de réception doit avoir une fin. Aucun de ceux-là n'est un dashboard au sens classique. Tous sont des dashboards au seul sens qui compte.

La divulgation progressive est le principe sous-jacent. Montre la seule chose qui compte maintenant. Révèle la longue traîne seulement quand l'utilisateur signale qu'il la veut.

Les cinq règles de l'anti-dashboard

Ces règles se cumulent. Quatre sur cinq et le dashboard fonctionne généralement. Deux, et tu as livré un cimetière.

Règle 1 : une question par écran

Chaque vue de dashboard répond à exactement une question. Écris-la. Si un widget ne peut pas être défendu comme partie de la réponse, il ne sort pas sur cette vue. Les autres questions ont d'autres vues, pas la même avec un onglet par-dessus.

La home de Stripe répond à « comment va le business aujourd'hui ». La vue projet de Vercel répond à « quel est l'état de ce déploiement ». L'inbox de Linear répond à « qu'est-ce qui demande mon attention maintenant ». Des surfaces différentes pour des questions différentes. Aucune ne tente d'être les trois.

Règle 2 : une liste de priorités, triée par le produit

L'écran a une seule liste, et c'est le produit qui la trie. Pas l'utilisateur. Pas un en-tête de colonne personnalisable. Le produit choisit l'ordre en fonction de la réponse à « que doit faire l'utilisateur ensuite ». L'ordre, c'est l'avis.

Linear trie par priorité puis SLA. Stripe Atlas trie ses quatre cartes d'action selon ce qui débloque la prochaine étape business. Superhuman trie par VIP et signal d'intention, pas en strict ordre chronologique inverse. Le produit fait le travail que l'utilisateur n'a pas envie de faire.

Règle 3 : un horizon temporel raisonnable, choisi une fois

Le dashboard choisit un horizon temporel par défaut et gagne le droit de le changer. Aujourd'hui, cette semaine, ce mois, depuis toujours. Choisis celui qui correspond à la question et arrête de proposer cinq bascules.

Un dashboard de revenus pour un business transactionnel est réglé par défaut sur aujourd'hui. Un dashboard de rétention, sur cette semaine. Un dashboard financier, sur ce mois. Un dashboard qui s'ouvre sans défaut et avec un sélecteur de dates qui attend une saisie a déjà perdu l'utilisateur.

Règle 4 : chaque chiffre est lié à une action

Un chiffre sans action attachée est de la décoration. L'anti-dashboard traite chaque chiffre principal comme un crochet vers le prochain geste. Le revenu du jour renvoie aux paiements échoués. Les issues ouvertes renvoient à la file de tri. Le temps de déploiement renvoie au log de build.

La mise en page à quatre cartes de Stripe Atlas en est l'exemple le plus net. Chaque carte est un chiffre plus un bouton. « 0 $ de revenu, configurez votre intégration de paiement. » « 0 employé, embauchez le premier. » L'utilisateur n'est jamais bloqué sur une stat sans chemin devant lui.

Règle 5 : cache la longue traîne

L'anti-dashboard accepte que 80 % des métriques comptent pour 5 % des utilisateurs, 5 % du temps. Ces métriques vivent derrière un onglet, un lien « plus », ou une vue analytique à part. L'écran d'accueil, c'est la question, pas l'index.

Cacher des métriques semble risqué parce que quelqu'un réclamera celle que tu as retirée. La solution est de la rendre trouvable, pas visible. La recherche et une surface analytique dédiée gèrent la longue traîne.

Les anti-patterns à supprimer à vue

On les retrouve dans presque chaque audit. Chacun révèle une équipe qui se cache derrière des fonctionnalités au lieu de livrer un avis.

Toutes les métriques sur tous les écrans. Revenu, rétention, churn, MAU, NPS et CSAT dans un seul cadre, ce n'est pas une question, c'est une esquive. Sépare en vues par rôle ou par tâche.

Les « widgets personnalisables » comme substitut à l'avis produit. Traduis « les utilisateurs peuvent configurer leur propre dashboard » par « l'équipe n'a pas réussi à s'accorder sur ce qui comptait ». La personnalisation est une vraie fonctionnalité quand les défauts sont solides, et une excuse quand ils ne le sont pas.

Le fil d'activité en direct que personne ne lit. Une liste qui défile avec chaque événement du système. Utile pour des logs de debug, inutile sur un dashboard. L'article data visualization pour designers explique pourquoi le temps réel sans hiérarchie n'est que du bruit coûteux.

L'état vide qui demande à l'utilisateur de concevoir son propre dashboard. « Glissez des widgets depuis la barre latérale pour commencer. » Le produit avoue dès le premier écran qu'il n'a aucun avis. L'article les états vides sont le produit explique pourquoi le premier écran est la surface d'activation, pas des devoirs à la maison.

Des onglets qui cachent la vraie réponse. Six onglets en haut, la donnée la plus importante sur le troisième. Soit tu promeus le troisième, soit tu admets que les onglets un et deux comptent moins que l'équipe ne le pensait.

Avant et après, en un cadre

Passer du cimetière à l'anti-dashboard est généralement une décision de mise en page, pas de fonctionnalité. Mêmes données, classées autour de la question.

Le « avant » est une grille 4x3 où chaque cellule se dispute l'attention. L'« après » utilise la hiérarchie visuelle pour découper l'écran en trois zones : une stat héroïque liée à la question, une courte liste d'actions liée au prochain geste, et un pied de page atténué pour l'utilisateur curieux. Rien n'est supprimé, l'équipe a juste choisi quelles fonctionnalités ont la place d'honneur.

L'audit de dashboard

Fais passer n'importe quel dashboard produit par ces sept questions. Si tu ne peux pas répondre oui clairement à chacune, le dashboard n'est pas terminé.

1. Quelle est l'unique question à laquelle cette vue répond ? Écris-la en une phrase. Si l'équipe ne s'accorde pas sur la phrase, elle n'a pas encore conçu le dashboard, elle a arrangé des widgets.
2. Y a-t-il un chiffre principal lié à une action ? Pas trois stats concurrentes. Un chiffre héros, un prochain geste évident, tous les autres éléments classés en dessous, comme la hero section d'une landing page.
3. La liste de priorités est-elle triée par le produit, pas par l'utilisateur ? Si la réponse est « l'utilisateur peut la trier comme il veut », le produit n'a pas choisi de camp. Les défauts sont l'avis.
4. Quel horizon temporel cette vue utilise-t-elle par défaut, et pourquoi ? Le défaut doit correspondre à la question. Une bascule sans défaut réfléchi trahit une équipe qui a botté en touche.
5. Qu'avez-vous décidé de cacher ? Si la réponse est « rien », l'équipe n'a pas fait le travail. Les métriques cachées sont la preuve d'un avis.
6. L'état vide fait-il avancer le produit, ou le bloque-t-il ? S'il demande à l'utilisateur de configurer des widgets, vous avez livré des devoirs comme produit. Remplacez-le par une seule action préparée.
7. Si un nouvel utilisateur ouvre cet écran et n'en voit jamais d'autre, comprend-il le produit ? La vue d'accueil est autant un argumentaire de vente qu'un outil.

Un dashboard qui passe ces sept tests est un dashboard que l'utilisateur ouvre plus d'une fois. Celui qui en rate un seul est survolé, capturé en screenshot et abandonné. L'article principes de design de landing page couvre la version page marketing de la même discipline, et celui sur les principes de web design montre comment le reste du produit suit.

La friction au bon endroit

L'anti-dashboard n'est pas du minimalisme pour le minimalisme. C'est de la friction au bon endroit. La vue d'accueil est facile, la longue traîne est un clic plus difficile. Ce gradient, c'est le design. L'article concevoir la friction à dessein explique pourquoi certaines frictions sont une fonctionnalité.

Questions fréquentes

Quelle est la différence entre un dashboard et un anti-dashboard ?

Un dashboard traditionnel essaie de montrer chaque métrique qu'un utilisateur pourrait vouloir. Un anti-dashboard répond à une seule question et lie chaque chiffre visible à une action. La version traditionnelle est un buffet. L'anti-dashboard est une surface de décision.

Chaque dashboard produit doit-il proposer de la personnalisation ?

Presque aucun dashboard produit n'a besoin d'une personnalisation poussée. La plupart des équipes la livrent pour éviter de choisir des défauts. De bons défauts battent des widgets configurables sur presque toutes les mesures de rétention. Réserve la personnalisation aux surfaces pour power users, pas à la vue d'accueil.

Combien de KPI un dashboard doit-il afficher sur l'écran d'accueil ?

Une stat héroïque liée à la réponse, plus trois à cinq actions secondaires. Au-delà de cinq, l'œil perd l'ordre de priorité et le dashboard retombe en carrousel de métriques. Cache la longue traîne derrière une surface analytique plus profonde.

Choisis ton camp, puis livre l'écran

Le design de dashboard n'est pas le problème le plus dur du produit. C'est le plus procrastiné. Les équipes passent des mois à arranger des widgets parce que préférer l'un à l'autre ressemble à un risque. L'anti-dashboard traite ce risque comme le vrai travail. Choisis la question. Choisis la priorité. Choisis l'horizon temporel. Choisis ce qu'on cache.

Les dashboards qui gagnent en 2026 ne sont pas ceux qui ont le plus de données. Ce sont ceux qui ont le plus d'avis. Linear, Vercel, Stripe, Cursor, Cron, Raycast, GitHub, Notion et Superhuman partagent tous une chose. Ils ont choisi un camp, et l'écran porte ce camp.

Si tu veux une équipe qui conçoit des dashboards produit comme des surfaces de décision plutôt que comme des grilles de widgets, engage Brainy. On livre l'avis dans la mise en page par défaut.