Architecture multi-tenant pour SaaS : le guide technique 2026

Chez HEXAIT, nous avons concu et fait evoluer des dizaines d'architectures SaaS ces dernieres annees, de la plateforme B2B servant quelques centaines de clients aux applications metier opaque traitant des donnees sensibles. La question du multi-tenant revient systematiquement au cadrage : c'est la decision technique la plus structurante, celle qu'il est le plus couteux de modifier apres coup. Une migration de modele multi-tenant sur un SaaS deja en production se compte en mois de travail et en risques de regression. Mieux vaut bien la prendre des le depart.

Ce guide s'adresse aux CTO, lead developpeurs et fondateurs techniques qui concoivent un SaaS ou envisagent de faire evoluer leur architecture. Nous y partageons les 3 modeles classiques, leurs avantages et leurs pieges, les 5 defis techniques a anticiper, et notre approche concrete chez HEXAIT.

Qu'est-ce qu'une architecture multi-tenant ?

Une architecture multi-tenant est un modele logiciel dans lequel une seule instance applicative (et son infrastructure) sert plusieurs clients, appeles tenants. Chaque tenant accede a ses propres donnees de maniere isolee, mais partage le meme code, le meme serveur d'application et bien souvent la meme base de donnees que les autres clients. C'est l'oppose du modele single-tenant, ou chaque client dispose d'une instance dediee : son propre serveur, sa propre base, son propre deploiement.

En single-tenant, chaque nouveau client signe une multiplication directe de l'infrastructure : nouveau serveur, nouvelle base, nouvelle pipeline de deploiement, nouveau monitoring. C'est viable pour quelques clients enterprise (model historique de l'ere on-premise), mais devient ingerable des qu'on vise la centaine ou le millier d'abonnes.

Le multi-tenant est devenu le standard de l'industrie SaaS depuis le milieu des annees 2010, porte par les leaders comme Salesforce, Slack ou Stripe. La logique est simple : mutualiser les ressources pour offrir un service moins cher, plus rapide a deployer et plus simple a maintenir. Mais derriere cette logique business se cachent des decisions techniques precises qui meritent d'etre comprises.

Pourquoi le multi-tenant est strategique des le premier jour

La mutualisation des couts d'infrastructure

C'est le levier economique le plus evident. En multi-tenant, un meme cluster PostgreSQL, un meme pool d'instances Node.js et un meme reverse proxy servent des centaines ou des milliers de clients. Le cout marginal par tenant additionnel est tres faible, ce qui permet de proposer des plans entre 19 et 99 euros par mois tout en maintenant des marges saines. En single-tenant, le cout fixe par client demarre souvent a plusieurs centaines d'euros par mois, ce qui exclut de fait toute strategie de plans low-touch ou self-service.

La vitesse de deploiement de nouveaux clients

En multi-tenant, l'onboarding d'un nouveau client se resume a une insertion en base de donnees : creation d'un nouveau tenant, association d'un premier utilisateur admin, eventuellement provisioning de quelques donnees de demarrage. Le tout en quelques secondes, sans intervention humaine. C'est ce qui permet aux SaaS modernes de proposer un essai gratuit instantane et un workflow self-service complet. En single-tenant, l'onboarding implique un deploiement d'infrastructure : plusieurs minutes au mieux, plusieurs jours au pire.

La maintenance et les deploiements unifies

Avec une architecture multi-tenant, vous deployez votre code une seule fois et tous vos clients beneficient instantanement de la mise a jour. Les correctifs de bug, les patchs de securite, les nouvelles fonctionnalites : tout est unifie. En single-tenant, chaque deploiement doit etre orchestre sur N instances, avec le risque de derive (drift) entre versions, des matrices de compatibilite a maintenir, et un cout operationnel qui croit lineairement avec le nombre de clients.

Le piege du "on migrera plus tard"

Une erreur recurrente que nous voyons dans les MVP : demarrer en single-tenant en se disant qu'on basculera en multi-tenant quand on aura plus de clients. C'est rarement viable. Le multi-tenant exige une discipline architecturale qui infuse partout dans le code : modeles de donnees avec colonne tenant_id, requetes ORM filtrees, middleware d'authentification, gestion du cache, routage par sous-domaine, tests unitaires. Refactorer une codebase single-tenant pour la rendre multi-tenant revient souvent a une reecriture partielle. Mieux vaut concevoir multi-tenant des le debut, meme avec un seul client en production. Voir notre article MVP SaaS : budget realiste, delais et erreurs a eviter pour les autres pieges du demarrage.

Les 3 modeles de multi-tenancy

Il existe trois modeles canoniques pour implementer une architecture multi-tenant, du plus mutualise au plus isole. Chacun a sa logique, ses cas d'usage et ses contraintes. Aucun n'est universellement meilleur : le bon choix depend de votre marche, de votre volumetrie cible et de la sensibilite des donnees traitees.

Modele 1 — Base de donnees partagee, schema partage (shared DB, shared schema)

C'est le modele le plus mutualise. Une seule base de donnees, un seul schema, et chaque table porte une colonne tenant_id qui identifie le client proprietaire de chaque ligne. Toutes les requetes applicatives doivent imperativement filtrer sur ce champ pour eviter de remonter des donnees d'un autre client. Salesforce a historiquement popularise ce modele, qui reste aujourd'hui le choix par defaut de la majorite des SaaS B2B grand public.

Quand le choisir ? Pour un SaaS B2B grand public avec des plans low-touch (moins de 100 euros par mois), une volumetrie attendue de plusieurs milliers a centaines de milliers de tenants, et des donnees relativement standards qui ne tombent pas sous un cadre reglementaire strict. Notion, Linear ou Intercom utilisent ce modele a tres grande echelle.

Modele 2 — Base de donnees partagee, schema par tenant (shared DB, schema per tenant)

Une approche intermediaire. Toujours une seule instance PostgreSQL, mais chaque tenant dispose de son propre schema (au sens PostgreSQL : un namespace logique qui contient ses propres tables). Les noms de tables sont identiques d'un schema a l'autre, mais les donnees sont physiquement separees. L'application route les requetes vers le bon schema en fonction du tenant authentifie, generalement via une commande SET search_path en debut de connexion.

Quand le choisir ? Pour un SaaS B2B mid-market (plans 200 a 2000 euros par mois), une volumetrie cible entre 50 et 500 clients, des besoins de customisation par client (champs personnalises, integrations specifiques), et un compromis recherche entre cout et isolation. C'est aussi un bon choix transitoire pour des SaaS qui anticipent une demande future de database-per-tenant pour leurs gros comptes.

Modele 3 — Base de donnees dediee par tenant (database per tenant)

Le modele le plus isole. Chaque tenant dispose de sa propre base de donnees physique (ou logique selon le moteur). L'application maintient un registre central qui associe chaque tenant a sa chaine de connexion, et route dynamiquement les requetes vers la bonne base. Les donnees sont totalement segregees, y compris au niveau du stockage disque.

Quand le choisir ? Pour un SaaS enterprise (plans 5000+ euros par mois), des secteurs reglementes (sante, finance, defense, juridique), des clients qui exigent contractuellement une isolation physique, ou des besoins de souverainete des donnees par pays. C'est le modele standard de Workday, ServiceNow ou SAP Business ByDesign.

Comment choisir le bon modele pour son SaaS

Le choix se joue sur quatre criteres principaux. Pas de regle absolue, mais une matrice de decision qui clarifie la majorite des situations.

Une approche pragmatique consiste a coder l'abstraction tenant des le depart (middleware, repository pattern, tests) en commencant par le modele le plus simple (shared schema avec RLS), puis a basculer certains gros comptes vers un modele plus isole quand le besoin commercial le justifie. C'est l'approche qu'a historiquement choisie Atlassian.

Les 5 defis techniques du multi-tenant

Choisir un modele n'est que le debut. La vraie complexite du multi-tenant reside dans cinq problemes transverses qu'il faut traiter avec rigueur des le premier commit.

1. L'isolation des donnees

C'est le risque numero un. Une seule requete SQL qui oublie le filtre tenant_id, et les donnees d'un client se retrouvent exposees a un autre. Les consequences : breach de donnees, perte de confiance, sanction RGPD. Et ce risque ne diminue jamais : plus la codebase grandit, plus les opportunites de l'oublier se multiplient.

La defense en profondeur impose deux niveaux. Au niveau base de donnees, activer le Row Level Security de PostgreSQL : on definit une policy qui filtre automatiquement chaque SELECT en fonction d'une variable de session (current_setting('app.tenant_id')). Meme si le code applicatif oublie le filtre, la base refuse de remonter des lignes du mauvais tenant. Au niveau applicatif, un middleware injecte automatiquement le tenant_id dans toutes les requetes ORM (Prisma middleware, Sequelize hooks, Drizzle plugins). La combinaison des deux rend la fuite techniquement impossible.

Il faut completer par des tests d'integration dedies : pour chaque endpoint critique, on cree deux tenants distincts et on verifie qu'ils ne voient pas les donnees l'un de l'autre. Ces tests doivent etre obligatoires dans la CI.

2. Securite et permissions

Le modele de permissions classique RBAC (Role-Based Access Control) devient multi-dimensionnel en multi-tenant. Chaque utilisateur appartient a un ou plusieurs tenants, et a un role specifique dans chacun d'eux. Il faut aussi gerer les super-administrateurs (votre equipe interne) qui peuvent acceder a tous les tenants pour le support, en tracant scrupuleusement chaque acces (audit log). Les invitations croisees entre tenants, les transferts d'utilisateurs, les SSO d'entreprise (SAML, OIDC) ajoutent une complexite supplementaire qu'il faut modeliser des le depart.

3. Scalabilite et performance

En shared schema, la premiere optimisation est l'index composite (tenant_id, colonne_metier) sur chaque table critique. Sans ces index, les requetes degenerent des qu'une table depasse quelques millions de lignes. La deuxieme : le sharding horizontal par tenant, qui consiste a repartir les tenants sur plusieurs bases en fonction d'un hash de leur ID. Solutions comme Citus ou Vitess automatisent cette logique au-dessus de PostgreSQL ou MySQL.

Le cache aussi doit etre cloisonne par tenant. Une cle Redis commeuser:123 est dangereuse : si deux tenants partagent des IDs (ce qui est normal en multi-tenant), vous melangez leurs caches. La bonne pratique : prefixer toutes les cles par le tenant_id, par exempletenant_abc:user:123.

4. Backup, restore et conformite

Un backup global de toute la base est facile. Le restaurer aussi. Mais qu'est-ce qu'il se passe quand un seul client demande la restauration de ses donnees a J-2 ? En shared schema, c'est complique : il faut extraire les lignes du client depuis un dump, les comparer a l'etat actuel, et reinjecter. En schema per tenant, on dump et restaure un schema specifique. En database per tenant, on restaure la base dediee.

Le RGPD ajoute deux obligations operationnelles : l'export complet des donnees d'un tenant (droit a la portabilite) et la suppression complete (droit a l'oubli). Ces deux operations doivent etre scriptees et testees. En multi-tenant mature, on les expose meme via une API interne pour permettre au support de les declencher en quelques clics.

5. Onboarding et provisioning

Creer un nouveau tenant doit etre instantane et idempotent. En shared schema, c'est trivial. En schema per tenant, il faut creer le schema, executer toutes les migrations, eventuellement injecter des donnees seed (roles par defaut, templates, exemples). En database per tenant, il faut creer la base, executer les migrations, configurer les utilisateurs, mettre a jour le routeur applicatif. Plus le modele est isole, plus le provisioning est complexe et lent. Il faut donc le piloter par une file de jobs asynchrone (BullMQ, Sidekiq, Temporal) pour decoupler du parcours utilisateur.

Les migrations de schema multi-tenant sont un sujet a part entiere. En shared schema, c'est une migration unique. En schema per tenant ou database per tenant, il faut orchestrer la migration sur N entites, gerer les echecs partiels, et avoir une strategie de rollback. Des outils comme Flyway ou Liquibase, combines a une logique maison ou un orchestrateur (Temporal), sont indispensables.

Outils et frameworks pour le multi-tenant

Heureusement, l'ecosysteme moderne fournit des outils robustes pour implementer chacun de ces modeles sans tout coder a la main. Voici les briques que nous utilisons le plus chez HEXAIT.

PostgreSQL avec Row Level Security (RLS)

Le combo gagnant pour le modele shared schema. PostgreSQL permet de definir des policies qui filtrent automatiquement les lignes en fonction du contexte de session. On stocke le tenant_id dans une variable de session (SET app.tenant_id = 'xxx') au debut de chaque requete HTTP, et toutes les queries sont automatiquement scope. Quasi-impossible a contourner par erreur. Supabase utilise massivement cette approche.

Prisma avec multi-schema

Prisma supporte nativement le multi-schema depuis 2024. On declare ses modeles dans un schema Prisma, on peut creer dynamiquement de nouveaux schemas PostgreSQL au runtime, et utiliserprisma.$extends() pour router les requetes vers le bon schema en fonction du tenant. Les migrations Prisma savent aussi iterer sur l'ensemble des schemas tenants.

Drizzle et Sequelize

Pour les projets non-Prisma, Drizzle ORM offre une API ergonomique pour gerer le search_path dynamiquement par requete. Sequelize, plus ancien, supporte le multi-schema via un middleware applicatif. Les deux conviennent pour des architectures schema per tenant.

Solutions cloud-native : Supabase et Neon

Supabase fournit un PostgreSQL managed avec RLS active par defaut, ce qui rend le modele 1 quasi-trivial a implementer. Neon, de son cote, propose des bases serverless qui scalent a zero : un excellent fit pour le modele database per tenant, car le cout d'une base inactive est negligeable. Les deux integrent nativement les pipelines Vercel/Next.js que nous utilisons sur la plupart de nos projets, comme detaille dans notre article Pourquoi choisir Next.js pour votre application web.

Notre approche chez HEXAIT

Sur un nouveau projet SaaS, nous demarrons systematiquement par un atelier d'architecture d'une demi-journee avec l'equipe technique du client. Nous y challengeons trois hypotheses : la volumetrie de tenants envisagee a 3 ans, la sensibilite reelle des donnees traitees (souvent surestimee, parfois sous-estimee), et la complexite des personnalisations attendues par client. Ces trois axes determinent a 80 % le choix du modele.

Pour la majorite de nos projets SaaS B2B (entre 50 et 500 clients attendus, donnees personnelles standard, plans 100-500 euros par mois), nous recommandons une stack eprouvee : PostgreSQL avec Row Level Security, Prisma pour l'ORM, middleware Next.js qui injecte le tenant_id dans le contexte de chaque requete API, et des tests d'isolation systematiques dans la CI. Cette combinaison offre le meilleur compromis entre cout d'infrastructure, securite et velocite de developpement.

Pour les clients sur des marches reglementes ou avec des comptes enterprise exigeant l'isolation physique, nous basculons sur une approche schema per tenant ou database per tenant, en utilisant Neon pour son scaling serverless. Vous pouvez voir comment nous avons applique ces principes sur des projets reels dans notre portfolio de realisations comme Welyx, Mently ou SoCaftan. Notre service de creation de SaaS inclut systematiquement le cadrage architecture, et notre offre de developpement SaaS sur mesure couvre l'implementation complete jusqu'a la mise en production.

4 erreurs frequentes a eviter