Services mutualisés

Statut

Document de cadrage écosystème — version initiale.

Objectif

Les services mutualisés forment le socle commun de l'écosystème DMV.

Ils permettent aux applications DMV, PlayLoop, AssoSuite, Mairie et futures apps de partager des briques stables sans perdre leur autonomie d'interface ou d'usage.

Catalogue des services partagés

Service	Rôle	État actuel visible
Identité et utilisateurs	Authentification, profils, rôles, rattachements.	Modules Identity, profils, rôles et usage Supabase Auth visibles.
Communes et territoire	Communes, élus, collectes, informations communales.	Module Territory visible.
Acteurs locaux	Acteurs, tags, documents, claims, visibilité.	Module Actor visible.
Publications	Publications, types, modération, signalements, rattachement aux communes.	Module Publication visible.
Médias et documents	Documents, images, médias de diffusion, storage.	Documents côté Actor, médias PlayLoop, migrations storage Supabase visibles.
Droits et accès	Admin, acteur, association, mairie, device, modération.	Middlewares et policies visibles selon modules.
Abonnements et monétisation	Plans, souscriptions, boosts, Stripe.	Module Monetization visible.
Statistiques	Événements, agrégats, lectures par acteur ou commune.	Module Analytics et migrations stats_events visibles.
Notifications	Emails, messages, alertes et communications.	Edge Functions et modules métier visibles, service unifié à formaliser.
IA Gateway	Assistance rédaction, recherche, classification, modération.	Cible stratégique documentée ; module applicatif dédié non confirmé dans le code inspecté.
Services API	Contrats entre applications et backend.	API Laravel modulaire visible ; rôle Supabase encore à clarifier.

Identité et utilisateurs

Le service d'identité doit permettre de reconnaître un utilisateur et ses droits dans plusieurs contextes :

• habitant ;
• acteur local ;
• administrateur ;
• responsable associatif ;
• utilisateur mairie ;
• device PlayLoop lorsque le contexte n'est pas humain.

L'état actuel montre Supabase Auth côté frontends et un module Laravel Identity avec Sanctum côté API. La cible est de clarifier progressivement le partage des responsabilités entre ces briques.

Communes, acteurs et territoire

Les communes et les acteurs sont des données structurantes.

Elles doivent servir :

• à organiser l'expérience publique DMV ;
• à rattacher des publications ;
• à filtrer les contenus PlayLoop ;
• à relier une association à son territoire ;
• à permettre aux communes de piloter leurs informations ;
• à produire des statistiques territoriales cohérentes.

La cohérence territoriale est un principe fort : une même commune ou un même acteur ne doit pas être redéfini différemment selon l'application.

Publications et médias

Les publications et médias sont au cœur des interactions entre applications.

Le service commun doit gérer :

• type de publication ;
• source applicative ;
• auteur ou entité porteuse ;
• statut de publication ;
• communes concernées ;
• visibilité publique ou interne ;
• droits de reprise ;
• médias associés.

La cible est d'éviter que chaque application invente son propre format de publication sans passerelle avec les autres.

Droits et permissions

Les droits doivent être mutualisés dans leur logique, mais appliqués selon le contexte.

Exemples :

• un administrateur global peut gérer plusieurs domaines ;
• une commune peut gérer ses propres alertes et services ;
• une association peut gérer ses membres et contenus internes ;
• un acteur peut gérer son mini-site ou ses publications ;
• un device PlayLoop ne doit accéder qu'à sa playlist ou aux contenus autorisés.

Les droits doivent rester auditables et compréhensibles par les équipes projet.

Statistiques

Le service statistique doit agréger sans confondre.

Les applications peuvent produire des événements différents :

• consultation d'une page DMV ;
• clic ou favori sur un acteur ;
• diffusion d'une playlist PlayLoop ;
• lecture d'une publication mairie ;
• usage d'un module AssoSuite ;
• envoi ou réception d'une notification.

Chaque événement doit conserver sa source, son contexte et son rattachement territorial quand il existe.

Notifications

Les notifications couvrent plusieurs réalités :

• messages ou emails vers un acteur ;
• alerte citoyenne ;
• information communale ;
• invitation associative ;
• notification administrative ;
• relance ou information liée à une cotisation.

L'état actuel montre des Edge Functions et modules métier capables d'envoyer ou traiter certains messages. La cible est un service de notification cohérent, avec règles d'envoi, consentement, traçabilité et canaux clairement définis.

IA Gateway

L'IA Gateway est une cible de service transversal.

Elle doit aider les applications à utiliser l'IA de manière contrôlée :

• aide à la rédaction de publications ;
• reformulation de contenus ;
• recherche ou classement ;
• assistance à la modération ;
• résumé ou structuration d'information ;
• gain de temps pour les communes, associations et acteurs.

À ce stade, ce service doit être documenté comme vision cible. Il ne faut pas le présenter comme une brique finalisée tant qu'un module ou une intégration officielle n'est pas confirmé dans le code.

Services API

Le backend cible est une API Laravel centrale modulaire.

Les services API doivent :

• exposer des contrats clairs par domaine ;
• éviter les accès concurrents non gouvernés ;
• sécuriser les mutations ;
• permettre aux applications de rester indépendantes côté interface ;
• documenter progressivement les transitions depuis les accès Supabase encore présents.

État actuel vs cible

Domaine	État actuel	Cible
API centrale	Laravel modulaire visible.	Source principale des règles métier et services partagés.
Supabase	Auth, migrations, storage, Edge Functions et accès frontends visibles.	Rôle clarifié progressivement, sans inventer de migration non décidée.
Services partagés	Plusieurs modules existent, mais le catalogue n'est pas encore formalisé partout.	Services transverses documentés, versionnés et gouvernés.
IA Gateway	Vision validée, pas confirmée comme module visible.	Couche métier discrète, contrôlée et mutualisée.
Notifications	Fonctions et usages dispersés visibles.	Service cohérent avec consentement, règles et traçabilité.

Principes de gouvernance

• Une brique mutualisée doit servir plusieurs applications ou réduire une duplication réelle.
• Une application peut garder un service spécifique si son besoin métier l'exige.
• Les accès directs aux données doivent être documentés et justifiés.
• Les règles de droits doivent être centralisées autant que possible.
• Les transitions techniques doivent être progressives et vérifiables.