Une architecture multi-tenant permet à une seule plateforme SaaS de servir plusieurs entreprises clientes, appelées tenants, chacune ne voyant que ses propres données. Trois modèles coexistent : le silo, où chaque client dispose de sa propre infrastructure ; le pool, où tout est partagé ; et un modèle hybride, qui partage certaines couches et en isole d’autres. Pour un SaaS B2B qui démarre, le choix se fait entre coût d’exploitation, exigences d’isolation des clients et capacité à grandir sans intervention manuelle à chaque signature.
Ce guide explique ces notions sans jargon inutile, pour les dirigeants et porteurs de projet qui veulent lancer un produit SaaS et dialoguer d’égal à égal avec leurs équipes techniques.
Qu’est-ce qu’un tenant, et pourquoi tout part de là ?
Un tenant (littéralement « locataire ») est l’unité pour laquelle la plateforme isole les données, la configuration et souvent la facturation. Dans un SaaS B2B, le tenant correspond généralement à une entreprise cliente, qui compte plusieurs utilisateurs. Le guide d’architecture de Microsoft invite pourtant à se poser la question sérieusement : un client peut avoir besoin de plusieurs tenants (une filiale par pays, un environnement de test séparé de la production).
L’image la plus parlante est celle d’un immeuble. Le silo, c’est une maison individuelle par client : très isolée, coûteuse à construire et à entretenir. Le pool, c’est un immeuble où chaque client a son appartement fermé à clé : les fondations, l’ascenseur et le chauffage sont partagés. Le modèle hybride, c’est un immeuble avec quelques étages réservés aux clients qui exigent davantage d’intimité.
Cette définition structure tout le reste : modèle de données, droits d’accès, facturation, support. Mieux vaut l’arrêter pendant le cadrage du MVP que de la découvrir au dixième client.
Silo, pool ou hybride : les trois modèles d’architecture
Le livre blanc d’Amazon Web Services sur les stratégies d’isolation des tenants emploie un vocabulaire devenu courant dans le métier.
- Le silo : chaque client dispose de ses propres ressources (application, base de données, parfois compte d’hébergement). L’isolation est maximale, le risque de fuite entre clients très faible, mais les économies d’échelle disparaissent.
- Le pool : tous les clients partagent les mêmes ressources. C’est le modèle le plus efficace en coût, mais l’isolation repose entièrement sur l’application et la base de données.
- Le bridge (hybride) : certaines couches sont partagées, d’autres isolées. Exemple typique : une interface web commune, mais une base de données par client.
Microsoft décrit les mêmes options sous d’autres noms : déploiements dédiés automatisés, déploiement entièrement mutualisé, partitionnement vertical (certains clients sur une infrastructure partagée, d’autres sur une infrastructure dédiée) et partitionnement horizontal (certaines couches partagées, d’autres dédiées).
| Critère | Silo | Pool | Hybride |
|---|---|---|---|
| Isolation des données | Très forte, physique | Logique, dépend du code et de la base | Forte sur les couches isolées |
| Coût d’exploitation par client | Élevé, croît avec chaque client | Faible, mutualisé | Intermédiaire |
| Ajout d’un nouveau client | Déploiement complet à automatiser | Création d’un enregistrement | Selon la couche isolée |
| Mises à jour | Une par déploiement, à orchestrer | Une seule pour tous | Mixte |
| Effet « voisin bruyant » | Inexistant | Possible, à surveiller | Limité aux couches partagées |
| Adapté à | Quelques grands comptes très exigeants | Nombreux clients aux besoins proches | Offre standard plus option « dédiée » |
L’effet « voisin bruyant » (noisy neighbor) désigne la dégradation des performances subie par tous les clients quand l’un d’eux lance une opération très lourde sur une ressource partagée. Microsoft souligne que l’isolation est un spectre plutôt qu’un choix binaire : on peut isoler la base et mutualiser le reste, ou l’inverse.
Comment isoler les données de chaque client dans un modèle partagé ?
Dans le modèle pool, toutes les données de tous les clients cohabitent dans les mêmes tables. Chaque enregistrement porte un identifiant de tenant, et chaque requête doit filtrer sur cet identifiant. Le risque est évident : une seule requête oubliée, et un client voit les factures d’un autre.
Ce risque n’est pas théorique. Le contrôle d’accès défaillant occupe la première place du Top 10 2025 de l’OWASP, la référence mondiale des risques de sécurité des applications web ; selon l’OWASP, 100 % des applications testées présentaient une forme de contrôle d’accès défaillant. L’exemple type cité : consulter ou modifier le compte de quelqu’un d’autre en changeant simplement un identifiant dans l’adresse. Dans un SaaS, cela se traduit par la pire fuite possible, celle des données d’un client vers un concurrent.
Les bonnes pratiques tiennent en quatre couches de défense :
- L’identifiant de tenant déduit de la session, jamais d’un paramètre envoyé par le navigateur. L’utilisateur authentifié appartient à une organisation ; c’est elle qui détermine les données accessibles.
- Un filtrage centralisé dans le code, appliqué automatiquement à toutes les requêtes, plutôt que recopié à la main dans chaque écran.
- Un filtrage imposé par la base de données elle-même. PostgreSQL, par exemple, propose des politiques de sécurité au niveau des lignes (row-level security) : même si le code oublie un filtre, la base refuse de renvoyer les lignes d’un autre client.
- Des tests automatisés d’isolation exécutés à chaque livraison : on crée deux clients fictifs et on vérifie, écran par écran et API par API, que l’un ne peut rien lire ni modifier chez l’autre.
Ces mesures relèvent de la sécurité applicative au sens large, mais elles prennent une importance particulière dans un produit dont la promesse repose sur la confiance de clients concurrents entre eux.
Que faut-il prévoir dès le MVP ?
Un MVP doit rester minimal, mais certaines fondations sont très coûteuses à ajouter après coup. Voici la liste de celles qui ne se négocient pas :
- L’identifiant de tenant sur toutes les données, y compris les fichiers, les journaux, les files de traitement et les caches.
- Organisations, utilisateurs et rôles : un utilisateur appartient à une ou plusieurs organisations, avec un rôle dans chacune (administrateur, membre, lecteur).
- Une inscription automatisée : créer un nouveau client ne doit demander aucune intervention technique. La SaaS Lens d’AWS recommande un processus d’intégration des nouveaux clients (onboarding) automatisé de bout en bout.
- La mesure de l’usage par client : nombre d’utilisateurs actifs, volumes, appels d’API. Elle sert à la facturation, au support et à repérer les voisins bruyants.
- L’export et la suppression des données d’un client, pour la réversibilité contractuelle et pour répondre aux obligations du RGPD.
- Des paramètres par client (logo, champs personnalisés, règles métier activables) plutôt que des branches de code spécifiques, qui transformeraient le SaaS en collection de projets sur mesure.
- Une table de correspondance entre client et déploiement, même s’il n’y a qu’un déploiement au départ. C’est elle qui permettra plus tard de déplacer un grand compte vers une infrastructure dédiée.
Quel modèle choisir pour démarrer ?
Pour la plupart des SaaS B2B qui démarrent, le bon point de départ est un modèle partagé avec une isolation logique rigoureuse, conçu pour pouvoir isoler plus tard. Il permet de lancer vite, de mettre à jour tous les clients en une fois et de garder des coûts d’exploitation maîtrisés pendant la phase de recherche de clients.
Trois situations justifient d’aller d’emblée vers plus d’isolation :
- Des clients réglementés (santé, finance, secteur public) qui exigent contractuellement une base ou un hébergement dédié. Le choix d’un hébergement souverain ou certifié entre alors aussi en ligne de compte.
- Des volumes très hétérogènes, où quelques clients pèsent beaucoup plus que tous les autres.
- Un marché de quelques grands comptes, où chaque contrat justifie un déploiement dédié, à condition qu’il soit entièrement automatisé.
Microsoft rappelle que le choix d’un modèle n’est pas seulement technique : c’est aussi une décision commerciale. Une option « instance dédiée » peut figurer dans une offre supérieure et financer son propre surcoût d’exploitation.
Les erreurs qui coûtent cher plus tard
Quelques pièges reviennent dans les SaaS qui grandissent mal :
- Commencer mono-client en se disant qu’on ajoutera le multi-tenant « quand on aura des clients ». Ajouter un identifiant de tenant à une base existante, à chaque requête et à chaque fichier, revient presque à réécrire l’application.
- Personnaliser par le code pour chaque client signé. Au cinquième client, chaque mise à jour devient un projet.
- Oublier les traitements en arrière-plan : exports, e-mails, calculs nocturnes. Ce sont souvent eux qui mélangent les données, parce qu’ils ne passent pas par le filtrage de l’interface.
- Ne pas tester l’isolation de façon automatisée. Un test manuel avant le lancement ne protège pas contre la régression introduite six mois plus tard.
- Négliger les intégrations par client : chaque client voudra connecter le SaaS à son CRM ou à son ERP. Une couche d’API documentée et des clés d’accès par organisation évitent les développements spécifiques.
Lancer un SaaS B2B, c’est donc construire deux produits en un : la fonctionnalité que vos clients achètent, et le socle invisible qui permet d’en servir cent aussi facilement qu’un seul. C’est ce socle que nous posons dans nos projets de produits SaaS, avec une phase de cadrage qui fixe le modèle de tenant avant la première ligne de code. Si vous préparez un lancement, décrivez votre projet dans notre diagnostic en ligne : nous revenons vers vous avec une première analyse de l’architecture adaptée.
