Personal Accounts Domain

Definition

Un compte personnel est un utilisateur unique rattache a une entreprise de type personal.

Ce modele sert au parcours gratuit hors console admin:

• creation autonome d'un compte par n'importe quel visiteur
• role applicatif force a personnel
• entreprise technique dediee de type personal

Regles d'acces

• n'importe qui peut creer un compte personnel si l'email est disponible
• la creation publique declenche une validation email Supabase via auth.signUp
• un compte personnel authentifie peut modifier ses propres informations
• un compte personnel authentifie peut supprimer son propre compte
• un super-admin peut lister, modifier et supprimer tous les comptes personnels
• un compte personnel n'a pas acces a la console admin

Endpoints

Endpoint	Auth	Description
POST /personal-accounts	Public	Cree un compte personnel, son entreprise personal, ses settings, son rattachement a l'environnement par defaut et envoie l'email de validation Supabase
GET /personal-accounts?page=1&pageSize=20	Bearer super-admin	Liste paginee des comptes personnels
PATCH /personal-accounts/:id	Bearer super-admin	Met a jour un compte personnel cible
DELETE /personal-accounts/:id	Bearer super-admin	Supprime un compte personnel cible
PATCH /personal-accounts/me	Bearer personnel	Met a jour son propre compte personnel
DELETE /personal-accounts/me	Bearer personnel	Supprime son propre compte personnel

Validation email

La creation publique d'un compte personnel utilise le client Supabase public (auth.signUp) et non auth.admin.createUser(email_confirm: true).

Effets attendus:

• Supabase envoie l'email de confirmation si l'option "Confirm email" est activee sur le projet
• l'utilisateur ne peut pas obtenir de session valide tant que Supabase n'a pas confirme l'email
• la reponse API expose emailConfirmed
• la reponse API expose aussi les settings de l'entreprise personal associee
• la console super-admin affiche le statut Valide ou En attente

Comportement actuel si Confirm email est desactive dans Supabase:

• aucun email de verification n'est envoye
• le compte est considere comme confirme immediatement par Supabase
• emailConfirmed = true des la creation
• la console affiche donc directement Valide
• ce mode est tolere tant que le workflow inter-applications n'est pas encore pret pour une redirection utilisateur apres verification email

Cycle attendu:

1. POST /personal-accounts cree l'entreprise personal, ses settings, son rattachement a l'environnement par defaut, puis appelle supabase.auth.signUp
2. si Supabase accepte la creation, le profil profiles est cree avec le role personnel
3. tant que l'email n'est pas confirme, emailConfirmed = false
4. apres clic sur le lien envoye par Supabase, la confirmation est portee par auth.users.email_confirmed_at
5. les lectures ulterieures du compte personnel retournent alors emailConfirmed = true

Impact fonctionnel:

• un compte personnel non confirme reste un compte valide cote metier, mais son email est en attente de verification
• un compte personnel ne peut pas acceder a la console admin, confirme ou non
• si l'email existe deja, l'API retourne un conflit fonctionnel avec le message Cette adresse email est deja utilisee.
• en cas d'echec pendant la creation auth/profile, les ressources techniques personal deja creees sont nettoyees

Source du statut:

• emailConfirmed est calcule a partir de auth.users.email_confirmed_at
• la valeur est exposee dans PersonalAccountDto.emailConfirmed, puis mappee cote front en email_confirmed

Structure retour utile:

• enterpriseId et enterpriseName de l'entreprise personal
• settings avec au minimum id, enterpriseId et code
• ce bloc permet a un client consommateur de recuperer les metadonnees metier de l'entreprise associee sans appel supplementaire

Configuration:

• SUPABASE_PERSONAL_ACCOUNT_EMAIL_REDIRECT_TO est optionnelle
• si elle est renseignee, elle est transmise comme emailRedirectTo au lien de confirmation Supabase
• l'URL doit etre autorisee dans la configuration Auth de Supabase
• en pratique, cette URL doit pointer vers le frontend public qui sait terminer le flux Supabase, par exemple /auth/callback

Recommandations d'exploitation:

• conserver Confirm email active sur les environnements publics
• utiliser une URL de redirection differente entre local, staging et production
• verifier que l'URL configuree est bien presente dans les Redirect URLs Supabase
• ne pas documenter ce flux comme un acces console: il concerne uniquement les comptes personnel
• si Confirm email est temporairement desactive, considerer emailConfirmed comme un reflet de la politique Supabase de l'environnement, et non comme une preuve de verification manuelle par l'utilisateur

Modification

Les champs geres par l'API de modification sont:

• firstname
• lastname
• email
• newPassword

Effets metier:

• le changement d'email reutilise l'audit profile_email_change_audits
• le changement de mot de passe reutilise l'audit profile_password_change_audits
• le nom de l'entreprise personal suit le prenom/nom du compte
• le code settings.code de cette entreprise est resynchronise

Suppression

La suppression d'un compte personnel:

• supprime auth.users
• supprime profiles
• supprime l'entreprise personal associee

Le compte personnel ne doit jamais apparaitre dans GET /enterprises, qui reste reserve aux entreprises de type enterprise.