Project Overview

Objectif

console-admin est une console d'administration pour gerer des entreprises, leurs etablissements, services, utilisateurs, roles, applications et environnements.

Le projet est en transition d'un modele ou le frontend parlait directement a Supabase vers un modele hybride:

• front conserve l'authentification utilisateur via Supabase
• back devient la couche d'API metier, de controle d'acces et d'orchestration
• Supabase reste la source de verite pour l'authentification et les donnees

Dossiers

• front/: application Nuxt 3
• back/: API NestJS
• docs/: documentation projet, architecture et metier

Flux cible

1. l'utilisateur se connecte dans front via Supabase Auth
2. front recupere le access_token de session
3. front appelle back avec Authorization: Bearer <token>
4. back verifie le token, charge profiles et roles
5. back applique les regles metier et appelle Supabase si necessaire

Un second flux d'acces existe maintenant pour les integrations machine-to-machine:

1. un super-admin cree une API key dans la console
2. la cle est stockee cote backend sous forme de hash HMAC
3. le client technique appelle back avec x-api-key
4. back charge les metadonnees de la cle, verifie expiration/revocation et applique les scopes

Roles applicatifs observes

• super-admin
• administrateur
• utilisateur

Seuls super-admin et administrateur ont actuellement acces a la console.

API keys

Le projet supporte maintenant des API keys pour des acces machine-to-machine.

Modele retenu:

• une cle est creee uniquement par un super-admin
• une cle porte un access_level
• super_admin donne un perimetre global
• enterprise_admin donne un perimetre limite a une entreprise
• les permissions techniques sont portees par des scopes

Type de cle	Perimetre	Entreprise requise	Exemple d'usage
super_admin	Global	Non	Synchronisation transverse
enterprise_admin	Une seule entreprise	Oui	Integration entreprise dediee

V1 actuellement en place:

• table public.api_keys
• table public.api_key_usage_logs
• expiration optionnelle
• revocation manuelle
• audit minimal d'usage
• historique detaille des usages consultable par super-admin
• scope backend expose: enterprises:read

Flux simplifie:

Super-admin
  -> cree une API key dans la console
  -> transmet la cle au client technique
  -> le client appelle le backend avec x-api-key
  -> le backend controle scope + perimetre + statut de la cle
  -> l'usage est journalise

Etat actuel de la migration

• l'authentification frontend est encore geree via Supabase client
• la route backend GET /enterprises existe et est consommee par le frontend pour la liste des entreprises
• certaines operations entreprises restent encore en acces direct Supabase dans le frontend, notamment fetchById, create, update, remove