L'essentiel sur l'architecture multi-tenant SaaS

Le multi-tenancy designe la capacite d'un SaaS a servir plusieurs clients (tenants) depuis une infrastructure partagee — en garantissant que les donnees et les traitements d'un client ne sont jamais accessibles a un autre. C'est le modele economique qui permet au SaaS de croitre sans que les couts infra ne croissent lineairement avec le nombre de clients.

Trois modeles existent, avec des trade-offs tres differents : (1) database partagee avec row-level security (RLS) — le modele le plus efficace economiquement, adapte pour <10 000 tenants avec des exigences d'isolation logique ; (2) schemas Postgres par tenant — isolation plus forte, migration par tenant possible, adapte aux exigences SOC2/ISO 27001 de clients enterprise ; (3) database par tenant — isolation maximale, cout eleve, adapte aux reglementations de donnees tres strictes (sante, defense). Le choix depend du profil de clients, des certifications visees et du budget infra.

Le risque principal du multi-tenant est la fuite de donnees cross-tenant — un bug dans la couche d'isolation qui expose les donnees d'un client a un autre. C'est un incident potentiellement mortel en B2B : perte de confiance, resiliation, risque juridique. Nehos implemente systematiquement plusieurs couches d'isolation (RLS Postgres + middleware applicatif + tests d'isolation automatises) pour eliminer ce risque.

Cas client SaaS B2B (logiciel de gestion de projet, 400 tenants, cible PME et ETI) : migration d'une architecture silo (400 databases independantes) vers un modele schemas Postgres par tenant avec RLS. Resultat : -40 % de cout infra, zero incident d'isolation en 18 mois de production, onboarding d'un nouveau tenant en 3 minutes au lieu de 2 heures.

Multi-tenancy SaaS : isolez vos clients sans multiplier vos couts infra

Une architecture mono-tenant par client (le modele silo) vous coute 5 a 10 fois plus cher en infra que le multi-tenant. Mais un multi-tenant mal concu peut exposer les donnees d'un client a un autre — un incident catastrophique en B2B. Nehos concoit des architectures multi-tenant avec RLS Postgres, schemas par tenant et tenant context middleware qui offrent les deux : isolation garantie et efficacite infra.

Adapté à toute taille de structure

Artisan

Startup

PME / TPE

ETI

Grand Groupe

Problématique

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 adressees. Les equipes fondatrices commencent generalement avec un modele simple et expeditif : une database par client (le modele silo). C'est simple a implementer, facile a expliquer aux clients ('vos donnees sont sur votre propre base de donnees'), et rassegurant sur la question de l'isolation. Sauf qu'a partir de 20 a 50 clients, ce modele devient un cauchemar operationnel et economique. Les couts 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 couts database avant meme de compter le compute. La majorite de ces instances fonctionnent a 5 a 15 % de leur capacite — 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 etre executee sur les 400 databases independamment. Un pipeline de migration sur 400 databases prend des heures, les echecs partiels creent des etats incoherents entre clients, et les rollbacks sont exponentiellement plus complexes. Les equipes qui ont vecu cette realite temoignent : au-dela de 50 clients en mode silo, les cycles de release ralentissent significativement a cause de la complexity des migrations. La complexite operationnelle du monitoring s'agrege egalement. Surveiller 400 instances de database independantes requiert des outils et une configuration qui ne passent pas a l'echelle simplement. Les alertes se multiplient, les faux positifs augmentent, et la detection d'incidents cross-tenant devient un exercice complexe. Sans compter que les sauvegardes de 400 databases independantes representent des couts de stockage et des procedures de restauration qui ne simplifient pas les PRA (Plans de Reprise d'Activite). Du cote du client enterprise, la conversation sur la certification SOC2 Type II ou ISO 27001 met souvent en evidence les lacunes du modele silo : absence de procedures de rotation des credentials automatisees, logging insuffisant des acces aux donnees, absence de controle d'acces granulaire au niveau des tables. Ces certifications — requises par de nombreux clients grands comptes — necessitent une architecture qui supporte nativement les controles d'acces, les audit logs et la separation des environnements. Enfin, les equipes engineering sous-estiment systematiquement le risque de regression lors des migrations sur le modele silo. Une migration mal conçue qui casse l'acces aux donnees de 5 % des clients represents 20 clients affectes sur 400 — un incident majeur. La meme migration sur un modele multi-tenant partage peut etre testee sur un sous-ensemble de tenants en production (canary deployment) avant d'etre generalisee — une capacite qui n'existe pas simplement en mode silo.

Notre solution

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 donnees par tenant, exigences de conformite (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 majorite des SaaS B2B avec 50 a 5 000 tenants et des exigences SOC2, le modele recommande par Nehos est le schema Postgres par tenant, combine avec la RLS au niveau de la database partagee. Concretement : chaque tenant dispose de son propre schema Postgres (`tenant_abc`, `tenant_xyz`) dans une database mutualisee. Toutes les tables critiques (contenant des donnees client) ont un policy RLS qui restreint les requetes au schema courant. Le middleware applicatif (en Node.js, Go ou Python selon la stack) resout le tenant a partir de chaque requete 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 resolu dans le middleware d'authentification, stocke dans le contexte de la requete (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 acces aux donnees. Les tests d'isolation automatises — qui tentent des acces cross-tenant et verifient 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 executees schema par schema, avec retry automatique sur echec, logging detaille par tenant, et possibilite 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 ajoutee (expand) avant que le code soit deploye, et l'ancienne est supprimee (contract) une fois l'adoption confirmee. Le monitoring par tenant est mis en place avec Datadog ou Grafana : chaque requete SQL est taguee avec le `tenant_id` dans les traces APM (OpenTelemetry), ce qui permet d'identifier immediatement les tenants qui consomment anormalement des ressources, de detecter des requetes N+1 specifiques a un tenant, et de calculer le cout 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 defaut, 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 utilisee par le self-service d'inscription et par l'equipe sales pour le provisionning manuel des comptes enterprise. Pour les clients qui requierent une isolation maximale (secteur sante avec HDS, defense, services financiers critiques), Nehos peut implementer le modele database-par-tenant — mais avec un overlay d'infrastructure-as-code (Terraform + Pulumi) qui automatise le provisionnement et la gestion des instances et reduit le surcoût operationnel du silo a un niveau acceptable.

-40 %

de cout d'infrastructure database apres migration d'un modele silo (400 databases independantes) vers un modele schemas Postgres par tenant — SaaS gestion de projet B2B, 2025

3 min

pour provisionner un nouveau tenant (creation schema Postgres + migrations + configuration) apres automatisation du pipeline — contre 2 heures en mode silo

incident d'isolation cross-tenant en 18 mois de production sur le cas client de reference — 400 tenants, modele schemas Postgres + RLS + middleware applicatif + tests CI automatises

400

tenants actifs sur la plateforme SaaS de reference, dont 12 comptes enterprise avec exigences SOC2 — tous sur la meme infrastructure multi-tenant schemas Postgres

Cas concret

Migration complete sans aucun downtime client en 6 semaines. Resultats a 12 mois : cout database reduit de à partir de 120 k€ a à partir de 109 k€/an (-40 %), duree des migrations schema reduite de 4 heures a 12 minutes, zero incident d'isolation cross-tenant, onboarding en 3 minutes. SOC2 Type II obtenu 4 mois apres la migration — les deux prospects grands comptes ont signe pour 11,5 k€ de ARR total. L'equipe tech a recupere 35 % du temps precedemment consacre a la gestion des migrations et du monitoring silo.

#Le probleme : pourquoi architecture multi-tenant est un enjeu critique

Les chiffres parlent d'eux-memes : 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 adressees. Les equipes fondatrices commencent generalement avec un modele simple et expeditif : une database par client (le modele silo). C'est simple a implementer, facile a expliquer aux clients ('vos donnees sont sur votre propre base de donnees'), et rassegurant sur la question de l'isolation. Sauf qu'a partir de 20 a 50 clients, ce modele devient un cauchemar operationnel et economique.

Les couts 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 couts database avant meme de compter le compute. La majorite de ces instances fonctionnent a 5 a 15 % de leur capacite — 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 etre executee sur les 400 databases independamment. Un pipeline de migration sur 400 databases prend des heures, les echecs partiels creent des etats incoherents entre clients, et les rollbacks sont exponentiellement plus complexes. Les equipes qui ont vecu cette realite temoignent : au-dela de 50 clients en mode silo, les cycles de release ralentissent significativement a cause de la complexity des migrations.

La complexite operationnelle du monitoring s'agrege egalement. Surveiller 400 instances de database independantes requiert des outils et une configuration qui ne passent pas a l'echelle simplement. Les alertes se multiplient, les faux positifs augmentent, et la detection d'incidents cross-tenant devient un exercice complexe. Sans compter que les sauvegardes de 400 databases independantes representent des couts de stockage et des procedures de restauration qui ne simplifient pas les PRA (Plans de Reprise d'Activite).

Du cote du client enterprise, la conversation sur la certification SOC2 Type II ou ISO 27001 met souvent en evidence les lacunes du modele silo : absence de procedures de rotation des credentials automatisees, logging insuffisant des acces aux donnees, absence de controle d'acces granulaire au niveau des tables. Ces certifications — requises par de nombreux clients grands comptes — necessitent une architecture qui supporte nativement les controles d'acces, les audit logs et la separation des environnements.

Enfin, les equipes engineering sous-estiment systematiquement le risque de regression lors des migrations sur le modele silo. Une migration mal conçue qui casse l'acces aux donnees de 5 % des clients represents 20 clients affectes sur 400 — un incident majeur. La meme migration sur un modele multi-tenant partage peut etre testee sur un sous-ensemble de tenants en production (canary deployment) avant d'etre generalisee — une capacite 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

#Phase 1 — Choix du modele de multi-tenancy (semaines 1-2)

Analyse des contraintes : nombre de tenants, exigences d'isolation (SOC2, ISO 27001, exigences client grand compte), volume de donnees par tenant, budget infra. Choix du modele : shared database + RLS (optimal pour <10 000 tenants, isolation logique), schemas Postgres par tenant (isolation renforcee, migration par tenant), database par tenant (isolation maximale, cout eleve). Decision documentee 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 bloquees.

Point cle : Le middleware applicatif (en Node.js, Go ou Python selon la stack) resout le tenant a partir de chaque requete 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 execution sequentielle 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 : metriques d'usage, alertes sur les tenants anormaux (pic de requetes, volume inhabituels). Customisation par tenant : feature flags, limites de quota, themes UI. Onboarding tenant automatise (provisionning, migration initiale, configuration).

Point cle : Nehos implemente une approche en defense profonde : le tenant est resolu dans le middleware d'authentification, stocke dans le contexte de la requete (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 acces aux donnees.

On s'appuie sur notre guide SOC2 Type II pour SaaS B2B pour cadrer chaque etape.

#Resultats mesures

Les resultats parlent mieux que les promesses.

Indicateur	Resultat	Source
-40 %	de cout d'infrastructure database apres migration d'un modele silo (400 databases independantes) vers un modele schem...	Analyse TCO Nehos 2025 — SaaS B2B client (2025)
3 min	pour provisionner un nouveau tenant (creation schema Postgres + migrations + configuration) apres automatisation du p...	Mesures ops Nehos 2025 (2025)
0	incident d'isolation cross-tenant en 18 mois de production sur le cas client de reference — 400 tenants, modele schem...	Post-mortems projet Nehos 2025 (2025)
400	tenants actifs sur la plateforme SaaS de reference, dont 12 comptes enterprise avec exigences SOC2 — tous sur la meme...	Dashboard ops Nehos 2025 (2025)

#Ce que ces chiffres signifient

-40 % — de cout d'infrastructure database apres migration d'un modele silo (400 databases independantes) vers un modele 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) apres automatisation du pipeline — contre 2 heures en mode silo. Un indicateur complementaire qui confirme l'impact operationnel. Source : Mesures ops Nehos 2025.

0 — incident d'isolation cross-tenant en 18 mois de production sur le cas client de reference — 400 tenants, modele 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 independantes). Cout database : à partir de 120 k€/an. Temps de migration schema : 4 heures pour les 400 instances, avec 8 a 12 echecs partiels par migration. Onboarding nouveaux clients : 2 heures. Certifications SOC2 Type II en cours — bloquee par les lacunes du modele silo. Equipe tech : 8 developpeurs.

#Le defi

Migrer 400 clients d'un modele silo vers un modele multi-tenant partage sans aucune interruption de service, reduire les couts infra database de 40 % minimum, et unlocker la certification SOC2 Type II (exigee par deux prospects grands comptes dont le contrat representait 400 k€ de ARR). Contrainte : la migration devait etre transparente pour les clients — aucun downtime accepte.

#Solution deployee

Choix du modele 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.

#Resultats obtenus

Decouvrez 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 demontrable.

Expertise sectorielle SaaS / Startup — On connait les contraintes reglementaires, les outils metier, 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 demontrable, on vous le dit. On a deja refuse des projets — et nos clients nous en remercient.

Stack maitrisee — Postgres RLS, schemas Postgres, PgBouncer transaction mode, Flyway, Aurora RDS, OpenTelemetry, Datadog, Terraform, Node.js AsyncLocalStorage, LaunchDarkly, Redis. Pas de dependance a un outil qu'on decouvre sur votre projet.

Accompagnement apres go-live — TMA, monitoring, evolution. On ne disparait pas apres la mise en production.

#Pour aller plus loin

Sources citees dans cet article :

Questions & Réponses

Questions frequentes sur l'architecture multi-tenant SaaS

Ce sont deux approches complementaires, pas exclusives. La RLS (Row-Level Security) est un mecanisme natif Postgres qui restreint, au niveau du moteur de base de donnees, quelles lignes un utilisateur/session peut lire et ecrire. 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 separees et que les requetes d'un tenant ne peuvent pas meme acceder 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 securite supplementaire.

La defense en profondeur est la seule approche valide. Concretement : (1) la RLS Postgres garantit l'isolation au niveau du moteur de base de donnees — meme si le code applicatif oublie de filtrer sur le tenant_id, Postgres bloque la requete ; (2) le middleware applicatif injecte le tenant_id dans chaque connexion de pool et verifie sa presence dans le contexte de chaque requete ; (3) une couche repository centralise tous les acces aux donnees et verifie le tenant_id avant chaque operation ; (4) des tests automatises cross-tenant s'executent en CI sur chaque PR — ils tentent des acces a des ressources d'un autre tenant et verifient que ces acces 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 reference, 120 tests cross-tenant sont executes en CI — zero incident en 18 mois.

Le pattern expand-contract est la reference pour les zero-downtime migrations en multi-tenant. Concretement : (1) phase expand — ajoutez la nouvelle structure (colonne, table, index) sans supprimer l'ancienne. Le code deploye peut utiliser les deux. (2) phase migration des donnees — backfill progressif des donnees dans la nouvelle structure, en background, tenant par tenant. (3) phase contract — une fois tous les tenants migres et le code stable, supprimez l'ancienne structure. Ce pattern permet de deployer 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 generaliser — limitant l'exposition en cas d'echec.

PgBouncer (ou un pooler de connexions equivalent — Pgpool-II, RDS Proxy) est quasi-obligatoire pour les architectures multi-tenant a forte concurrence. Le probleme sans pooler : chaque connexion applicative ouvre une connexion directe a Postgres, dont le nombre de connexions simultanees 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 resout ce probleme : il maintient un pool de connexions Postgres reduites et les reutilise entre les requetes de differents tenants. Attention : le mode transaction pooling de PgBouncer est incompatible avec certaines features Postgres (LISTEN/NOTIFY, advisory locks, prepared statements persistants) — ces contraintes doivent etre evaluees avant le choix du mode.

Oui — et c'est souvent le multi-tenancy bien concu qui permet d'obtenir SOC2 Type II, pas de l'en empecher. SOC2 exige notamment : la separation des donnees clients (le multi-tenant avec RLS et schemas y repond), le logging des acces aux donnees (les audit logs par tenant_id en APM OpenTelemetry y repondent), la gestion des acces et des privileges (le modele RBAC par tenant y repond), 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 ete facilitee par l'architecture multi-tenant — les auditeurs ont apprecie la coherence du modele d'isolation et la qualite des audit logs par tenant. Voir notre guide [SOC2 Type II pour SaaS B2B](/guides/soc2-type-ii-saas-b2b).

La customisation par tenant dans un systeme multi-tenant partage se gere via une table de configuration par tenant dans la database partagee, combinee a un systeme de feature flags. Concretement : 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 demarrage 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 etre integres avec un tenant_id comme cle d'evaluation. Les limites de quota (rate limiting par tenant) sont gerees avec Redis + un compteur par tenant_id. Le white-labeling UI (themes, logos, couleurs) s'appuie sur le systeme de tokens CSS present dans le design system — voir notre cas d'usage [design system SaaS](/cas-usage/saas-startup/design-system-saas).

Exploration associée

design system SaaS et white-labeling solutions architecture SaaS et startup