ADR-0005 — Le tenant est le groupe, pas l'entreprise

Statut	✅ Accepté — 2026-06-10
Portée	Modèle de domaine ActuaryLab (backend), sémantique du tenant Quantis vue du module
Décision	Le tenant Quantis correspond au périmètre client le plus large (groupe / conglomérat / incubateur) ; les entreprises (filiales, entités juridiques) sont des objets internes au domaine ActuaryLab, jamais des tenants distincts
Réf.	Vision — Trajectoires, mobilité groupe, émergence (étage 2) ; ADR-0003 (chaîne SSO)

🎯 À retenir

Le tenant Quantis = le périmètre client le plus large (groupe / conglomérat / incubateur, ou entreprise seule en cas dégénéré). Les entreprises sont des objets internes au domaine ActuaryLab, jamais des tenants distincts : une mutation intra-groupe reste un événement interne et l'isolation 404 cross-tenant est préservée. Aucune table n'est créée aujourd'hui (YAGNI) — l'ADR fixe la sémantique. Règle d'onboarding : un contrat-client = un tenant.

Contexte

La vision « mobilité groupe » (étage 2 de la note de vision) exige qu'un employé muté entre deux filiales d'un même groupe conserve ses droits (ancienneté IFC, avantages) : la mutation est un événement interne à son parcours, pas un changement de monde.

Or l'isolation tenant d'ActuaryLab est stricte par construction : toute ressource est scopée tenant_schema, et l'accès cross-tenant répond 404 (invariant couvert par les tests de persistance.py). Le modèle actuel (Tenant = tenant_schema Quantis, créé à la volée au premier SSO) ne dit rien de ce que le tenant représente métier : une entreprise ? un groupe ? L'ambiguïté était sans conséquence tant que les dossiers étaient des photos isolées ; elle devient structurante dès le Jalon 1 (vrais clients, vraies populations) :

• si tenant = entreprise, une mutation intra-groupe est un transfert cross-tenant — interdit par notre invariant d'isolation ; il faudrait soit percer l'isolation (dangereux), soit dupliquer l'employé (perte de la trajectoire et des droits) ;
• si tenant = groupe, la mutation est un événement interne au tenant, l'isolation reste intacte, et la portabilité des droits devient un problème de domaine, pas d'infrastructure.

Options considérées

• A — Tenant = groupe (périmètre client le plus large) : l'entité Entreprise naît dans le domaine ActuaryLab, rattachée au tenant ; un client mono-entreprise est le cas dégénéré (groupe à une seule entreprise).
• B — Tenant = entreprise : chaque filiale est un tenant ; la mobilité groupe exige un mécanisme de transfert cross-tenant.
• C — Ne pas trancher : laisser chaque déploiement décider.

Comparatif pour / contre

Critère	A — Tenant = groupe	B — Tenant = entreprise	C — Ambigu
Compatible isolation stricte (404 cross-tenant)	✅ mutation = interne	❌ exige de percer l'isolation	⚠️ indéterminé
Portabilité des droits (vision étage 2)	✅ problème de domaine	❌ problème d'infrastructure	❌ irrésolu
Cas client mono-entreprise	✅ cas dégénéré (groupe à 1)	✅ naturel	⚠️
Confidentialité inter-filiales d'un groupe	⚠️ à gérer en RBAC interne (personas, ADR-0003)	✅ par construction	⚠️
Facturation / contrat (1 client = 1 contrat)	✅ aligné (le contrat est signé par le groupe)	⚠️ N contrats ou mapping	⚠️
Coût aujourd'hui	✅ nul (sémantique seulement)	✅ nul	✅ nul

Le seul vrai prix de A : si deux filiales d'un même groupe ne doivent pas se voir, la séparation se fait par le RBAC du module (personas scopés entreprise, pattern sso_link de l'ADR-0003) et non par l'isolation tenant. C'est un contrôle d'accès plus fin à construire le jour venu — pas une faille, une responsabilité déplacée au bon étage.

Décision

Option A. Le tenant Quantis = le périmètre contractuel client le plus large (groupe, conglomérat, incubateur — ou entreprise seule, cas dégénéré). Conséquence de modélisation, le jour où le multi-entités devient réel : une entité Entreprise (rattachée au tenant) entre dans le domaine, et Dossier / les futurs événements de carrière s'y rattachent. Aucune table n'est créée aujourd'hui (YAGNI) : cet ADR fixe la sémantique pour que le Jalon 1 ne fige pas l'hypothèse inverse dans les données.

Conséquences

• Le Jalon 1 (upload RH) est conçu sous cette sémantique : un dossier appartient à un tenant-groupe ; le rattachement à une entreprise du groupe est une dimension interne (colonne ou entité future), pas un nouveau tenant.
• L'invariant d'isolation 404 cross-tenant est préservé tel quel — aucun mécanisme de transfert cross-tenant ne sera construit.
• La confidentialité inter-filiales, si un client l'exige, se traite par personas scopés entreprise (pattern ADR-0003), pas par multiplication des tenants.
• Côté socle Quantis : rien à changer techniquement (le socle ne connaît que des tenants) ; mais la règle d'onboarding commercial devient : un contrat-client = un tenant, jamais un tenant par filiale.

Déclencheur de réexamen (pré-enregistré)

Si un client exige une étanchéité réglementaire forte entre filiales (au-delà du RBAC : juridictions distinctes, régulateurs distincts, données non co-hébergeables), réexaminer — la réponse serait alors probablement deux contrats, deux tenants, en acceptant la perte de la trajectoire inter-filiales pour ce client.