Plan de revue du Dashboard (app back-office)

Objectif : Prévoir une revue structurée du dashboard d’accueil de l’application (page / ou /dashboard) pour en améliorer la clarté, la pertinence et la maintenabilité.

Contexte

• Page : frontend/src/pages/dashboard/DashboardPage/
• État actuel : Hub simplifié (réduction de la densité, Quick Actions, vues spécialisées dans les pages métier) — voir PLAN_AMELIORATIONS_CRM.md « Accueil Dashboard = Hub simplifié ».
• Références : AGENTS_DESIGN.md, AGENTS_FRONTEND.md (documentation interne), PRIORITES.md.

État actuel (inventaire)

Structure de la page

• Header : titre « Dashboard », boutons Session wizard, Actions rapides, Paramètres (sidebar).
• Sections (ordre actuel) :
  1. RequestsSection — formulaires de capture (lead forms), requêtes récentes, métriques, alerte inactivité.
  2. RevenueSection — revenus (stats, tendance, graphique).
  3. DuplicatesSection — groupes de doublons (email/téléphone/nom), CTA « Gérer les doublons » (masqué si aucun doublon).
  4. ContactsSection — contacts récents, nouveaux cette semaine / aujourd’hui, lien dédoublonnage.
  5. SessionsSection — prochaine session, sessions cette semaine, sessions récentes.
  6. DocumentsSection — indicateurs documents (à préciser selon l’implémentation).

Données et hooks

• useDashboard (hooks/useDashboard.tsx) : agrège contacts, sessions, doublons, lead forms, stats globales (useDashboardStats), formatage dates/devises.
• Sidebar paramètres : DashboardSettingsSidebarContent — personnalisation des widgets, rafraîchissement (à confirmer selon l’implémentation).

Modales

• QuickSetupModal — actions rapides (création session, contact, etc.).
• SessionWizardModal — création de session en mode wizard.

Objectifs de la revue

1. Pertinence : Les blocs affichés correspondent-ils aux usages prioritaires (premier écran après login) ?
2. Hiérarchie : Ordre et poids visuel des sections (stats vs actions vs listes).
3. Performance : Nombre de requêtes au chargement, possibilité de lazy-load ou de sections pliables.
4. Mobile : Lisibilité, touch targets, ordre des sections sur petit écran (voir AGENTS_MOBILE.md).
5. Design tokens : Respect de AGENTS_DESIGN.md (tokens, typo, pas de valeurs arbitraires).
6. Accessibilité : Landmarks, titres de section, annonces pour chargements dynamiques.
7. Maintenabilité : Découpage des sections, partage de logique (hooks), tests.

Phases proposées

Phase 1 — Audit

• Lister toutes les sections, leurs données (endpoints / hooks) et leur coût au premier rendu.
• Vérifier la conformité design tokens / typo (valeurs en dur, tailles, espacements).
• Passer en revue l’accessibilité (titres, aria, landmarks) et appliquer les corrections.
• Documenter une checklist mobile (ordre, lisibilité, Quick Actions, touch targets).
• Tester sur mobile en conditions réelles (à faire manuellement).

Livrable : document ou section « Audit dashboard » avec checklist et constats.

---

Phase 1 — Résultats de l’audit (2026-02-25)

1. Sections et données (endpoints / requêtes au chargement)

Section	Données	Hooks / sources	Requêtes API effectives
RequestsSection	Formulaires, requêtes récentes, métriques, inactivité	useLeadFormsOverview (formsLimit: 4, latestLimit: 6)	GET /api/lead-forms/overview (ou équivalent)
RevenueSection	Revenus, tendance, graphique	useDashboardStats → agrège quotes, invoices, sessions	useAllQuotes, useAllInvoices, useContracts, useSessions, useAllDuplicates, useRegisteredDuplicates
DuplicatesSection	Groupes doublons, CTA	useContactDuplicateGroups("both"), useAllDuplicates, useRegisteredDuplicates	GET /api/contacts/duplicate-groups, duplicates list/registered
ContactsSection	Contacts récents, nouveaux	useContacts, useContactDuplicateGroups	Déjà chargés (contacts, duplicate-groups)
SessionsSection	Prochaine session, cette semaine, récentes	useSessions	Déjà chargé (sessions)
DocumentsSection	Indicateurs documents	stats (useDashboardStats)	Agrégé via quotes/invoices/contracts/sessions

Synthèse : Au premier rendu, le dashboard déclenche en parallèle : contacts, sessions, duplicate-groups, duplicates (all + registered), lead-forms overview, quotes, invoices, contracts. Pas d’endpoint unique « dashboard » ; useDashboardStats réutilise des hooks déjà utilisés par useDashboard (doublons, sessions) mais ajoute quotes, invoices, contracts. Nombre de requêtes réseau : ~6–8 selon le cache (contacts, sessions, duplicate-groups, duplicates, lead-forms, quotes, invoices, contracts).

2. Design tokens / valeurs arbitraires

• Conformes : RevenueSection (h-chart-empty, size tokens), RequestsSection (max-h scroll panel), modales (max-w dialog).
• À corriger :
  • text-[11px] utilisé dans DocumentsSection, DuplicatesSection, RequestsSection, StatusStatCard → remplacer par text-2xs (token --text-2xs: 0.6875rem = 11px).
  • SectionHeader : min-w-[1.5rem] → remplacer par min-w-6 (Tailwind standard 1.5rem).

3. Accessibilité

• À vérifier manuellement : titres de section (h2/h3), landmarks (main, region), annonces de chargement (aria-live / skeletons).
• Boutons header : icône Settings avec sr-only présent.

Corrections appliquées (2026-02-25) :

• Landmark principal : contenu du dashboard (toutes les sections) enveloppé dans un <main aria-label="…"> (titre dashboard) pour permettre « skip to main content » et annonce claire du contenu principal.
• Sections : SectionWrapper utilise désormais <section> avec aria-labelledby pointant vers un h2 doté d’un id unique (dashboard-section-{section}) pour chaque bloc (Revenus, Doublons, Contacts, Sessions, Documents).
• RequestsSection : enveloppée dans <section aria-labelledby="dashboard-requests-title">, avec CardTitle (h3) ayant id="dashboard-requests-title" pour associer le titre à la région.
• Optionnel (Phase 3) : aria-live="polite" sur les zones qui se mettent à jour au chargement si besoin d’annonces dynamiques.

4. Mobile (web responsive)

• À valider manuellement : ordre des sections, touch targets (Quick Actions, boutons), lisibilité des cartes.

Checklist test manuel (viewport étroit / tactile) :

• Ordre : défilement naturel (Requests → Revenus → Doublons → Contacts → Sessions → Documents) ; pas de contenu coupé ou illogique.
• Header : boutons « Session wizard », « Actions rapides » en pleine largeur sur mobile (w-full sm:w-auto) ; bouton Paramètres (icône) accessible.
• Quick Actions (modale) : grille 1 colonne sur mobile (grid-cols-1 sm:grid-cols-2), boutons en px-4 py-3 (zone de touch correcte).
• Sections : cartes et listes lisibles (pas de texte tronqué abusif), liens et boutons (ex. « Gérer les demandes », « Voir les soumissions ») facilement cliquables.
• Touch targets : bouton icône Paramètres en min-h-11 min-w-11 (44px) + touch-manipulation (Phase 3 appliqué).

Phase 2 — Priorisation produit

• Rédiger la spec (ordre proposé, optionnel, checklist) → voir DASHBOARD_TARGET_SPEC.md.
• Valider avec le produit les blocs indispensables vs optionnels.
• Décider de l’ordre cible des sections (ex. : prochaine session + actions en tête, puis revenus, puis listes).
• Décider si certaines sections deviennent optionnelles (paramétrables via la sidebar existante ou masquables).
• Aligner la terminologie (titres de section, libellés boutons) avec le reste de l’app et l’i18n.

Livrable : spec courte « Dashboard cible » → DASHBOARD_TARGET_SPEC.md (rédigée ; validation produit en attente).

Phase 3 — Ajustements techniques et UX

• Réordonner ou masquer des sections selon la spec Phase 2 (ordre appliqué ; sections masquables via préférences).
• Sections optionnelles : afficher/masquer par section via sidebar Paramètres ; persistance via store UI (localStorage).
• Remplacer les valeurs arbitraires par des tokens (si pas déjà fait).
• Améliorer le chargement : skeletons homogènes, gestion d’erreur par section, éventuel lazy-load des sections non above-the-fold.
• Améliorer la responsive et le touch (Quick Actions, cartes, bouton Paramètres 44px).
• Ajuster l’accessibilité (landmarks, aria-labelledby).

Skeletons (état actuel) : RequestsSection, StatusStatCard, RecentItemsList, StatCard utilisent <Skeleton> avec hauteurs cohérentes (h-7, h-8, h-16, h-20). RevenueSection et DocumentsSection n'affichent pas de skeleton dédié (données agrégées). Homogénéité suffisante ; optionnel : skeleton global pour Revenue/Documents au premier chargement.

Livrable : PR(s) implémentant les changements priorisés.

Phase 4 — Optionnel (évolution)

• Widgets afficher/masquer et persistance (sidebar Paramètres → store UI persisté en localStorage).
• Réordonnancement des sections par glisser-déposer (ordre personnalisé) — optionnel.
• Rafraîchissement automatique configurable (déjà évoqué dans la sidebar).
• Tests E2E ciblés sur le dashboard (chargement, clics principaux).

Références

• DASHBOARD_TARGET_SPEC.md — Spec Phase 2 (ordre cible, sections optionnelles, validation produit).
• PLAN_AMELIORATIONS_CRM.md — Accueil Dashboard = Hub simplifié, Quick Actions.
• PRIORITES.md — Dashboard, sidebar settings, Session Wizard.
• AGENTS_DESIGN.md — Tokens, typo, hiérarchie.
• AGENTS_MOBILE.md — Contraintes mobile.
• ROADMAP.md — Point d’entrée priorités.

Changelog

• 2026-02-25 : Phase 3 : liaison DashboardPage ↔ dashboardWidgetPreferences ; les sections (Sessions, Requests, Revenue, Documents, Contacts, Duplicates) sont affichées ou masquées selon les préférences sidebar ; persistance déjà en place (store UI + localStorage).
• 2026-02-25 : Phase 2 : spec « Dashboard cible » rédigée (DASHBOARD_TARGET_SPEC.md) ; ordre proposé, sections optionnelles, checklist validation produit.
• 2026-02-25 : Phase 3 : Error Boundary par section (DashboardSectionBoundary + Sentry, fallback i18n + retry) ; doc skeletons + erreur dans le plan.
• 2026-02-25 : Phase 3 (anticipé) : bouton Paramètres dashboard en min-h-11 min-w-11 + touch-manipulation pour cible tactile 44px.
• 2026-02-25 : Phase 1 mobile : checklist test manuel (ordre, header, Quick Actions, touch targets) et note 36px vs 44px pour le bouton Paramètres.
• 2026-02-25 : Phase 1 accessibilité : <main>, <section> avec aria-labelledby / titres associés (SectionWrapper, RequestsSection) ; doc mise à jour.
• 2026-02-25 : Phase 1 audit : inventaire sections/endpoints, constats design tokens, correction text-[11px] → text-2xs et min-w-[1.5rem] → min-w-6 dans les composants dashboard.
• 2026-02-25 : Création du plan (inventaire, objectifs, phases 1–4).