Multi-tenant
Définition
Architecture SaaS où plusieurs entreprises clientes partagent la même infrastructure, avec des données strictement isolées entre elles. Modèle classique pour un SaaS B2B.
Comment ça marche
Une architecture multi-tenant héberge plusieurs entreprises clientes (les tenants) sur la même infrastructure et la même base de données, avec une isolation stricte des données. Concrètement, chaque table contient une colonne organization_id ou tenant_id qui identifie le propriétaire de la ligne. Toutes les requêtes filtrent obligatoirement sur cette colonne, de sorte que le client A ne voit jamais les données du client B. L'isolation peut se faire au niveau applicatif (code qui ajoute le filtre partout) ou au niveau base via la Row Level Security (le filtre est imposé par PostgreSQL, indépendamment du code).
À quoi ça sert
Le multi-tenant est le modèle économique standard des SaaS B2B. Slack, Notion, HubSpot, Linear, Intercom fonctionnent tous ainsi : une seule application, des milliers d'organisations clientes. Le bénéfice est massif : un seul code à maintenir, une seule base à sauvegarder, des mises à jour appliquées à tout le monde simultanément. Le coût marginal d'un nouveau client est proche de zéro, ce qui rend possible des marges très élevées à partir d'un certain volume. C'est la condition pour qu'un SaaS scale économiquement.
Les modèles d'isolation
Trois approches existent. Tenant partagé en colonnes : tous les tenants dans les mêmes tables, filtrage par tenant_id. C'est le modèle Supabase/PostgreSQL standard, le plus efficient en ressources. Tenant par schéma : un schéma SQL par client dans la même base, isolation plus stricte au prix d'une complexité de migration. Tenant par base : une base de données entière par client, isolation maximale mais coûts et opérations multipliés. Pour 99% des SaaS, le modèle en colonnes avec RLS suffit. Les autres approches se justifient uniquement pour les contraintes réglementaires extrêmes.
Le rôle de la RLS
La Row Level Security de PostgreSQL est l'outil parfait pour le multi-tenant en colonnes. On définit une policy SQL ("un utilisateur ne voit que les lignes où organization_id correspond à son organisation") et la base l'applique automatiquement à toutes les requêtes, indépendamment du code applicatif. Plus besoin de filtrer manuellement à 50 endroits différents : la base est le garde-fou. C'est ce qui rend Supabase si efficace pour les SaaS multi-tenant : on écrit moins de code, on a moins de bugs de sécurité, et l'isolation est garantie au niveau le plus profond.
Les défis
Quelques défis spécifiques au multi-tenant. Le noisy neighbor : un client qui fait des requêtes énormes ralentit les autres. On l'atténue avec des limites par tenant (rate limiting, quotas de requêtes) et un monitoring fin par client. Les sauvegardes par client : si un client demande la suppression complète RGPD, il faut savoir extraire ses données et les supprimer sans toucher aux autres. La facturation usage-based : compter précisément ce que chaque client consomme (requêtes, stockage, IA) demande une instrumentation côté code, dès le départ. Et les exports : permettre à un client de récupérer toutes ses données dans un format portable.
Quand l'utiliser
Multi-tenant est le bon défaut pour tout SaaS B2B : Notion, Linear, Slack n'auraient pas existé autrement. On le choisit dès la conception, on ne le rajoute pas après. Pour un produit B2C grand public à très fort volume (réseau social, jeu mobile), c'est aussi le modèle standard. Pour des produits avec contraintes réglementaires fortes (santé HDS, défense), on peut combiner multi-tenant général avec instances dédiées pour les clients les plus exigeants. Pour un outil interne ou un produit pour un seul client, le multi-tenant ajoute de la complexité sans bénéfice.
Les pièges à éviter
Le piège majeur : une fuite de données entre tenants. Une seule requête mal filtrée, un seul JOIN qui oublie le tenant_id, et un client voit les données d'un autre. Catastrophique pour la confiance. On l'évite avec RLS au niveau base + tests d'intégration qui valident systématiquement l'isolation. Autre piège : ne pas anticiper les exports et suppressions RGPD. On les conçoit dès le départ, pas à la première demande client. Et on évite à tout prix les configurations spécifiques par tenant dans le code : le code reste générique, la personnalisation vit en données, paramétrable par tenant via la base.