Interactions entre applications

Statut

Document de cadrage écosystème — version initiale.

Objectif

Les interactions entre applications doivent permettre à l'écosystème DMV de fonctionner comme un ensemble cohérent, sans transformer chaque application en dépendance forte des autres.

Le principe est le suivant : chaque application garde son usage principal, mais peut consommer, produire ou exposer certaines données partagées selon des règles explicites.

Principes directeurs

• Une application ne doit pas publier automatiquement dans une autre sans règle de validation.
• Une donnée partagée doit avoir une source de vérité identifiable.
• Les droits doivent être vérifiés au niveau du service commun ou de l'API.
• Les usages internes et publics doivent rester séparés.
• Les statistiques doivent indiquer l'application source quand c'est nécessaire.
• Les médias doivent respecter les droits de diffusion du contexte d'origine.

Matrice d'interactions

Source	Destination	Interaction possible	Condition de cohérence
DMV	PlayLoop	Réutilisation de publications, événements ou médias dans une playlist.	Sélection explicite, droits de diffusion écran, contexte territorial valide.
Mairie	DMV	Publication d'alertes, services ou contenus mairie dans l'expérience publique locale.	Règles de visibilité publique et durée de validité.
Mairie	PlayLoop	Diffusion d'alertes ou informations communales sur écrans.	Priorisation, expiration et validation communale.
AssoSuite	DMV	Diffusion d'événements ou publications associatives publiques.	Séparation claire entre contenu interne et contenu public.
AssoSuite	PlayLoop	Diffusion de contenus associatifs sur écrans locaux.	Accord de l'association et règles de diffusion du lieu.
DMV	AssoSuite	Visibilité publique d'une association et lien vers ses contenus.	Données acteur cohérentes et droits de gestion.
Backoffice/Admin	Toutes	Administration, correction, validation et configuration.	Droits administrateurs, traçabilité et règles de gouvernance.

Flux de contenu

Les flux de contenu doivent distinguer trois niveaux :

• contenu public : visible par les habitants dans DMV ou sur un écran PlayLoop ;
• contenu métier : géré dans Mairie, AssoSuite ou PlayLoop pour un usage spécifique ;
• contenu interne : non destiné à la publication publique.

Cette distinction évite qu'une information interne devienne publique par erreur, ou qu'un contenu public soit diffusé dans un contexte inadapté.

Publications

Les publications constituent l'un des points de jonction les plus importants.

Elles peuvent venir :

• d'un acteur local dans DMV ;
• d'une mairie via Mairie ;
• d'une association via AssoSuite ;
• d'un administrateur ou d'un module de gestion.

La cible est de partager un modèle commun de publication, avec des champs, droits, statuts et périmètres clairs. L'état actuel montre déjà un module Laravel Publication, mais les usages exacts par application doivent être documentés progressivement.

Médias

Les médias peuvent être utilisés par plusieurs applications, mais leur diffusion doit rester contrôlée.

Exemples :

• image d'une publication DMV reprise dans PlayLoop ;
• document public d'un acteur visible dans DMV ;
• média propre à une playlist PlayLoop ;
• document associatif interne réservé à AssoSuite.

La mutualisation des médias ne doit pas supprimer les règles de contexte, de propriété ou de visibilité.

Identité et droits

Les interactions reposent sur une identité et des droits partagés :

• utilisateurs ;
• profils ;
• rôles globaux ;
• rôles applicatifs ;
• rattachements à des acteurs, associations ou communes ;
• droits de publication, modération, administration ou diffusion.

L'état actuel visible montre des modules Identity, Admin, AssoSuite, Mairie et des middlewares spécialisés. La cible est de formaliser les droits par application sans multiplier les logiques contradictoires.

Statistiques

Les statistiques doivent permettre de comprendre l'usage sans confondre les contextes.

Une vue de publication dans DMV, une diffusion sur PlayLoop et une lecture interne dans AssoSuite ne représentent pas le même usage. Les événements statistiques doivent donc indiquer leur source, leur contexte et leur finalité.

État actuel vs cible

Sujet	État actuel visible	Cible
API	Modules Laravel actifs et routes spécialisées.	Contrats API explicites entre applications.
Frontends	DMV public et backoffice visibles ; interfaces dédiées PlayLoop, AssoSuite et Mairie à clarifier.	Interfaces autonomes ou parcours dédiés par application.
Supabase	Accès frontends et migrations encore présents.	Clarification progressive du rôle Supabase face à l'API centrale.
Publications	Module partagé visible.	Règles de diffusion inter-apps documentées.
Médias	Présence de documents, storage et médias selon modules.	Service média commun avec droits de visibilité.

Règle de conception

Une interaction entre applications doit être ajoutée seulement si elle réduit la friction pour l'utilisateur ou améliore la cohérence du territoire.

Une interaction qui crée de l'ambiguïté sur la source, les droits ou la visibilité doit être refusée ou redessinée.