Garder un modèle multi-tenant cohérent
L'identité, les droits, les données et les horaires doivent rester cohérents à travers les cas d'usage, sans laisser les raccourcis locaux créer un second modèle concurrent.
Emovanti : décider l'architecture d'un SaaS multi-tenant avant la bêta
Ce projet interne formalise les décisions d'architecture et de produit d'Emovanti, un SaaS multi-tenant dont les environnements de pré-production sont déployés et dont la bêta est en préparation, sans utilisateurs en production.
L'objectif n'est pas de documenter des choix après coup : c'est de rendre explicites les règles qui protègent l'identité, les données, les droits et le temps avant que le produit ne grandisse.
Décider avant que les conventions ne deviennent des contraintes
Dans un SaaS multi-tenant, une approximation sur l'identité, l'autorité ou la localisation des données devient vite une dette de produit. Les décisions servent ici de contrat entre le domaine, la plateforme et les futurs changements.
Le problème à résoudre
Des décisions qui protègent les frontières du produit
Chaque choix fixe une règle lisible par le produit et l'ingénierie, plutôt qu'une convention implicite cachée dans une table ou un écran.
Une identité de référence par flotte
Le véhicule de référence appartient au tenant flotte qui le possède. VIN et immatriculation servent de signaux de rapprochement, jamais de clés globales ; un second modèle de véhicule qui se chevauchait est retiré.
Trois mécanismes pour trois lectures
Logs, piste d'audit et chronologie d'acteur ont des propriétaires et lecteurs distincts. La chronologie orientée produit ne consulte jamais les lignes brutes d'audit.
Rétention et résidence décidées par domaine
Chaque catégorie de données a sa durée de conservation cible, avec une archive d'audit. Une flotte choisit sa zone selon son marché à sa création, sans changement implicite, et ses fichiers suivent cette zone ; tous les marchés mappent vers l'Europe au lancement.
Plans, droits et temps sous une règle unique
Une seule notion de flotte porte le plan et ses capacités via un résolveur de droits unique ; sans abonnement, le plan est Free. Les instants sont stockés et comparés en UTC, les autorités d'affectation sont des intervalles semi-ouverts, et l'affichage utilise le fuseau de l'utilisateur ou de la flotte.
Un registre pour relier les décisions au produit
Les ADRs et le registre daté évitent que les règles critiques dépendent d'une mémoire individuelle. Ils donnent un point de départ pour challenger une décision, expliquer une contrainte et faire évoluer le produit sans défaire ses frontières.
Décider, puis rendre la règle exploitable
Les décisions couvrent l'identité de référence, la lecture des traces, la conservation, la résidence, les droits et les instants d'autorité : des règles qui gardent les cas d'usage cohérents quand ils se croisent.
Les repères publiés
Ils décrivent la discipline de décision du produit, pas une promesse de disponibilité ou de scale.
- ADRs
- 29 décisions d'architecture.
- Registre
- 112 décisions produit datées.
- Identité
- Une référence véhicule, tenant par tenant.
- Temps
- UTC pour décider, fuseau utilisateur ou flotte pour afficher.
Ce que cette étude établit
Un SaaS multi-tenant tient mieux lorsque ses invariants de domaine deviennent des décisions écrites, testables et compréhensibles avant la montée en charge.
Rendre les invariants de produit explicites avant de les multiplier dans le code.
Un modèle de référence, une règle d'autorité et une lecture adaptée à chaque public évitent qu'un produit ajoute des exceptions au moment où il devrait préserver ses frontières.