Architecture Multi-Tenant
#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.
#Cas d'usage concrets
Exemple de situation — SaaS B2B de CRM sur Payload v3 et Postgres RLS — Situation type : une plateforme CRM conversationnelle multi-clients construite sur Payload CMS v3 et PostgreSQL. Architecture à schéma partagé avec RLS : le tenant_id est injecté via le JWT Supabase Auth à chaque requête et des policies RLS couvrent les tables sensibles.
Des tests automatisés vérifient l'isolation entre tenants à chaque pull request. La mutualisation de l'infrastructure réduit le coût par rapport à une instance dédiée par client.
Exemple de situation — plateforme e-commerce B2B multi-marques — Situation type : un distributeur industriel veut ouvrir son catalogue à trois filiales, chacune avec ses tarifs, son catalogue et ses utilisateurs. Architecture multi-tenant à schéma partagé : un tenant_id sur toutes les tables de commandes, produits et clients, et des feature flags par tenant pour activer ou désactiver des modules. Une mise à jour unique est déployée pour les trois filiales en même temps.
Exemple de situation — marketplace RH : un schéma par entreprise cliente — Situation type : une plateforme RH en SaaS sert de nombreuses PME. Elle choisit un schéma SQL dédié par entreprise cliente pour permettre des formulaires et des champs métier spécifiques à chacune. Les migrations sont orchestrées par des scripts automatisés exécutés sur chaque schéma. L'isolation plus forte rassure les DRH ; la contrepartie est que les migrations sont plus longues qu'en schéma partagé.
Exemple de situation — fintech réglementée : une base par tenant enterprise — Situation type : un éditeur de logiciel de gestion financière sert de grands comptes bancaires, qui imposent par contrat et par réglementation une isolation physique des données. Architecture à base séparée : une instance Postgres dédiée par banque, dans un réseau privé isolé.
Le coût d'infrastructure est multiplié par le nombre de clients, mais la conformité aux exigences des clients et du régulateur est complète et un SLA par client devient possible.
#Architecture Multi-Tenant chez Nehos Groupe
Nehos Groupe applique ce concept au quotidien. 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. 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.
- Row Level Security (RLS)
- PostgreSQL
- SaaS (Software as a Service)
- Payload CMS
- JWT (JSON Web Token)
- Single-Tenant
- Noisy Neighbor
- RGPD
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
« Situation type : une plateforme CRM conversationnelle multi-clients construite sur Payload CMS v3 et PostgreSQL. Architecture à schéma partagé avec RLS : le tenant_id est injecté via le JWT Supabase Auth à chaque requête et des policies RLS couvrent les tables sensibles. Des tests automatisés vérifient l'isolation entre tenants à chaque pull request. La mutualisation de l'infrastructure réduit le coût par rapport à une instance dédiée par client. »
« Situation type : un distributeur industriel veut ouvrir son catalogue à trois filiales, chacune avec ses tarifs, son catalogue et ses utilisateurs. Architecture multi-tenant à schéma partagé : un tenant_id sur toutes les tables de commandes, produits et clients, et des feature flags par tenant pour activer ou désactiver des modules. Une mise à jour unique est déployée pour les trois filiales en même temps. »
« Situation type : une plateforme RH en SaaS sert de nombreuses PME. Elle choisit un schéma SQL dédié par entreprise cliente pour permettre des formulaires et des champs métier spécifiques à chacune. Les migrations sont orchestrées par des scripts automatisés exécutés sur chaque schéma. L'isolation plus forte rassure les DRH ; la contrepartie est que les migrations sont plus longues qu'en schéma partagé. »
« Situation type : un éditeur de logiciel de gestion financière sert de grands comptes bancaires, qui imposent par contrat et par réglementation une isolation physique des données. Architecture à base séparée : une instance Postgres dédiée par banque, dans un réseau privé isolé. Le coût d'infrastructure est multiplié par le nombre de clients, mais la conformité aux exigences des clients et du régulateur est complète et un SLA par client devient 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. Nous appliquons ce pattern aux SaaS B2B sur mesure.
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.