Stratégie multi-applications
Statut
Document de cadrage architecture — version initiale.
Vue d'ensemble
DMV est un écosystème multi-applications : DMV public, backoffice, PlayLoop, AssoSuite, Mairie et futures apps connectées.
Chaque application doit rester autonome côté interface et usage, tout en partageant le socle métier et les données communes via l'API Laravel cible.
Applications visibles ou cibles
| Application | État actuel | Rôle |
|---|---|---|
| DMV public | Next.js visible dans dmv-public. | Porte d'entrée locale publique. |
| Backoffice | React/Vite visible dans dmv_backoffice. | Administration et pilotage global. |
| PlayLoop | Module backend visible, frontend dédié non confirmé. | Affichage dynamique local. |
| AssoSuite | Module backend visible, frontend dédié non confirmé. | Gestion associative. |
| Mairie | Module backend visible, frontend dédié non confirmé. | Interface communale. |
| Futures apps | Vision cible. | Nouveaux usages territoriaux. |
Principes
- Une application ne doit pas dépendre de l'interface d'une autre pour son usage principal.
- Les données communes doivent avoir une source de vérité claire.
- Les droits doivent être gérés côté backend.
- Les interactions inter-apps doivent être explicites.
- Les frontends peuvent évoluer à des rythmes différents.
- Les services transverses doivent être mutualisés quand cela évite la duplication.
Autonomie interface
Chaque application peut avoir :
- ses parcours ;
- sa navigation ;
- ses contraintes UX ;
- ses écrans spécialisés ;
- son rythme de déploiement frontend ;
- ses capacités offline ou PWA selon le besoin.
Cette autonomie ne doit pas créer des règles métier divergentes.
Cohérence backend
La cohérence doit venir de :
- l'API Laravel centrale ;
- modules métier ;
- modèles communs ;
- policies et middlewares ;
- services partagés ;
- contrats de publication, média, droits et notifications.
État actuel vs cible
| Sujet | État actuel visible | Vision cible |
|---|---|---|
| Apps principales | DMV public et backoffice présents. | Interfaces dédiées selon besoin pour PlayLoop, AssoSuite, Mairie. |
| Backend | Modules pour apps connectées déjà visibles. | API commune gouvernant les règles. |
| Supabase | Encore utilisé côté frontends. | Rôle clarifié et maîtrisé. |
| Source app | X-App-Source visible. | Contexte d'application systématique. |
Risques et points à clarifier
- Frontends dédiés PlayLoop, AssoSuite et Mairie à préciser.
- Partage exact des composants UI à décider.
- Stratégie d'authentification cross-app à formaliser.
- Gestion des permissions multi-rôles à documenter.