SaaS multi-tenant : ce que le fondateur doit comprendre

Un SaaS multi-tenant sert tous ses clients avec une seule version du logiciel, sur une infrastructure en partie ou totalement partagée, et chaque client ne voit que ses propres données. C'est ce partage qui rend un SaaS rentable : vous n'exploitez pas cent serveurs pour cent clients. La contrepartie, c'est que l'isolement entre clients ne vient plus des murs de l'infrastructure, mais de la conception du logiciel.

Les ressources sur le sujet sont surtout des documentations d'architectes cloud, écrites pour des ingénieurs. Cet article s'adresse au fondateur ou au dirigeant qui doit trancher : quel modèle choisir, ce qu'il coûte, ce qu'il protège, et ce qu'il faudra répondre au premier grand compte qui demande sa propre base de données.

Le vocabulaire en une minute

• Locataire (tenant) : un client du SaaS, en B2B une entreprise. Il a plusieurs utilisateurs, ses propres données et ses propres réglages.
• Utilisateur : une personne qui se connecte, rattachée à un locataire.
• Déploiement : un ensemble d'infrastructure (serveurs, base de données, stockage) qui fait tourner le logiciel. Il peut servir un ou plusieurs locataires.
• Isolement : la garantie qu'un locataire ne voit ni ne perturbe les données et les performances d'un autre.

Le guide d'architecture de Microsoft Azure résume le point de départ : en B2B, un locataire correspond le plus souvent à une entreprise cliente, et tous ses salariés sont des utilisateurs de ce locataire. Il insiste aussi sur le fait que le choix du modèle n'est pas seulement technique, mais commercial.

Trois modèles, et un hybride

Les fournisseurs de cloud décrivent les mêmes modèles avec des mots différents ; AWS parle de « silo » pour ce qui est dédié et de « pool » pour ce qui est partagé.

Tout mutualisé. Une application, une base, une colonne « client » dans chaque table. Microsoft le présente comme le modèle le moins cher à exploiter, avec trois risques à maîtriser : la fuite de données entre clients, le « voisin bruyant » (un gros client qui ralentit les autres) et la mise à jour qui touche tout le monde à la fois.

Base par client. L'application reste commune, chaque client a sa base. L'isolement des données est plus fort, et un client qui sollicite beaucoup sa base ne dégrade pas celle des autres. En contrepartie, chaque évolution du schéma doit être appliquée à toutes les bases.

Déploiement dédié. Chaque client a son propre ensemble d'infrastructure. Microsoft le résume sans détour : si un client coûte une certaine somme en infrastructure, cent clients coûtent probablement cent fois plus. C'est le modèle des clients aux exigences réglementaires fortes.

Hybride. La plupart des clients sont mutualisés, quelques-uns ont un déploiement dédié. AWS décrit exactement ce cas : des clients d'une offre de base dans l'environnement partagé, des clients premium qui paient plus pour leur propre environnement. Il ajoute une règle essentielle : ces environnements dédiés doivent tourner avec la même version et la même configuration, sans personnalisation au cas par cas.

Ce que ce choix change pour vous

Pour un SaaS qui démarre, le modèle mutualisé est presque toujours le bon point de départ : il garde le coût de développement et d'exploitation sous contrôle pendant que vous cherchez vos premiers clients. Le dédié devient pertinent quand un client paie pour l'obtenir.

Comment l'isolement se garantit dans un modèle mutualisé

C'est la question à poser à votre prestataire, et la réponse doit être précise.

• Un identifiant client partout. Chaque table qui contient des données d'un client porte cet identifiant, sans exception.
• Un filtre appliqué au même endroit, pas requête par requête. Si chaque développeur doit penser à filtrer, un oubli suffit à exposer les données d'un autre client. Une règle centrale protège même du code écrit à la hâte.
• Une protection au niveau de la base. PostgreSQL propose la sécurité au niveau des lignes (Row-Level Security), qui restreint les lignes visibles selon des politiques. Attention, sa documentation précise que le propriétaire de la table et les super-utilisateurs y échappent par défaut : l'application doit donc se connecter avec un rôle soumis aux politiques.
• Tout ce qui n'est pas la base. Fichiers déposés, caches, index de recherche, exports, journaux, tâches planifiées : chacun doit savoir à quel client il appartient.
• Des tests qui essaient de tricher. Un test automatique se connecte en tant que client A et tente de lire les données du client B. Microsoft recommande de tester ainsi l'isolement, quel que soit le modèle.

Ces mesures s'ajoutent aux essentiels de sécurité d'une application métier, elles ne les remplacent pas.

Les clients exigeants

Tôt ou tard, un prospect plus gros que les autres pose ses conditions. Les plus fréquentes :

• Une base de données ou un environnement dédié, pour des raisons de conformité ou de politique interne.
• Un hébergement localisé, en France ou dans l'Union européenne, parfois avec une certification particulière. Notre article sur où héberger une application métier détaille les niveaux d'exigence.
• La connexion avec son propre annuaire d'entreprise (authentification unique).
• Un niveau de service écrit et des engagements sur les sous-traitants.

Un SaaS conçu pour l'hybride peut dire oui sans réécriture : il sait sur quel déploiement se trouve chaque client et sait en créer un nouveau automatiquement. Ce oui a un coût, qui doit apparaître dans votre grille, comme une formule supérieure ou un devis. Notre guide pour fixer le prix d'un SaaS B2B en parle.

Multi-tenant et RGPD

Dans un SaaS B2B, vous traitez les données de vos clients pour leur compte : au sens du RGPD, vous êtes en général leur sous-traitant. L'article 28 du RGPD impose notamment qu'au terme du service vous supprimiez ou renvoyiez les données personnelles, au choix du client. Dans un modèle mutualisé, cela veut dire savoir extraire et effacer les données d'un seul client, partout où elles se trouvent, sans toucher aux autres. C'est simple si l'identifiant client est présent partout ; c'est un chantier s'il ne l'est pas.

Le contrat qui encadre tout cela, avec l'accord de sous-traitance, est traité dans contrat SaaS : CGV, niveau de service et sous-traitance RGPD.

Commencer simple, sans se fermer de portes

La recommandation la plus utile tient en trois points :

1. Mettez l'identifiant client partout dès la première version, même si vous n'avez qu'un client. L'ajouter après coup oblige à reprendre chaque table, chaque requête et chaque tâche de fond.
2. Commencez mutualisé, avec un filtre central et des tests d'isolement.
3. Prévoyez une table qui associe chaque client à son déploiement. Microsoft souligne qu'un code prévu pour le mutualisé et le dédié permet ensuite de déplacer un client vers son propre environnement.

C'est aussi le cas typique d'un outil interne qui devient un produit : notre article sur transformer un outil interne en SaaS montre que l'ajout du multi-tenant est souvent le plus gros du chantier.

Les questions à poser à votre prestataire

• Quel modèle proposez-vous, et pourquoi pour mon cas ?
• Où l'identifiant client est-il vérifié : à un endroit central, ou dans chaque requête ?
• Comment testez-vous qu'un client ne peut pas lire les données d'un autre ?
• Comment supprime-t-on toutes les données d'un seul client ?
• Que faudrait-il pour offrir un environnement dédié à un client, et combien de temps cela prendrait-il ?
• Comment déroulez-vous une mise à jour sans interrompre tous les clients ?

Par où commencer

Listez vos clients cibles et leurs exigences probables : taille, secteur, données sensibles, attentes d'hébergement. Si aucun ne demandera d'environnement dédié à court terme, partez sur un modèle mutualisé bien isolé, conçu pour accueillir un jour des déploiements dédiés. Si votre marché est réglementé, prévoyez l'hybride dès le départ et intégrez son coût dans votre prix.