L’hébergement multi-tenant dans le cloud est un modèle où les mêmes serveurs et logiciels servent de nombreux clients, avec une isolation logique entre tenants. Pensez à un immeuble : les appartements partagent la structure, la plomberie et l’électricité, mais chaque porte ferme à clé. L’alternative — l’hébergement single-tenant — est une maison individuelle : contrôle total, loyer plus élevé, et une plus grande part de l’entretien vous revient.
Points clés
| Question | Réponse |
|---|---|
| Ce que c’est | Serveurs et logiciels partagés, de nombreux clients, des données séparées logiquement |
| Pourquoi cela existe | Mutualiser l’infrastructure est ce qui rend la tarification du cloud possible |
| La partie difficile | L’isolation — un tenant ne doit jamais voir les données des autres ni ressentir leur charge |
| vs. single-tenant | Moins cher, onboarding plus rapide, un seul cycle de mises à jour — au prix de la séparation physique |
| Où placer l’isolation | Dans la couche de données — pas dans la clause WHERE de chaque requête |
Comment les données des tenants restent séparées
Tout système multi-tenant répond d’abord à une question : où vit l’isolation ? Au niveau de la base de données, il existe trois modèles canoniques — schema partagé, schema par tenant et base par tenant. Le schema partagé est le cheval de trait, et il est le plus sûr quand la base de données elle-même impose la frontière :
-- Modèle 1 : schema partagé — chaque ligne porte son tenant
CREATE TABLE invoices (
id bigserial PRIMARY KEY,
tenant_id uuid NOT NULL,
amount numeric(10,2) NOT NULL
);
-- Imposez l'isolation dans la base de données, pas dans chaque requête
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON invoices
USING (tenant_id = current_setting('app.tenant_id')::uuid);Avec une politique au niveau des lignes, une requête qui oublie son filtre de tenant ne renvoie rien au lieu de tout renvoyer — le mode de défaillance passe de la fuite de données à la page vide.
Sur un Backend as a Service, le même principe s’exprime par un contrôle d’accès par objet plutôt que par des politiques SQL. Chaque enregistrement porte une ACL qui désigne le rôle du tenant autorisé à le voir, et la plateforme l’impose à chaque requête :
// JavaScript / Node.js — Back4app JS SDK
const doc = new Parse.Object('Invoice');
doc.set('amount', 480);
const acl = new Parse.ACL();
acl.setPublicReadAccess(false); // invisible to every other tenant
acl.setRoleReadAccess('tenant-acme', true);
acl.setRoleWriteAccess('tenant-acme', true);
doc.setACL(acl);
await doc.save();// Flutter / Dart — Back4app Flutter SDK
final doc = ParseObject('Invoice')..set('amount', 480);
final acl = ParseACL();
acl.setPublicReadAccess(allowed: false);
acl.setRoleReadAccess('tenant-acme', true);
acl.setRoleWriteAccess('tenant-acme', true);
doc.setACL(acl);
await doc.save();// iOS / Swift — Back4app Swift SDK
var doc = Invoice()
doc.amount = 480
var acl = ParseACL()
acl.publicRead = false
acl.setReadAccess(roleName: "tenant-acme", value: true)
acl.setWriteAccess(roleName: "tenant-acme", value: true)
doc.ACL = acl
doc.save { _ in }// Android / Kotlin — Back4app Android SDK
val doc = ParseObject("Invoice").apply { put("amount", 480) }
val acl = ParseACL().apply {
publicReadAccess = false
setRoleReadAccess("tenant-acme", true)
setRoleWriteAccess("tenant-acme", true)
}
doc.acl = acl
doc.saveInBackground()L’isolation est un spectre, pas un interrupteur
Entre « tout partagé » et « tout dédié » se trouvent les trois formes de déploiement parmi lesquelles choisissent la plupart des systèmes réels :
Les plateformes matures les combinent : pool pour les nombreux petits tenants, bridge pour ceux de taille moyenne, silo pour les rares qui sont réglementés, énormes ou bruyants. L’erreur consiste à traiter ce choix comme global — il peut se faire par offre, et même par composant.
Hébergement multi-tenant vs. single-tenant
| Dimension | Multi-tenant | Single-tenant |
|---|---|---|
| Coût par tenant | Faible — l’infrastructure est amortie | Élevé — stack dédié par client |
| Isolation des données | Logique (politiques, ACL, schémas) | Physique (instance et base de données séparées) |
| Rayon d’impact | Un incident peut toucher de nombreux tenants | Limité à un seul client |
| Noisy neighbors (voisins bruyants) | Possibles ; exigent quotas et throttling | Aucun — les ressources sont privées |
| Mises à niveau | Un seul déploiement met tout le monde à jour | Chaque instance est patchée séparément |
| Onboarding | Changement de configuration, en minutes | Provisionnement, de quelques heures à plusieurs semaines |
| Personnalisation | Configuration et feature flags | Modifications profondes possibles par instance |
| Adéquation à la conformité | Suffisante pour la plupart ; frictions sous des régimes stricts | Préféré face à des exigences d’isolation stricte |
| Usage typique | SaaS, BaaS, plateformes cloud partagées | Secteurs réglementés, offres enterprise premium |
Deux sens à bien distinguer
« Hébergement multi-tenant dans le cloud » s’emploie à deux altitudes différentes, et la plupart des explications les confondent :
- Comme niveau d’hébergement : l’hébergement mutualisé — votre charge de travail tourne sur les mêmes machines physiques que celles d’autres clients. C’est le mode par défaut de tout cloud public ; la définition du NIST cite la mutualisation des ressources entre tenants comme une caractéristique essentielle du cloud computing lui-même.
- Comme architecture applicative : votre propre produit sert ses clients depuis un backend partagé — la façon dont se construit le logiciel par abonnement. Ici, le propriétaire, c’est vous, et l’isolation des tenants devient votre responsabilité — c’est là qu’interviennent les modèles décrits plus haut.
Les deux se combinent : un produit SaaS (multi-tenancy au niveau applicatif) tourne généralement sur une infrastructure cloud mutualisée (multi-tenancy au niveau de l’hébergement), chaque couche isolant ses propres tenants.
Le problème du noisy neighbor
Partager, c’est subir la contention : l’import massif d’un tenant peut ralentir le checkout d’un autre. Les parades classiques, par ordre d’escalade :
- Quotas et rate limiting par tenant — plafonner ce que chaque tenant peut consommer par fenêtre.
- Ordonnancement des ressources et autoscaling — absorber les pics avant qu’ils ne deviennent la latence de quelqu’un d’autre.
- Séparation des charges de travail — déplacer les jobs lourds (exports, analytique) vers des files d’attente en arrière-plan, hors du chemin des requêtes.
- Silo partiel — quand un tenant tourne constamment à plein régime, donner au composant sous contention (généralement la base de données) sa propre partition et laisser le reste mutualisé.
Cas d’usage courants
- Produits SaaS. Toute app par abonnement qui sert tous ses clients depuis une seule base de code — le cas canonique, et la raison d’être du modèle.
- BaaS et hébergement de plateformes. Les plateformes font tourner des milliers d’apps sur une infrastructure partagée et isolée, si bien que provisionner chaque app ne coûte presque rien — le modèle derrière les offres gratuites.
- Applications B2B avec espaces de travail par tenant. Un déploiement, de nombreuses organisations clientes, chacune avec ses utilisateurs, ses rôles et sa frontière de données.
- Plateformes internes. Un déploiement d’analytique ou d’outillage partagé entre départements, isolé par équipe.
- Agences qui gèrent de nombreuses apps clientes. Une plateforme partagée en dessous, un backend isolé par client au-dessus.
Multi-tenant, single-tenant ou mixte ? Matrice de décision
| Choisissez le multi-tenant quand… | Choisissez le single-tenant quand… | Choisissez le mixte quand… |
|---|---|---|
| Vous servez de nombreux clients avec un seul produit | La réglementation ou les contrats exigent une isolation physique | La plupart des tenants sont standard, quelques-uns sont réglementés |
| Le coût par client doit tendre vers zéro | Le SLA d’un client justifie une capacité dédiée | Un tenant est 100× plus gros que la médiane |
| Vous voulez un seul cycle de mises à jour pour tous | La personnalisation poussée par client est le produit | Il vous faut une offre premium « dédiée » |
| L’onboarding doit être en libre-service et instantané | Vos clients se comptent sur les doigts d’une main | Un tenant bruyant a besoin de sa propre base de données |
Partez du multi-tenant par défaut et n’en sortez que tenant par tenant, quand c’est mérité — greffer la tenancy après coup sur une base de code single-tenant est bien plus difficile que de placer plus tard un client trop gourmand dans un silo.
Limites et trade-offs
- L’isolation ne vaut que ce que vaut son application. Un filtre de tenant oublié dans le code applicatif est la fuite de données entre tenants classique. Poussez la frontière dans la couche de données — politiques au niveau des lignes, ACL par objet — pour que la plateforme échoue en mode fermé.
- Rayon d’impact partagé. Une panne, un mauvais déploiement ou une brèche peut toucher tous les tenants à la fois. Les déploiements progressifs et les sauvegardes par tenant réduisent l’impact, pas le partage.
- Les noisy neighbors sont structurels. Quotas et ordonnancement gèrent la contention ; seul le silo partiel la supprime, au prix d’un silo partiel.
- Plafond de personnalisation. Les tenants partagent une seule base de code, donc le comportement propre à chaque tenant vit dans la configuration et les feature flags — une contrainte que les clients single-tenant n’ont pas.
- Le contexte de tenant partout. Chaque requête, clé de cache, job et ligne de log doit connaître le tenant ; la complexité passe de l’infrastructure à l’application — précisément la charge que l’isolation gérée dans la couche de données a vocation à absorber.
L’hébergement multi-tenant sur Back4app
Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Elle est multi-tenant aux deux altitudes. En tant que plateforme, elle fait tourner des milliers de backends d’apps isolés sur une infrastructure partagée — c’est pourquoi un nouveau backend se provisionne en quelques minutes avec l’offre gratuite. Pour les tenants de votre application, l’isolation est une fonctionnalité de la couche de données plutôt qu’une convention : chaque objet porte une ACL, les rôles regroupent les utilisateurs par tenant, et les permissions au niveau de la classe fixent des règles à l’échelle du schéma, le tout imposé par Back4app à chaque requête. L’analyse approfondie de l’équipe d’ingénierie sur la sécurité au niveau des lignes montre le modèle complet sur une base de données orientée documents — sans discipline de clause WHERE à respecter.
Questions fréquentes
Qu'est-ce que la multi-tenancy dans le cloud computing ?
Une architecture dans laquelle une seule instance logicielle — et l'infrastructure qui la porte — sert plusieurs clients, appelés tenants. Les tenants partagent le calcul, le stockage et une même base de code, mais les données de chacun sont isolées logiquement et invisibles pour les autres. C'est le modèle qui fait fonctionner l'économie du cloud : ajouter un client est un changement de configuration, pas du matériel supplémentaire.
Quelle est la différence entre hébergement multi-tenant et single-tenant ?
Le single-tenant donne à chaque client une instance et une base de données dédiées — contrôle maximal et isolation physique, pour un prix plus élevé, chaque instance étant patchée et mise à niveau séparément. Le multi-tenant partage une instance entre tous les clients — coût par tenant plus bas, un seul cycle de mises à jour pour tout le monde, et une isolation imposée logiquement plutôt que physiquement. La plupart des SaaS fonctionnent en multi-tenant ; les clients réglementés ou très grands justifient parfois le single-tenant.
Un cloud multi-tenant est-il sûr ?
Oui, quand l'isolation est correctement imposée — les tenants ne peuvent pas voir les données les uns des autres. Les risques résiduels sont les bugs applicatifs qui oublient un filtre de tenant, et le rayon d'impact plus large d'un système partagé : une brèche ou une panne peut toucher chaque tenant. C'est pourquoi les conceptions les plus robustes descendent l'isolation jusqu'à la couche de données — politiques au niveau des lignes et contrôle d'accès par objet — au lieu de compter sur chaque requête pour se souvenir de sa clause WHERE.
Qu'est-ce que le problème du noisy neighbor (voisin bruyant) ?
L'usage intensif du CPU, de la mémoire ou des I/O partagés par un tenant, qui dégrade les performances de tous les autres sur la même infrastructure. Les parades incluent des quotas et du rate limiting par tenant, l'ordonnancement des ressources, l'autoscaling et — quand un tenant tourne constamment à plein régime — le partitionnement du composant sous contention, généralement la base de données, dans son propre silo.
Comment les données des tenants restent-elles séparées dans un cloud partagé ?
Au niveau de la base de données, il existe trois modèles canoniques : un schema partagé où chaque ligne porte un identifiant de tenant (densité maximale, généralement associé à la sécurité au niveau des lignes), un schema par tenant dans une base partagée, et une base par tenant (isolation la plus forte, coût le plus élevé). En dessous, l'infrastructure ajoute ses propres couches : machines virtuelles, namespaces de conteneurs et micro-VM maintiennent séparées les charges de travail des tenants.
La multi-tenancy est-elle la même chose que la virtualisation ?
Non. La virtualisation découpe une machine physique en machines virtuelles isolées ; la multi-tenancy partage une instance applicative entre de nombreux clients. Les deux sont complémentaires — la virtualisation est l'un des mécanismes qu'utilisent les fournisseurs pour isoler les charges de travail des tenants, tandis que la multi-tenancy est le modèle d'architecture qui décide, en amont, de ce qui est partagé.
Quand devriez-vous plutôt choisir le single-tenant ?
Quand des régimes réglementaires stricts ou des contrats exigent une isolation physique ou la résidence des données, quand un client a besoin d'une personnalisation poussée par instance, ou quand la performance garantie d'un compte à forte valeur l'emporte sur le coût. La réponse de plus en plus courante est la tenancy mixte : mutualiser la plupart des tenants sur une infrastructure partagée et placer en silo les rares qui sont réglementés, énormes ou bruyants.
Pourquoi la multi-tenancy compte-t-elle pour le SaaS ?
C'est l'architecture sur laquelle repose le logiciel par abonnement. Une seule base de code sert chaque client, si bien que correctifs et fonctionnalités arrivent chez tous les tenants en même temps ; l'utilisation du matériel est répartie sur l'ensemble de la clientèle ; et l'onboarding d'un nouveau client ne coûte presque rien. Sans multi-tenancy, chaque abonnement porterait le prix de serveurs dédiés et d'une maintenance par client.