Aller au contenu principal

Mobile Vision

Version : 1.0

Statut : Décision d'architecture

1. Introduction​

L'application mobile DMV constitue le prolongement naturel de la plateforme DMV.

Elle ne représente ni un nouveau produit, ni une nouvelle plateforme.

Son objectif est d'offrir une véritable expérience mobile tout en conservant une architecture unique.

DMV reste une seule plateforme, accessible depuis plusieurs interfaces.

Aujourd'hui :

  • Navigateur Web
  • Smartphone Android
  • Smartphone iPhone
  • Tablette
  • (à terme) Montres connectées

Toutes utilisent la même plateforme.

2. Contexte​

DMV est avant tout une plateforme territoriale.

Son rôle est de connecter :

  • les habitants ;
  • les communes ;
  • les acteurs locaux ;
  • les associations ;
  • les professionnels ;
  • les services publics.

L'application mobile ne doit jamais devenir une plateforme parallèle.

Elle doit simplement permettre un accès plus naturel aux services de DMV.

3. Pourquoi une application mobile ?​

Les usages mobiles sont devenus majoritaires.

Les utilisateurs attendent désormais :

  • des notifications instantanées ;
  • un lancement rapide ;
  • une navigation fluide ;
  • une ouverture directe depuis une notification ;
  • un accès à la caméra ;
  • le partage natif ;
  • un fonctionnement même avec une connexion instable.

Ces attentes dépassent aujourd'hui les possibilités d'une simple application web.

4. Les objectifs​

4.1 Une seule plateforme​

Le premier objectif est de conserver une plateforme unique.

Il ne doit jamais exister :

  • une version Web ;
  • une version Mobile.

Il existe uniquement DMV.

Les interfaces évoluent.

La plateforme reste identique.

4.2 Une expérience native​

L'utilisateur ne doit jamais avoir l'impression d'utiliser une WebView.

L'application doit respecter :

Android :

  • navigation
  • retour
  • notifications
  • partage

iOS :

  • animations
  • swipe
  • notifications
  • comportement natif

4.3 Toujours à jour​

La plateforme évolue en permanence.

Chaque jour peuvent être créés :

  • de nouveaux utilisateurs ;
  • de nouveaux acteurs ;
  • de nouvelles communes ;
  • de nouveaux événements ;
  • de nouvelles publications.

Ces nouveautés doivent apparaître immédiatement.

Une publication sur les Stores ne doit pas être nécessaire pour rendre ces contenus métier disponibles lorsque l'évolution est servie par le web et reste compatible avec le shell installé. Les évolutions natives continuent de passer par les Stores.

4.4 Réutiliser l'existant​

DMV possède déjà :

  • une architecture Cloudflare ;
  • une API Laravel ;
  • deux applications React ;
  • une base PostgreSQL.

L'application mobile doit capitaliser sur cet existant.

L'objectif n'est pas de reconstruire la plateforme.

4.5 Exploiter les capacités du téléphone​

Le téléphone apporte des possibilités qui n'existent pas sur le Web.

Exemples :

  • notifications push ;
  • appareil photo ;
  • galerie ;
  • géolocalisation ;
  • biométrie ;
  • stockage local ;
  • partage natif.

Ces fonctionnalités doivent enrichir l'expérience utilisateur sans déplacer la logique métier vers le téléphone.

5. Les non-objectifs​

Il est tout aussi important de définir ce que DMV Mobile ne cherche pas à faire.

Ne pas créer une nouvelle plateforme​

DMV Mobile n'est pas un projet indépendant.

Toutes les règles métier restent communes avec le Web.

Ne pas remplacer le serveur​

Le téléphone ne devient jamais la source officielle des données.

Toutes les décisions métier restent prises par le serveur.

Ne pas fonctionner totalement hors connexion​

DMV n'est pas conçu comme une plateforme Offline First.

Certaines opérations nécessitent obligatoirement une connexion.

C'est un choix volontaire.

Ne pas dupliquer la logique métier​

Aucune règle métier ne doit être implémentée dans :

  • Capacitor ;
  • Android ;
  • iOS.

Le téléphone reste un client.

6. Les utilisateurs​

DMV Mobile s'adresse à plusieurs profils.

Visiteur​

Le visiteur n'est pas connecté.

Il accède uniquement à la partie publique.

Utilisateur​

L'utilisateur possède un compte DMV.

Il retrouve notamment :

  • Mon Espace ;
  • ses favoris ;
  • ses agendas ;
  • ses notifications.

Gestionnaire d'acteur​

Il utilise également le Workspace afin de gérer :

  • son acteur ;
  • ses publications ;
  • ses collaborateurs.

Gestionnaire de commune​

Même principe.

Il administre la commune depuis le Workspace.

Administrateur DMV​

Les administrateurs utilisent le Backoffice.

Le Backoffice ne fait pas partie de l'application mobile.

7. Principes directeurs​

Les principes suivants guident toutes les décisions d'architecture.

Une plateforme​

Une seule plateforme.

Une API​

Une seule API.

Une logique métier​

Une seule logique métier.

Une base de données​

Une seule base de données.

Une source de vérité​

Le serveur.

Toujours.

Un shell natif​

Le téléphone apporte uniquement :

  • les capacités natives ;
  • le cache ;
  • la continuité de service.

8. Philosophie Mobile​

DMV Mobile repose sur une idée simple :

Le téléphone améliore l'expérience utilisateur.

Il ne remplace jamais la plateforme.

Le téléphone est considéré comme :

  • un accélérateur ;
  • une interface ;
  • un compagnon.

Jamais comme une plateforme autonome.

9. Philosophie Offline​

DMV adopte une stratégie :

Online First with Offline Continuity

Cela signifie :

Le serveur reste disponible dès que possible.

Lorsque la connexion disparaît :

  • l'utilisateur continue à consulter les contenus disponibles ;
  • son contexte est conservé ;
  • son travail n'est jamais perdu.

Le retour du réseau permet une reprise automatique.

10. Vision long terme​

L'architecture retenue doit permettre d'ajouter progressivement de nouvelles capacités sans remettre en cause le socle.

Exemples :

  • Apple Watch
  • Wear OS
  • Widgets
  • Wallet
  • NFC
  • CarPlay
  • Android Auto
  • Réalité augmentée
  • Réalité mixte

Toutes ces évolutions devront pouvoir être intégrées sans modifier les principes fondamentaux de DMV Mobile.

11. Décisions d'architecture​

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

✅ Une seule plateforme DMV

✅ Une seule API

✅ Une seule logique métier

✅ Une seule base de données

✅ Un shell Capacitor

✅ Online First with Offline Continuity

✅ Le serveur reste la source de vérité

✅ Le téléphone améliore l'expérience utilisateur sans remplacer la plateforme.

Conclusion​

DMV Mobile ne constitue pas un nouveau produit.

Il constitue une nouvelle manière d'utiliser DMV.

L'objectif est de proposer une expérience mobile moderne tout en conservant une architecture simple, durable et évolutive.

Toutes les décisions prises dans les documents suivants devront respecter cette vision.