Aller au contenu principal

Mobile Roadmap

Version : 1.0

Statut : Architecture cible

ADR : MOBILE-013

1. Objectif​

Ce document définit la feuille de route officielle de DMV Mobile.

Contrairement à un planning projet, cette roadmap décrit l'évolution de l'architecture mobile sur plusieurs années.

Elle permet de :

  • prioriser les développements ;
  • conserver une vision long terme ;
  • éviter les refontes inutiles ;
  • garantir la compatibilité des évolutions futures.

La roadmap est évolutive.

Les objectifs peuvent évoluer.

Les principes d'architecture, eux, restent stables.

2. Philosophie​

DMV Mobile est conçu pour évoluer progressivement.

L'objectif n'est pas de développer immédiatement toutes les fonctionnalités possibles.

Au contraire.

Chaque étape doit :

  • apporter une valeur réelle ;
  • rester compatible avec les étapes suivantes ;
  • ne jamais remettre en cause l'architecture.

Cette approche permet de réduire les risques et d'obtenir rapidement un produit utilisable.

3. Vision long terme​

À terme, DMV Mobile doit devenir l'interface mobile officielle de l'ensemble de l'écosystème DMV.

Il ne s'agit pas uniquement de proposer une version mobile du site web.

L'objectif est de construire une plateforme mobile capable d'intégrer progressivement :

  • les fonctionnalités natives ;
  • les nouveaux produits DMV ;
  • les services territoriaux futurs.

4. Phase 1 — MVP​

Objectif :

Disposer d'une véritable application Android et iOS reposant sur l'architecture actuelle.

Fonctionnalités :

  • Shell Capacitor
  • dmv-public
  • dmv-workspace
  • Authentification
  • Navigation
  • Cache initial
  • Synchronisation
  • Notifications de base

Objectif principal :

Valider l'expérience utilisateur.

5. Phase 2 — Expérience Mobile​

Après validation du MVP.

Ajouts :

  • optimisation du cache ;
  • amélioration des performances ;
  • meilleure gestion Offline Continuity ;
  • partage natif ;
  • caméra ;
  • galerie ;
  • téléchargements.

Cette phase transforme DMV en une véritable application mobile.

6. Phase 3 — Plateforme Native​

Ajout des premières capacités avancées.

Exemples :

  • Widgets Android
  • Widgets iOS
  • Dynamic Island
  • Live Activities
  • raccourcis système
  • recherche Spotlight

L'objectif est d'intégrer DMV dans le système d'exploitation.

7. Phase 4 — Services Territoriaux​

Extension des fonctionnalités mobiles.

Exemples :

  • Wallet
  • cartes d'adhérent
  • cartes bibliothèque
  • cartes piscine
  • QR Codes
  • NFC

Cette phase ouvre la voie aux usages municipaux.

8. Phase 5 — Écosystème DMV​

L'application devient la porte d'entrée unique de tous les produits DMV.

Exemples :

  • AssoSuite
  • Paiement
  • Billetterie
  • Réservation
  • Santé
  • Coach IA
  • Produits futurs

Le téléphone devient le compagnon numérique de l'utilisateur.

9. Phase 6 — Objets connectés​

L'architecture prévoit dès aujourd'hui la possibilité d'intégrer :

  • Apple Watch
  • Wear OS
  • Android Health Connect
  • Apple Health
  • Bluetooth Low Energy

Ces fonctionnalités ne sont pas prioritaires mais ne doivent nécessiter aucune refonte.

10. Phase 7 — Véhicules​

À plus long terme.

Compatibilité avec :

  • Android Auto
  • Apple CarPlay

Exemples :

  • guidage vers un événement ;
  • navigation vers un acteur ;
  • alertes municipales vocales.

11. Phase 8 — Intelligence Contextuelle​

L'application devient proactive.

Exemples :

  • suggestions basées sur la localisation ;
  • rappels intelligents ;
  • notifications contextuelles ;
  • recommandations territoriales.

Cette intelligence repose sur les moteurs déjà présents dans DMV.

Aucune logique spécifique n'est ajoutée côté mobile.

12. Critères de passage​

Une phase n'est engagée que si la précédente est considérée comme stable.

Les critères principaux sont :

  • stabilité ;
  • performances ;
  • adoption utilisateur ;
  • maintenabilité ;
  • sécurité.

L'objectif est de privilégier une croissance maîtrisée plutôt qu'une accumulation de fonctionnalités.

13. Compatibilité​

Toutes les évolutions doivent respecter les principes fondateurs.

Aucune nouvelle fonctionnalité ne peut remettre en cause :

  • l'architecture serveur ;
  • l'API Laravel ;
  • le Context Engine ;
  • le Wall Engine ;
  • le Cache Engine ;
  • le Synchronization Engine.

14. Dépendances​

Certaines étapes nécessitent d'autres chantiers DMV.

Exemples :

Wallet

↓

Infrastructure QR Code

↓

Gestion des cartes

Watch

↓

Notifications

↓

Synchronisation

Coach IA

↓

Moteur IA

↓

API

↓

Application mobile

15. Gouvernance​

La roadmap est pilotée par les besoins métier.

Une fonctionnalité n'est pas développée parce qu'elle est techniquement possible.

Elle est développée lorsqu'elle apporte une réelle valeur aux utilisateurs.

16. ADR​

Alternatives étudiées​

Développer toutes les fonctionnalités dès le départ​

Rejetée.

Complexité excessive.

Temps de développement trop long.

Risque élevé.

Développement incrémental​

Retenu.

Chaque étape apporte de la valeur.

Chaque étape prépare la suivante.

17. Décisions figées​

✅ Développement progressif.

✅ Priorité au MVP.

✅ Aucune refonte majeure entre les phases.

✅ Les futures fonctionnalités doivent s'intégrer à l'architecture existante.

✅ Les besoins utilisateurs guident la roadmap.

Conclusion​

La roadmap de DMV Mobile ne constitue pas un simple planning.

Elle représente la vision d'évolution de la plateforme mobile sur plusieurs années.

En privilégiant une approche incrémentale et une architecture stable, DMV pourra enrichir progressivement son application tout en conservant un socle technique durable, cohérent et évolutif.