Philosophie data
Statut
Document de cadrage data — version initiale.
Vision
La stratégie data DMV doit soutenir un écosystème territorial fiable, lisible et évolutif.
Les données doivent permettre de connecter communes, habitants, acteurs locaux, contributeurs, publications, services communaux, applications connectées et statistiques, sans créer de confusion entre les responsabilités.
Principes
- PostgreSQL est la base relationnelle principale.
- La donnée métier doit être gouvernée par l'API Laravel centrale autant que possible.
- Les accès directs Supabase côté frontend existent et doivent être rationalisés progressivement.
- La séparation utilisateurs / acteurs / communes doit rester claire.
- Les données publiques, privées, internes et administratives doivent être distinguées.
- Les données doivent rester portables et migrables.
- Les données analytiques doivent mesurer la valeur produit sans devenir intrusives.
- L'IA ne doit jamais accéder directement à la base.
Données structurantes
| Domaine | Données principales |
|---|---|
| Identité | profils, rôles, rattachements utilisateurs. |
| Territoire | communes, élus, collectes, informations communales. |
| Acteurs | acteurs locaux, tags, documents, revendications. |
| Publications | contenus, types, communes rattachées, signalements, modération. |
| Communauté | contributeurs, favoris, groupes. |
| Monétisation | plans, abonnements, boosts, usages. |
| Applications | PlayLoop, AssoSuite, Mairie, chat. |
| Analytics | événements, agrégats, statistiques produit. |
| IA | usages, coûts, crédits, prompts, logs et contextes autorisés. |
État actuel visible
Le workspace contient :
- des migrations Laravel dans
api/database/migrations; - des migrations Supabase historiques dans
dmv_backoffice/supabase/migrations; - une migration Supabase
stats_eventsdansdmv-public/supabase/migrations; - des clients Supabase encore utilisés côté frontends ;
- des modules Laravel couvrant les principaux domaines métier.
Vision cible
La cible est une stratégie où :
- les règles métier sont contrôlées par l'API Laravel ;
- les schémas et migrations ont une source canonique claire ;
- les RPC sont documentées et utilisées seulement pour des besoins maîtrisés ;
- les données géographiques sont renforcées par PostGIS si le besoin est validé ;
- le partitionnement est utilisé progressivement pour les gros volumes ;
- la donnée IA est isolée, sécurisée et mesurée.
Points à clarifier
- Source canonique entre migrations Laravel et Supabase.
- Rôle futur de Supabase : auth, storage, base, edge functions ou historique.
- Convention de schéma PostgreSQL.
- Stratégie de sauvegarde et restauration.
- Politique de rétention par type de donnée.