Frontière entre `dmv-public` et `dmv-workspace`

Statut

Document de cadrage architecture — v2.0 — créé le 2026-06-27, mis à jour le 2026-07-18.

Ce document est désormais la référence de l'architecture de routage et de déploiement réellement en production, vérifiée directement dans le Dashboard Cloudflare et par tests HTTP en production le 2026-07-18 (pas une extrapolation du code seul). Il remplace toute description antérieure d'un workspace exposé sous /mon-espace/* — voir ## 6. Historique vs architecture actuelle pour la distinction explicite.

1. Domaine canonique

https://www.dansmonvillage.fr

dansmonvillage.fr (sans www.) redirige en 301 vers www.dansmonvillage.fr, pour toutes les routes, y compris celles sans rapport avec le workspace (vérifié notamment sur /mon-espace/, propre à dmv-public). C'est une règle de zone Cloudflare, pas une redirection applicative.
Toute URL cross-app générée par le code (dmv-public → dmv-workspace et retour) doit utiliser www. explicitement. Un lien sans www. déclenche ce saut de redirection avant d'atteindre la bonne page — suffisant à lui seul pour casser la continuité PWA en mode standalone sur iOS, même quand la destination finale est correcte.
mon-espace.dansmonvillage.fr est un Custom Domain Cloudflare Pages actif, attaché au projet dmv-workspace, mais c'est un domaine technique/historique. Il ne doit plus apparaître dans un parcours utilisateur normal (voir ## 5. Règles non négociables).

2. Répartition des responsabilités

`dmv-public`

Application utilisateur — expérience publique et personnelle.

Contient :

/ — mur de ville ;
pages territoriales (/{commune}, /{commune}/acteur/{slug}, /{commune}/contributeur/{slug}) ;
/mon-espace — hub personnel (mur, favoris, profil, agenda) ;
recherche, contenus légaux ;
le manifest PWA (public/manifest.json) — DMV s'installe depuis dmv-public.

`dmv-workspace`

Outil de gestion — exposé derrière le Worker Cloudflare, à la racine du domaine canonique, jamais sous /mon-espace/.

Contient :

gestion acteur (/acteur/{slug}/tableau-de-bord, /profil, /publications, /services, /infos, /alertes, /stats, /collaborateurs, /avantages, /offre, /parametres) ;
gestion mairie, comme un type d'acteur (kind === "mairie"), via les mêmes routes /acteur/{slug}/* — pas de routing dédié séparé. Le groupe de routes historique /mairie/[slug]/* (avec ses propres guards) a été supprimé ; seule la route Worker /mairie* subsiste comme entrée alternative vers ce même modèle unifié.

Règle de bascule

Voir (fiche publique) reste sur dmv-public.
Gérer ouvre dmv-workspace, sur la même origine, sans jamais quitter le shell PWA.

Le workspace n'est pas une version privée du site public : c'est un outil métier distinct, mais perçu comme faisant partie de la même application par l'utilisateur.

3. Table de routage

URL publique	Projet responsable	Usage	Worker ?	Visible utilisateur
`www.dansmonvillage.fr/`	`dmv-public`	Mur de ville	Non	Oui
`www.dansmonvillage.fr/{commune}`	`dmv-public`	Annuaire communal	Non	Oui
`www.dansmonvillage.fr/{commune}/acteur/{slug}`	`dmv-public`	Fiche publique d'un acteur	Non	Oui
`www.dansmonvillage.fr/mon-espace`	`dmv-public`	Hub personnel	Non	Oui
`www.dansmonvillage.fr/acteur/{slug}/tableau-de-bord`	`dmv-workspace`	Gestion acteur	Oui (`/acteur*`)	Oui
`www.dansmonvillage.fr/acteur/{slug}/offre`	`dmv-workspace`	Abonnement/offre acteur	Oui (`/acteur*`)	Oui
`www.dansmonvillage.fr/mairie/*`	`dmv-workspace`	Entrée alternative gestion mairie	Oui (`/mairie*`)	Oui
`dmv-workspace.pages.dev`	`dmv-workspace`	Build brut CF Pages, cible du proxy Worker	—	Technique seulement, jamais dans un lien utilisateur
`mon-espace.dansmonvillage.fr`	`dmv-workspace`	Custom Domain historique/technique	Non (accès direct)	Ne doit plus être utilisé dans un parcours utilisateur

Non-chevauchement garanti par construction : la fiche publique (/{commune}/acteur/{slug} — 1er segment = nom de commune) et la route de gestion (/acteur/{slug}/… — 1er segment littéralement acteur) ont un découpage de segments différent. Une commune ne s'appelle jamais « acteur » : aucune collision possible en pratique, sans logique d'arbitrage nécessaire côté Worker.

4. Diagramme de flux

iPhone, PWA DMV installée (origine : www.dansmonvillage.fr)
  │
  ▼
www.dansmonvillage.fr/mon-espace          (dmv-public, natif)
  │
  │  clic « gérer mon acteur »
  ▼
www.dansmonvillage.fr/acteur/{slug}/…     (même origine, pas de redirection)
  │
  ▼
Worker Cloudflare "mon-espace"            (route dansmonvillage.fr/acteur*)
  │  proxy transparent (fetch), pas de redirection HTTP
  │  hostname cible ← PAGES_HOSTNAME (dmv-workspace.pages.dev)
  ▼
CF Pages dmv-workspace                    (contenu réel de la page)
  │
  ▼
Réponse servie sous le hostname public inchangé (www.dansmonvillage.fr)
  → l'utilisateur ne voit jamais dmv-workspace.pages.dev
  → aucune sortie du shell standalone iOS

5. Règles non négociables

Jamais de lien utilisateur vers mon-espace.dansmonvillage.fr.
Jamais de lien utilisateur vers un hostname *.pages.dev.
Jamais de domaine sans www. dans les helpers cross-app (lib/workspaceUrls.ts côté dmv-public, lib/public-urls.ts côté dmv-workspace).
Jamais de target="_blank" pour le passage public ↔ workspace.
Jamais de changement d'origine dans le parcours PWA — toute navigation entre dmv-public et dmv-workspace doit rester sur www.dansmonvillage.fr.
Toute nouvelle route workspace doit être déclarée explicitement côté Worker (Cloudflare Dashboard → Worker mon-espace → Triggers) — une route non déclarée renvoie une erreur, elle ne « marche pas par hasard ».
Toute modification du routage doit vérifier l'absence de collision avec les routes publiques de dmv-public (voir ## 3. Table de routage, note sur le non-chevauchement).

6. Historique vs architecture actuelle

D'anciens documents (et l'ancien fichier dmv-workspace/docs/deployment/mon-espace-cloudflare.md) décrivent un workspace exposé sous dansmonvillage.fr/mon-espace/*, avec BASE_PATH=/mon-espace au build. Cette description correspond à une architecture envisagée, partiellement construite (le Worker et le script existaient), mais jamais réellement mise en service. Ce n'est pas une erreur de conception détectée après coup — c'est une documentation rédigée pour une cible qui a été remplacée en cours de route par l'architecture décrite ci-dessus (routes /acteur* et /mairie* directement à la racine), sans que la documentation soit mise à jour en conséquence.

Concrètement, vérifié le 2026-07-18 :

Le Worker Cloudflare (nommé historiquement mon-espace) n'avait aucune variable configurée (PAGES_HOSTNAME absent) — il renvoyait une erreur pour toute requête.
Le projet CF Pages dmv-workspace (et non dmv-mon-espace, autre écart avec l'ancienne documentation) n'a aucun BASE_PATH configuré en Production — le build ne prévoit pas de préfixe.
Les routes réellement déclarées sur le Worker sont /acteur* et /mairie*, pas /mon-espace* — cohérent avec le fait que /mon-espace/* est déjà un chemin propre à dmv-public (son hub personnel), qui aurait entraîné une collision si le workspace avait aussi tenté de l'utiliser.

Les routes suivantes, encore présentes dans d'anciens documents ou audits datés, n'existent plus et ne doivent pas être recréées :

/mon-espace/acteur/* (ancien tableau de bord acteur intégré à dmv-public, supprimé)
/mon-espace/mairie/* (n'a jamais existé sous cette forme)

Les mentions de ces routes dans des documents explicitement datés (ex. docs/audits/dmv-v1-readiness-audit.md, daté du 2026-06-07) sont des enregistrements historiques légitimes de l'état du code à cette date — elles ne sont pas corrigées, seulement signalées comme non représentatives de l'architecture actuelle.

7. Source de vérité

Pour l'architecture de routage et de déploiement, la priorité est, dans cet ordre :

Code déployé (branche de production réelle de chaque dépôt, pas une branche de travail).
Configuration Cloudflare active (Dashboard — Workers routes, variables, Custom Domains).
Tests de production (requêtes réelles, logs de build).
Documentation (ce document et les documents qu'il référence).

La documentation doit être synchronisée avec ces trois sources — jamais l'inverse. En cas de doute ou de divergence constatée, vérifier dans cet ordre plutôt que de faire confiance à un document non daté ou non revérifié récemment.

Annexe — Comportement d'implémentation détaillé

Racine de `dmv-workspace`

Depuis le 2026-07-18, la racine (/) de dmv-workspace n'affiche plus de hub personnel. Elle applique une logique de répartition basée sur les espaces administrés par l'utilisateur (useWorkspaceAccess() / services/workspace/access.ts) :

Un seul espace géré → redirection directe vers son tableau de bord (/acteur/[slug]/tableau-de-bord).
Plusieurs espaces gérés → sélecteur minimal (SpaceSelector dans app/page.tsx), sans mur, favoris, profil ou onboarding.
Aucun espace géré → redirection vers Mon espace de dmv-public, via getPersonalSpaceHref() (lib/public-urls.ts), basé sur NEXT_PUBLIC_SITE_URL (doit inclure www., voir ## 1. Domaine canonique).

La route /profil ne présente plus de profil personnel : elle redirige vers la page profil de dmv-public via getPersonalProfileHref().

Unification du routing mairie

Le groupe de routes app/(workspace)/mairie/[slug]/** (et ses guards dédiés MairieGuard/MairieCapabilityGuard, sa navigation WorkspaceSidebar/WorkspaceBottomNav) a été supprimé côté application. Une mairie est désormais gérée exclusivement comme un acteur (kind === "mairie") via /acteur/[slug]/*. services/workspace/access.ts résout directement l'acteur lié à chaque commune gérée (mairie_actor_id → slug de l'acteur) pour construire ses liens.

Cas limite non couvert : une commune gérée sans acteur lié (mairie_actor_id null) n'a plus aucune interface de gestion dans dmv-workspace — l'ancien layout mairie autonome qui gérait ce cas a disparu avec les routes. À vérifier en base avant mise en production (nombre de communes concernées) via dmv-workspace/scripts/check-mairie-data-integrity.sh.

Conséquence pour l'architecture Wall

Le Wall Engine appartient au domaine de consultation utilisateur, donc pensé d'abord pour dmv-public. Le workspace peut ouvrir des vues de consultation si nécessaire, mais ne doit pas devenir le centre du moteur.

Statut​

1. Domaine canonique​

2. Répartition des responsabilités​

dmv-public​

dmv-workspace​

Règle de bascule​

3. Table de routage​

4. Diagramme de flux​

5. Règles non négociables​

6. Historique vs architecture actuelle​

7. Source de vérité​

Annexe — Comportement d'implémentation détaillé​

Racine de dmv-workspace​

Unification du routing mairie​

Conséquence pour l'architecture Wall​