Le choix d'une architecture multi-tenant est l'une des décisions les plus déterminantes dans la conception d'une plateforme SaaS. Elle affecte la structure des coûts, l'isolation des données, les caractéristiques de performance et la complexité opérationnelle pour toute la durée de vie du produit. Les trois modèles dominants sont la base de données partagée avec discrimination par identifiant de tenant, le schéma par tenant au sein d'un serveur de base de données partagé, et la base de données entièrement isolée par tenant. Chaque modèle occupe un point différent sur le spectre entre efficacité opérationnelle et isolation des tenants. Nous avons construit des plateformes SaaS en production avec ces trois modèles et pouvons vous fournir des recommandations concrètes pour adapter le modèle au contexte métier.
Le modèle de base de données partagée stocke toutes les données des tenants dans des tables communes, distinguées par une colonne d'identifiant de tenant. C'est l'approche la plus économique car l'infrastructure évolue en fonction du volume total de données plutôt que du nombre de tenants. L'ajout d'un nouveau tenant est instantané et ne nécessite aucun provisionnement. Cependant, ce modèle exige une rigueur absolue dans la conception des requêtes : chaque requête doit inclure le filtre d'identifiant de tenant, et un filtre oublié signifie une fuite de données catastrophique. Nous atténuons ce risque avec des politiques de sécurité au niveau des lignes dans la base de données et un middleware de contexte tenant obligatoire qui injecte automatiquement le filtre. L'isolation des performances est l'autre défi, car un seul tenant exécutant des requêtes lourdes peut impacter tous les autres sans une gouvernance rigoureuse des ressources.
Le schéma par tenant offre une isolation logique plus forte tout en partageant le serveur de base de données sous-jacent. Chaque tenant dispose de son propre schéma avec des structures de tables identiques, et l'application change de schéma en fonction du contexte du tenant authentifié. Ce modèle simplifie les discussions de conformité car vous pouvez démontrer des limites de données claires, et les migrations de schéma spécifiques au tenant deviennent possibles pour la personnalisation entreprise. Le coût opérationnel croît linéairement avec le nombre de tenants, car chaque schéma nécessite une gestion de migration indépendante. Nous avons constaté que ce modèle fonctionne bien pour les produits SaaS B2B avec des dizaines à des centaines de tenants où les exigences d'isolation des données sont modérées et où une certaine personnalisation par tenant est attendue.
La base de données par tenant offre les garanties d'isolation les plus fortes. Chaque tenant dispose d'une instance de base de données complètement indépendante, potentiellement sur du matériel dédié. Ce modèle est nécessaire lorsque les tenants ont des exigences réglementaires de résidence des données, lorsque l'isolation des performances doit être absolue, ou lorsque les tenants ont besoin de la possibilité d'apporter leurs propres clés de chiffrement. Le compromis est une surcharge opérationnelle significative : le provisionnement, la surveillance, la sauvegarde et la migration doivent être automatisés pour chaque instance de tenant. Le coût évolue directement avec le nombre de tenants, indépendamment de l'utilisation. Nous recommandons ce modèle pour les produits SaaS de niveau entreprise avec moins d'une centaine de tenants à forte valeur où les exigences d'isolation justifient l'investissement en infrastructure.