Aller au contenu principal

Architecture Decisions

Version : 1.0

Statut : Référence architecturale

ADR : MOBILE-014

1. Objectif​

Ce document rassemble les décisions d'architecture considérées comme fondatrices de DMV Mobile.

Contrairement aux autres documents qui décrivent un composant ou un domaine particulier, celui-ci explique pourquoi certaines décisions ont été prises.

Ces décisions servent de référence pour tous les développements futurs.

Elles ne doivent être remises en cause qu'à l'occasion d'une évolution majeure de l'architecture.

2. Philosophie​

Une architecture durable ne repose pas uniquement sur des choix techniques.

Elle repose sur des principes.

Les technologies évolueront.

Les principes doivent rester stables.

Les décisions suivantes sont donc considérées comme faisant partie de l'ADN de DMV Mobile.

ADR-001 — Une seule plateforme​

Décision​

DMV reste une plateforme unique.

Le Web et le Mobile ne constituent pas deux produits différents.

Ils représentent deux interfaces d'une même plateforme.

Motivation​

Éviter :

  • les divergences fonctionnelles ;
  • les doubles développements ;
  • les comportements incohérents.

Conséquences​

Toutes les évolutions fonctionnelles sont partagées.

Une fonctionnalité développée pour le Web doit pouvoir bénéficier au Mobile, et inversement.

ADR-002 — Une seule application mobile​

Décision​

DMV Mobile est une application unique.

Elle embarque :

  • dmv-public
  • dmv-workspace

Le Backoffice reste indépendant.

Alternatives étudiées​

Deux applications séparées :

Rejeté.

Complexité :

  • double maintenance ;
  • double publication ;
  • double authentification ;
  • UX dégradée.

Conséquences​

L'utilisateur navigue naturellement entre les espaces sans changer d'application.

ADR-003 — Capacitor comme socle​

Décision​

Capacitor constitue le shell officiel de DMV Mobile.

Alternatives étudiées​

Flutter

React Native

Développement natif

Motivation​

Réutilisation maximale des applications React existantes.

Maintenance réduite.

Architecture unique.

ADR-004 — Le serveur est la source de vérité​

Décision​

Aucune donnée locale n'est considérée comme officielle.

Le serveur reste l'unique référence.

Motivation​

Les données DMV évoluent en permanence.

Le téléphone ne peut garantir leur exactitude.

Conséquences​

Le cache améliore l'expérience.

Il ne remplace jamais le serveur.

ADR-005 — Online First with Offline Continuity​

Décision​

DMV n'est pas une plateforme Offline First.

Motivation​

Le mode hors connexion doit améliorer le confort.

Pas remplacer la plateforme.

Conséquences​

Les données déjà consultées restent disponibles.

Les actions critiques nécessitent une connexion.

ADR-006 — Cache hiérarchisé​

Décision​

Le cache est organisé par niveaux.

Il ne s'agit pas d'un simple cache HTTP.

Motivation​

Toutes les données n'ont pas la même importance.

Le cache doit refléter cette hiérarchie.

ADR-007 — Synchronisation automatique​

Décision​

Toutes les synchronisations sont automatiques.

Motivation​

Éviter les erreurs utilisateur.

Garantir une plateforme cohérente.

ADR-008 — Les brouillons avant la publication​

Décision​

Une publication ne peut jamais être créée directement hors connexion.

Le téléphone crée uniquement un brouillon.

Motivation​

Éviter les conflits.

Garantir la validation serveur.

ADR-009 — Aucun métier dans le mobile​

Décision​

La logique métier reste entièrement côté serveur.

Le téléphone fournit uniquement :

  • une interface ;
  • un cache ;
  • des services natifs.

Motivation​

Une seule logique métier.

Une seule maintenance.

ADR-010 — Native Platform​

Décision​

Toutes les fonctionnalités natives passent par une couche d'abstraction.

Jamais directement par Capacitor.

Motivation​

Découpler les applications React du runtime mobile.

Préparer les évolutions futures.

ADR-011 — Security by Design​

Décision​

La sécurité est intégrée dès l'architecture.

Elle ne constitue pas un ajout ultérieur.

Principes​

  • Zero Trust
  • Least Privilege
  • Privacy by Design

ADR-012 — Performance by Design​

Décision​

Les performances constituent une responsabilité d'architecture.

Elles ne sont pas uniquement optimisées en fin de développement.

ADR-013 — Une plateforme évolutive​

Décision​

L'architecture actuelle doit permettre d'intégrer sans refonte :

  • Widgets
  • Wallet
  • NFC
  • Apple Watch
  • Wear OS
  • Android Auto
  • CarPlay
  • futurs services DMV

ADR-014 — Le Backoffice reste indépendant​

Décision​

Le Backoffice n'est pas intégré à DMV Mobile.

Motivation​

Les usages sont différents.

Les contraintes de sécurité sont différentes.

Les utilisateurs sont différents.

ADR-015 — Navigation Engine​

Décision​

La navigation devient un composant d'architecture à part entière (Navigation Engine), indépendant de toute plateforme d'exécution (Cloudflare, Next.js, Capacitor, hébergeur).

Alternatives étudiées​

Coupler directement chaque application à sa plateforme d'hébergement :

Rejeté.

Chaque nouvelle plateforme oblige alors à revalider ou réécrire la navigation de chaque application indépendamment.

Réécrire immédiatement toute la navigation existante :

Rejeté.

Contredit le principe de migration progressive ; risque de régression disproportionné.

Conséquences​

Toute plateforme d'exécution est intégrée via un Platform Adapter, jamais directement.

La V0.9 Beta n'est pas impactée : le mécanisme de routing actuel du Workspace est conservé tel quel.

Détail complet : 16-navigation-engine.md.

3. Décisions considérées comme figées​

Les décisions suivantes sont considérées comme fondatrices de DMV Mobile.

Elles ne doivent être remises en cause qu'en cas de changement majeur de la plateforme.

✅ Une seule plateforme DMV

✅ Une seule application mobile

✅ Deux applications embarquées :

  • dmv-public
  • dmv-workspace

✅ Backoffice indépendant

✅ Capacitor comme shell officiel

✅ Une seule API Laravel

✅ Une seule base PostgreSQL

✅ Le serveur reste la source de vérité

✅ Online First with Offline Continuity

✅ Cache Engine hiérarchisé

✅ Synchronization Engine centralisé

✅ Native Platform

✅ Navigation Engine

✅ Security by Design

✅ Quality by Design

4. Évolutions futures​

Les technologies pourront évoluer.

Par exemple :

  • Capacitor pourra être remplacé ;
  • Android évoluera ;
  • iOS évoluera ;
  • React évoluera.

Ces changements ne devront jamais remettre en cause les principes définis dans ce document.

Les décisions d'architecture doivent survivre aux technologies.

Conclusion​

Ce document constitue la référence architecturale de DMV Mobile.

Les documents précédents décrivent comment fonctionne la plateforme.

Celui-ci explique pourquoi elle a été conçue ainsi.

Toute évolution future devra être évaluée à la lumière de ces décisions afin de préserver la cohérence de l'architecture dans le temps.