Architecture de la Plateforme DMV
Statut
Document fondateur — v1.0 — rédigé le 2026-07-19.
Ce document est la référence architecturale principale de DMV. Il explique comment l'ensemble des composants de la plateforme s'articulent entre eux, indépendamment des technologies qui les implémentent aujourd'hui.
Il ne remplace aucun document existant décrivant un composant particulier (Context Engine, Wall Engine, Cache Engine, Navigation Engine...). Il leur donne un cadre commun et explique où chacun se situe. Voir la section « Positionnement des documents existants ».
1. Objectif
DMV n'est pas une application. DMV est une plateforme, composée de plusieurs applications, qui partagent des services, des moteurs de décision et une infrastructure communs.
Ce document répond à une question simple, mais qui n'avait jamais de réponse unique avant lui : où placer un nouveau composant, et de quoi a-t-il le droit de dépendre ?
Il est volontairement rédigé indépendamment de toute technologie. Laravel, Next.js, Supabase, Cloudflare ou Capacitor pourront chacun être remplacés un jour sans que ce document change une seule ligne — c'est précisément ce qu'il garantit.
2. Principe fondamental
DMV est organisé en couches.
Les couches supérieures dépendent des couches inférieures. L'inverse est interdit.
Ce principe n'est pas une préférence de style. C'est la règle qui permet à DMV de rester compréhensible, remplaçable et évolutif, même lorsque le nombre d'applications, de moteurs et de technologies augmente.
Applications
↓
Engines
↓
Platform Services
↓
Infrastructure
Remarque sur l'ordre des couches. Une première lecture pourrait ranger les Platform Services au-dessus des Engines, puisqu'ils apparaissent souvent en premier dans le parcours technique d'un événement (une notification arrive d'abord par un Platform Service, avant d'atteindre un Engine). Ce n'est pas la bonne lecture. La couche à laquelle appartient un composant se détermine par qui décide, jamais par qui est sollicité en premier. Les Engines décident ; les Platform Services exécutent. Un Engine se situe donc au-dessus des Platform Services qu'il utilise pour appliquer ses décisions, quel que soit l'ordre chronologique dans lequel un événement traverse la plateforme. La section 6 revient en détail sur ce point, qui est la source la plus fréquente de confusion dans ce type d'architecture.
3. Les couches
3.1 Applications
Les applications sont les points d'entrée de la plateforme pour un utilisateur donné.
Exemples : DMV Public, DMV Workspace, DMV Mobile, Coach, AssoSuite, Backoffice.
Une application orchestre des composants. Elle compose une expérience à partir d'Engines et de Platform Services déjà existants. Elle ne contient jamais la logique fondamentale de la plateforme — ni règle métier, ni algorithme de décision, ni accès direct à l'infrastructure.
Une application peut avoir sa propre navigation, ses propres écrans, son propre rythme de déploiement. Cette autonomie d'interface ne l'autorise jamais à dupliquer une règle que porte déjà un Engine ou un Platform Service ailleurs dans la plateforme.
Si une application se retrouve à contenir une décision (« si ce rôle, alors cette permission » ; « si cette source, alors ce classement »), c'est le signe qu'un Engine est manquant ou mal positionné — pas que l'application peut légitimement porter cette décision elle-même.
3.2 Engines
Les Engines prennent des décisions. Ils appliquent les règles métier de la plateforme.
Exemples déjà réels et documentés : Context Engine (détermine le contexte de consultation — qui regarde, depuis quel point de vue, avec quels droits), Wall Engine (construit le contenu affiché à partir d'un contexte déjà résolu), Knowledge Engine (récupère et normalise les données brutes en unités exploitables par les autres Engines), Experience Engine (calcule le classement et la priorité de ce qui est affiché). Exemple émergent, non encore détaillé dans un document dédié : Coach Engine (oriente et accompagne l'utilisateur — sa documentation propre reste à écrire ; il est mentionné ici pour fixer sa place dans l'architecture, pas son fonctionnement interne).
Un Engine ne dépend jamais d'une technologie particulière. Un Engine ne sait pas ce qu'est Next.js, Capacitor ou Cloudflare. Il reçoit des entrées structurées, applique des règles, produit une sortie structurée. Deux Engines différents peuvent collaborer entre eux (le Wall Engine consomme la sortie du Context Engine, par exemple) — cette collaboration reste interne à la couche Engines et ne viole pas le principe de dépendance descendante.
Un Engine peut orchestrer un ou plusieurs Platform Services pour exécuter ce qu'il a décidé (demander l'envoi d'une notification, demander la résolution d'une route), mais il ne réalise jamais cette exécution lui-même.
3.3 Platform Services
Les Platform Services exécutent des capacités techniques réutilisables. Ils ne prennent jamais de décision métier.
Exemples : Navigation, Authentication, Notifications, Storage, Cache, Synchronization.
Un Platform Service répond toujours à une question de la forme « comment faire X ? », jamais à une question de la forme « faut-il faire X, et pour qui ? ». Le service Navigation sait résoudre une route et l'atteindre sur la plateforme courante ; il ne sait jamais si l'utilisateur a le droit d'y accéder. Le service Notifications sait délivrer un message à un appareil ; il ne décide jamais quel utilisateur doit recevoir quel contenu.
Un Platform Service est réutilisable par toutes les applications et par tous les Engines, sans connaître ni les unes ni les autres individuellement. C'est ce qui permet à un même service Cache ou Notifications de servir DMV Public, DMV Workspace et une future application sans modification.
3.4 Infrastructure
L'infrastructure fournit les capacités techniques brutes sur lesquelles reposent les Platform Services.
Exemples : Laravel, PostgreSQL, Supabase, Cloudflare, Capacitor, Workers, CDN.
L'infrastructure ne contient jamais de logique métier. Un choix d'infrastructure (remplacer Cloudflare par un autre CDN, faire évoluer Capacitor) ne doit jamais nécessiter de modifier un Engine ou une règle métier — seul le Platform Service concerné, et éventuellement son implémentation technique sous-jacente, doit être ajusté.
4. Principe architectural majeur
Les Engines prennent des décisions.
Les Platform Services exécutent ces décisions.
L'Infrastructure fournit les capacités techniques.
Les Applications composent l'expérience utilisateur.
Ce principe est l'un des fondements de DMV, au même titre que « le serveur reste la source de vérité » ou « une seule logique métier ». Il doit rester vrai quel que soit le nombre d'applications, de moteurs ou de technologies que DMV accumulera dans les années à venir.
La question à se poser face à tout nouveau composant n'est jamais « quelle technologie utilise-t-il ? » mais « décide-t-il, exécute-t-il, fournit-il une capacité, ou compose-t-il une expérience ? ». La réponse détermine sa couche sans ambiguïté.
5. Dépendances
5.1 Dépendances autorisées
Applications
↓
Engines
↓
Platform Services
↓
Infrastructure
Une couche peut dépendre de n'importe quelle couche strictement inférieure, pas seulement de la couche immédiatement en dessous — une Application peut, par exemple, appeler directement un Platform Service pour un besoin purement technique sans décision associée (afficher un indicateur de connectivité, par exemple), sans passer par un Engine dont ce n'est pas le rôle.
5.2 Dépendances interdites
❌ Une application ne doit jamais dépendre directement de Cloudflare, de Capacitor ou de tout autre élément d'infrastructure. Elle passe toujours par un Platform Service.
❌ Un Engine ne doit jamais dépendre directement de Capacitor, de Cloudflare, ou de toute autre technologie d'infrastructure. S'il a besoin d'une capacité technique, il passe par un Platform Service.
❌ Une règle métier ne doit jamais être implémentée dans un Platform Service. Un Platform Service qui commence à contenir une condition dépendant d'un rôle, d'un droit ou d'un type de contenu a cessé d'être un Platform Service — cette logique doit remonter dans un Engine.
❌ L'infrastructure ne doit jamais contenir de logique métier. Un Worker Cloudflare, une configuration Nginx ou une fonction Supabase ne décide jamais d'un droit d'accès métier — elle applique, au mieux, une règle technique de routage ou de sécurité générique.
❌ Un Platform Service ne doit jamais dépendre directement d'un autre Platform Service d'une façon qui l'oblige à connaître sa logique interne. Deux Platform Services peuvent collaborer via une interface stable, jamais en s'imbriquant.
❌ Une couche inférieure ne doit jamais importer ou référencer directement le code d'une couche supérieure. Voir la section 6 pour la façon correcte de faire remonter un événement technique vers une décision, sans violer cette règle.
6. Dépendance structurelle et flux d'exécution — la distinction qui évite la confusion
La règle de dépendance décrite en section 5 est une règle structurelle : elle dit quel code a le droit de référencer quel autre code. Ce n'est pas une règle sur l'ordre chronologique dans lequel un événement traverse la plateforme.
Un événement technique — une notification reçue par le téléphone, un utilisateur qui perd sa connexion, un lien profond ouvert depuis l'extérieur de l'application — entre nécessairement par le bas de la pile, au niveau de l'Infrastructure ou d'un Platform Service. Il doit pourtant, presque toujours, remonter jusqu'à un Engine pour qu'une vraie décision soit prise (quel contenu afficher, avec quel contexte, pour quel utilisateur).
Ceci ne viole pas le principe de dépendance descendante, à une condition : le Platform Service qui reçoit l'événement ne doit jamais avoir besoin de connaître ou d'importer le code de l'Engine qui va le traiter. Il expose une interface générique (un point d'écoute, un événement, une notification interne) que l'Engine concerné vient s'abonner à l'initialisation de la plateforme. C'est l'Engine — la couche supérieure — qui connaît le Platform Service et s'y raccorde, jamais l'inverse.
Concrètement : le Platform Service Notifications ne contient jamais de ligne de code qui appelle « Context Engine ». Il expose un mécanisme générique de notification d'événement. C'est le Context Engine, au démarrage de la plateforme, qui s'enregistre auprès de ce mécanisme pour être averti chaque fois qu'une notification est ouverte. Le sens de la dépendance structurelle reste intact — seul le sens du signal, au moment de l'exécution, remonte la pile.
Cette distinction est la source la plus fréquente de confusion dans ce type d'architecture. Un composant ne se positionne jamais en fonction de l'ordre dans lequel il intervient dans un scénario donné, mais en fonction de la nature de ce qu'il fait : décider, exécuter, fournir une capacité, ou composer une expérience.
7. Exemples
7.1 Ouverture d'une notification
Notification (Infrastructure / OS natif)
↓ (signal générique, aucune dépendance de code vers le haut)
Navigation Service (Platform Service — résout la route associée à la notification)
↓ (le Navigation Service exécute une résolution technique, sans décision métier)
Context Engine (Engine — détermine le contexte : qui est l'utilisateur, quel espace, quels droits)
↓
Wall Engine (Engine — construit le contenu à afficher pour ce contexte)
↓
Application (affiche l'écran final)
Le Navigation Service ne sait jamais « pour qui » il résout la route, ni ce qui sera affiché — il sait uniquement transformer une référence de notification en une destination technique. La décision de ce qui est réellement montré appartient entièrement aux Engines.
7.2 Ouverture d'une fiche acteur
Application (l'utilisateur clique sur une fiche acteur)
↓
Navigation Service (résout l'URL/la route de la fiche)
↓
Context Engine (détermine le contexte : visiteur, utilisateur connecté, gestionnaire de l'acteur ?)
↓
Knowledge Engine (récupère et normalise les données de l'acteur et de ses publications)
↓
Wall Engine (compose l'affichage final à partir du contexte et des données normalisées)
↓
Application (affiche la fiche)
Le même parcours technique produit un résultat différent selon le contexte résolu par le Context Engine (un visiteur, un utilisateur suivant cet acteur, ou son propre gestionnaire ne voient pas exactement la même fiche) — sans qu'aucune de ces différences ne soit codée dans l'Application elle-même.
7.3 Connexion
Application (l'utilisateur déclenche une connexion)
↓
Authentication Service (Platform Service — exécute le protocole d'authentification, obtient et stocke un jeton)
↓
Context Engine (résout le contexte utilisateur une fois la session ouverte : rôles, espaces accessibles)
↓
Application (redirige vers l'espace pertinent, déjà déterminé par le contexte résolu)
Le service Authentication ne décide jamais où rediriger l'utilisateur après connexion, ni quels espaces lui sont accessibles — il exécute uniquement le protocole d'authentification et produit une session valide. La décision de destination et de contexte reste entièrement du ressort du Context Engine.
8. Positionnement des documents existants
Ce document ne se substitue à aucun document existant. Il leur donne un emplacement commun.
| Document | Couche | Rôle |
|---|---|---|
06-architecture/wall-engine/02-context-engine.md | Engine | Résolution du contexte de consultation |
06-architecture/wall-engine/03-wall-engine.md | Engine | Construction du contenu affiché |
08-frontend/architecture DMV synthese.md | Engine (Knowledge Engine, Experience Engine) | Détail du pipeline de classement et de récupération des données ; document métier, sans mention technologique, cohérent avec ce document |
12-apps/dmv/mobile/16-navigation-engine.md | Platform Service (Navigation) | Détail de l'abstraction de navigation indépendante des plateformes |
12-apps/dmv/mobile/06-cache-engine.md | Platform Service (Cache) | Détail de la politique de cache mobile |
12-apps/dmv/mobile/07-synchronization-engine.md | Platform Service (Synchronization) | Détail de la synchronisation mobile |
12-apps/dmv/mobile/08-native-platform.md | Platform Service ↔ Infrastructure | Couche d'abstraction entre les Platform Services et Capacitor |
12-apps/dmv/mobile/* (ensemble) | Application (DMV Mobile) + adaptation des Platform Services | Le shell mobile est une Application au sens de ce document ; ses moteurs internes (Cache, Synchronization, Navigation) sont des déclinaisons mobiles de Platform Services de plateforme |
06-architecture/01-global-architecture.md | Historique | Première tentative de cadrage global, antérieure à la formalisation des Engines et Platform Services. Conservé comme référence historique ; ce document le remplace comme référence courante. |
Note sur les Platform Services nommés « Engine » dans la documentation mobile. Les documents mobiles utilisent le terme « Engine » pour le Cache Engine et le Synchronization Engine (ex. 06-cache-engine.md, 07-synchronization-engine.md). Au sens strict de ce document, ce sont des Platform Services : ils exécutent des capacités techniques réutilisables (mettre en cache, synchroniser), sans jamais décider quelle donnée a de la valeur pour un utilisateur donné — cette décision reste du ressort des Engines qui les consomment. Le nom « Engine » leur a été donné avant que la distinction Engine / Platform Service ne soit formalisée par ce document. Renommer ces documents n'est pas nécessaire dans l'immédiat ; leur classification correcte dans ce tableau suffit à lever toute ambiguïté pour un nouveau développeur.
9. Évolution
Cette architecture est conçue pour évoluer.
De nouveaux Engines apparaîtront à mesure que de nouvelles décisions métier devront être prises quelque part (le Coach Engine, aujourd'hui à peine nommé, en est un exemple direct). De nouveaux Platform Services apparaîtront à mesure que de nouvelles capacités techniques réutilisables seront nécessaires. De nouvelles applications intégreront la plateforme sans qu'aucune des couches inférieures n'ait besoin d'anticiper leur existence.
Ce qui ne doit jamais évoluer, c'est le principe de dépendance descendante et la distinction entre décider (Engines), exécuter (Platform Services), fournir (Infrastructure) et composer (Applications). Une technologie remplacée, un Engine ajouté ou un Platform Service scindé en deux ne remettent jamais ce principe en cause — c'est précisément ce qui rend cette architecture capable de rester valide pendant de nombreuses années, indépendamment des choix technologiques qui la traversent.
Conclusion
DMV est une plateforme organisée en quatre couches, dont l'ordre n'est jamais négociable : les Applications composent, les Engines décident, les Platform Services exécutent, l'Infrastructure fournit.
Face à un nouveau composant, la question à poser n'est jamais technologique. Elle est architecturale : que fait-il réellement ? S'il décide, c'est un Engine. S'il exécute une capacité technique réutilisable sans décider, c'est un Platform Service. S'il fournit une capacité brute, c'est de l'Infrastructure. S'il compose une expérience à partir de ce qui existe déjà, c'est une Application.
Ce document constitue la référence architecturale principale de DMV. Tout nouveau composant, toute nouvelle application, tout nouveau document d'architecture doit pouvoir s'y positionner sans ambiguïté.
Voir aussi : 27-architecture-governance.md définit comment cette architecture est autorisée à évoluer — niveaux de stabilité, processus de décision, registre des ADR, gestion de la dette architecturale.