Engineering Roadmap V2
Plan d'exécution de DMV V2
| Version | 1.0 |
| Statut | Référence d'implémentation |
| Public | Équipe de développement, Codex, Architectes |
Objectif
Ce document ne décrit pas l'architecture.
L'architecture est déjà définie dans les documents de référence.
Ce document décrit l'ordre d'exécution des chantiers afin d'implémenter DMV V2 avec un minimum de risques.
Chaque étape possède :
- un objectif ;
- des prérequis ;
- des critères d'acceptation ;
- des dépendances avec les autres chantiers.
Le principe est simple :
On ne développe jamais une étape tant que les dépendances précédentes ne sont pas validées.
Principes
1. DMV Core est la source de vérité
Toutes les règles métier vivent dans DMV Core.
Les applications ne contiennent aucune logique métier.
2. Les applications sont des clients
Les applications suivantes consomment DMV Core :
- DMV Public ;
- Workspace ;
- Backoffice ;
- Application Mobile.
3. Les migrations sont incrémentales
Aucune réécriture complète.
Chaque chantier doit être :
- testable ;
- réversible ;
- mergeable indépendamment.
4. Aucun chantier ne casse la production
La branche principale reste toujours publiable.
Phase 0 — Documentation
Statut
✅ Terminé
Livrables
- Vision
- Architecture
- Business
- Product
- IA
- Sécurité
- RFC
- ADR
Validation
Documentation figée.
Phase 1 — DMV Core
Objectif
Restructurer le backend autour des Bounded Contexts.
Référence d'exécution
EPIC-001 — Restructuration DMV Core pilote l'ensemble du chantier backend.
ENG-001.1 — Audit DMV Core constitue le prérequis opérationnel de cette phase. Aucun chantier de restructuration backend ne doit être lancé avant que cet audit ait produit la cartographie, les écarts et le découpage en Pull Requests.
Chantiers
- séparation des modules ;
- suppression des dépendances croisées ;
- ownership des données ;
- commandes ;
- événements métier ;
- services partagés.
Dépendances
Aucune.
Validation
- architecture conforme ;
- tests verts ;
- API inchangée ou compatible.
Phase 2 — API
Objectif
Stabiliser les contrats exposés aux applications.
Chantiers
- endpoints ;
- versionnement ;
- DTO ;
- Resources ;
- Validation ;
- erreurs standardisées.
Dépendances
Phase 1 terminée.
Validation
API stable.
Phase 3 — Frontend
Objectif
Aligner Public et Workspace sur DMV Core.
Chantiers
- suppression du legacy ;
- unification API ;
- nettoyage hooks ;
- suppression logique métier frontend ;
- optimisation.
Validation
Applications fonctionnelles.
Phase 4 — Mobile Readiness
Objectif
Préparer DMV à Capacitor.
Chantiers
- audit ;
- deep links ;
- secure storage ;
- routing ;
- authentification ;
- shell.
Validation
GO Capacitor.
Phase 5 — Mobile Shell
Objectif
Créer la couche native commune.
Le Shell est responsable de
- stockage sécurisé ;
- notifications ;
- liens profonds ;
- permissions ;
- caméra ;
- galerie ;
- partage ;
- presse-papiers ;
- géolocalisation ;
- réseau ;
- cycle de vie ;
- mises à jour.
Le Shell ne fait jamais
- métier ;
- appels directs Supabase ;
- règles business.
Validation
Interfaces validées.
Phase 6 — Capacitor
Objectif
Créer les projets Android et iOS.
Chantiers
- Android ;
- iOS ;
- plugins ;
- bridge ;
- builds.
Validation
Application démarre sur Android et iOS.
Phase 7 — Fonctionnalités natives
Implémenter
- Secure Storage ;
- Deep Links ;
- Notifications ;
- Biométrie ;
- Caméra ;
- Galerie ;
- GPS ;
- Share ;
- Clipboard ;
- Files ;
- Lifecycle.
Validation
Tous les providers sont implémentés.
Phase 8 — Store Readiness
Apple
- Privacy Manifest ;
- App Icons ;
- Splash ;
- Metadata ;
- Screenshots ;
- Review.
Google
- Data Safety ;
- Billing ;
- Permissions ;
- Store Listing.
Validation
Applications publiables.
Phase 9 — Publication
Android
- Internal ;
- Closed ;
- Open ;
- Production.
iOS
- TestFlight ;
- External TestFlight ;
- App Store.
Phase 10 — Améliorations
P2
- widgets ;
- watch ;
- live activities ;
- offline avancé ;
- synchronisation avancée ;
- optimisation batterie ;
- optimisation mémoire.
Mobile Shell
Le Mobile Shell fournit uniquement des services natifs.
Interfaces
StorageProvider
NotificationProvider
LinkProvider
PermissionProvider
CameraProvider
LocationProvider
ShareProvider
ClipboardProvider
FileProvider
NetworkProvider
UpdateProvider
LifecycleProvider
BiometricProvider
DeviceProvider
Chaque interface possède :
- implémentation Browser ;
- implémentation Capacitor ;
- implémentation Mock.
Le code métier dépend uniquement de ces interfaces.
Critères d'acceptation
Une phase est terminée lorsque :
- les tests sont verts ;
- la documentation est mise à jour ;
- les critères d'acceptation sont validés ;
- aucune régression n'est détectée.
Ordre d'implémentation recommandé
- DMV Core
- API
- Public
- Workspace
- Mobile Readiness
- Mobile Shell
- Capacitor
- Secure Storage
- Deep Links
- Notifications
- Camera
- Files
- Share
- Location
- Biométrie
- Tests
- Store Readiness
- Publication
Règles d'ingénierie
- Une Pull Request = un seul chantier.
- Une responsabilité = un module.
- Une décision = une RFC ou une ADR.
- Aucun contournement de DMV Core.
- Aucun accès direct aux données métier depuis les applications.
- Les fonctionnalités natives passent exclusivement par le Mobile Shell.
- Les interfaces sont stables avant leurs implémentations.
- Les implémentations Browser et Capacitor doivent respecter exactement le même contrat.
- Chaque étape doit être testable indépendamment.
- Toute régression bloque le merge.
Définition de Done
Une fonctionnalité est considérée comme terminée uniquement si :
- le code est implémenté ;
- les tests passent ;
- les types sont validés ;
- les règles d'architecture sont respectées ;
- la documentation est mise à jour ;
- la revue de code est validée ;
- les critères d'acceptation sont satisfaits.
Une fonctionnalité non documentée n'est pas considérée comme terminée.