Multi-Tenant vs Single-Tenant | Choisir la bonne architecture SaaS

Chaque produit SaaS doit repondre a une question fondamentale : comment servir plusieurs clients depuis le meme logiciel ? La reponse est votre modele de tenancy. Il affecte le cout, la securite, les performances et la vitesse a laquelle vous pouvez livrer. Bien choisir des le depart vous evite des migrations douloureuses plus tard.

Definitions

Multi-tenant

Une seule instance de l’application sert tous les clients. Tout le monde partage les memes serveurs, le meme code et souvent la meme base de donnees. Les donnees de chaque client sont isolees logiquement, mais l’infrastructure est partagee.

Imaginez un immeuble d’appartements. Chaque locataire vit dans le meme batiment, partage l’ascenseur et les couloirs, mais dispose de son propre logement ferme a cle avec ses propres meubles.

Single-tenant

Chaque client obtient sa propre instance dediee de l’application. Des serveurs separes, des bases de donnees separees, parfois des bases de code separees. Rien n’est partage entre les clients.

Imaginez des maisons individuelles. Chaque locataire a son propre batiment, sa propre plomberie, son propre jardin. Isolation complete, mais plus couteux a maintenir.

Comment fonctionne le multi-tenancy

Il existe trois approches courantes de l’architecture multi-tenant, chacune avec des compromis differents.

Modele 1 : Application partagee, base de donnees partagee

Tous les tenants partagent une seule instance applicative et une seule base de donnees. Les donnees des tenants sont separees a l’aide d’un identifiant de tenant (generalement une colonne tenant_id) sur chaque table.

Architecture :

• Un serveur applicatif (ou cluster) traite toutes les requetes.
• Une base de donnees stocke toutes les donnees des tenants.
• Chaque requete inclut une clause WHERE tenant_id = ? pour limiter les donnees au bon tenant.

Avantages :

• Cout d’infrastructure le plus bas. Une base de donnees, un deploiement applicatif.
• Le plus simple a deployer et mettre a jour. Un seul push, tout le monde recoit le changement.
• Facile d’agreger les donnees entre tenants pour l’analytique et le reporting.

Inconvenients :

• Risque le plus eleve de fuite de donnees si une requete oublie le filtre tenant.
• Un tenant bruyant peut degrader les performances pour tout le monde.
• Les migrations de base de donnees affectent tous les tenants simultanement.
• Le plus difficile pour respecter les reglementations sur la residence des donnees.

C’est l’approche la plus courante pour les produits SaaS B2B avec un grand nombre de clients de petite et moyenne taille.

Modele 2 : Application partagee, bases de donnees separees

Tous les tenants partagent la meme instance applicative, mais chaque tenant a sa propre base de donnees. L’application route les requetes vers la bonne base de donnees en fonction du tenant authentifie.

Architecture :

• Un serveur applicatif (ou cluster) traite toutes les requetes.
• Une base de donnees separee pour chaque tenant.
• Une couche de routage fait correspondre l’identite du tenant a la bonne connexion de base de donnees.

Avantages :

• Isolation des donnees plus forte. Aucun risque de requetes inter-tenants.
• Plus facile de respecter les exigences de residence des donnees. Vous pouvez placer chaque base de donnees dans la region requise par le tenant.
• La sauvegarde et restauration par tenant est simple.
• L’utilisation intensive d’un tenant ne verrouillera pas les tables des autres tenants.

Inconvenients :

• Plus d’infrastructure a gerer. Des centaines de tenants signifient des centaines de bases de donnees.
• Les migrations de schema doivent etre appliquees a chaque base de donnees individuellement.
• Le reporting inter-tenants necessite d’interroger plusieurs bases de donnees.
• Cout plus eleve qu’un modele entierement partage.

C’est un bon compromis pour les produits qui ont besoin d’une meilleure isolation sans le cout du single-tenancy complet.

Modele 3 : Application separee, base de donnees separee

Chaque tenant obtient sa propre instance applicative et sa propre base de donnees. Entierement isole. C’est essentiellement du single-tenancy, mais gere par le fournisseur SaaS plutot que par le client.

Architecture :

• Un deploiement applicatif dedie par tenant.
• Une base de donnees dediee par tenant.
• Une couche de routage (souvent un load balancer ou une API gateway) dirige le trafic vers la bonne instance.

Avantages :

• Isolation complete. Aucune ressource partagee entre tenants.
• Flexibilite maximale pour la personnalisation par tenant.
• Les performances d’un tenant n’affectent jamais un autre.
• Le plus simple du point de vue conformite.

Inconvenients :

• Cout d’infrastructure le plus eleve de loin.
• La complexite de deploiement croit lineairement avec le nombre de tenants.
• Les mises a jour doivent etre deployes sur chaque instance individuellement (ou automatisees avec soin).
• Non viable economiquement pour un grand nombre de petits tenants.

Ce modele est pertinent pour le SaaS enterprise ou les clients exigent une infrastructure dediee et sont prets a payer un supplement.

Avantages et inconvenients en un coup d’oeil

Facteur	Multi-Tenant (BD partagee)	Multi-Tenant (BD separees)	Single-Tenant
Cout d’infrastructure	Le plus bas	Moyen	Le plus eleve
Isolation des donnees	Logique (niveau ligne)	Physique (niveau base)	Complete
Complexite de deploiement	Faible	Moyenne	Elevee
Vitesse de mise a jour	Instantanee pour tous	App instantanee, migrations par BD	Deploiement par instance
Personnalisation	Limitee	Limitee	Totale
Conformite	Plus difficile	Moderee	La plus facile
Scalabilite (nombre de tenants)	Excellente	Bonne	Faible
Risque de voisin bruyant	Eleve	Moyen	Aucun

Isolation des donnees et securite

L’isolation des donnees est la consideration la plus importante dans tout modele de tenancy. Une faille de securite ou un tenant accede aux donnees d’un autre tenant est catastrophique pour un business SaaS. Cela peut detruire la confiance, violer les reglementations et mettre fin a l’entreprise.

Securite au niveau des lignes

Dans un modele de base de donnees partagee, le Row-Level Security (RLS) de PostgreSQL est l’une des meilleures defenses contre les fuites de donnees. Le RLS impose l’isolation des tenants au niveau de la base de donnees, pas au niveau applicatif. Meme si votre code applicatif a un bug qui oublie de filtrer par tenant, la base de donnees elle-meme empeche l’acces inter-tenant.

Voici comment le configurer :

-- Enable RLS on a table
ALTER TABLE projects ENABLE ROW LEVEL SECURITY;

-- Create a policy that restricts access to the current tenant
CREATE POLICY tenant_isolation ON projects
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);

-- Force RLS even for table owners
ALTER TABLE projects FORCE ROW LEVEL SECURITY;

Avant d’executer une requete, definissez le contexte du tenant :

-- Set at the beginning of each request/transaction
SET LOCAL app.current_tenant_id = 'a1b2c3d4-e5f6-7890-abcd-ef1234567890';

-- Now this query automatically returns only the current tenant's data
SELECT * FROM projects;
-- No WHERE clause needed. RLS handles it.

Isolation au niveau applicatif

En plus de la securite au niveau de la base de donnees, votre application doit imposer les frontieres de tenant :

// Middleware that sets tenant context on every request
async function tenantMiddleware(req: Request, res: Response, next: NextFunction) {
  const tenantId = extractTenantId(req); // From JWT, subdomain, or header

  if (!tenantId) {
    return res.status(401).json({ error: "Tenant not identified" });
  }

  // Set tenant context for the database connection
  await db.raw(`SET LOCAL app.current_tenant_id = '${tenantId}'`);

  req.tenantId = tenantId;
  next();
}

La defense en profondeur est le principe ici. Ne vous fiez jamais a une seule couche d’isolation. Combinez le filtrage au niveau applicatif, la securite au niveau de la base de donnees et des audits de securite reguliers.

Considerations de performance

Defis de la base de donnees partagee

Dans une base de donnees partagee, tous les tenants se disputent les memes ressources. Un tenant qui lance un rapport lourd peut ralentir les requetes de tout le monde. Les mesures d’attenuation incluent :

• Connection pooling. Utilisez PgBouncer ou un outil similaire pour empecher un tenant d’epuiser les connexions a la base de donnees.
• Timeouts de requete. Definissez des temps d’execution maximaux pour qu’une requete hors de controle ne puisse pas verrouiller les ressources indefiniment.
• Rate limiting. Imposez des limites par tenant sur les requetes API et les operations de base de donnees.
• Replicas en lecture. Routez les operations de lecture lourdes (rapports, exports) vers une replica pour ne pas affecter la base de donnees primaire.

Avantages des bases de donnees separees

Avec des bases de donnees par tenant, l’isolation des performances est integree. La charge de travail lourde d’un tenant n’affecte que sa propre base de donnees. Vous pouvez aussi provisionner des bases de donnees plus ou moins grandes en fonction du plan et de l’utilisation de chaque tenant.

Le compromis est la charge de gestion. Surveiller 500 bases de donnees est plus difficile que d’en surveiller une seule. L’outillage automatise devient essentiel.

Implications de cout a grande echelle

Regardons quelques chiffres approximatifs. Supposons que vous avez 100 tenants.

Base de donnees partagee (multi-tenant) :

• 1 cluster applicatif : ~200 EUR/mois
• 1 instance PostgreSQL geree : ~100 EUR/mois
• Total : ~300 EUR/mois (3 EUR par tenant)

Bases de donnees separees (multi-tenant) :

• 1 cluster applicatif : ~200 EUR/mois
• 100 petites instances de base de donnees : ~2 000 EUR/mois
• Total : ~2 200 EUR/mois (22 EUR par tenant)

Single-tenant :

• 100 instances applicatives : ~5 000 EUR/mois
• 100 instances de base de donnees : ~2 000 EUR/mois
• Total : ~7 000 EUR/mois (70 EUR par tenant)

Ces chiffres sont simplifies, mais le schema se confirme. L’infrastructure partagee est drastiquement moins chere. A 1 000 tenants, l’ecart se creuse encore plus.

C’est pourquoi la tarification doit s’aligner avec l’architecture. Si vous facturez 20 EUR par mois et exploitez une infrastructure single-tenant a 70 EUR par tenant, vous perdez de l’argent sur chaque client.

Quand choisir le multi-tenant

L’architecture multi-tenant est le bon choix quand :

• Vous construisez du SaaS B2B pour les PME. Volume eleve, prix bas et fonctionnalites standardisees.
• L’efficacite des couts compte. Vous devez maintenir les couts d’infrastructure bas par rapport aux revenus.
• Vous voulez des mises a jour rapides et uniformes. Deployez une fois, tous les tenants beneficient de l’amelioration.
• Vos clients n’exigent pas d’infrastructure dediee. La plupart des petites et moyennes entreprises ne se soucient pas de l’emplacement de leurs donnees, tant qu’elles sont securisees.
• Vous etes en phase de demarrage. Commencez en multi-tenant. C’est moins cher et plus simple. Vous pourrez toujours proposer du single-tenant plus tard pour les clients enterprise.

Quand choisir le single-tenant

L’architecture single-tenant est pertinente quand :

• Vous vendez aux grandes entreprises. Les grandes organisations exigent souvent une infrastructure dediee dans leur processus d’achat.
• La conformite l’exige. Les secteurs comme la sante (HIPAA), la finance (SOX, PCI-DSS) et le gouvernement ont des exigences strictes d’isolation des donnees.
• Les clients ont besoin de personnalisation. Si chaque client necessite des configurations, integrations ou fonctionnalites differentes, le single-tenant vous donne la flexibilite.
• Votre prix le permet. Si vous facturez 5 000 EUR ou plus par mois par client, le cout d’infrastructure est facilement justifie.
• La residence des donnees est une exigence ferme. Quand les donnees doivent resider dans un pays specifique, une infrastructure separee par tenant est l’approche la plus directe.

Approches hybrides

Vous n’etes pas oblige de choisir un seul modele. De nombreuses entreprises SaaS a succes utilisent un modele hybride :

• Multi-tenant pour les niveaux standard. Les clients gratuits, starter et pro partagent l’infrastructure. Cela maintient les couts bas et vous permet de passer a l’echelle.
• Single-tenant pour l’enterprise. Les clients premium obtiennent des instances dediees avec des SLA personnalises, des certifications de conformite et un support dedie.

Le code applicatif est le meme. Le modele de deploiement differe. Cela necessite une bonne automatisation de l’infrastructure, mais c’est un pattern eprouve.

Comment implementer un modele hybride

1. Construisez l’app en multi-tenant d’abord. Toute la logique d’isolation des tenants reste la meme quel que soit le modele de deploiement.
2. Utilisez l’infrastructure-as-code (Terraform, Pulumi ou CDK) pour automatiser la creation d’environnements.
3. Creez un pipeline de provisionnement capable de lancer un nouvel environnement dedie en minutes, pas en jours.
4. Maintenez un code unique. La meme image Docker tourne dans les environnements partages et dedies. La configuration (pas le code) determine le comportement.

Strategies de base de donnees en detail

La base de donnees est l’endroit ou les decisions de tenancy ont le plus d’impact. Voici trois strategies eprouvees.

Strategie 1 : Tables partagees avec tenant_id

Chaque table a une colonne tenant_id. Toutes les requetes filtrent dessus.

CREATE TABLE projects (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id),
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

CREATE INDEX idx_projects_tenant ON projects(tenant_id);

-- Always query with tenant context
SELECT * FROM projects WHERE tenant_id = $1;

Ideal pour : La plupart des produits SaaS. Simple, economique, bien compris.

Strategie 2 : Schema par tenant

Chaque tenant obtient son propre schema PostgreSQL au sein d’une base de donnees partagee. Les tables ont la meme structure, mais les donnees sont physiquement separees.

-- Create a schema for a new tenant
CREATE SCHEMA tenant_abc123;

-- Create tables in the tenant's schema
CREATE TABLE tenant_abc123.projects (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Set the search path per request
SET search_path TO tenant_abc123, public;

-- Now queries are automatically scoped
SELECT * FROM projects;

Ideal pour : Les produits qui ont besoin d’une isolation plus forte que le niveau ligne mais qui ne veulent pas le cout de bases de donnees separees. Fonctionne bien jusqu’a quelques centaines de tenants.

Strategie 3 : Bases de donnees separees

Chaque tenant obtient une instance PostgreSQL dediee (ou une base de donnees dediee sur un serveur partage).

// Database connection routing
class TenantDatabaseRouter {
  private connections: Map<string, DatabasePool> = new Map();

  async getConnection(tenantId: string): Promise<DatabasePool> {
    if (this.connections.has(tenantId)) {
      return this.connections.get(tenantId)!;
    }

    const config = await this.loadTenantDbConfig(tenantId);
    const pool = new DatabasePool({
      host: config.host,
      port: config.port,
      database: config.database,
      user: config.user,
      password: config.password,
    });

    this.connections.set(tenantId, pool);
    return pool;
  }

  private async loadTenantDbConfig(tenantId: string): Promise<DbConfig> {
    // Look up tenant's database connection details
    // from a central configuration store
    return await configStore.get(`tenants/${tenantId}/database`);
  }
}

Ideal pour : Le SaaS enterprise avec des clients a forte valeur, des exigences de conformite strictes ou des obligations de residence des donnees.

Prendre la decision

Voici un cadre de decision simple :

1. Quelle est la taille de vos clients cibles ? PME oriente vers le multi-tenant. Enterprise oriente vers le single-tenant ou hybride.
2. Quel est votre prix ? En dessous de 100 EUR/mois, vous avez besoin du multi-tenant pour etre rentable. Au-dessus de 1 000 EUR/mois, le single-tenant devient viable.
3. Quelles sont les exigences de conformite ? Les secteurs reglementes necessitent souvent une isolation plus forte.
4. Combien de tenants prevoyez-vous ? Des centaines ou milliers de tenants necessitent une infrastructure partagee. Dix a cinquante gros tenants peuvent fonctionner avec des instances dediees.
5. Quelle est la capacite operationnelle de votre equipe ? Le single-tenant requiert plus d’investissement DevOps. Le multi-tenant est operationnellement plus simple.

Si vous n’etes pas sur, commencez en multi-tenant avec une base de donnees partagee et la securite au niveau des lignes. C’est l’option la moins couteuse, elle est securisee quand elle est correctement implementee, et elle garde votre architecture simple. Vous pouvez toujours ajouter un tier dedie pour les clients enterprise plus tard.

Le mot de la fin

Il n’existe pas de modele de tenancy universellement correct. Le bon choix depend de vos clients, de votre tarification, de vos exigences de conformite et de vos capacites operationnelles.

La plupart des produits SaaS devraient commencer en multi-tenant. C’est moins cher, plus simple et passe bien a l’echelle. A mesure que vous montez en gamme et commencez a vendre a de plus grandes organisations, ajoutez des options single-tenant pour les clients qui en ont besoin et qui sont prets a payer en consequence.

L’architecture doit servir le business, pas l’inverse. Construisez pour les clients que vous avez aujourd’hui, et concevez avec assez de flexibilite pour servir les clients que vous voulez demain.

---

Besoin d’aide pour choisir la bonne architecture pour votre produit SaaS ? Nous avons construit des systemes multi-tenant et single-tenant dans de nombreux secteurs. Trouvons ensemble la meilleure approche pour votre projet.