Environments Domain

Definition

Un environment represente un contexte de deploiement auquel sont rattachees des entreprises et des applications.

Chaque environnement a une cle technique unique (key) qui sert d'identifiant stable dans les appels API.

Exemple: l'environnement Cloud a la cle default.

Schema Supabase

Table environments

Champ	Type	Description
id	uuid	Identifiant interne
key	text (unique)	Cle technique stable (ex: default)
name	text	Nom d'affichage (ex: Cloud)
type	shared | private	Mutualisé = plusieurs entreprises, Dédié = une seule
is_default	boolean	Environnement par defaut de la console

Table enterprise_environments

Table de liaison entre entreprises et environnements.

Champ	Type
enterprise_id	integer → enterprises.id
environment_id	uuid → environments.id

Contraintes:

• un environnement private ne peut contenir qu'une seule entreprise
• la cle composite (enterprise_id, environment_id) est unique

Table environment_applications

Table de liaison entre environnements et applications.

Champ	Type
environment_id	uuid → environments.id
application_id	uuid → applications.id

Regles metier

Acces

• seul un super-admin peut lister les entreprises d'un environnement
• les appels machine-to-machine sont autorises via x-api-key avec le scope enterprises:read
• un administrateur n'a pas acces a cet endpoint

Filtrage

• seules les entreprises de type = 'enterprise' sont retournees
• les comptes personnels (type = 'personal') sont toujours exclus

Environnement introuvable

Si la key passee en parametre ne correspond a aucun environnement en base, l'API retourne 404 Not Found.

Endpoint

GET /environments/:key/enterprises

Retourne la liste paginee des entreprises rattachees a un environnement.

Parametres path:

• key — cle technique de l'environnement (ex: default)

Parametres query:

• page — numero de page (defaut: 1)
• pageSize — taille de page, max 100 (defaut: 20)

Authentification:

• Bearer Supabase avec role super-admin
• x-api-key de type super_admin avec scope enterprises:read

Reponse 200:

{
  "items": [
    {
      "id": 1,
      "name": "Kalixys",
      "type": "enterprise",
      "logo_id": null,
      "logoUrl": null,
      "environnement": "shared",
      "created_at": "2026-01-01T00:00:00.000Z",
      "updated_at": "2026-01-01T00:00:00.000Z"
    }
  ],
  "page": 1,
  "pageSize": 20,
  "total": 3
}

Reponse 404 — si la cle d'environnement est inconnue.

Implementation:

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

Flux applicatif

Lister les entreprises d'un environnement (appel M2M)

Ce flux est concu pour les applications tierces (ex: Outil BDD) qui ont besoin de connaitre uniquement les entreprises de leur propre environnement.

1. L'application cliente appelle GET /environments/default/enterprises avec son x-api-key
2. Le backend verifie la cle API et le scope enterprises:read
3. Le backend resout l'environnement par sa key → 404 si inconnu
4. Le backend charge les enterprise_id de la table enterprise_environments
5. Le backend retourne les entreprises filtrees et paginées

Decisions de conception

Pourquoi un parametre key et non id

La key est stable et lisible dans les variables d'environnement applicatives (ex: CONSOLE_ADMIN_ENVIRONMENT_SLUG=default). Un UUID changerait si l'environnement etait recrée, alors que la key est contractuelle.

Pourquoi super-admin uniquement

Cet endpoint expose potentiellement la liste complete d'un environnement. Un administrateur n'a de visibilite que sur sa propre entreprise — lui permettre de voir les autres entreprises de son environnement sortirait du modele de role en place.

Pourquoi trois requetes sequentielles

Le service effectue trois requetes Supabase:

1. resoudre l'environnement par key → permet un 404 explicite si la cle est inconnue
2. charger les IDs entreprises de la table de liaison
3. charger les entreprises paginées par ces IDs

Une jointure imbriquee aurait rendu le 404 difficile a distinguer d'une liste vide.