Multi-tenancy SaaS : isolez vos clients sans multiplier vos coûts infra
Une architecture mono-tenant par client (le modèle silo) vous coûte beaucoup plus cher en infra que le multi-tenant. Mais un multi-tenant mal conçu peut exposer les données d'un client a un autre — un incident catastrophique en B2B. Nehos conçoit des architectures multi-tenant avec RLS Postgres, schemas par tenant et tenant context middleware qui offrent les deux : isolation garantie et efficacité infra.
Nos clients types
La question du multi-tenancy est l'une des plus structurantes dans l'architecture d'un SaaS B2B — et l'une des plus souvent mal adressées. Les equipes fondatrices commencent généralement avec un modèle simple et expéditif : une database par client (le modèle silo). C'est simple a implementer, facile a expliquer aux clients ('vos données sont sur votre propre base de données'), et rassegurant sur la question de l'isolation. Sauf qu'a partir de 20 à 50 clients, ce modèle devient un cauchemar opérationnel et économique. Les coûts d'infrastructure explosent lineairement avec le nombre de clients. Chaque nouvelle database requiert son propre provisionnement, sa propre sauvegarde, son propre monitoring, ses propres migrations. Sur AWS RDS ou sur GCP Cloud SQL, une instance database par client représente un coût fixe par client, quelle que soit sa taille. Pour plusieurs centaines de clients, ce sont des coûts database considérables avant même de compter le compute. La plupart de ces instances fonctionnent à une faible part de leur capacité — un gaspillage massif. Les migrations de schema deviennent le cauchemar du CTO. Chaque modification du schema (ajout d'une colonne, modification d'un index, creation d'une table) doit être exécutée sur chaque database indépendamment. Un pipeline de migration sur des centaines de databases prend des heures, les échecs partiels créent des états incohérents entre clients, et les rollbacks sont exponentiellement plus complexes. Les equipes qui ont vécu cette réalité témoignent : au-delà d'un certain nombre de clients en mode silo, les cycles de release ralentissent significativement a cause de la complexity des migrations. La complexité opérationnelle du monitoring s'agrege également. Surveiller des centaines d'instances de database indépendantes requiert des outils et une configuration qui ne passent pas à l'échelle simplement. Les alertes se multiplient, les faux positifs augmentent, et la détection d'incidents cross-tenant devient un exercice complexe. Sans compter que les sauvegardes de centaines de databases indépendantes représentent des coûts de stockage et des procedures de restauration qui ne simplifient pas les PRA (Plans de Reprise d'Activité). Du cote du client enterprise, la conversation sur la certification SOC2 Type II ou ISO 27001 met souvent en evidence les lacunes du modèle silo : absence de procedures de rotation des credentials automatisées, logging insuffisant des accès aux données, absence de controle d'accès granulaire au niveau des tables. Ces certifications — requises par de nombreux clients grands comptes — nécessitent une architecture qui supporte nativement les controles d'accès, les audit logs et la separation des environnements. Enfin, les equipes engineering sous-estiment systématiquement le risque de regression lors des migrations sur le modèle silo. Une migration mal conçue qui casse l'accès aux données d'une partie des clients est un incident majeur. La meme migration sur un modèle multi-tenant partage peut être testee sur un sous-ensemble de tenants en production (canary deployment) avant d'être généralisée — une capacité qui n'existe pas simplement en mode silo.
La conception de l'architecture multi-tenant par Nehos commence par un atelier de 2 jours avec le CTO et l'equipe engineering pour qualifier les exigences : nombre de tenants actuels et projetés a 24 mois, volume de données par tenant, exigences de conformité (SOC2 Type II, ISO 27001, RGPD, HDS selon le secteur), performance attendue (p99 latency), et contraintes de customisation par tenant (features flags, limites de quota, themes UI).
Pour la majorité des SaaS B2B avec des dizaines à des milliers de tenants et des exigences SOC2, le modèle recommande par Nehos est le schema Postgres par tenant, combine avec la RLS au niveau de la database partagée. Concrètement : chaque tenant dispose de son propre schema Postgres (tenant_abc, tenant_xyz) dans une database mutualisée. Toutes les tables critiques (contenant des données client) ont un policy RLS qui restreint les requêtes au schema courant. Le middleware applicatif (en Node.js, Go ou Python selon la stack) résout le tenant à partir de chaque requête entrante (sous-domaine, JWT claim tenant_id, API key), et execute un SET search_path avant chaque transaction.
La resolution du tenant est la couche la plus critique — et la plus sensible aux bugs. Nehos implemente une approche en defense profonde : le tenant est résolu dans le middleware d'authentification, stocke dans le contexte de la requête (AsyncLocalStorage en Node.js), injecte dans chaque connexion du pool de connexions (PgBouncer en mode transaction mode), et verifie une seconde fois dans une couche repository avant chaque accès aux données. Les tests d'isolation automatises — qui tentent des accès cross-tenant et vérifient qu'ils sont bloques — sont executes en CI sur chaque PR.
La gestion des migrations est le second chantier critique. Nehos met en place un pipeline de migration tenant-aware base sur Flyway ou Liquibase : les migrations sont exécutées schema par schema, avec retry automatique sur échec, logging detaille par tenant, et possibilité de cibler un sous-ensemble de tenants pour les migrations a risque. Le pattern expand-contract est applique pour les zero-downtime migrations : la nouvelle colonne est ajoutée (expand) avant que le code soit déployé, et l'ancienne est supprimée (contract) une fois l'adoption confirmée.
Le monitoring par tenant est mis en place avec Datadog ou Grafana : chaque requête SQL est taguee avec le tenant_id dans les traces APM (OpenTelemetry), ce qui permet d'identifier immédiatement les tenants qui consomment anormalement des ressources, de detecter des requêtes N+1 spécifiques a un tenant, et de calculer le coût infra par tenant pour la facturation (usage-based pricing). PgBouncer est configure en mode transaction pooling avec routing tenant-aware pour optimiser l'utilisation des connexions Postgres.
Le provisionning de nouveaux tenants est automatise via un pipeline idempotent : creation du schema Postgres, execution des migrations initiales, creation de l'utilisateur admin, configuration des feature flags par défaut, envoi de l'email de bienvenue. Ce pipeline s'execute en moins de 3 minutes — contre 2 heures en mode silo. Il est expose via une API interne utilisée par le self-service d'inscription et par l'equipe sales pour le provisionning manuel des comptes enterprise.
Pour les clients qui requièrent une isolation maximale (secteur santé avec HDS, defense, services financiers critiques), Nehos peut implementer le modèle database-par-tenant — mais avec un overlay d'infrastructure-as-code (Terraform + Pulumi) qui automatise le provisionnement et la gestion des instances et réduit le surcoût opérationnel du silo a un niveau acceptable.
À mesurer
coût d'infrastructure database après migration d'un modèle silo vers un modèle schemas Postgres par tenant, comparé à la situation de départ
À mesurer
temps pour provisionner un nouveau tenant (création du schéma Postgres, migrations, configuration) après automatisation du pipeline, comparé au mode silo
0 visé
incidents d'isolation cross-tenant en production : modèle schemas Postgres + RLS + middleware applicatif + tests CI automatisés
À mesurer
comptes enterprise avec exigences SOC2 hébergés sur la même infrastructure multi-tenant à schemas Postgres, avec audit logs par tenant
#Le problème : pourquoi architecture multi-tenant est un enjeu critique
Le constat : La question du multi-tenancy est l'une des plus structurantes dans l'architecture d'un SaaS B2B — et l'une des plus souvent mal adressées. Les equipes fondatrices commencent généralement avec un modèle simple et expéditif : une database par client (le modèle silo). C'est simple a implementer, facile a expliquer aux clients ('vos données sont sur votre propre base de données'), et rassegurant sur la question de l'isolation. Sauf qu'a partir de 20 à 50 clients, ce modèle devient un cauchemar opérationnel et économique.
Les coûts d'infrastructure explosent lineairement avec le nombre de clients. Chaque nouvelle database requiert son propre provisionnement, sa propre sauvegarde, son propre monitoring, ses propres migrations. Sur AWS RDS ou sur GCP Cloud SQL, une instance database par client représente un coût fixe par client, quelle que soit sa taille.
Pour plusieurs centaines de clients, ce sont des coûts database considérables avant même de compter le compute. La plupart de ces instances fonctionnent à une faible part de leur capacité — un gaspillage massif.
Les migrations de schema deviennent le cauchemar du CTO. Chaque modification du schema (ajout d'une colonne, modification d'un index, creation d'une table) doit être exécutée sur chaque database indépendamment. Un pipeline de migration sur des centaines de databases prend des heures, les échecs partiels créent des états incohérents entre clients, et les rollbacks sont exponentiellement plus complexes.
Les equipes qui ont vécu cette réalité témoignent : au-delà d'un certain nombre de clients en mode silo, les cycles de release ralentissent significativement a cause de la complexity des migrations.
La complexité opérationnelle du monitoring s'agrege également. Surveiller des centaines d'instances de database indépendantes requiert des outils et une configuration qui ne passent pas à l'échelle simplement. Les alertes se multiplient, les faux positifs augmentent, et la détection d'incidents cross-tenant devient un exercice complexe.
Sans compter que les sauvegardes de centaines de databases indépendantes représentent des coûts de stockage et des procedures de restauration qui ne simplifient pas les PRA (Plans de Reprise d'Activité).
Du cote du client enterprise, la conversation sur la certification SOC2 Type II ou ISO 27001 met souvent en evidence les lacunes du modèle silo : absence de procedures de rotation des credentials automatisées, logging insuffisant des accès aux données, absence de controle d'accès granulaire au niveau des tables.
Ces certifications — requises par de nombreux clients grands comptes — nécessitent une architecture qui supporte nativement les controles d'accès, les audit logs et la separation des environnements.
Enfin, les equipes engineering sous-estiment systématiquement le risque de regression lors des migrations sur le modèle silo. Une migration mal conçue qui casse l'accès aux données d'une partie des clients est un incident majeur. La meme migration sur un modèle multi-tenant partage peut être testee sur un sous-ensemble de tenants en production (canary deployment) avant d'être généralisée — une capacité qui n'existe pas simplement en mode silo.
Pour approfondir ce sujet, consultez notre page architecture multi-tenant SaaS conception.
#Notre approche en 4 phases
La conception de l'architecture multi-tenant par Nehos commence par un atelier de 2 jours avec le CTO et l'equipe engineering pour qualifier les exigences : nombre de tenants actuels et projetés a 24 mois, volume de données par tenant, exigences de conformité (SOC2 Type II, ISO 27001, RGPD, HDS selon le secteur), performance attendue (p99 latency), et contraintes de customisation par tenant (features flags, limites de quota, themes UI).
Pour la majorité des SaaS B2B avec des dizaines à des milliers de tenants et des exigences SOC2, le modèle recommande par Nehos est le schema Postgres par tenant, combine avec la RLS au niveau de la database partagée. Concrètement : chaque tenant dispose de son propre schema Postgres (tenant_abc, tenant_xyz) dans une database mutualisée.
#Phase 1 — Choix du modèle de multi-tenancy (semaines 1-2)
Analyse des contraintes : nombre de tenants, exigences d'isolation (SOC2, ISO 27001, exigences client grand compte), volume de données par tenant, budget infra. Choix du modèle : shared database + RLS (optimal pour <10 000 tenants, isolation logique), schemas Postgres par tenant (isolation renforcée, migration par tenant), database par tenant (isolation maximale, coût eleve). Decision documentée avec les trade-offs.
#Phase 2 — Implementation Postgres RLS et tenant context (semaines 3-7)
Mise en place du tenant_id dans toutes les tables. Policies RLS Postgres : CREATE POLICY isolate_tenant ON orders USING (tenant_id = current_setting('app.tenant_id')). Middleware tenant context en Node.js/Python : resolution du tenant (sous-domaine, JWT claim, API key), injection du SET app.tenant_id dans chaque connexion de pool. Tests d'isolation : tentatives de cross-tenant data access bloquées.
Point clé : Le middleware applicatif (en Node.js, Go ou Python selon la stack) résout le tenant à partir de chaque requête entrante (sous-domaine, JWT claim tenant_id, API key), et execute un SET search_path avant chaque transaction.
#Phase 3 — Gestion des migrations et du schema evolution (semaines 8-10)
Pipeline de migration tenant-aware : Flyway ou Liquibase avec exécution séquentielle par schema/tenant. Strategies de zero-downtime migration (expand-contract pattern). Gestion des migrations d'urgence sur un sous-ensemble de tenants. Tests de regression post-migration automatises.
#Phase 4 — Scaling, monitoring et customisation par tenant (semaines 11-12)
Connection pooling avec PgBouncer (tenant-aware routing). Monitoring par tenant : métriques d'usage, alertes sur les tenants anormaux (pic de requêtes, volume inhabituels). Customisation par tenant : feature flags, limites de quota, themes UI. Onboarding tenant automatise (provisionning, migration initiale, configuration).
Point clé : Nehos implemente une approche en defense profonde : le tenant est résolu dans le middleware d'authentification, stocke dans le contexte de la requête (AsyncLocalStorage en Node.js), injecte dans chaque connexion du pool de connexions (PgBouncer en mode transaction mode), et verifie une seconde fois dans une couche repository avant chaque accès aux données.
On s'appuie sur notre guide SOC2 Type II pour SaaS B2B pour cadrer chaque étape.
#Ce qu'on mesure
Nous ne publions pas de chiffres de résultats pour ce type de projet : chaque contexte est différent. Voici les indicateurs qu'on met en place dès le pilote pour décider, chiffres réels à l'appui, d'aller plus loin ou non.
| Indicateur | Ce qu'on regarde |
|---|---|
| Coût database | coût d'infrastructure database après migration d'un modèle silo vers un modèle schemas Postgres par tenant, comparé à la situation de départ |
| Provisionnement d'un tenant | temps pour provisionner un nouveau tenant (création du schéma Postgres, migrations, configuration) après automatisation du pipeline, comparé au mode silo |
| Incidents d'isolation | incidents d'isolation cross-tenant en production : modèle schemas Postgres + RLS + middleware applicatif + tests CI automatisés |
| Comptes enterprise | comptes enterprise avec exigences SOC2 hébergés sur la même infrastructure multi-tenant à schemas Postgres, avec audit logs par tenant |
#Exemple de situation : SaaS B2B de gestion de projets
Ce n'est pas une référence client : c'est une situation type, telle que nous la rencontrons dans ce secteur.
#Contexte
Un SaaS B2B de gestion de projets pour la construction et l'immobilier, avec plusieurs centaines de clients PME et ETI, en architecture silo initiale : une instance RDS indépendante par client. Les migrations de schéma doivent être exécutées sur chaque instance et échouent partiellement de façon récurrente. L'onboarding d'un nouveau client est long. La certification SOC2 Type II est en cours, bloquée par les lacunes du modèle silo. L'équipe tech est restreinte.
#Le défi
Migrer les clients d'un modèle silo vers un modèle multi-tenant partagé sans aucune interruption de service, réduire significativement les coûts d'infrastructure database et débloquer la certification SOC2 Type II, exigée par des prospects grands comptes. Contrainte : la migration doit être transparente pour les clients, sans downtime accepté.
#Solution envisagée
Choix du modèle schemas Postgres par tenant (un seul cluster Aurora plutôt que des instances RDS multiples). Mise en place de la RLS Postgres et d'un tenant context middleware (Node.js AsyncLocalStorage, PgBouncer en transaction mode). Pipeline de migration Flyway tenant-aware : migration progressive des tenants par lots, avec validation automatique après chaque migration. Tests d'isolation en CI : tests cross-tenant automatisés. Monitoring par tenant_id et pipeline d'onboarding automatisé.
#Ce qu'on mesure
On ne promet pas de chiffre. On suit le coût database, la durée des migrations de schéma, le nombre d'incidents d'isolation cross-tenant, le temps d'onboarding d'un nouveau tenant, l'avancement de la certification SOC2 et le temps que l'équipe tech consacre encore à la gestion des migrations et du monitoring. La comparaison avec la situation de départ permet de décider de la suite.
#Pourquoi Nehos pour architecture multi-tenant
Pourquoi choisir Nehos ? Parce qu'on refuse les projets ou le ROI n'est pas démontrable.
Expertise sectorielle SaaS / Startup — On connaît les contraintes réglementaires, les outils métier, les workflows terrain. Chokri Siala (CTO) pilote ce type de projet personnellement.
Approche ROI-First — On chiffre le retour avant de coder. Si le retour attendu n'est pas démontrable, on vous le dit avant de démarrer.
Stack maîtrisée — Postgres RLS, schemas Postgres, PgBouncer transaction mode, Flyway, Aurora RDS, OpenTelemetry, Datadog, Terraform, Node.js AsyncLocalStorage, LaunchDarkly, Redis. Pas de dépendance a un outil qu'on découvre sur votre projet.
Accompagnement après go-live — TMA, monitoring, evolution. On ne disparaît pas après la mise en production.
#Pour aller plus loin
- comparateur modèles multi-tenancy SaaS
- design system SaaS et white-labeling
- solutions architecture SaaS et startup
Sources citées dans cet article :
- PostgreSQL — Documentation officielle Row Security Policies (RLS)
- AICPA — SOC 2 Type II — Trust Services Criteria et exigences d'isolation des données
- PgBouncer — Documentation configuration transaction pooling pour SaaS multi-tenant
Questions & réponses
Questions frequentes sur l'architecture multi-tenant SaaS
Ce sont deux approches complémentaires, pas exclusives. La RLS (Row-Level Security) est un mécanisme natif Postgres qui restreint, au niveau du moteur de base de données, quelles lignes un utilisateur/session peut lire et écrire. Elle s'applique en ajoutant un tenant_id sur chaque table et une policy qui filtre sur ce tenant_id. Elle est efficace mais necessite une discipline absolue : oublier la policy sur une table expose cette table a tous les tenants. Les schemas Postgres par tenant sont une separation plus forte : chaque tenant a son propre namespace de tables (schema), ce qui signifie que les tables sont physiquement séparées et que les requêtes d'un tenant ne peuvent pas meme accéder aux tables d'un autre schema par inadvertance. Notre recommandation pour les SaaS B2B avec des exigences SOC2 : les deux ensemble — schemas par tenant pour la separation des tables + RLS pour une couche de sécurité supplémentaire.
La defense en profondeur est la seule approche valide. Concrètement : (1) la RLS Postgres garantit l'isolation au niveau du moteur de base de données — même si le code applicatif oublie de filtrer sur le tenant_id, Postgres bloque la requête ; (2) le middleware applicatif injecte le tenant_id dans chaque connexion de pool et verifie sa presence dans le contexte de chaque requête ; (3) une couche repository centralise tous les accès aux données et verifie le tenant_id avant chaque opération ; (4) des tests automatises cross-tenant s'exécutent en CI sur chaque PR — ils tentent des accès à des ressources d'un autre tenant et vérifient que ces accès sont bloques. La combinaison de ces 4 couches garantit qu'un bug dans l'une des couches est rattrapé par les autres. Une suite de tests cross-tenant est exécutée en CI à chaque modification : c'est ce qui garantit l'isolation dans la durée.
Le pattern expand-contract est la référence pour les zero-downtime migrations en multi-tenant. Concrètement : (1) phase expand — ajoutez la nouvelle structure (colonne, table, index) sans supprimer l'ancienne. Le code déployé peut utiliser les deux. (2) phase migration des données — backfill progressif des données dans la nouvelle structure, en background, tenant par tenant. (3) phase contract — une fois tous les tenants migrés et le code stable, supprimez l'ancienne structure. Ce pattern permet de déployer et migrer sans downtime sur des centaines de tenants. Pour les migrations urgentes, notre pipeline Flyway tenant-aware permet de cibler un sous-ensemble de tenants (canary migration) avant de généraliser — limitant l'exposition en cas d'échec.
PgBouncer (ou un pooler de connexions equivalent — Pgpool-II, RDS Proxy) est quasi-obligatoire pour les architectures multi-tenant a forte concurrence. Le problème sans pooler : chaque connexion applicative ouvre une connexion directe a Postgres, dont le nombre de connexions simultanées est limite (max_connections, typiquement 100-500 selon l'instance). Sur un SaaS avec des centaines de tenants actifs et plusieurs pods applicatifs, on peut facilement saturer le pool de connexions Postgres. PgBouncer en mode transaction pooling résout ce problème : il maintient un pool de connexions Postgres réduites et les reutilise entre les requêtes de différents tenants. Attention : le mode transaction pooling de PgBouncer est incompatible avec certaines features Postgres (LISTEN/NOTIFY, advisory locks, prepared statements persistants) — ces contraintes doivent être évaluées avant le choix du mode.
Oui — et c'est souvent le multi-tenancy bien conçu qui permet d'obtenir SOC2 Type II, pas de l'en empêcher. SOC2 exige notamment : la separation des données clients (le multi-tenant avec RLS et schemas y répond), le logging des accès aux données (les audit logs par tenant_id en APM OpenTelemetry y répondent), la gestion des accès et des privileges (le modèle RBAC par tenant y répond), et les procedures de sauvegarde et de restauration (des sauvegardes par schema permettent une restauration granulaire par tenant). L'architecture multi-tenant facilite l'obtention du SOC2 Type II : les auditeurs apprécient la cohérence du modèle d'isolation et la qualité des audit logs par tenant. Voir notre guide SOC2 Type II pour SaaS B2B.
La customisation par tenant dans un système multi-tenant partage se gere via une table de configuration par tenant dans la database partagée, combinée a un système de feature flags. Concrètement : une table tenant_config stocke les parametres par tenant (quota_api_calls_per_day, feature_advanced_analytics, theme_primary_color, plan_tier). Le code applicatif charge cette configuration au démarrage de la session tenant et l'injecte dans le contexte. Pour les feature flags complexes (A/B tests, rollouts progressifs), des outils comme LaunchDarkly, PostHog ou Unleash peuvent être intégrés avec un tenant_id comme clé d'évaluation. Les limites de quota (rate limiting par tenant) sont gérées avec Redis + un compteur par tenant_id. Le white-labeling UI (themes, logos, couleurs) s'appuie sur le système de tokens CSS present dans le design system — voir notre cas d'usage design system SaaS.