Règles data

Statut

Document de règles projet — version initiale.

Objectif

Garantir une donnée DMV fiable, portable, sécurisée et exploitable par l'écosystème territorial.

Règles strictes

• PostgreSQL est la base relationnelle principale.
• La séparation utilisateurs, acteurs et communes doit rester claire.
• Les accès métier sensibles doivent passer par l'API Laravel cible.
• L'IA ne doit pas accéder directement à la base.
• Ne pas créer deux sources de vérité pour la même donnée.
• Ne pas stocker de données personnelles sans finalité claire.
• Ne pas exposer les champs internes dans les réponses publiques.

Données structurantes

• profils et rôles ;
• communes ;
• acteurs ;
• claims ;
• publications ;
• signalements ;
• favoris ;
• groupes ;
• abonnements ;
• boosts ;
• PlayLoop ;
• AssoSuite ;
• Mairie ;
• statistiques ;
• IA.

Migrations

• Documenter la source canonique.
• Nommer clairement les migrations.
• Éviter les migrations destructrices directes.
• Tester avant production.
• Prévoir rollback ou migration en deux temps.
• Ne pas laisser Laravel et Supabase diverger sans décision.

Qualité data

• Valider à l'entrée.
• Normaliser les champs importants.
• Indexer les recherches fréquentes.
• Garder les statuts explicites.
• Éviter les valeurs magiques non documentées.
• Prévoir audit sur actions sensibles.

Anti-patterns

• Table fourre-tout.
• JSON utilisé pour remplacer un modèle clair.
• Statuts libres non documentés.
• Accès frontend direct pour modifier une donnée sensible.
• Données analytics trop intrusives.
• Logs contenant données privées inutiles.

État actuel vs cible

Sujet	État actuel	Cible
Migrations	Laravel et Supabase visibles.	Source canonique clarifiée.
Accès data	Supabase JS encore visible.	API Laravel gouvernante.
PostGIS	Stratégique.	Usage progressif si besoin validé.

Points à clarifier

• Schéma canonique.
• Rôle final Supabase.
• Rétention par donnée.
• Backups et restauration.
• Stratégie partitionnement.