Aller au contenu principal

Routing

Statut​

Document de cadrage frontend — v1.1 — relu le 2026-05-11, corrigé le 2026-07-18.

Vue d'ensemble​

Le routing frontend diffère selon les applications :

  • dmv-public utilise le routing fichier de Next.js App Router ;
  • dmv-workspace utilise également le routing fichier Next.js App Router, exposé derrière un Worker Cloudflare sous /acteur* et /mairie* à la racine du domaine public (voir 06-architecture/wall-engine/08-workspace-boundary.md, section de référence pour tout le routage cross-app) ;
  • dmv_backoffice utilise react-router-dom dans une SPA Vite.

Routes publiques visibles​

Dans dmv-public, les routes visibles incluent notamment :

  • /
  • /[commune]
  • /[commune]/acteur/[slug]
  • /[commune]/contributeur/[slug]
  • /mon-espace
  • /mon-espace/connexion
  • /mon-espace/profil
  • /mon-espace/tarifs
  • /mon-espace/reset-password
  • /a-propos
  • /contact
  • /cgu
  • /confidentialite
  • /mentions-legales

/mon-espace/acteur a existé (ancien tableau de bord acteur intégré à dmv-public) mais a été supprimé — la gestion acteur/mairie vit exclusivement dans dmv-workspace, voir ci-dessous.

Les pages communales et mini-sites utilisent des paramètres dynamiques.

Routes de gestion (dmv-workspace, cross-app)​

Ces routes ne sont pas servies par dmv-public : elles sont exposées à la racine du même domaine public (www.dansmonvillage.fr) via un Worker Cloudflare qui proxifie vers dmv-workspace, afin de rester sur la même origine (contrainte de continuité PWA sur iOS). Détail complet, table de routage et diagramme de flux : 06-architecture/wall-engine/08-workspace-boundary.md.

  • /acteur/[slug]/tableau-de-bord
  • /acteur/[slug]/profil
  • /acteur/[slug]/publications, /services, /infos, /alertes, /stats, /collaborateurs, /avantages, /offre, /parametres
  • /mairie/* (entrée alternative vers le même modèle de gestion, la mairie étant traitée comme un type d'acteur)

Ne jamais faire pointer un lien applicatif vers mon-espace.dansmonvillage.fr (domaine technique/historique) ou vers un hostname *.pages.dev — voir les règles non négociables du document de référence ci-dessus.

Routes backoffice visibles​

Le backoffice expose notamment :

  • /login
  • /signup
  • /forgot-password
  • /reset-password
  • /pending
  • /
  • /profile
  • /publications
  • /acteurs
  • /communes
  • /users
  • /stats
  • /contributors
  • /groupes
  • /messages
  • /actor-requests
  • /claims
  • /plans
  • /souscriptions
  • /administration/medias-defaults
  • /administration/feature-tabs

Le backoffice applique des guards selon session, profil, statut et rôle admin.

Principes​

  • Les routes publiques doivent être lisibles, stables et SEO-friendly.
  • Les routes backoffice doivent privilégier la clarté opérationnelle.
  • Les redirections doivent rester explicites.
  • Les routes dynamiques doivent gérer notFound ou état absent proprement.
  • Les routes protégées doivent être contrôlées côté backend en plus des guards frontend.

SEO et routing​

Le site public utilise :

  • metadata dans les pages ;
  • generateMetadata pour des pages dynamiques ;
  • robots.ts ;
  • sitemap.ts ;
  • trailing slash via next.config.mjs.

Ces éléments confirment une intention SEO sur les pages publiques.

Vision cible​

La cible est de maintenir :

  • routes publiques courtes et compréhensibles ;
  • routes backoffice organisées par domaine métier ;
  • redirections minimales ;
  • gestion claire des erreurs ;
  • compatibilité PWA ;
  • compatibilité future avec l'API Laravel centrale.

Points à clarifier​

  • Convention finale des URLs mairie, PlayLoop et AssoSuite côté frontend.
  • Politique de redirection lors de migrations d'URL.
  • Gestion des slugs et collisions.
  • Stratégie multi-communes à grande échelle.