The DMV Way
Statut
Document fondateur — v1.0 — rédigé le 2026-07-19.
Ce document ne remplace aucune documentation existante. Il la précède. C'est le premier texte que toute personne rejoignant DMV doit lire — avant l'architecture, avant le code, avant tout détail technique.
Pourquoi DMV existe
DMV existe parce que l'information locale est abondante, mais introuvable au bon moment. Le problème n'a jamais été le manque de contenu — c'est sa dispersion, et l'absence d'un endroit unique capable de la rendre utile à l'instant où elle compte.
La mission qui en découle tient en deux lignes : simplifier l'accès à l'information locale, et valoriser les acteurs qui la produisent. Tout ce que DMV construit — produit, architecture, code — n'est qu'un moyen d'y parvenir. (Le récit complet de cette conviction se trouve dans le Manifeste DMV.)
Notre manière de construire
Nous concevons avant de coder.
Nous privilégions les responsabilités aux technologies.
Nous construisons une plateforme avant des applications.
Nous recherchons la simplicité durable, pas la simplicité immédiate.
Nous privilégions l'évolution à la perfection immédiate.
Une bonne idée mal placée dans l'architecture coûte plus cher qu'une idée moyenne bien placée.
Notre architecture
DMV s'organise en couches. Chacune ne dépend que de celle qui la précède.
Applications
↓
Engines
↓
Platform Services
↓
Infrastructure
Les Applications composent une expérience. Les Engines décident. Les Platform Services exécutent. L'Infrastructure fournit.
Aucune couche ne connaît en détail celle du dessous. Aucune couche n'emprunte de raccourci vers celle du dessus.
Notre manière de prendre des décisions
Vision
↓
Architecture
↓
ADR
↓
Work Packages
↓
Code
Le code n'est jamais le point de départ. Il est toujours la dernière étape d'une décision prise plus haut — jamais l'endroit où une décision d'architecture se prend par défaut, faute d'avoir été posée ailleurs.
Nos règles
Une responsabilité, un composant.
Ne jamais contourner une abstraction, même quand c'est plus rapide.
Une couche ne dépend jamais de celle du dessus.
Préférer une architecture simple à une optimisation prématurée.
Documenter avant de généraliser.
Ne créer un nouveau composant qu'en dernier recours.
Une décision importante devient une ADR — jamais une convention orale.
Le code implémente une décision ; il ne la remplace jamais.
Ce qui est stable ne change que par décision explicite. Ce qui est évolutif change librement.
Un principe qui dépend d'une technologie n'est pas un principe.
Notre philosophie
Une architecture n'est pas faite pour empêcher d'évoluer. Elle est faite pour rendre l'évolution prévisible.
C'est la seule chose que ce document demande de retenir avant d'ouvrir le reste de la documentation.