Aller au contenu principal

Master Book DMV

Ce dossier a vocation à devenir le Master Book officiel du projet DMV.

Cette première version est volontairement factuelle : elle documente uniquement ce qui est visible dans l'arborescence, les manifests, les routes, les modules et les fichiers de configuration du projet courant. Les éléments non confirmés sont signalés comme tels.

Statut du document​

  • Statut : initialisation du Master Book.
  • Dernière analyse locale : 2026-05-08.
  • Périmètre analysé : racine du projet, applications api, dmv_backoffice, dmv-public, dossier deployment et structure docs.
  • Limite : aucune validation fonctionnelle, métier, juridique, financière ou produit n'est encore déduite au-delà du code visible.

Projet visible​

Le workspace contient plusieurs sous-projets distincts :

  • api : API Laravel modulaire, avec routes versionnées sous /api/v1, authentification Sanctum, intégration Stripe et modules fonctionnels séparés.
  • dmv_backoffice : application React/Vite d'administration, connectée à Supabase, avec des pages de gestion pour utilisateurs, communes, acteurs, publications, statistiques, messages, claims, abonnements et configuration.
  • dmv-public : application publique Next.js/React/TypeScript, connectée à Supabase, avec pages publiques, annuaire par commune, espace utilisateur, pages légales et composants de publications.
  • dmv_backoffice/supabase et dmv-public/supabase : migrations SQL et Edge Functions Supabase visibles.
  • deployment : scripts et fichiers de déploiement, dont deploy.sh, install.sh, nginx.conf, supervisor.conf, crontab.txt et un exemple d'environnement production.
  • documents : ressources documentaires externes au Master Book.
  • docs : structure documentaire cible, organisée en chapitres.

La racine du workspace ne semble pas être un dépôt Git unique. Des dépôts Git séparés sont visibles dans api, dmv_backoffice, dmv-public et docs.

Structure du Master Book​

La structure docs est organisée en grands domaines :

  • 00-governance : cadrage projet, gouvernance, rôles, standards et risques.
  • 01-vision : vision globale, positionnement, utilisateurs cibles et impact territorial.
  • 02-ecosystem : écosystème DMV, PlayLoop, AssoSuite, Mairie et services partagés.
  • 03-business : modèle économique, offres, revenus, acquisition, rétention et KPI.
  • 04-product : produit, parcours, fonctionnalités, onboarding, modération et accessibilité.
  • 05-ia : vision IA, providers, RAG, sécurité, quotas, agents et prompts.
  • 06-architecture : architecture globale, modules, services, performance, observabilité et stratégie cloud.
  • 07-backend : architecture Laravel, modules, services, jobs, API, tests et standards.
  • 08-frontend : architecture React, Vite, design system, PWA, SEO, analytics et tests.
  • 09-data : PostgreSQL, schémas, migrations, cache, recherche, analytics, rétention et backups.
  • 10-security : authentification, autorisation, RLS, API security, secrets, RGPD et audit logs.
  • 11-devops : infrastructure, Docker, CI/CD, environnements, monitoring et déploiements.
  • 12-apps : documentation par application : DMV, PlayLoop, AssoSuite, Mairie et futures apps.
  • 13-roadmap : versions, priorités, dépendances et vision long terme.
  • 14-marketing : marque, positionnement, SEO, lancement, contenus et partenariats.
  • 15-finance : business plan, revenus, coûts, projections, financement et KPI.
  • 16-operations : support, modération, incidents, validation, mairie relations et processus documentaire.
  • 17-legal : structure, CGU, confidentialité, RGPD, cookies, responsabilité et assurances.
  • 18-annexes : glossaire, conventions, exemples, user stories, cas d'usage, FAQ et benchmarks.
  • decisions, prompts, rules, schemas, assets : espaces de support pour décisions, prompts, règles, schémas et ressources visuelles.

Règles de rédaction​

  • Distinguer clairement le visible dans le code de ce qui reste à confirmer.
  • Citer les dossiers et fichiers sources quand cela aide à vérifier l'information.
  • Éviter les promesses produit, commerciales ou techniques non observées.
  • Préférer un français clair, opérationnel et durable.
  • Ne pas documenter une intention comme une réalité tant qu'elle n'est pas confirmée par le code, une décision ou une validation explicite.

Points à confirmer​

  • Nom officiel complet du projet : le site public utilise Dans Mon Village, mais le statut officiel de ce libellé pour tout l'écosystème DMV reste à confirmer.
  • Source de vérité applicative : le code montre à la fois une API Laravel et des accès directs Supabase côté frontends ; le partage exact des responsabilités reste à formaliser.
  • Statut de production : les scripts de déploiement existent, mais l'état réel des environnements, domaines et pipelines reste à confirmer.
  • Périmètre produit : PlayLoop, AssoSuite et Mairie sont visibles dans l'API et la documentation cible, mais leurs frontends dédiés ne sont pas visibles comme applications séparées dans ce workspace.
  • Roadmap, modèle économique, juridique, sécurité, opérations, IA et finance : les chapitres existent dans docs, mais leur contenu officiel reste à établir.

Point d'entrée​

Le cadrage factuel initial du projet est documenté dans 00-governance/01-project-overview.md.