Tableau de bord

Architecture d'information du tableau de bord, navigation, accueils selon les rôles et comportement du shell partagé.

Vue d'ensemble

Le tableau de bord est le shell produit authentifié. Ce n'est pas une page d'accueil générique unique; c'est un ensemble de surfaces opérationnelles adaptées aux rôles et enracinées sous:

/dashboard
/dashboard/admin
/dashboard/content
/dashboard/organization
/dashboard/settings
/dashboard/test

Toutes les routes du tableau de bord sont préfixées par la locale au runtime, par exemple /en/dashboard/content/pages.

Groupes de routes

Les routes du tableau de bord sont organisées par intention utilisateur:

Section	Racine de route	Objectif
Accueil	`/dashboard`	Hub de navigation conscient des permissions pour les sections dashboard visibles et les liens rapides.
Admin	`/dashboard/admin`	Santé plateforme et contrôles superadmin.
Contenu	`/dashboard/content`	CMS, médias, pages, sections, composants, données, design tokens et e-mails transactionnels.
Organisation	`/dashboard/organization`	Facturation d'organisation, plans, accès au code, membres et réglages d'organisation.
Réglages	`/dashboard/settings`	Compte personnel, sécurité, préférences, organisations et clés API développeur.
Test	`/dashboard/test`	Diagnostics internes d'autorisation et de routes.

Les éléments parents de la barre latérale sont des tableaux de bord de section navigables. Une route parente ne doit jamais pointer vers une page masquée ou manquante. Cela garde la navigation au clavier via le menu de commande, les fils d'Ariane et les liens directs prévisibles.

Shell partagé

Le shell du tableau de bord fournit:

le layout authentifié et les vérifications d'organisation active
la navigation de barre latérale
les actions de barre applicative
les fils d'Ariane
le menu de commande
le sélecteur d'organisation active
le menu utilisateur
l'overlay de focus pour le contenu de tableau de bord gardé

Les lectures serveur du tableau de bord utilisent une organisation active effective, résolue depuis la session Better Auth et les appartenances d'organisation de l'utilisateur. Lorsque l'organisation active stockée par Better Auth est absente ou n'appartient plus à l'utilisateur, le serveur se rabat sur l'organisation par défaut de l'utilisateur, puis sur la première appartenance. Les view-models du tableau de bord, le filtrage de navigation et les actions serveur doivent s'appuyer sur ce contexte de session serveur plutôt que d'attendre l'hydratation client de l'organisation.

Fichiers clés:

src/app/[locale]/dashboard/layout.tsx
src/blocks/dashboard/navigation/*
src/blocks/dashboard/auth-checker.server.tsx
src/blocks/dashboard/auth-checker.client.tsx
src/blocks/dashboard/section-dashboard/index.tsx

Les routes du tableau de bord devraient utiliser PageDashboard ou les modèles locaux de blocs de tableau de bord plutôt que de créer un chrome de page sans rapport.

Tableaux de bord de section

Les tableaux de bord de section sont des pages compactes de racine de route qui résument les signaux de santé utiles pour la section courante. Ils évitent que les parents de barre latérale se comportent comme des libellés non cliquables, sans répéter le titre de page déjà possédé par la barre applicative du tableau de bord.

Le shell du tableau de bord rend sur desktop une barre de navigation de section partagée dans un sous-en-tête sticky directement sous la barre applicative, avec les fils d'Ariane au-dessus lorsque le flag breadcrumb est actif. Elle est dérivée de l'arbre de barre latérale filtré et ne liste que les routes enfants de la section active; elle reste donc compacte, consciente des permissions et centrée sur la navigation locale de sous-section au lieu de dupliquer les sections de tableau de bord de premier niveau. Le fil d'Ariane et la barre de navigation de section sont contrôlés indépendamment par les indicateurs de fonctionnalité gérés dashboard-breadcrumbs-enabled et dashboard-section-navigation-enabled.

Tableaux de bord de section actuels:

/dashboard/admin
/dashboard/content
/dashboard/organization
/dashboard/settings
/dashboard/test

Chaque tableau de bord de section devrait:

s'appuyer sur la navigation de section du shell pour les liens enfants visibles
respecter la visibilité authz
afficher des cartes, graphiques et appels à l'action opérationnels propres à cette section
éviter de dupliquer les actions cachées d'admin, de facturation ou de navigation de premier niveau via des cartes de raccourcis autonomes

Accueil adapté aux rôles

La route principale /dashboard est l'accueil de navigation conscient des permissions. Elle est pilotée par un view-model serveur qui lit l'arbre de barre latérale filtré et transforme les racines de sections visibles en cartes plus un court ensemble de liens rapides.

Comme la page d'accueil dérive de navigationConfig.nav.sidebar.groups après filterNavigationByPermissions(...), les futures pages dashboard peuvent y apparaître en étant ajoutées au modèle normal de sidebar et en passant les mêmes filtres authz. Ne maintenez pas un second registre de raccourcis pour l'accueil.

Tous les utilisateurs authentifiés:

reçoivent des cartes de section pour les racines dashboard visibles selon leur rôle
reçoivent des liens rapides générés depuis les routes enfants visibles
voient le contexte d'organisation active lorsqu'il existe
ne reçoivent pas de doublons de santé organisationnelle, facturation, contenu, revenus ou analytics fournisseur sur la page d'accueil

Services clés:

src/lib/server/services/dashboard/dashboard-home.ts
src/lib/server/services/dashboard/dashboard-analytics.ts
src/lib/server/services/dashboard/cms-dashboard.ts
src/lib/server/services/dashboard/dashboard-sources.ts

Les lectures de métriques sont server-only et passent par un contrat partagé de sources dashboard. Les sources base de données, PostHog, Stripe et déploiement renvoient ready, stale, missing_config, timeout ou error avec des métadonnées de statut. Les agrégats utilisent le Data Cache partagé de Next.js pendant 5 minutes, avec clés par route, période, organisation et périmètre d'accès, et une coalescence des lectures en vol pour éviter les doublons de cache froid pendant le render serveur et le refresh client. Un court snapshot last-good en mémoire garde visibles les métriques précédemment chargées lorsqu'une source échoue ensuite. La session et les checks d'autorisation restent par requête. TanStack Query peut rafraîchir ces modèles dashboard en lecture seule via /api/dashboard/*, mais ne doit pas refetch automatiquement au mount, focus, reconnexion ou retry loop, et ne remplace jamais l'autorisation serveur. Les erreurs SQL brutes et fournisseur doivent rester dans les logs serveur plutôt que d'être sérialisées dans les view-models client.

Tableau de bord admin

/dashboard/admin est la surface de santé plateforme superadmin. Elle résume:

les revenus Stripe et la santé des abonnements
l'audience et l'activité PostHog
le statut de déploiement depuis Vercel ou les métadonnées statiques auto-hébergées lorsqu'elles sont configurées
la croissance des utilisateurs inscrits
les webhooks de facturation échoués
les problèmes de synchronisation du catalogue Stripe
la navigation de section admin consciente des permissions

/dashboard/admin/users est la surface superadmin de gestion des utilisateurs. Elle est gardée par Yayaw user:manage, pas par Better Auth user.role. Elle liste les utilisateurs Better Auth, l'état de bannissement et 2FA, les organisations par défaut, les sessions actives et les compteurs d'appartenance aux organisations. Le tiroir de détail permet aux superadmins d'ajouter un utilisateur à une autre organisation, de modifier le rôle d'appartenance Better Auth à une organisation, de retirer une appartenance, de définir l'organisation par défaut, d'inspecter les groupes Yayaw correspondants et de démarrer ou d'arrêter une impersonation contrôlée par RBAC.

Cette page remplace l'ancienne route /dashboard/admin/status comme point d'entrée de la barre latérale. Traitez /dashboard/admin comme l'URL canonique du statut plateforme dans les nouvelles docs et navigations.

Tableau de bord contenu

/dashboard/content est le tableau de bord de santé du CMS. Sa surface principale centrée sur les pages résume la progression de publication, la création de nouvelles pages dans la plage sélectionnée et les pages récemment mises à jour, puis l'appuie par des signaux CMS plus larges:

sections
stockage média
analytics de vues CMS visibles dans le dashboard et classement des pages principales depuis PostHog lorsque les variables privées de Query API sont configurées
modèles et entrées de données CMS
activité Page AI et Section AI
santé de publication
navigation de section vers les surfaces de contenu accessibles à l'utilisateur courant

Le chemin de lecture par défaut du tableau de bord CMS utilise des compteurs de base de données indexés rapides pour les pages, sections, médias, composants, modèles de données et modèles d'e-mails, afin que la route se rende rapidement. Les lectures PostHog de vues de pages s'exécutent séparément comme fournisseur best-effort, bornées par l'événement cms_page_viewed émis par le runtime de pages CMS et par les périmètres de pages CMS visibles dans le dashboard. Les vues de pages d'organisation utilisent le périmètre de l'organisation active; les vues de pages globales exigent page:manage global parce que page:read global peut représenter l'accès public runtime. Le dashboard affiche le total de la période sélectionnée et une table des pages principales ordonnée par vues, puis se dégrade sans bloquer les compteurs base si PostHog est indisponible. Les compteurs base et les agrégats de vues de pages sont mis en cache 5 minutes avec des clés conscientes de l'accès. Définissez CMS_DASHBOARD_FULL_METRICS=true uniquement après avoir optimisé la base de données pour les agrégats de publication et d'activité plus lourds.

Docs propres au contenu:

Tableau de bord organisation

/dashboard/organization est la racine de section pour les opérations de l'organisation active:

métriques d'activité de l'organisation
signaux d'usage des membres, du contenu, des médias et de PostHog
état de facturation et consommation des sièges
résumé de facturation
sélection de plan
accès au code acheté
membres
réglages d'organisation

Les surfaces de facturation restent volontairement séparées:

/dashboard/organization/billing pour l'état et l'activité courants
/dashboard/organization/plans pour les actions de checkout
/dashboard/organization/code-access pour les livrables de code source achetés

Cette séparation évite de tasser la comparaison des plans, l'historique de facturation et les flux d'accès post-achat dans une seule page.

Tableau de bord réglages

/dashboard/settings regroupe les réglages personnels et développeur:

inventaire du compte
posture de sécurité
instantanés de profil et de préférences
profil du compte
sécurité et MFA
préférences
organisations rejointes
clés API développeur

La page Réglages développeur utilise le bloc de clé API personnalisé de Yayaw, pas l'UI générique de clés API Better Auth, car les permissions de plan de contrôle (control plane) sont gérées côté serveur et doivent être écrites par le flux d'émission/réparation de permissions de Yayaw.

/dashboard/test est une vue d'ensemble de diagnostics internes. Elle résume la couverture des routes du tableau de bord, le seeding des indicateurs de fonctionnalité gérés et les contrats ressource/action d'autorisation, puis crée des liens vers les surfaces de test de routes et d'autorisation.

La navigation devrait utiliser la configuration partagée route/navigation et les helpers @/i18n/navigation. Évitez next/link brut et la concaténation de chemins brute dans les composants de navigation du tableau de bord, sauf raison spécifique au niveau route.

Règles:

les libellés de barre latérale et les entrées du menu de commande doivent se résoudre depuis le même modèle de routes
les fils d'Ariane devraient refléter de vrais parents navigables
les routes masquées ne devraient pas apparaître dans la barre latérale ou le menu de commande
les éléments parents devraient avoir une vraie page, pas seulement des enfants expansibles
la visibilité des routes devrait correspondre aux gates authz/ressource

Autorisation

L'accès aux routes du tableau de bord utilise le service d'autorisation Yayaw au-dessus de la session Better Auth et de l'appartenance d'organisation.

Contrats importants:

les vérifications de routes sont côté serveur
les actions DB générées exécutent toujours can(...)
la visibilité de navigation ne remplace pas l'autorisation serveur
la gestion des utilisateurs plateforme et l'impersonation utilisent user:manage
Yayaw ne traite jamais Better Auth user.role comme autorisation applicative
les routes de test sous /dashboard/test sont uniquement des diagnostics

La page d'administration de l'autorisation vit à:

/dashboard/admin/authorization

Elle prend en charge l'inspection des groupes/rôles/policies, l'évaluation rapide, les vues de détail et les diagnostics orientés audit pour le modèle RBAC.

Checklist de développement

Lors de l'ajout d'une page au tableau de bord:

Ajoutez la route sous la bonne racine de section.
Ajoutez ou mettez à jour les métadonnées/configuration de navigation de route.
Assurez-vous que le tableau de bord de section parent y renvoie lorsqu'elle est visible.
Ajoutez les vérifications d'accès côté serveur.
Gardez la navigation visible à l'utilisateur avec la même intention authz/ressource.
Ajoutez les traductions sous src/messages/default/dashboard.json et src/messages/fr/dashboard.json.
Mettez à jour les docs anglaises pertinentes.
Ajoutez des tests ciblés lorsque la route modifie la navigation, l'authz ou le comportement de view-model partagé du tableau de bord.

Validation

Vérifications utiles après des changements de navigation du tableau de bord:

bun run check
bunx tsc --noEmit
bun test src/lib/server/authz/contracts.test.ts
bun run build