Locataires, hôte et filtre de données
ToRun repose sur le modèle multi-locataire d'ABP Framework. Une ligne marquée IsMultiTenant possède une colonne TenantId que le framework filtre automatiquement ; les requêtes exécutées dans le contexte d'un locataire ne voient jamais les lignes d'un autre. Le contexte hôte (TenantId == null) voit une tranche distincte : c'est là que vivent les catalogues canoniques comme SubscriptionPlan, AiProvider et LegalDocument.
Pourquoi nous traitons l'hôte comme un participant à part entière
La plupart des produits SaaS ajoutent l'hôte sous forme d'« outils d'administration ». Nous le modélisons comme un locataire frère : l'hôte a ses propres tableaux de bord, ses propres politiques d'IA et ses propres relations de facturation. Cela nous permet de faire tourner notre propre trafic de production sur les mêmes briques que celles qu'utilise chaque client.
Fonctionnalités liées au plan par locataire
Les plans d'abonnement portent des lignes FeatureLimit, Entitlement, Capability et Mode. Quand un locataire active un plan, l'ensemble des fonctionnalités auxquelles il a accès est l'intersection entre son plan et le catalogue global. Ajouter un nouveau mode n'oblige pas à toucher chaque locataire : il le reçoit automatiquement si le plan qu'il possède l'inclut.
Injection du BYOK à chaque appel
Même avec une infrastructure partagée, les identifiants BYOK restent limités au locataire qui les possède. Chaque requête d'IA résout les identifiants dans le contexte du locataire avec le même filtre de données ; les fuites de clés entre locataires sont impossibles au niveau du stockage.
Ce que nous ne faisons volontairement pas
Nous n'isolons pas les locataires au niveau de la base de données ou du processus. Le coût de la montée en charge d'une base par locataire ruine l'économie unitaire d'un produit SaaS multi-locataire. Le filtre de données associé à un cache cloisonné par locataire suffit quand le schéma est conçu pour cela dès le premier jour.