UI du tableau de bord
À l'issue de cette leçon, le stagiaire maîtrise la grammaire visuelle des dashboards modernes, identifie les trois pièges classiques de charte, et génère un dashboard en trois passes structurées avec Claude.
La grammaire visuelle stabilisée
Un tableau de bord moderne suit une grammaire visuelle stabilisée depuis quelques années. La connaître vous évite de réinventer une roue carrée et fait gagner du temps à Claude. Quand vous lui demandez « un dashboard standard », il sait quoi produire.
Barre latérale à gauche
Navigation entre sections. Logo en haut, items de menu au milieu, profil utilisateur en bas. Réduit la charge cognitive : les sections principales sont toujours visibles.
En-tête en haut
Recherche globale, notifications, profil utilisateur. Optionnellement un fil d'Ariane. Garde l'utilisateur orienté dans une arborescence profonde.
Zone principale — KPI en haut
4 à 6 cartes de chiffres-clés avec évolution (en % vs période précédente). C'est ce que l'utilisateur scanne en premier.
Zone principale — graphiques au milieu
Tendances temporelles, répartitions, comparaisons. Maximum 4 graphiques par écran. Au-delà, l'œil se perd.
Zone principale — tableaux en bas
Détails et actions. Trié, filtrable, paginé. C'est là que l'utilisateur descend quand il a une question précise après avoir vu les KPI.
Elle suit le mouvement naturel du regard : du général au particulier, du chiffre au détail. Un cadre regarde les KPI en 5 secondes, plonge dans un graphique en 30 secondes, n'ouvre le tableau qu'en cas de question précise. La structure honore cette hiérarchie d'attention.
Trois pièges classiques à éviter
1. Trop de couleurs
Un dashboard utile a 2 à 3 teintes accent maximum, le reste en gris neutre. Un dashboard arc-en-ciel est illisible : l'œil ne sait plus où regarder en priorité.
2. Pas de hiérarchie
Trop d'informations au même niveau visuel. Ce qui doit être vu en premier doit être plus grand, plus contrasté, plus haut. Ce qui est secondaire doit être discret.
3. Densité inadaptée
Un dashboard pour un cadre qui le consulte 2 fois par semaine n'a pas la même densité qu'un dashboard pour un opérateur qui l'a sous les yeux toute la journée. Le premier privilégie la lisibilité, le second la quantité d'informations.
Toujours préciser à Claude
Quand vous demandez un dashboard à Claude, précisez le profil utilisateur cible et la fréquence d'usage. Sans cette précision, il produit une densité moyenne qui ne convient à personne précisément.
Démo — générer en trois passes
L'erreur classique du débutant : demander tout en un seul prompt et obtenir un résultat médiocre sur tous les axes. La bonne méthode : itérer par couches, valider chaque couche avant la suivante.
# PASSE 1 — Structure générale (sans charte) → Génère la structure d'un dashboard pour un consultant : - sidebar avec sections Missions / Facturation / Prospects - header avec recherche et profil - zone principale : 4 KPI cards 2 graphiques (évolution mensuelle CA en barres, répartition par client en donut) 1 tableau des dernières factures Stack : React + shadcn-ui. PAS de styles charte pour l'instant. # Vérifier la structure dans le navigateur # Si OK → passer à la passe 2 # PASSE 2 — Charte visuelle → Applique la charte suivante : - palette sable + terre cuite + encre brune - typographie sérif élégante pour titres - sans-serif pour le corps - hiérarchie : KPI cards très visibles, graphiques discrets, tableau dense mais lisible # PASSE 3 — Micro-interactions → Ajoute : - hover sur les cartes (légère élévation) - transitions entre onglets (200 ms) - états vides (que se passe-t-il sans données ?) - chargement (skeleton ou spinner ?)
Trois prompts ciblés valent mieux qu'un prompt monolithique. La méthode permet aussi de défaire une passe si elle ne convient pas, sans repartir de zéro.
Test final — les trois résolutions
Avant de considérer un dashboard comme livrable, testez-le sur trois résolutions via les DevTools du navigateur (mode responsive) :
Mobile — 375 px
Le dashboard doit rester utilisable, même si les KPI passent en colonne unique et les tableaux en cartes empilées. Les graphiques peuvent disparaître ou se réduire.
Tablette — 768 px
Largeur intermédiaire. KPI sur 2 colonnes typiquement. Sidebar peut basculer en menu hamburger selon le contexte.
Desktop — 1280 px et plus
Affichage complet. C'est le cas nominal pour la plupart des dashboards B2B. Vérifier que la densité reste agréable même sur grand écran.
C'est le test qui sépare un dashboard présentable en démo d'un dashboard utilisable en production. Si l'utilisateur peut se retrouver sur mobile (ce qui arrive plus souvent qu'on ne le pense), tout casse en condition réelle.
Concevez votre dashboard de pilotage
Concevez le dashboard que vous aimeriez avoir pour piloter votre activité. Pour un consultant : missions, facturation, prospects. Pour un formateur : sessions, taux de remplissage, satisfaction. Pour un dirigeant : trésorerie, marge, équipe. (1) Spécifiez-le par écrit avant de générer (KPI, graphiques, tableaux). (2) Faites-le générer par Claude en trois passes. (3) Testez sur les 3 résolutions. Documentez ce qui marche et ce qui demande ajustement.
Cet exercice est à conserver dans votre dossier de stagiaire. Il n'est pas évalué mais il est tracé.
- ui.shadcn.com — Examples Dashboard exemple de dashboard de référence en composants shadcn-ui
- recharts.org bibliothèque de graphiques React utilisée fréquemment avec shadcn-ui
Vous savez générer un dashboard structuré en 3 passes et le tester sur 3 résolutions ?