ADR-000 — DMV Core & Modular Applications Architecture

Statut

Accepted

Date

2026-07-19

Décideurs

Équipe Architecture DMV

Impact

Architecture globale, API, Applications, Produits, Roadmap

---

Note sur la numérotation

Cette ADR porte le numéro 000, hors de la séquence chronologique du registre (ADR-001 à ADR-013). Ce n'est pas une erreur : elle définit le principe fondateur sur lequel reposent l'ensemble des décisions déjà actées. Elle précède conceptuellement, et non chronologiquement, toutes les autres ADR de ce registre — une décision qui aurait dû exister avant toutes les autres si elle avait été formulée plus tôt.

Contexte

Au fil de l'évolution du projet, DMV est progressivement passé d'une application unique à une plateforme composée de plusieurs produits spécialisés.

Cette évolution impose de définir clairement où se situe le cœur du système.

Sans cette décision, chaque nouveau besoin risque d'être ajouté dans l'application existante, conduisant progressivement à un monolithe fonctionnel difficile à maintenir.

Cette ADR définit donc l'architecture cible de la plateforme DMV.

Décision

DMV est une plateforme modulaire.

Le cœur de la plateforme est constitué du DMV Core, implémenté par l'API Laravel.

Les applications ne constituent pas le cœur de DMV.

Elles sont des clients spécialisés qui consomment les services du DMV Core.

Aucune application n'a vocation à devenir le centre de la plateforme.

DMV Core et les couches d'architecture — deux axes orthogonaux

Cette ADR ne définit pas une nouvelle couche d'architecture. Elle ne remplace ni ne concurrence la distinction déjà établie dans 26-platform-architecture.md entre Applications, Engines, Platform Services et Infrastructure.

Ces deux documents répondent à deux questions différentes, sur deux axes orthogonaux :

• 26-platform-architecture.md répond à : quelle est la responsabilité de ce composant ? (décide-t-il, exécute-t-il, fournit-il, compose-t-il ?)
• Cette ADR répond à : où vit cette responsabilité ?

Un Engine peut être implémenté dans DMV Core. Un Platform Service peut être implémenté dans DMV Core. L'Infrastructure héberge DMV Core. Aucune de ces couches ne devient une propriété de DMV Core, ni DMV Core une cinquième couche qui s'ajouterait aux quatre déjà définies.

Pourquoi « DMV Core » plutôt que « Platform Core ». Le nom initialement envisagé, Platform Core, entrait en collision directe avec les Platform Services déjà nommés dans l'architecture (Navigation, Authentication, Notifications, Storage, Cache, Synchronization) — deux concepts distincts que des noms aussi proches auraient fini par confondre dans l'esprit d'un nouveau développeur. DMV Core répond à « quel système physique porte la logique partagée entre applications », les Platform Services répondent à « quel type de responsabilité est-ce » — deux questions différentes qui n'ont plus besoin de partager un vocabulaire aussi proche.

Le DMV Core

Le DMV Core est la source de vérité de toute la plateforme.

Il centralise les fonctionnalités transverses partagées par l'ensemble des applications.

Parmi celles-ci :

• Authentification
• Gestion des utilisateurs
• Gestion des acteurs
• Permissions
• Organisations
• Médias
• Notifications
• Paiements
• IA
• Recherche
• Journalisation
• Audit
• API publiques
• Webhooks
• Services communs

Cette liste évoluera dans le temps mais le principe restera identique :

tout service partagé appartient au DMV Core.

Les applications

Les applications sont des interfaces spécialisées.

Elles implémentent un métier précis.

Chaque application est indépendante des autres.

Elles partagent uniquement le DMV Core.

Exemples actuels :

• DMV Public
• DMV Workspace
• Backoffice

Exemples futurs :

• AssoSuite
• MairieSuite
• PlayLoop
• Coach Platform
• autres applications métier

Ces applications peuvent évoluer indépendamment, posséder leur propre interface, leur propre UX et leur propre cycle de développement.

DMV Workspace

DMV Workspace est une application parmi les autres.

Son rôle est de fournir une interface générique permettant à un acteur DMV de gérer :

• son profil
• ses publications
• ses statistiques
• ses paramètres
• les fonctionnalités communes

Workspace n'a pas vocation à absorber les métiers spécialisés.

Lorsqu'un domaine devient suffisamment riche, il devient une application dédiée.

Exemple :

La gestion complète d'une association appartient à AssoSuite.

Elle n'a pas vocation à être développée dans Workspace.

Le rôle de l'API

Toutes les applications communiquent avec le DMV Core.

L'API constitue l'unique point de vérité concernant :

• les acteurs
• les permissions
• les données
• les règles métier
• les services partagés

Les applications ne doivent jamais dupliquer ces responsabilités.

Applications spécialisées

Lorsqu'un nouveau besoin apparaît, la question architecturale devient :

Le besoin relève-t-il :

• d'un service partagé ?

ou

• d'un métier spécialisé ?

Si le besoin est partagé par plusieurs applications :

→ il appartient au DMV Core.

Si le besoin correspond à un métier complet :

→ il devient une nouvelle application consommant le DMV Core.

Ce raisonnement se résume dans l'arbre de décision suivant :

Nouvelle fonctionnalité
        │
        ▼
Est-elle utilisée par plusieurs applications ?
        │
   Oui ─┴─ Non
   │          │
   ▼          ▼
DMV Core   Est-ce un métier complet ?
                │
          Oui ──┴── Non
           │         │
           ▼         ▼
 Nouvelle app   DMV Workspace

Le cas « Non / Non » aboutit par défaut à DMV Workspace parce qu'il reste, par construction (voir « DMV Workspace » ci-dessus), l'application générique pour les besoins de gestion d'un acteur qui ne justifient ni un service partagé ni un métier assez riche pour une application dédiée.

Découplage

Les applications sont faiblement couplées.

Elles peuvent :

• évoluer indépendamment ;
• être déployées indépendamment ;
• être remplacées indépendamment ;
• changer de technologie si nécessaire.

Leur seul contrat est l'API du DMV Core.

DMV Public

DMV Public constitue une application particulière.

Son objectif est la consultation publique des données de la plateforme.

Pour des raisons historiques et de performances, certaines données peuvent actuellement être obtenues directement depuis Supabase.

Cette optimisation est un détail d'implémentation.

Elle ne constitue pas un principe architectural.

L'architecture cible reste une plateforme dont le DMV Core constitue la référence fonctionnelle.

Conséquences

Cette décision implique notamment que :

• Workspace ne deviendra jamais un monolithe regroupant tous les métiers.
• Les futurs produits seront développés comme des applications autonomes.
• Toute logique métier partagée sera implémentée dans le DMV Core.
• Les applications restent des clients du DMV Core.
• L'API Laravel constitue le cœur fonctionnel de DMV.

Avantages

Cette architecture permet :

• une meilleure séparation des responsabilités ;
• une évolution indépendante des produits ;
• une maintenance simplifiée ;
• une meilleure réutilisation des services ;
• une réduction du couplage entre applications ;
• une meilleure évolutivité de la plateforme ;
• une architecture compatible avec une croissance sur plusieurs années.

Alternatives envisagées

Alternative	Raison de non-priorisation
Nommer ce composant « Platform Core »	Collision de vocabulaire avec les Platform Services déjà nommés dans 26-platform-architecture.md — voir section ci-dessus.
Laisser chaque application développer sa propre logique métier partagée	Conduit à la duplication et à la divergence entre applications, exactement le risque que cette ADR cherche à écarter.
Laisser Workspace absorber progressivement les métiers spécialisés	Reconstitue un monolithe fonctionnel au fil du temps — contredit l'objectif même de la modularité recherchée.

Risques

Le principal risque est qu'une application, par facilité à court terme, réimplémente localement un service déjà porté par le DMV Core plutôt que de le consommer — reconstituant progressivement la duplication que cette ADR cherche à éviter. Le critère de la section « Applications spécialisées » (besoin partagé vs métier complet) doit être appliqué à chaque nouvelle fonctionnalité, pas seulement au moment de cette décision.

Principe fondateur

DMV n'est pas une application.

DMV est une plateforme.

Le cœur de cette plateforme est le DMV Core.

Les applications ne sont que des interfaces spécialisées consommant les services du DMV Core.

Schéma d'architecture cible

                         DMV Platform

                      DMV Core (Laravel)

 ┌──────────────────────────────────────────────────────────────┐
 │                                                              │
 │ Auth │ Acteurs │ Permissions │ IA │ Médias │ Paiements │ API │
 │ Notifications │ Recherche │ Audit │ Services communs │       │
 │                                                              │
 └──────────────────────────────────────────────────────────────┘
              ▲             ▲              ▲
              │             │              │
──────────────┼─────────────┼──────────────┼──────────────────────
              │             │              │
      DMV Public     DMV Workspace     Backoffice
              │
              ├─────────────┬──────────────┬───────────────┐
              │             │              │               │
         AssoSuite    MairieSuite     PlayLoop      Coach Platform

Liens associés

• docs/06-architecture/26-platform-architecture.md
• docs/06-architecture/27-architecture-governance.md
• docs/decisions/ADR-011-wall-engine-context-engine.md
• docs/decisions/ADR-012-architecture-foundation-frozen.md
• docs/decisions/ADR-013-workspace-as-application.md