Définition technique
Architecture logicielle où une seule instance d’application sert plusieurs clients (tenants) : chaque client perçoit un espace dédié (données, paramètres, marque) tout en partageant la même infrastructure et le même code. Typique des SaaS : un produit, des milliers de clients sans déployer une instance par client. Les modèles vont du partage total (même base de données, isolation par identifiant tenant) au partage partiel (schéma ou base par tenant). Les enjeux : isolation des données, performance, facturation et personnalisation par tenant.
Comment ça fonctionne ?
Chaque requête est associée à un tenant (via sous-domaine, header, token). L’application filtre toutes les requêtes (lecture, écriture) par cet identifiant. Les données sont soit dans des tables partagées avec une colonne tenant_id, soit dans des bases ou schémas dédiés par tenant.
L'erreur classique à éviter
Oublier de filtrer une requête par tenant (fuite de données entre clients). Surcharger une base partagée sans stratégie de sharding ou de séparation. Mélanger des données sensibles de tenants dans les logs ou le cache.
Impact business : pourquoi s'en soucier ?
Le multitenant est la base économique du SaaS : coûts d’infrastructure et de déploiement partagés, mises à jour déployées une fois pour tous. Pour une entreprise qui lance un SaaS, le choix du modèle (DB partagée vs base par client) impacte la scalabilité, la conformité (RGPD, données par pays) et la complexité. Un bon multitenant permet de grandir sans multiplier les serveurs et les maintenances.
La règle d'or
Toujours filtrer par tenant_id (ou équivalent) au niveau requête. Tester l’isolation (tentative d’accès cross-tenant). Documenter le modèle (shared DB, schema per tenant, DB per tenant) et les critères de choix.