Multi-tenancy SaaS : isolez vos clients sans multiplier vos coûts infra
Une architecture mono-tenant par client (le modèle silo) vous coute 5 a 10 fois 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 coute entre 50 et à partir de 496 €/mois selon la taille. Pour 400 clients, c'est à partir de 873 €/mois de coûts database avant meme de compter le compute. La majorité de ces instances fonctionnent a 5 a 15 % 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 les 400 databases indépendamment. Un pipeline de migration sur 400 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à de 50 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 400 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 400 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 de 5 % des clients represents 20 clients affectes sur 400 — 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 50 a 5 000 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.
-40 %
de coût d'infrastructure database après migration d'un modèle silo (400 databases indépendantes) vers un modèle schemas Postgres par tenant — SaaS gestion de projet B2B, 2025
3 min
pour provisionner un nouveau tenant (creation schema Postgres + migrations + configuration) après automatisation du pipeline — contre 2 heures en mode silo
0
incident d'isolation cross-tenant en 18 mois de production sur le cas client de référence — 400 tenants, modèle schemas Postgres + RLS + middleware applicatif + tests CI automatises
400
tenants actifs sur la plateforme SaaS de référence, dont 12 comptes enterprise avec exigences SOC2 — tous sur la même infrastructure multi-tenant schemas Postgres
#Le problème : pourquoi architecture multi-tenant est un enjeu critique
Les chiffres parlent d'eux-mêmes : 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 coute entre 50 et à partir de 496 €/mois selon la taille. Pour 400 clients, c'est à partir de 873 €/mois de coûts database avant meme de compter le compute. La majorité de ces instances fonctionnent a 5 a 15 % de leur capacité — un gaspillage massif. (source : PostgreSQL.org)
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 les 400 databases indépendamment. Un pipeline de migration sur 400 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à de 50 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 400 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 400 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 de 5 % des clients represents 20 clients affectes sur 400 — 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 50 a 5 000 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.
#Résultats mesures
Les résultats parlent mieux que les promesses.
| Indicateur | Résultat | Source |
|---|---|---|
| -40 % | de coût d'infrastructure database après migration d'un modèle silo (400 databases indépendantes) vers un modèle schem... | Analyse TCO Nehos 2025 — SaaS B2B client (2025) |
| 3 min | pour provisionner un nouveau tenant (creation schema Postgres + migrations + configuration) après automatisation du p... | Mesures ops Nehos 2025 (2025) |
| 0 | incident d'isolation cross-tenant en 18 mois de production sur le cas client de référence — 400 tenants, modèle schem... | Post-mortems projet Nehos 2025 (2025) |
| 400 | tenants actifs sur la plateforme SaaS de référence, dont 12 comptes enterprise avec exigences SOC2 — tous sur la même... | Dashboard ops Nehos 2025 (2025) |
#Ce que ces chiffres signifient
-40 % — de coût d'infrastructure database après migration d'un modèle silo (400 databases indépendantes) vers un modèle schemas Postgres par tenant — SaaS gestion de projet B2B, 2025. C'est le chiffre principal, celui qui justifie l'investissement. Source : Analyse TCO Nehos 2025 — SaaS B2B client.
3 min — pour provisionner un nouveau tenant (creation schema Postgres + migrations + configuration) après automatisation du pipeline — contre 2 heures en mode silo. Un indicateur complémentaire qui confirme l'impact opérationnel. Source : Mesures ops Nehos 2025.
0 — incident d'isolation cross-tenant en 18 mois de production sur le cas client de référence — 400 tenants, modèle schemas Postgres + RLS + middleware applicatif + tests CI automatises. Source : Post-mortems projet Nehos 2025.
#Cas client : SaaS B2B de gestion de projets (construction
Voici comment ca s'est passe sur un projet recent.
#Contexte
SaaS B2B de gestion de projets (construction, immobilier), 400 clients PME et ETI, architecture silo initiale (400 instances RDS indépendantes). Coût database : à partir de 120 k€/an. Temps de migration schema : 4 heures pour les 400 instances, avec 8 a 12 échecs partiels par migration. Onboarding nouveaux clients : 2 heures. Certifications SOC2 Type II en cours — bloquée par les lacunes du modèle silo. Equipe tech : 8 développeurs.
#Le défi
Migrer 400 clients d'un modèle silo vers un modèle multi-tenant partage sans aucune interruption de service, réduire les coûts infra database de 40 % minimum, et unlocker la certification SOC2 Type II (exigée par deux prospects grands comptes dont le contrat représentait 400 k€ de ARR). Contrainte : la migration devait être transparente pour les clients — aucun downtime accepte.
#Solution déployée
Choix du modèle schemas Postgres par tenant (non RDS multi-instance, mais un seul cluster Aurora avec 400 schemas). Implementation de la RLS Postgres + tenant context middleware (Node.js AsyncLocalStorage + PgBouncer transaction mode). Pipeline de migration Flyway tenant-aware : migration progressive des 400 tenants sur 6 semaines (lots de 20 tenants par nuit, avec validation automatique post-migration). Tests d'isolation CI : 120 tests cross-tenant automatises ajoutés. Monitoring Datadog par tenant_id. Onboarding pipeline automatise : 3 minutes. Infrastructure-as-code Terraform pour le cluster Aurora.
#Résultats obtenus
Migration complete sans aucun downtime client en 6 semaines. Résultats a 12 mois : coût database réduit de 120 k€ a à partir de 109 k€/an (-40 %), durée des migrations schema réduite de 4 heures a 12 minutes, zero incident d'isolation cross-tenant, onboarding en 3 minutes. SOC2 Type II obtenu 4 mois après la migration — les deux prospects grands comptes ont signe pour 11,5 k€ de ARR total. L'equipe tech a récupéré 35 % du temps précédemment consacre a la gestion des migrations et du monitoring silo.
Découvrez aussi notre optimisation Postgres performance SaaS.
#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 ROI n'est pas démontrable, on vous le dit. On a déjà refuse des projets — et nos clients nous en remercient.
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 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. Sur notre cas client de référence, 120 tests cross-tenant sont executes en CI — zero incident en 18 mois.
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 400 tenants actifs et 10 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). Dans notre cas client, l'obtention du SOC2 Type II a été facilitée par l'architecture multi-tenant — les auditeurs ont apprecie la coherence 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.