Architecture globale

Statut

Document de cadrage architecture — version initiale.

Vue d'ensemble

L'écosystème DMV est organisé autour de plusieurs applications : DMV public, backoffice, PlayLoop, AssoSuite, Mairie et futures applications connectées.

La cible stratégique est une API Laravel centrale modulaire, servant de couche métier commune. Les interfaces restent autonomes, mais mutualisent les services structurants : identité, acteurs, communes, publications, médias, droits, abonnements, statistiques, notifications et future AI Gateway.

État actuel visible

Élément	État visible dans le workspace
API	Projet Laravel dans api, avec modules métier actifs et routes /api/v1.
Site public	Application Next.js dans dmv-public.
Backoffice	Application React/Vite dans dmv_backoffice.
Supabase	Clients frontends, migrations SQL et Edge Functions encore visibles.
Déploiement API	Dossier deployment avec Nginx, Supervisor, cron et scripts Linux.
Jobs	Scheduler Laravel et workers Supervisor visibles pour queues Redis.
IA	AI Gateway documentée comme vision cible, non confirmée comme module livré.

Vision cible

La cible est une architecture en couches :

• interfaces applicatives autonomes ;
• API Laravel modulaire comme point d'entrée métier ;
• services métier partagés ;
• stockage et services techniques gouvernés ;
• jobs asynchrones pour traitements longs ;
• observabilité et sécurité transverses ;
• AI Gateway centralisée pour tous les usages IA.

Schéma logique

Applications
  ├─ DMV public (Next.js)
  ├─ Backoffice (React/Vite)
  ├─ PlayLoop
  ├─ AssoSuite
  ├─ Mairie
  └─ Futures apps

Backend cible
  └─ API Laravel modulaire
      ├─ Identity / Territory / Actor
      ├─ Publication / Community / Monetization
      ├─ Settings / Analytics / Admin
      ├─ PlayLoop / AssoSuite / Mairie / Chat
      ├─ Notifications / Media / Jobs
      └─ AI Gateway (vision cible)

Infrastructure
  ├─ Linux / Nginx / PHP-FPM
  ├─ Supervisor workers
  ├─ Cron Laravel scheduler
  ├─ Redis pour queues cible visible dans Supervisor
  └─ Cloudflare / VPS comme option visible dans la documentation de déploiement

Principes d'architecture

• Commencer simple, mais garder les limites de modules claires.
• Centraliser les règles métier dans l'API.
• Éviter les accès directs non gouvernés aux données.
• Garder les frontends indépendants côté interface.
• Mutualiser les services transverses.
• Préserver la réversibilité et la migrabilité.
• Scaler progressivement par cache, queues, séparation des workloads et optimisation.

Risques et points à clarifier

• Rôle exact de Supabase à clarifier progressivement.
• Source de vérité des migrations Laravel vs Supabase à formaliser.
• Statut réel des environnements production à confirmer.
• Contrats API inter-applications à documenter.
• AI Gateway, notifications unifiées et observabilité complète encore à définir comme implémentation.