ADR-0004 - Multi-établissements par « scope » applicatif
- Statut : ✅ Accepté (état de fait)
- Date : 2026-07-10 (constat)
- Tags : architecture, métier, cloisonnement
Contexte
Le réseau regroupe plusieurs sociétés (entities, avec SIRET) et
établissements/boutiques (locations), regroupés par ville (Paris,
Bordeaux, Lyon) via CITY_CONFIG (rapprochement par mots-clés sur le nom/adresse).
Chaque manager ne doit voir que son périmètre.
Décision
Modéliser le périmètre d'un compte par deux colonnes sur app_users :
scope_type ∈ {city, entity, location} et scope_id. Le filtrage est calculé
côté client (visibleEmployees, isEmployeeInScope, scopeLabel), et la ville
est devinée par correspondance textuelle (getLocationCity) plutôt que par
une clé étrangère.
Conséquences
Positives
- Souplesse : un manager peut être rattaché à une ville, une société ou une boutique.
- Regroupement par ville pratique pour le planning multi-sociétés.
Négatives / compromis
- Ville non normalisée : dépend de mots-clés (
paris,temple,kobike…) dans le nom/adresse → fragile, non fiable si un libellé change. - Le périmètre n'est pas appliqué en base (cf. ADR-0003) : cloisonnement purement visuel.
scope_type/scope_idabsents de la migrationsupabase-schema.sql(dérive de schéma).
Risques & dette induite
- Ajout d'une ville = modifier le code (
CITY_CONFIG) au lieu d'une donnée.
Alternatives envisagées
| Option | Avantages | Inconvénients | Retenue ? |
|---|---|---|---|
Table cities + locations.city_id (FK) |
Fiable, éditable sans déploiement | Migration + UI | ⏳ recommandé |
| Scope par mots-clés (actuel) | Zéro migration | Fragile | ✅ (temporaire) |
Décision cible (proposée)
Introduire une vraie entité city (ou un champ locations.city), versionner
scope_type/scope_id, et appliquer le périmètre dans les policies RLS.
Références
gestionrh-github/src/App.jsx:CITY_CONFIG,getLocationCity,visibleEmployees,scopeLabelsupabase-schema.sql(colonnesscope_*manquantes)