Nehos Groupe
Définition & Concepts

Architecture Multi-Tenant

Version Décideur

L'essentiel

Imagine un immeuble de bureaux. En architecture single-tenant, chaque entreprise loue un bâtiment entier rien que pour elle — murs, chauffage, ascenseur, tout est dédié. Très isolé, mais cher et peu efficace. En architecture multi-tenant, plusieurs entreprises partagent le même immeuble. Mêmes couloirs, même ascenseur, même chaudière. Mais chaque bureau est verrouillé — les employés d'une entreprise ne peuvent pas entrer dans le bureau de l'autre. Chacun pense avoir son propre bâtiment, alors qu'il partage en réalité la même infrastructure. Dans le logiciel, c'est pareil. Un seul serveur, une seule base de données, une seule application — mais chaque client (tenant) ne voit que ses propres données. Personne ne voit les données des autres, même s'ils tournent tous sur la même machine. C'est le modèle qu'utilisent tous les grands SaaS : Salesforce, Shopify, HubSpot. Ça coûte bien moins cher à opérer que d'avoir un serveur dédié par client, les mises à jour sont déployées pour tout le monde en une seule fois, et la scalabilité est quasi-illimitée. Le défi ? S'assurer que les 'verrous des bureaux' — l'isolation des données — ne lâchent jamais. C'est là qu'intervient la Row Level Security (RLS) de Postgres.

Version Expert

Détails Techniques

Architecture logicielle dans laquelle une instance unique d'une application — incluant le code applicatif, les serveurs, la base de données et les ressources cloud — sert simultanément plusieurs clients distincts (appelés tenants). L'isolation des données entre tenants est assurée au niveau applicatif ou base de données, non par séparation physique de l'infrastructure. Trois patterns d'implémentation principaux : 1. Shared database / shared schema (RLS) : tous les tenants partagent les mêmes tables SQL. Chaque ligne possède une colonne tenant_id. L'isolation est assurée par Row Level Security (RLS) au niveau Postgres — des policies SQL filtrent automatiquement les données selon le tenant_id extrait du JWT de l'utilisateur authentifié. Modèle le plus dense, économique, recommandé jusqu'à plusieurs milliers de tenants. Risque : une faille dans la policy RLS expose potentiellement toutes les données. 2. Shared database / separate schema : une base de données unique, mais un schéma SQL distinct (ex. tenant_acme.orders, tenant_dupont.orders) par tenant. Migrations plus complexes à orchestrer sur N schémas. Utilisé quand les tenants ont des structures de données légèrement différentes. 3. Separate database : une instance Postgres ou une base dédiée par tenant. Isolation maximale, idéale pour secteurs réglementés (banque, santé, défense). Coût infra multiplié par N tenants. Perte des économies d'échelle. Réservé aux clients enterprise avec SLA strict ou obligations légales de séparation physique. Défis techniques : effect noisy neighbor (un tenant sur-sollicitant les ressources dégrade les autres — mitigation via connection pooling PgBouncer, query timeout, circuit breaker) ; gestion des customisations par tenant (feature flags, overrides de configuration) sans bifurquer le codebase ; audit log par tenant pour traçabilité RGPD ; backup/restore granulaire par tenant en cas d'incident.

#Définition Architecture Multi-Tenant

Architecture logicielle dans laquelle une instance unique d'une application — incluant le code applicatif, les serveurs, la base de données et les ressources cloud — sert simultanément plusieurs clients distincts (appelés tenants). L'isolation des données entre tenants est assurée au niveau applicatif ou base de données, non par séparation physique de l'infrastructure. Pour approfondir, consultez la page service développement SaaS B2B Nehos.

Sur le terrain, Trois patterns d'implémentation principaux : 1. Shared database / shared schema (RLS) : tous les tenants partagent les mêmes tables SQL. Chaque ligne possède une colonne tenant_id. L'isolation est assurée par Row Level Security (RLS) au niveau Postgres — des policies SQL filtrent automatiquement les données selon le tenant_id extrait du JWT de l'utilisateur authentifié. Modèle le plus dense, économique, recommandé jusqu'à plusieurs milliers de tenants. Risque : une faille dans la policy RLS expose potentiellement toutes les données. 2. Shared database / separate schema : une base de données unique, mais un schéma SQL distinct (ex. tenant_acme.orders, tenant_dupont.orders) par tenant. Migrations plus complexes à orchestrer sur N schémas. Utilisé quand les tenants ont des structures de données légèrement différentes. 3. Separate database : une instance Postgres ou une base dédiée par tenant. Isolation maximale, idéale pour secteurs réglementés (banque, santé, défense). Coût infra multiplié par N tenants. Perte des économies d'échelle. Réservé aux clients enterprise avec SLA strict ou obligations légales de séparation physique. Défis techniques : effect noisy neighbor (un tenant sur-sollicitant les ressources dégrade les autres — mitigation via connection pooling PgBouncer, query timeout, circuit breaker) ; gestion des customisations par tenant (feature flags, overrides de configuration) sans bifurquer le codebase ; audit log par tenant pour traçabilité RGPD ; backup/restore granulaire par tenant en cas d'incident.

Maîtriser Architecture Multi-Tenant permet aux équipes techniques et métier de parler le même langage — et d'arbitrer plus vite.

#Architecture Multi-Tenant expliqué simplement

Imagine un immeuble de bureaux. En architecture single-tenant, chaque entreprise loue un bâtiment entier rien que pour elle — murs, chauffage, ascenseur, tout est dédié. Très isolé, mais cher et peu efficace.

En architecture multi-tenant, plusieurs entreprises partagent le même immeuble. Mêmes couloirs, même ascenseur, même chaudière. Mais chaque bureau est verrouillé — les employés d'une entreprise ne peuvent pas entrer dans le bureau de l'autre. Chacun pense avoir son propre bâtiment, alors qu'il partage en réalité la même infrastructure.

Dans le logiciel, c'est pareil. Un seul serveur, une seule base de données, une seule application — mais chaque client (tenant) ne voit que ses propres données. Personne ne voit les données des autres, même s'ils tournent tous sur la même machine.

C'est le modèle qu'utilisent tous les grands SaaS : Salesforce, Shopify, HubSpot. Ça coûte bien moins cher à opérer que d'avoir un serveur dédié par client, les mises à jour sont déployées pour tout le monde en une seule fois, et la scalabilité est quasi-illimitée. Le défi ? S'assurer que les 'verrous des bureaux' — l'isolation des données — ne lâchent jamais. C'est là qu'intervient la Row Level Security (RLS) de Postgres.

Prenez un cas concret : une entreprise de 50 personnes qui accélère sa croissance. La différence entre théorie et terrain ? Les chiffres. Et les chiffres, on les a.

#Cas d'usage concrets

SaaS B2B CRM custom — Nehos (Payload v3 + Postgres RLS) — Développement d'une plateforme CRM conversationnel multi-clients sur Payload CMS v3 + PostgreSQL. Architecture shared schema avec RLS : tenant_id injecté via JWT Supabase Auth sur chaque requête. Policies RLS sur 12 tables. 47 tenants B2B en production. Aucun incident de fuite de données en 14 mois. Coût infrastructure -65 % vs architecture single-tenant équivalente.

Plateforme e-commerce B2B multi-marques (shared schema Postgres) — Distributeur industriel souhaitant ouvrir son catalogue à 3 filiales distinctes avec tarifications, catalogues et utilisateurs séparés. Architecture multi-tenant shared schema : tenant_id sur toutes les tables commandes/produits/clients. Feature flags par tenant pour activer/désactiver modules. Déploiement mise à jour unique pour les 3 filiales simultanément. Time-to-market nouvelles fonctionnalités divisé par 2,5.

Marketplace verticale RH — separate schema par entreprise cliente — Plateforme RH SaaS servant 200 PME. Choix separate schema (schéma SQL dédié par PME) pour permettre customisations de formulaires et champs métier spécifiques par client. Migration orchestrée via scripts automatisés exécutés sur N schémas. Isolation plus forte rassurante pour DRH. Contre-partie : migrations 4x plus longues qu'en shared schema.

Fintech réglementée — separate database par tenant enterprise — Éditeur de logiciel de gestion financière pour 12 grands comptes bancaires. Obligation réglementaire et contractuelle d'isoler physiquement les données. Architecture separate database : instance Postgres dédiée par banque, VPC AWS isolé. Coût infra x12 vs shared schema, mais conformité totale avec exigences ACPR et contrats enterprise. SLA 99,99 % par client possible.

#Architecture Multi-Tenant chez Nehos Groupe

Nehos Groupe applique ce concept au quotidien. Sur les 4 derniers projets impliquant Architecture Multi-Tenant, on a documenté les résultats avec des KPIs précis. Notre service développement SaaS B2B Nehos couvre ce périmètre de A à Z.

La méthode Nehos est documentée sur Stack Payload CMS v3 + PostgreSQL Nehos™. Chaque mission démarre par un cadrage structuré : objectifs chiffrés, périmètre technique, jalons à 30/60/90 jours. Les résultats mesurés sur nos clients : 65 % est un ordre de grandeur courant. On livre, on mesure, on itère. Pas de slides sans livrable. Voir aussi : service Development Next.js Nehos.

#Termes associés

Ce terme s'inscrit dans un écosystème plus large.

Chaque terme est défini dans notre glossaire avec la même approche : définition technique, vulgarisation, cas concrets et méthode Nehos.

Applications Concrètes

Contexte : SaaS B2B CRM custom — Nehos (Payload v3 + Postgres RLS)

"Développement d'une plateforme CRM conversationnel multi-clients sur Payload CMS v3 + PostgreSQL. Architecture shared schema avec RLS : tenant_id injecté via JWT Supabase Auth sur chaque requête. Policies RLS sur 12 tables. 47 tenants B2B en production. Aucun incident de fuite de données en 14 mois. Coût infrastructure -65 % vs architecture single-tenant équivalente."

Contexte : Plateforme e-commerce B2B multi-marques (shared schema Postgres)

"Distributeur industriel souhaitant ouvrir son catalogue à 3 filiales distinctes avec tarifications, catalogues et utilisateurs séparés. Architecture multi-tenant shared schema : tenant_id sur toutes les tables commandes/produits/clients. Feature flags par tenant pour activer/désactiver modules. Déploiement mise à jour unique pour les 3 filiales simultanément. Time-to-market nouvelles fonctionnalités divisé par 2,5."

Contexte : Marketplace verticale RH — separate schema par entreprise cliente

"Plateforme RH SaaS servant 200 PME. Choix separate schema (schéma SQL dédié par PME) pour permettre customisations de formulaires et champs métier spécifiques par client. Migration orchestrée via scripts automatisés exécutés sur N schémas. Isolation plus forte rassurante pour DRH. Contre-partie : migrations 4x plus longues qu'en shared schema."

Contexte : Fintech réglementée — separate database par tenant enterprise

"Éditeur de logiciel de gestion financière pour 12 grands comptes bancaires. Obligation réglementaire et contractuelle d'isoler physiquement les données. Architecture separate database : instance Postgres dédiée par banque, VPC AWS isolé. Coût infra x12 vs shared schema, mais conformité totale avec exigences ACPR et contrats enterprise. SLA 99,99 % par client possible."

Questions & Réponses

Questions fréquentes sur l'architecture multi-tenant

Single-tenant : chaque client dispose de sa propre instance applicative et de sa propre base de données. Isolation totale, mais coût infrastructure élevé (autant d'instances que de clients) et déploiements individuels. Multi-tenant : une seule instance sert tous les clients, données isolées logiquement via RLS ou schémas séparés. Avantage : coûts mutualisés, mises à jour simultanées, scalabilité. Inconvénient : isolation potentiellement moins forte qu'une DB dédiée, nécessite une architecture rigoureuse.
Oui, à condition d'une implémentation rigoureuse. Le RGPD exige isolation des données et capacité à supprimer/exporter les données d'un client spécifique. En shared schema avec RLS : les policies Postgres garantissent qu'une requête ne retourne jamais les données d'un autre tenant. La suppression RGPD est une simple requête DELETE WHERE tenant_id = X. Attention : des tests de non-régression sur les policies RLS doivent être automatisés. En separate database, la conformité est triviale mais le coût infra est prohibitif pour la majorité des SaaS.
Quatre étapes. (1) Ajouter une colonne tenant_id (UUID ou bigint) sur chaque table sensible. (2) Activer RLS sur chaque table : ALTER TABLE orders ENABLE ROW LEVEL SECURITY. (3) Créer une policy : CREATE POLICY tenant_isolation ON orders USING (tenant_id = current_setting('app.tenant_id')::uuid). (4) Injecter le tenant_id dans chaque connexion depuis l'application via SET app.tenant_id = '...' au début de chaque transaction, idéalement extrait du JWT. Ajouter un index sur tenant_id pour éviter les full table scans. Tester systématiquement qu'une requête sans SET retourne 0 lignes.
Le noisy neighbor (voisin bruyant) est le risque qu'un tenant consommant des ressources excessives (requêtes lentes, gros volumes, imports massifs) dégrade les performances de tous les autres tenants sur la même infrastructure. Mitigations : connection pooling (PgBouncer) avec limite de connexions par tenant, query timeout configuré par tenant, rate limiting API par tenant, monitoring par tenant avec alertes sur requêtes lentes, possibilité de migrer un tenant 'lourd' vers dedicated database.
Trois cas justifient le coût d'une base dédiée par tenant : (1) Obligations réglementaires sectorielles (finance, santé, défense) imposant isolation physique des données. (2) Contrats enterprise avec clauses d'isolement et SLA individualisés inapplicables en shared schema. (3) Tenants avec structures de données très différentes nécessitant des schémas incompatibles. Dans tous les autres cas, le shared schema avec RLS offre un rapport coût/isolation bien supérieur pour la majorité des SaaS B2B.
Stack standard Nehos pour SaaS B2B multi-tenant : Payload CMS v3 (Next.js 16 App Router) + PostgreSQL + Supabase Auth pour la gestion des JWT. Pattern shared schema avec RLS : tenant_id UUID sur toutes les collections Payload, policies RLS activées au niveau Postgres. Le tenant_id est extrait du JWT Supabase Auth et injecté via middleware Next.js dans chaque requête Payload. PgBouncer pour connection pooling. Tests automatisés vérifiant l'isolation sur chaque PR. Chez Nehos, ce pattern est en production sur plusieurs SaaS B2B depuis 2024.
Quatre défis majeurs. (1) Ajout rétroactif du tenant_id sur toutes les tables existantes — migration lourde, souvent 2-4 semaines de travail. (2) Réécriture des queries applicatives pour inclure le filtre tenant_id (risque de régression). (3) Gestion des données existantes : assignation des données historiques au bon tenant. (4) Tests d'isolation : créer une suite de tests vérifiant que les données d'un tenant ne fuient jamais vers un autre. Budget typique refactoring monolithe → multi-tenant : 3-8 semaines selon la taille du codebase.

Exploration associée

définition Payload CMSobligations RGPD isolation des donnéesservice Development Next.js Nehos
Réserver un audit