Le multi-tenancy est la capacité d'un SaaS à servir plusieurs clients (tenants) depuis une seule instance, en garantissant que les données de chaque client restent isolées des autres. C'est l'un des sujets d'architecture les plus structurants d'un projet SaaS.
Le choix du modèle de tenancy a des implications sur la sécurité, les performances, les coûts d'infrastructure et la complexité de maintenance pour les années à venir.
Les trois modèles d'architecture multi-tenant
Shared database, shared schema : tous les tenants partagent la même base de données et les mêmes tables. L'isolation est assurée par une colonne `tenant_id` sur chaque table. C'est le modèle le moins coûteux mais qui exige une rigueur maximale dans le code pour éviter les fuites de données entre tenants.
Shared database, isolated schema : chaque tenant a son propre schéma dans la même base. Plus d'isolation, mais des coûts de gestion de schémas qui augmentent avec le nombre de tenants.
Database per tenant : chaque tenant a sa propre base de données. Isolation maximale, mais coûts d'infrastructure qui croissent linéairement avec le nombre de tenants. Adapté aux clients enterprise avec des exigences contractuelles fortes.
Sécurité : éviter les fuites de données inter-tenant
Dans un modèle shared schema, chaque requête à la base de données doit filtrer par `tenant_id`. La mise en place d'un middleware qui injecte automatiquement ce filtre sur toutes les requêtes (Row Level Security sous PostgreSQL, ou middleware applicatif) est la protection principale contre les fuites accidentelles.
Les tests de sécurité multi-tenant doivent vérifier explicitement qu'un utilisateur d'un tenant ne peut jamais accéder aux données d'un autre tenant, même en manipulant les paramètres de requête.
Onboarding et provisioning d'un nouveau tenant
Le processus de création d'un nouveau tenant doit être automatisé : inscription, création de l'espace tenant, configuration initiale, envoi des emails de bienvenue, et démarrage de l'essai ou de l'abonnement. Ce processus doit fonctionner sans intervention manuelle dès la v1.
En modèle isolated schema ou database per tenant, la création automatisée du schéma ou de la base inclut l'exécution des migrations initiales. Ce processus doit être idempotent et gérer les erreurs proprement.
Performances dans un contexte multi-tenant
Dans un modèle shared schema, les index sur `tenant_id` + les colonnes de filtrage courantes sont critiques pour les performances. Une requête qui ne filtre pas par `tenant_id` en premier peut scanner toute la table sur un SaaS avec des milliers de tenants.
La surveillance des slow queries par tenant permet d'identifier les tenants dont le volume de données est disproportionné et qui impactent les performances des autres. Un plan de quotas ou de migration vers un schéma isolé peut être nécessaire pour ces cas extrêmes.