Aller au contenu principal

Mobile Architecture

Version : 1.0

Statut : Architecture cible

1. Objectif​

Ce document décrit l'architecture générale de DMV Mobile.

Il présente les différents composants constituant l'application mobile ainsi que leurs responsabilités.

Il ne décrit pas les règles métier de DMV.

Il décrit uniquement l'architecture technique.

État actuel​

Le projet existe aujourd'hui sous forme de plusieurs applications web et d'une API Laravel :

  • dmv-public porte l'expérience publique et Mon Espace ;
  • dmv-workspace porte les espaces acteurs et contributeurs ;
  • dmv-backoffice reste séparé et réservé à l'administration ;
  • l'API Laravel expose les endpoints métier et échange un JWT Supabase contre un token Sanctum ;
  • Supabase reste la base PostgreSQL de référence et fournit Supabase Auth ;
  • certains écrans ou services front utilisent encore des accès Supabase directs, notamment pour des RPC, du storage ou des lectures spécialisées.

Aucun dossier Capacitor complet n'est encore identifié dans le code audité. Le mobile décrit ici est donc une cible d'intégration autour des applications existantes, pas une réécriture déjà livrée.

Architecture cible​

DMV Mobile est une seule application Capacitor embarquant dmv-public et dmv-workspace. Le Backoffice reste exclu du shell mobile.

La cible conserve le serveur comme source de vérité :

  • Supabase Auth authentifie l'utilisateur ;
  • le JWT Supabase prouve l'identité ;
  • Laravel valide ce JWT et émet un token Sanctum applicatif ;
  • Sanctum protège les routes métier Laravel ;
  • l'API Laravel porte les décisions métier ;
  • Supabase / PostgreSQL reste la base officielle.

Les accès directs Supabase ne sont pas interdits par dogme, mais ils doivent être explicitement cadrés. La cible est de réserver les écritures métier et les décisions d'autorisation à Laravel, tout en conservant des usages Supabase maîtrisés lorsque l'architecture le justifie : Auth, Storage, Realtime, RPC ou lecture soumise à RLS.

Migration​

La convergence consiste à encapsuler progressivement l'existant sans rupture :

  1. créer le shell Capacitor autour des parcours web existants ;
  2. stabiliser l'échange Supabase JWT → Laravel Sanctum pour les appels métier ;
  3. inventorier les accès Supabase directs encore utilisés côté front ;
  4. migrer vers l'API Laravel les opérations métier qui nécessitent contrôle, audit ou orchestration ;
  5. conserver uniquement les accès Supabase directs explicitement validés et protégés par RLS ou par des contraintes de service ;
  6. introduire ensuite Cache Engine, Synchronization Engine et Native Platform comme couches transversales.

2. Architecture générale​

DMV Mobile repose sur une architecture hybride.

Le téléphone n'embarque pas une copie de la plateforme.

Il embarque un shell natif chargé d'exécuter les applications web existantes.

                   Android / iOS

                        │

                Shell Capacitor

                        │

         ┌──────────────┴──────────────┐
         │                             │
         │                             │
    dmv-public                 dmv-workspace

         └──────────────┬──────────────┘
                        │

               Cloudflare Worker

                        │

                  Laravel API

                        │

             PostgreSQL / Supabase

3. Les composants​

3.1 Shell Capacitor​

Le shell Capacitor constitue la seule partie réellement native.

Il fournit :

  • l'intégration Android ;
  • l'intégration iOS ;
  • les API natives ;
  • le stockage local ;
  • les notifications ;
  • la caméra ;
  • la géolocalisation ;
  • le partage ;
  • les Deep Links.

Le shell ne contient aucune logique métier.

3.2 dmv-public​

dmv-public reste l'application principale.

Elle est accessible :

  • aux visiteurs ;
  • aux utilisateurs connectés.

Elle contient notamment :

  • Mur
  • Recherche
  • Commune
  • Mon Espace
  • Agenda
  • Favoris
  • Profils publics
  • Publications
  • Services

Toutes les fonctionnalités actuellement disponibles restent inchangées.

3.3 dmv-workspace​

dmv-workspace est réservé aux utilisateurs possédant des droits de gestion.

Le Workspace permet notamment :

  • gérer un acteur ;
  • gérer une mairie ;
  • publier ;
  • modifier les informations ;
  • gérer les collaborateurs ;
  • consulter les statistiques.

Le Workspace est embarqué dans la même application mobile.

L'utilisateur ne change jamais d'application.

3.4 API Laravel​

Toute opération métier passe par l'API.

Exemples :

  • connexion ;
  • publications ;
  • favoris ;
  • agenda ;
  • recherche ;
  • acteurs ;
  • communes ;
  • Workspace.

Aucune opération métier ne contourne l'API.

3.5 Base de données​

La plateforme conserve une base unique.

PostgreSQL / Supabase.

Toutes les données officielles résident exclusivement sur le serveur.

Le téléphone ne possède jamais de copie complète de la base.

4. Source de vérité​

L'un des principes fondamentaux est le suivant :

Le serveur est toujours la source officielle des données.

Même lorsqu'une donnée est disponible dans le cache :

  • seule la version serveur fait foi ;
  • seule la version serveur est modifiable.

Le téléphone conserve uniquement une copie temporaire.

5. Communication​

Toutes les communications transitent par le Cloudflare Worker.

Téléphone

↓

Cloudflare Worker

↓

API Laravel

↓

Base de données

Le Worker reste responsable :

  • du routage ;
  • de la sécurité ;
  • de la distribution des applications ;
  • des optimisations.

Dans la cible, l'application mobile ne contourne jamais Laravel pour les opérations métier. Les accès Supabase directs existants ou futurs doivent rester explicites, limités et compatibles avec RLS, Storage, Realtime ou des RPC validées.

6. Architecture applicative​

Chaque couche possède une responsabilité clairement définie.

Capacitor​

Responsabilités :

  • Shell natif
  • Plugins
  • API mobiles
  • Notifications
  • Stockage local
  • Détection réseau

Ne fait jamais :

  • métier
  • permissions fonctionnelles
  • calculs métiers

dmv-public​

Responsable de :

  • l'expérience utilisateur publique ;
  • Mon Espace ;
  • les consultations ;
  • les interactions utilisateur.

dmv-workspace​

Responsable de :

  • l'administration des acteurs ;
  • la gestion des publications ;
  • les espaces administrés.

Laravel​

Responsable :

  • des règles métier ;
  • des permissions ;
  • des traitements ;
  • des validations ;
  • des API.

PostgreSQL​

Responsable :

  • du stockage officiel.

7. Flux de fonctionnement​

Consultation​

Utilisateur

↓

dmv-public

↓

Cloudflare

↓

Laravel

↓

Base

↓

Réponse

↓

Cache éventuel

Publication​

Workspace

↓

API Laravel

↓

Validation

↓

Base

↓

Publication

↓

Mur

Brouillon hors connexion​

Utilisateur

↓

Workspace

↓

Brouillon local

↓

Retour réseau

↓

API

↓

Brouillon serveur

Aucune publication automatique.

8. Architecture Offline​

Le téléphone possède uniquement :

  • le cache ;
  • les brouillons ;
  • les préférences.

Il ne possède jamais :

  • les droits ;
  • la base métier ;
  • les règles fonctionnelles.

9. Séparation des responsabilités​

ComposantResponsabilité
CapacitorShell natif
dmv-publicInterface publique
dmv-workspaceInterface de gestion
Cloudflare WorkerRoutage et distribution
LaravelMétier
PostgreSQLDonnées

Cette séparation ne doit jamais être remise en cause.

10. Architecture évolutive​

L'architecture retenue doit permettre d'ajouter facilement :

  • Widgets
  • Apple Watch
  • Wear OS
  • Wallet
  • NFC
  • CarPlay
  • Android Auto
  • Live Activities
  • Dynamic Island

sans modifier :

  • les applications React ;
  • l'API ;
  • la base.

11. Décisions d'architecture​

Les décisions suivantes sont considérées comme figées.

✅ Une seule application mobile

✅ Deux applications embarquées :

  • dmv-public
  • dmv-workspace

✅ Le Backoffice reste indépendant

✅ Le Cloudflare Worker reste le point d'entrée

✅ Laravel reste la seule couche métier

✅ PostgreSQL reste la seule source officielle des données

✅ Le téléphone ne contient qu'un cache local

12. Conclusion​

L'architecture de DMV Mobile repose sur un principe simple :

Le téléphone n'est qu'une nouvelle interface de la plateforme DMV.

Toute la logique métier, les données et les règles restent centralisées sur le serveur.

Cette architecture permet :

  • une maintenance réduite ;
  • une mise à jour continue ;
  • une évolution simple ;
  • une compatibilité durable avec les futures fonctionnalités mobiles.