Multi-tenant : ce que c’est et comment choisir une architecture SaaS pour plusieurs clients

Lorsque vous planifiez un produit SaaS, une des premières décisions d’architecture semble anodine : chaque client reçoit-il sa propre copie de l’application et de la base de données, ou tous partagent-ils une seule instance ? Cette seconde réponse, c’est le multi-tenant (aussi « multitenancy »). Cette seule décision détermine ce que vous payez en infrastructure, la vitesse à laquelle un correctif atteint tous les clients, ce que vous pouvez répondre à un grand client qui interroge sur l’isolation des données — et la gravité des conséquences d’un seul bug de code.

Ce texte explique ce que signifie l’architecture multi-tenant selon les normes et la documentation des grands fournisseurs de cloud, quels modèles intermédiaires décrivent AWS et Microsoft, comment on sépare en pratique les données des clients dans une base, et où cette isolation peut échouer. Nous nous appuyons uniquement sur des sources vérifiables — normes, documentation technique, communiqués de sécurité et droit suisse de la protection des données.

Multi-tenant : ce que c’est

La définition la plus ancienne et la plus citée du cloud computing, NIST SP 800-145, de septembre 2011, place le partage de ressources parmi les cinq caractéristiques essentielles du cloud computing : « Resource pooling. The provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. » — traduction libre : « Mise en commun des ressources. Les ressources informatiques du fournisseur sont mises en commun pour servir plusieurs consommateurs selon un modèle multilocataire, les ressources physiques et virtuelles étant attribuées et réattribuées dynamiquement selon la demande des consommateurs. » (NIST SP 800-145)

NIST dit donc que le modèle multilocataire est simplement la façon dont le cloud fonctionne en général. Il ne dit pas, en revanche, ce que ce modèle exige. C’est la norme ISO/IEC 17788:2014 (identique à la recommandation UIT-T Y.3500) qui le précise, en définissant deux termes (citations en anglais, suivies d’une traduction libre) (UIT-T Y.3500) :

• multi-tenancy (§3.2.27) : « Allocation of physical or virtual resources such that multiple tenants and their computations and data are isolated from and inaccessible to one another. » — « Attribution de ressources physiques ou virtuelles de telle sorte que plusieurs locataires, ainsi que leurs calculs et leurs données, soient isolés les uns des autres et mutuellement inaccessibles. » ;
• tenant (§3.2.37) : « One or more cloud service users sharing access to a set of physical and virtual resources. » — « Un ou plusieurs utilisateurs d’un service cloud partageant l’accès à un ensemble de ressources physiques et virtuelles. »

Le mot « locataire » (tenant) compte. Ce n’est pas un simple utilisateur : c’est l’unité que l’on isole — dans un SaaS B2B typique, c’est l’entreprise cliente, avec l’ensemble de ses employés. Dans la définition ISO, l’enjeu n’est pas le partage mais l’isolation : les ressources sont partagées, mais les données d’un locataire doivent rester inaccessibles à un autre. Tout le reste de cet article porte sur la façon de garantir cela, et sur ce que cela coûte.

Nous expliquons ce qu’est le cloud computing lui-même, et en quoi diffèrent les modèles IaaS, PaaS et SaaS, séparément dans notre article sur le cloud computing.

Single tenant contre multi-tenant : ce que l’on gagne, ce que l’on perd

Les deux extrêmes sont simples à décrire. Dans un modèle single tenant, chaque client dispose de son propre environnement : sa propre instance d’application, sa propre base de données, souvent ses propres serveurs. Dans un modèle multi-tenant, tous les clients utilisent la même application et la même infrastructure, et la logique applicative et la base de données séparent leurs données.

Les différences se voient le plus nettement dans quatre domaines qui intéressent aussi bien le dirigeant que la personne responsable de la technologie.

Coût. Le partage des ressources explique pourquoi un SaaS peut coûter à un client une somme modeste par mois — quelques dizaines de francs, pas une nouvelle facture de serveur. En single tenant, chaque nouveau client signifie un nouvel environnement à déployer et à payer, même si cinq personnes seulement l’utilisent une fois par semaine. En multi-tenant, un nouveau client représente quelques lignes de plus dans une base de données.

Mises à jour. Dans le modèle partagé, vous déployez un correctif une fois, et tous les clients en bénéficient immédiatement. Dans le modèle à environnements séparés, chaque déploiement doit être répété pour chaque client — et si cela n’est pas entièrement automatisé, les environnements se retrouvent vite dans des versions différentes.

Isolation. Ici, l’avantage va au single tenant. Quand les données de chaque client résident dans sa propre base, une requête boguée ne peut pas montrer les données du client A au client B, car ces données ne figurent simplement pas dans la base de A. Dans le modèle partagé, cette frontière est tracée par le code et la configuration de la base — et chaque bug dans l’un ou l’autre est une fuite potentielle entre clients.

Personnalisation. Un environnement séparé est plus facile à adapter à un client : une région de résidence des données différente, une fenêtre de maintenance différente, son propre domaine, parfois ses propres extensions. Dans le modèle partagé, chaque différence de ce type doit être gérée à l’intérieur d’une seule application — généralement via des paramètres par locataire.

AWS souligne un point facile à oublier : même des environnements séparés par client ne transforment pas un produit en service géré. Le SaaS Lens indique : « a silo environment still relies on a shared identity, onboarding, and operational experience... This differentiates SaaS from a managed service model » — traduction libre : « un environnement silo repose malgré tout sur une identité, un processus d’intégration et une expérience opérationnelle partagés... C’est ce qui distingue le SaaS d’un modèle de service géré » (AWS SaaS Lens). En d’autres termes : si l’environnement de chaque client est construit et maintenu différemment, à la main, ce n’est plus du SaaS — c’est de l’hébergement sur mesure.

Trois modèles selon AWS : silo, pool et bridge

En pratique, peu de produits se situent entièrement d’un seul côté. Le Well-Architected SaaS Lens d’AWS décrit trois modèles (citations en anglais, suivies d’une traduction libre) (AWS, « Silo, Pool, and Bridge Models ») :

• silo — « The silo model refers to an architecture where tenants are provided dedicated resources. » — « Le modèle silo désigne une architecture où les locataires reçoivent des ressources dédiées. » ;
• pool — « the pool model of SaaS refers to a scenario where tenants share resources. This is the more classic notion of multi-tenancy » — « le modèle pool désigne un scénario où les locataires partagent des ressources. C’est la notion la plus classique du multi-tenant » ;
• bridge — « Bridge is meant to acknowledge the reality that SaaS businesses aren't always exclusively silo or pool. » — « Le modèle bridge reconnaît que les entreprises SaaS ne relèvent pas toujours exclusivement du silo ou du pool. »

Le modèle bridge est en pratique le plus fréquent, même si on le nomme rarement ainsi. Exemple typique : une application web partagée, mais des bases de données séparées pour les clients qui en ont besoin. Ou l’inverse — une base partagée pour tous, mais des files d’attente de tâches séparées pour les clients générant le plus de trafic.

AWS dispose aussi d’un document entièrement consacré à l’isolation, « SaaS Tenant Isolation Strategies », du 1er août 2020. Utile à connaître, avec une réserve : AWS le qualifie désormais lui-même de « for historical reference only » — à titre historique uniquement (AWS, document technique). Les solutions techniques précises qu’il décrit ont pu vieillir. Une phrase reste d’actualité et résume bien l’enjeu : « Crossing this boundary in any form would represent a significant and potentially un-recoverable event for a SaaS business. » — traduction libre : « Franchir cette frontière, sous quelque forme que ce soit, représenterait pour une entreprise SaaS un événement grave et potentiellement irréversible. »

Quatre modèles selon Microsoft

L’Azure Architecture Center de Microsoft aborde le même problème du côté des déploiements et distingue quatre modèles (Microsoft Learn, « Modèles de location pour une solution multilocataire ») :

1. Déploiements automatisés à locataire unique — « vous déployez un ensemble dédié d’infrastructure pour chaque locataire ». Le mot « automatisés » compte : des environnements séparés n’ont de sens que s’ils proviennent d’un seul modèle, et non d’un processus manuel.
2. Déploiements mutualisés complets — « un déploiement entièrement mutualisé dans lequel tous les composants sont partagés ».
3. Déploiements partitionnés verticalement — « Utilisez une combinaison de déploiements à locataire unique et de déploiements mutualisés. » Par exemple, les clients du plan de base atterrissent dans un environnement partagé, tandis que les clients grands comptes reçoivent le leur.
4. Déploiements partitionnés horizontalement — « vous avez certains composants partagés, mais vous en gérez d’autres avec des déploiements à locataire unique. Par exemple, vous pouvez créer une couche Application unique, puis déployer des bases de données individuelles pour chaque locataire ».

Deux phrases de ce document méritent d’être retenues plus que les noms des modèles eux-mêmes. La première : « Au lieu de considérer l’isolation comme une propriété discrète, voyez-la comme un spectre. » La seconde : « La sélection d’un modèle de location n’est pas seulement une décision technique. C’est aussi une décision commerciale. » Ce que vous pouvez promettre à un client dans un contrat, et à quel prix, découle directement de la façon dont vous avez construit l’isolation.

Comment les données sont réellement séparées : base séparée, schéma séparé ou tables partagées

La partie la plus importante de l’isolation, ce sont les données. Quel que soit le nom du modèle, au niveau de la base de données, vous avez le choix entre trois approches fondamentales.

Une base de données séparée par client. La séparation logique la plus forte : une requête exécutée dans la base du client A n’a physiquement aucun accès aux tables du client B. Il est aussi facile de restaurer la sauvegarde d’un client, de le déplacer vers une autre région, ou de supprimer toutes ses données à la fin d’un contrat. Le prix à payer est la maintenance : chaque changement de schéma doit être exécuté séparément sur chaque base, et le nombre de connexions et les coûts croissent avec le nombre de clients.

Une base partagée, un schéma séparé par client. Une solution intermédiaire : une seule instance de base de données, mais les tables de chaque client vivent dans leur propre espace de noms. La séparation est plus faible qu’avec des bases distinctes, et le problème de migration de schéma demeure — à l’intérieur d’un seul serveur, cette fois.

Tables partagées avec une colonne `tenant_id`. Le modèle pool classique : les enregistrements de tous les clients vivent dans les mêmes tables, et chaque ligne porte un identifiant de locataire. C’est la solution la moins chère et la plus simple à maintenir, mais Microsoft en indique directement le point faible : « Lorsque plusieurs locataires partagent un même déploiement …, vous vous appuyez généralement sur le code de votre application et sur un identificateur de locataire qui est dans une base de données pour séparer les données de chaque locataire. » (Microsoft Learn) Une seule requête sans clause WHERE tenant_id = …, et les données de tous les clients sont exposées.

Row Level Security dans PostgreSQL : une seconde ligne de défense

C’est précisément pour cela que, dans un modèle à tables partagées, il ne faut pas se fier au seul code applicatif. PostgreSQL dispose d’un mécanisme qui déplace ce contrôle dans la base elle-même : la Row Level Security (RLS). Sa documentation la décrit ainsi : les tables « can have row security policies that restrict, on a per-user basis, which rows can be returned by normal queries or inserted, updated, or deleted by data modification commands. This feature is also known as Row-Level Security. » — traduction libre : « peuvent disposer de politiques de sécurité au niveau des lignes, qui restreignent, par utilisateur, les lignes pouvant être renvoyées par des requêtes normales ou insérées, modifiées ou supprimées par des commandes de modification de données. Cette fonctionnalité est aussi appelée Row-Level Security. » (PostgreSQL, 5.9 Row Security Policies)

Simplifié, pour une table avec une colonne tenant_id, cela peut ressembler à ceci (une esquisse, pas du code prêt pour la production) :

1ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
2ALTER TABLE invoices FORCE ROW LEVEL SECURITY;
3
4CREATE POLICY tenant_isolation ON invoices
5  USING (tenant_id = current_setting('app.tenant_id')::uuid);
Copy

L’application définit l’identifiant de locataire pour la connexion, et la base ajoute elle-même la condition correspondante à chaque requête. Même si un développeur oublie le filtre, la base ne renverra pas les lignes d’un autre locataire.

La documentation de PostgreSQL donne trois règles qui déterminent si la RLS protège réellement (traduction libre) :

• Refus par défaut. Si aucune politique n’existe pour la table, une politique de refus par défaut est appliquée : aucune ligne n’est visible ni modifiable. Activer la RLS sans politique ferme la table — cela ne l’ouvre pas.
• Les superutilisateurs, et les rôles avec l’attribut BYPASSRLS, contournent toujours les politiques. Si votre application se connecte en tant que superutilisateur, la RLS ne s’applique simplement pas.
• Les propriétaires de table la contournent aussi généralement. Les propriétaires de table contournent normalement aussi la sécurité au niveau des lignes, bien qu’un propriétaire puisse choisir de s’y soumettre avec ALTER TABLE ... FORCE ROW LEVEL SECURITY. C’est un piège fréquent : l’application se connecte avec le même rôle que celui qui a créé les tables, et les politiques ne s’appliquent pas à lui. D’où la deuxième ligne de l’exemple ci-dessus.

Supabase : la RLS n’est active que selon sa configuration

Supabase est une plateforme populaire basée sur PostgreSQL, que beaucoup de startups utilisent pour construire un MVP. Ici, la RLS compte encore plus, car les tables peuvent être atteintes directement depuis le navigateur via une API. Sa documentation est sans ambiguïté : « A table in an exposed schema without RLS is readable and writable by any role with a grant on it. Enable RLS on every table in an exposed schema. » — traduction libre : « Une table d’un schéma exposé sans RLS peut être lue et modifiée par tout rôle disposant d’une autorisation sur elle. Activez la RLS sur chaque table d’un schéma exposé. » (Supabase, Row Level Security)

Deux autres pièges tirés de la même documentation (traduction libre) :

• la clé service_role donne un accès complet et contourne la RLS — elle doit donc rester côté serveur ; si elle se retrouve dans le code du frontend, l’isolation des locataires n’existe plus ;
• les vues : elles contournent la RLS par défaut, car elles sont généralement créées avec l’utilisateur postgres. Une vue construite sur une table dotée de politiques peut donc montrer toutes les lignes de tous les clients. Depuis PostgreSQL 15, on peut obliger une vue à respecter les politiques avec l’option security_invoker = true.

Supabase rappelle aussi que l’ajout de politiques ne supprime pas les autorisations par défaut accordées aux rôles. La RLS est une seconde ligne de défense, pas un substitut à une réflexion sur les autorisations elles-mêmes.

Le voisin bruyant, et les autres coûts du partage

L’isolation des données n’est pas le seul problème d’une infrastructure partagée. Le second porte un nom assez imagé pour s’être imposé dans la documentation : le problème du voisin bruyant (noisy neighbor). Microsoft le définit ainsi : « Le problème de voisin bruyant se produit lorsque les performances d’un locataire sont détériorées en raison des activités d’un autre locataire. » (Azure Architecture Center, « Antipattern de voisin bruyant »)

Dans un produit SaaS, cela se présente généralement de façon banale : un client importe un gros fichier, génère un rapport lourd, ou son intégration envoie des milliers de requêtes par minute — et l’application ralentit pour tous les autres. Microsoft ajoute une phrase à garder en tête avant de faire des promesses dans un contrat : « Le partage d’une seule ressource entraîne intrinsèquement le risque de problèmes de voisin bruyant que vous ne pouvez pas éviter complètement. »

On peut le limiter : des quotas de requêtes par locataire, des files d’attente séparées pour les tâches lourdes, une surveillance de la consommation de ressources par client, et, en dernier recours, le déplacement du plus grand client vers son propre environnement — ce qui revient à passer au modèle bridge. Si vous envisagez de promettre aux clients une garantie de disponibilité ou de temps de réponse, le voisin bruyant est un des risques à intégrer dans ces promesses (nous traitons des garanties elles-mêmes dans notre article sur le SLA).

D’autres coûts du partage sont moins visibles mais réels : il est plus difficile de restaurer les données d’un client à partir de la sauvegarde d’une base partagée sans toucher les autres, plus difficile de supprimer définitivement toutes les données d’un client à la fin d’un contrat, et chaque migration de base touche tout le monde à la fois.

Quand l’isolation échoue : ChaosDB et ExtraReplica

Le multi-tenant est-il sûr ? La meilleure réponse vient des cas où l’isolation des locataires a réellement été brisée — chez un fournisseur de la taille de Microsoft. Des chercheurs de Wiz ont décrit deux cas de ce type, que Microsoft a confirmés dans ses propres communiqués. Dans les deux cas, il s’agit de vulnérabilités découvertes par des chercheurs, pas de fuites de données confirmées.

ChaosDB — Azure Cosmos DB, 2021. Le 27 août 2021, le Microsoft Security Response Center a décrit une vulnérabilité dans la fonctionnalité Jupyter Notebook de Cosmos DB qui (traduction libre) « pouvait potentiellement permettre à un utilisateur d’accéder aux ressources d’un autre client en utilisant la clé principale de lecture-écriture du compte ». Le problème a été signalé le 12 août 2021, et Microsoft a désactivé la fonctionnalité en préversion et demandé aux clients l’ayant utilisée entre le 7 et le 13 août de régénérer leurs clés. La phrase clé du communiqué (traduction libre) : « Aucune donnée client n’a été consultée du fait de cette vulnérabilité, ni par des tiers ni par des chercheurs en sécurité. » (MSRC, 27 août 2021) Les chercheurs de Wiz ont décrit l’ampleur potentielle comme (traduction libre) « un accès complet et illimité aux bases de données de plusieurs milliers de clients Microsoft Azure » ; ils ont reçu une prime de 40 000 dollars pour ce signalement (Wiz, ChaosDB).

ExtraReplica — Azure Database for PostgreSQL Flexible Server, 2022. Le 28 avril 2022, Microsoft a décrit une vulnérabilité permettant (traduction libre) un « accès non autorisé à des bases de données d’autres comptes dans une région ». Parmi les causes figurait une expression régulière mal ancrée, permettant de contourner l’authentification. La vulnérabilité ne touchait que les serveurs utilisant l’option d’accès réseau public. Les correctifs ont été déployés le 13 janvier 2022 (isolation des locataires) et le 25 février 2022 (ensemble de l’infrastructure). Microsoft a déclaré (traduction libre) : « Notre analyse a révélé qu’aucune donnée client n’a été consultée à l’aide de cette vulnérabilité. » (MSRC, 28 avril 2022 ; Wiz, ExtraReplica)

Trois conclusions pour votre propre produit. D’abord, l’isolation des locataires n’est pas un seul verrou, mais plusieurs couches — dans ExtraReplica, un seul bug dans une expression régulière a suffi à en faire tomber une. Ensuite, dans les deux cas, la frontière a cédé en un point additionnel : une fonctionnalité en préversion et un mode d’accès réseau optionnel. Toute nouvelle fonctionnalité touchant les données de plusieurs clients mérite sa propre revue de sécurité. Enfin, pour pouvoir dire à vos clients, après une divulgation, si quelqu’un en a profité, il faut disposer de journaux permettant de le déterminer. Dans un petit SaaS, cela signifie au minimum journaliser l’accès aux données avec l’identifiant du locataire.

Protection des données en Suisse et SaaS multi-clients

Si votre SaaS traite des données personnelles pour le compte de vos clients, la nouvelle loi fédérale sur la protection des données (nLPD) s’applique directement. L’art. 8 fixe la base : « 1 Les responsables du traitement et les sous-traitants doivent assurer, par des mesures organisationnelles et techniques appropriées, une sécurité adéquate des données personnelles par rapport au risque encouru. 2 Les mesures doivent permettre d’éviter toute violation de la sécurité des données. » Le Conseil fédéral précise ensuite ce principe par l’ordonnance sur la protection des données (OPDo), qui donne un ancrage textuel plus précis pour l’isolation des locataires :

> Art. 3, al. 1, let. a : « les personnes autorisées n’aient accès qu’aux données personnelles dont elles ont besoin pour accomplir leurs tâches (contrôle de l’accès aux données) ».

>

> Art. 3, al. 2, let. d : « … [que la disponibilité des données personnelles et l’accès à celles-ci] puissent être rapidement restaurés en cas d’incident physique ou technique (restauration) ».

Il faut le dire honnêtement : ni l’art. 8 de la nLPD ni l’OPDo n’exigent littéralement de séparer les locataires, ni aucune architecture précise. Ce que nous en tirons relève de notre propre interprétation. Dans un SaaS multi-clients, le « contrôle de l’accès aux données » de l’art. 3, al. 1, let. a, est l’ancrage textuel le plus proche de l’isolation des locataires — les personnes autorisées ne devraient pouvoir accéder qu’aux données de leur propre locataire. L’exigence de restauration de l’art. 3, al. 2, let. d, se rattache au temps de reprise après un incident, que nous traitons dans notre article sur le SLA. Si votre produit propose aussi son service à des personnes dans l’Union européenne, le RGPD peut s’appliquer à cette partie de l’activité (art. 3, al. 2), même si le reste relève du droit suisse.

Nous traitons plus largement la répartition des responsabilités entre fournisseur et client, le contrat de sous-traitance et les questions à poser à un fournisseur cloud dans notre article sur la sécurité des données dans le cloud.

Comment choisir un modèle pour démarrer

Il n’y a pas de bonne réponse unique, mais il existe des questions qui réduisent vite le choix. À se poser avant que la première table n’existe dans la base.

Qui sont vos clients, et qu’exigeront-ils ? Si vous vendez à de petites entreprises payant un abonnement modeste, un modèle partagé est généralement le seul viable économiquement. Si vous visez des clients grands comptes, attendez-vous à des questions sur l’isolation des données, la région de résidence des données et les audits — parfois une exigence explicite de base séparée. Dans ce cas, concevez l’application dès le départ pour qu’elle puisse fonctionner dans les deux modes (le modèle bridge).

Combien pouvez-vous dépenser en infrastructure par client ? Microsoft a raison de parler ici de décision commerciale. Un environnement séparé pour un client payant un petit abonnement mensuel a rarement du sens ; pour un client avec un grand contrat annuel, c’est souvent le cas.

Quelle échelle visez-vous ? Quelques dizaines de clients se gèrent dans n’importe quel modèle. Avec des centaines ou des milliers de clients, des bases séparées signifient des centaines ou des milliers de migrations à chaque changement de structure de données.

Quelles réglementations et quels contrats vous lient ? Des données particulièrement sensibles, des exigences sectorielles, des clauses dans les contrats de sous-traitance de vos clients — tout cela peut imposer un niveau d’isolation plus élevé que celui que vous choisiriez pour des raisons de coût seules.

Pour la plupart des nouveaux produits, un point de départ raisonnable est un modèle partagé avec des tables partagées, une colonne d’identifiant de locataire sur chaque table contenant des données clients, et la Row Level Security comme seconde ligne de défense — conçu pour qu’un grand client puisse plus tard être isolé dans sa propre base. Cette architecture est peu coûteuse au départ et ne ferme pas la voie vers un modèle bridge. Le scénario le plus coûteux consiste à ajouter un identifiant de locataire à une application existante qui n’a jamais été conçue pour cela — il faut alors revoir chaque requête une par une.

Que coûte la construction d’une telle application ? Nous n’avons trouvé aucun référentiel suisse de coûts avec un échantillon publié — le SaaS multi-tenant se situe dans la catégorie la plus coûteuse des constructions sur mesure, aux côtés des intégrations ERP/CRM et des projets soumis à des exigences de conformité, principalement parce que le modèle de données, le modèle de droits d’accès et la couche d’isolation doivent être pensés ensemble plutôt qu’ajoutés après coup. Le point pratique à retenir tient moins à un chiffre qu’à une règle de séquence : planifiez la colonne `tenant_id` dès la première version, même dans le MVP le moins cher, afin que l’extension ultérieure de l’isolation ne signifie pas réécrire le modèle de données. Vous pouvez obtenir une estimation approximative pour votre propre périmètre avec notre calculateur de coût d’application web.

Si vous validez encore l’idée, commencez par notre article sur le MVP. Pour les briques dont une application SaaS a besoin au-delà de l’isolation des locataires elle-même — comptes, paiements, droits — voir notre article sur les applications SaaS, et pour le modèle d’affaires complet, notre guide du SaaS. Nous construisons des produits dans le cadre de nos services de création d’applications web et de MVP pour startups, et si vous avez d’abord besoin d’un avis indépendant sur votre architecture, nous pouvons vous aider via le conseil technologique.