Enterprise Domain

Definition

Une enterprise represente un tenant principal de la console d'administration.

Le type utile pour la console est enterprise. Le type personal existe dans le modele de donnees mais ne doit pas etre melange a la liste des entreprises administrables.

Champs observes

Champs frontend et backend actuellement relies au domaine:

• id
• name
• type
• logo_id
• logoUrl
• FrontVersion
• maxOrganisations
• maxUsers
• environnement
• created_at
• updated_at

References:

• console/types/entities.ts
• back/src/enterprises/dto/enterprise.dto.ts

Regles metier

Visibilite

• un super-admin peut voir toutes les entreprises de type enterprise
• un administrateur ne peut voir que l'entreprise referencee par profile.enterprise_id
• un utilisateur ne peut pas appeler l'API de liste des entreprises

Important:

• une entreprise de type personal ne doit jamais apparaitre dans la liste des entreprises
• ces entreprises sont des faux tenants techniques utilises pour la gestion des comptes personnels
• si profile.enterprise_id pointe sur une entreprise personal, la liste retournee pour un administrateur doit etre vide

Implementation actuelle:

• back/src/enterprises/enterprises.service.ts

Tri et filtrage

• la liste doit etre triee par name
• la liste doit exclure les enregistrements dont type != 'enterprise'
• en particulier, les enregistrements type = 'personal' sont exclus par defaut

Filtrage par environnement (M2M)

Les applications tierces qui ont besoin des entreprises de leur propre environnement uniquement doivent utiliser l'endpoint dedie:

• GET /environments/:key/enterprises — retourne uniquement les entreprises rattachees a l'environnement key
• accessible via x-api-key avec scope enterprises:read (role super_admin)
• retourne 404 si la cle d'environnement est inconnue

Reference: Environments Domain

Logo d'entreprise

• seul un super-admin peut gerer le logo de n'importe quelle entreprise
• un administrateur ne peut gerer que le logo de sa propre entreprise
• les appels machine-to-machine sont autorises via x-api-key avec le scope enterprises:write
• le format accepte est PNG uniquement
• la limite de taille est 5 Mo
• le backend stocke uniquement logo_id en base
• l'API expose un logoUrl signe pour l'affichage

Endpoints:

• POST /enterprises/:id/logo
• DELETE /enterprises/:id/logo

Stockage:

• bucket Supabase Storage configurable via SUPABASE_ENTERPRISE_LOGOS_BUCKET
• valeur par defaut: enterprise-logos
• chemin calcule: <enterprise_id>/<logo_id>.png

Contexte d'entreprise courant

Le frontend maintient un contexte d'entreprise courant.

• pour un super-admin, ce contexte peut etre change dynamiquement
• pour un administrateur, l'entreprise de reference provient de profile.enterprise_id

Reference:

• console/composables/useEntrepriseContext.ts

Selection par un super-admin

Le super-admin peut changer l'entreprise courante en mettant a jour son profile.enterprise_id.

Impact:

• la selection d'entreprise n'est pas seulement un etat frontend
• elle est persistee via POST /profiles/me/enterprise
• les liaisons profiles_organisations et profiles_services du super-admin courant sont purgees au moment du changement
• cette route est reservee au bearer utilisateur super-admin
• les API keys ne peuvent pas appeler cette route

Objectif:

• repartir d'un contexte propre sur la nouvelle entreprise
• eviter toute fuite de rattachements residuels depuis l'entreprise precedente

Flux applicatifs

Lister les entreprises

Flux actuel:

1. le frontend recupere le token de session Supabase
2. le frontend appelle GET /enterprises sur le backend
3. le backend verifie le token
4. le backend charge profile et role
5. le backend retourne uniquement les entreprises de type enterprise visibles selon le role

Reference frontend:

• console/composables/useEntreprises.ts

Reference backend:

• back/src/enterprises/enterprises.controller.ts
• back/src/enterprises/enterprises.service.ts

Gerer un logo d'entreprise

Flux actuel:

1. le frontend ouvre la modale d'edition d'une entreprise
2. le frontend envoie le fichier PNG au backend via multipart/form-data
3. le backend verifie le role, le perimetre entreprise et le format
4. le backend charge ou remplace le fichier dans Supabase Storage
5. le backend met a jour enterprises.logo_id
6. l'API renvoie l'entreprise avec logoUrl signe

Charger une entreprise par identifiant

Etat actuel:

• le frontend appelle encore Supabase directement via fetchById()
• ce flux n'est pas encore migre vers back

Impact:

• il est normal d'observer encore des appels rest/v1/enterprises?id=eq.<id>

Decisions de conception

Pourquoi le backend filtre explicitement

La regle de visibilite est appliquee explicitement dans le service backend, meme si une partie des droits pourrait aussi etre exprimee via RLS.

Objectifs:

• rendre la regle lisible dans le code applicatif
• permettre des tests unitaires et d'integration precis
• eviter de faire reposer toute la comprehension metier sur des policies SQL

Pourquoi garder une migration progressive

Le domaine enterprises est migre pas a pas pour reduire le risque:

• d'abord la lecture de liste
• ensuite la lecture par identifiant
• ensuite les mutations

Cette approche permet de verifier chaque flux en condition reelle avant de migrer le suivant.

Risques connus

• certaines operations enterprise restent directes depuis le frontend vers Supabase
• le contexte d'entreprise courant cote frontend depend encore de fetchById() en direct
• il existe une dependance forte a profiles.enterprise_id pour le comportement des admins
• la creation, modification et suppression metier d'une entreprise ne sont pas encore migrees en backend, seul le logo l'est

Checklist de modification

Si une evolution touche le domaine enterprises, verifier:

• le role super-admin garde-t-il une vision globale ?
• le role administrateur reste-t-il borne a son enterprise_id ?
• les enregistrements de type personal restent-ils exclus ?
• le tri par name est-il preserve ?
• les tests unitaires et d'integration ont-ils ete adaptes ?