Concepts clés

Le modèle à deux niveaux

┌─────────────────────────────────────────────────┐
│  Plateforme SaaSes                              │
│                                                 │
│  ┌───────────────────────────────────────────┐  │
│  │  Organisation  (votre compte SaaSes)      │  │
│  │  ex. "Algosoft"                           │  │
│  │                                           │  │
│  │  ┌────────────┐    ┌────────────┐         │  │
│  │  │ App: CRS   │    │ App: Staff │         │  │
│  │  │  Plans     │    │  Plans     │         │  │
│  │  │  ────────  │    │  ────────  │         │  │
│  │  │  Tenants   │    │  Tenants   │         │  │
│  │  │ (casaride) │    │  (acme)    │         │  │
│  │  └────────────┘    └────────────┘         │  │
│  └───────────────────────────────────────────┘  │
└─────────────────────────────────────────────────┘

Les six termes à retenir

Organisation

Votre équipe ou votre entreprise. C'est le compte qui souscrit à SaaSes lui-même. Chaque donnée stockée dans SaaSes appartient à une Organisation.

OrganizationMember

Un utilisateur qui peut accéder à votre Organisation (votre équipe interne). Identifié par email. Un même email peut appartenir à plusieurs Organisations avec des rôles différents.

Application

Un produit SaaS que vous éditez et que vous enregistrez dans SaaSes. Une Application possède sa propre clé API, son modèle de tenancy, et sa propre liste de plans.

Plan

Un tarif d'une Application : nom, prix, fréquence de facturation, plus deux objets JSON opaques — quotas et features — que votre application interprète.

ManagedTenant (Tenant géré)

Un client de votre SaaS — typiquement une autre entreprise. SaaSes n'impose aucun champ métier ; vous pouvez stocker des métadonnées libres en JSON.

TenantApplicationSubscription (TAS)

L'enregistrement central qui lie un Tenant à une Application sous un Plan. Chaque TAS a son propre cycle de vie (essai, actif, suspendu, annulé), sa propre configuration de routage, et éventuellement des overrides de quota.

Modèles de tenancy

Quand vous enregistrez une Application, vous déclarez comment elle reconnaît un tenant à l'exécution. SaaSes valide alors la forme du routingConfig à chaque écriture, et vous renvoie un objet typé via l'API de résolution.

• TENANT_ID_SINGLE_DB — Un identifiant tenant porté en claim ou en header. Une seule base avec colonne tenant_id par ligne.
• SUBDOMAIN_SINGLE_DB — Sous-domaine HTTP (acme.app.com) avec une seule base et isolation par colonne.
• SUBDOMAIN_MULTI_DB — Sous-domaine, mais une base par tenant. Le routingConfig contient les credentials chiffrés.
• PATH_PARAM — Un segment d'URL (/t/{tenantId}/...).
• HEADER — Un header HTTP custom (par ex. X-Tenant-ID).

Quotas et features sont opaques

SaaSes ne sait pas ce que signifie maxVehicles ou advancedReports. Ces clés sont vos clés. SaaSes :

• Stocke les valeurs au niveau du Plan et au niveau du TAS (pour les overrides).
• Fusionne plan.quotas + tas.quotaOverrides au moment de la résolution.
• Renvoie le résultat tel quel dans effectiveQuotas.

L'application est responsable de lire ces valeurs et d'appliquer la règle métier — par exemple bloquer une création quand currentVehicles >= maxVehicles.