Modèle utilisateurs
Objectif du modèle
Représenter les comptes humains qui accèdent à DMV, au backoffice et aux applications connectées.
Responsabilités
- Porter l’identité applicative d’un compte.
- Servir de point d’entrée aux sessions, rôles et préférences.
- Relier un utilisateur à des acteurs, communes, notifications, favoris ou usages IA.
- Ne pas représenter directement une organisation locale.
Relations principales
- Un utilisateur peut gérer plusieurs acteurs via
actor_users. - Un utilisateur peut recevoir des notifications.
- Un utilisateur peut initier des publications selon ses droits.
- Un utilisateur peut consommer des quotas ou crédits IA selon son offre ou son périmètre.
Cycle de vie
- Création du compte via le provider d’authentification retenu.
- Activation ou vérification selon règles à confirmer.
- Association éventuelle à des acteurs, communes ou rôles.
- Usage courant.
- Suspension, anonymisation, suppression ou export selon règles RGPD à définir.
Permissions/RBAC liées
- Les droits globaux ne doivent pas être déduits uniquement du compte.
- Les permissions métier passent par rôles, scopes et pivots comme
actor_users. - Les rôles sensibles doivent être validés côté Laravel.
Contraintes métier
- Séparer clairement compte utilisateur et acteur local.
- Ne pas dupliquer les droits acteur dans le profil utilisateur.
- Prévoir des préférences de communication et confidentialité.
Données sensibles éventuelles
- Identité, email, téléphone ou informations de connexion selon provider.
- Préférences, consentements, historique de connexion ou audit.
- Données RGPD soumises à minimisation, export et suppression.
Cache/offline éventuel
- Cache frontend limité aux informations non sensibles.
- Session locale possible selon app, mais droits sensibles revalidés côté API.
Stratégie d’indexation
- Index conceptuels sur identifiant provider, email normalisé, statut et dates utiles.
- Index métier à confirmer selon usage réel de recherche et support.
Partitionnement si concerné
Non prioritaire. Les utilisateurs ne sont pas le candidat principal au partitionnement mensuel.
État actuel vs cible
| Niveau | Description |
|---|---|
| Structure visible/confirmée | Supabase Auth côté frontends ; JWT Supabase décodé via librairie firebase/php-jwt → token Sanctum émis ; modules Identity et Admin visibles. |
| Structure probable | Table ou référentiel utilisateur lié à un provider externe et à des rôles/scopes backend. |
| Cible future | Identité centralisée, autorisations métier côté Laravel, gestion RGPD documentée. |
Points à confirmer
- Provider d’identité final.
- Mapping exact entre utilisateur auth et utilisateur métier.
- Champs RGPD obligatoires.
- Politique de suppression/anonymisation.