Une seule base de code, des centaines de locataires, aucune fuite de données — le fondement de toute entreprise SaaS évolutive.

Vous construisez une plateforme qui sert plusieurs clients à partir d'un unique déploiement. Chaque client attend des données isolées, des expériences personnalisées et une facturation par locataire — mais vous ne pouvez pas vous permettre de gérer une infrastructure distincte pour chacun. Vous avez besoin de l'économie d'une infrastructure partagée avec les garanties d'isolation de systèmes dédiés. C'est la tension fondamentale de l'architecture SaaS, et une mauvaise approche du modèle d'isolation dès le début est l'une des erreurs les plus coûteuses dans le développement de plateforme.
Explore more design patterns and system architectures
Nos architectes peuvent vous aider à concevoir et construire des systèmes utilisant ce modèle pour vos besoins spécifiques.
Contactez-nousL'architecture SaaS multi-locataire offre une séparation logique ou physique entre les locataires tout en partageant les ressources de calcul, de stockage et de réseau sous-jacentes. Ce modèle englobe le provisionnement des locataires, l'isolation des données, la gestion des fonctionnalités, la mesure de la facturation et la personnalisation en marque blanche. La décision de conception essentielle est le modèle d'isolation : base de données partagée avec sécurité au niveau des lignes (row-level security), schéma par locataire (schema-per-tenant), ou base de données par locataire (database-per-tenant). Chaque modèle présente un compromis entre la force de l'isolation et la complexité opérationnelle et l'efficacité des coûts.
Le système est organisé en trois couches. La passerelle sensible aux locataires gère l'authentification, la résolution des locataires (via le sous-domaine, le JWT claim ou la clé API) et le routage des requêtes. La couche d'application opère entièrement dans le contexte du locataire — chaque requête, chaque clé de cache, chaque message de file d'attente est délimité au locataire résolu. La couche de données impose l'isolation au niveau du stockage grâce aux politiques de sécurité au niveau des lignes (row-level security policies), au pool de connexions par locataire et au partitionnement chiffré au repos.
tenant_id. Pour schema-per-tenant : routage dynamique des connexions avec gestion du pool de connexions. Pour database-per-tenant : automatisation du provisionnement avec Terraform/Pulumiacme.yourapp.com) sont plus propres pour les produits en marque blanche et permettent des certificats TLS par locataire. Basée sur le chemin (yourapp.com/acme/) est plus simple à implémenter et évite la complexité du DNS wildcard. MW recommande la résolution par sous-domaine pour les SaaS B2B avec des exigences de marque blanche, et la résolution basée sur le chemin pour les outils multi-locataires internes.tenant_id. Cela semble évident, mais les collisions de clés de cache entre locataires sont l'un des bugs multi-locataires les plus courants. Nous l'appliquons via une fabrique de clés de cache qui préfixe automatiquement le contexte du locataire.
System Architecture Overview
| Couche | Technologies |
|---|---|
| Calcul | Node.js (NestJS), Python (FastAPI), conteneurisé sur ECS Fargate ou Kubernetes |
| Données | PostgreSQL avec RLS, Redis (limité aux locataires), S3 (buckets partitionnés par locataire) |
| Identité | Clerk, Auth0, ou Okta avec des organisations limitées aux locataires |
| Facturation | Stripe Connect (modèle de place de marché), Stripe Billing (abonnements mesurés) |
| Observabilité | Datadog avec des tags de dimension locataire, journalisation structurée avec tenant_id sur chaque entrée |
| Utiliser Quand | Éviter Quand |
|---|---|
| Construction d'une plateforme B2B servant plus de 10 clients à partir d'une infrastructure partagée | Chaque client exige une infrastructure entièrement dédiée (conformité/contractuel) |
| Vous avez besoin de branding en marque blanche, de domaines personnalisés et de contrôle des fonctionnalités par locataire | Vous avez moins de 3 clients — un déploiement plus simple par client peut suffire |
| Une tarification basée sur l'utilisation ou échelonnée nécessite une mesure par locataire | Le produit est une application grand public avec des comptes au niveau utilisateur, et non des locataires au niveau organisationnel |
| Vous voulez un pipeline de déploiement unique, une pile de surveillance unique, une rotation d'astreinte unique | Les locataires ont des schémas ou une logique métier fondamentalement différents (pas seulement la configuration) |
MW considère le multi-locataire comme une préoccupation transversale, et non comme une fonctionnalité. Nous implémentons la propagation du contexte locataire au niveau du middleware afin que le code d'application ne filtre jamais manuellement par locataire — c'est appliqué par le framework. Nos implémentations RLS incluent des suites de tests automatisées qui tentent l'accès aux données entre locataires à chaque exécution de CI. Nous avons construit des plateformes multi-locataires servant plus de 500 locataires sur une infrastructure partagée sans aucun incident de fuite de données, et nous avons migré des monolithes mono-locataires vers des architectures multi-locataires en utilisant le modèle du figuier étrangleur.
Les modèles ne fonctionnent pas seuls. Le pipeline qui entraîne, valide, déploie et surveille vos modèles est le produit réel — le modèle n'est qu'un artefact.
Le choix optimal dépend de vos exigences d'isolation des locataires et de l'échelle. MicrocosmWorks recommande généralement une approche shared-database, separate-schema pour la plupart des produits SaaS B2B car elle équilibre l'efficacité des coûts avec l'isolation des données, bien que nous mettions en œuvre le database-per-tenant pour les clients des secteurs réglementés comme la santé ou la finance où une ségrégation stricte des données est exigée. Nos architectes évaluent vos besoins de conformité, le nombre de locataires attendu et les modèles de requêtes avant de recommander le bon tenancy model.
MicrocosmWorks met en œuvre une limitation de débit consciente des locataires, un pool de connexions avec des quotas par locataire et l'isolation des ressources au niveau de la couche de calcul pour prévenir les problèmes de voisins bruyants. Nous utilisons des techniques telles que le *weighted fair queuing* et des niveaux de cache spécifiques aux locataires afin qu'un pic soudain d'un client ne se répercute pas en latence pour les autres. Pour les locataires de niveau entreprise, nous pouvons provisionner des partitions de calcul dédiées tout en gardant le *control plane* partagé intact.
MicrocosmWorks propose des services de conception et d'implémentation d'architecture à des tarifs de conseil allant de 15 $ à 45 $/heure, selon la complexité et la séniorité de l'équipe requises. Un engagement typique d'architecture SaaS multi-tenant – couvrant la conception de base de données, l'isolation des tenants, l'authentification et les pipelines de déploiement – dure de 8 à 16 semaines avec une équipe interfonctionnelle. Nous définissons la portée de chaque projet avec une phase de découverte à prix fixe afin que vous ayez une visibilité totale des coûts avant de vous engager dans la construction.
MicrocosmWorks met en place des pipelines de provisionnement automatisé des locataires qui gèrent la création de schémas, la configuration DNS, l'initialisation des feature flags et le déploiement des données initiales en quelques minutes après une nouvelle inscription. Nous utilisons des outils d'infrastructure-as-code comme Terraform ou Pulumi, combinés à des workflows événementiels, afin que chaque nouveau locataire obtienne un environnement entièrement configuré sans intervention manuelle. Cette approche permet à nos clients de passer de 10 à 10 000 locataires sans modifier le processus d'intégration.
MicrocosmWorks implémente une couche de personnalisation pilotée par la configuration en utilisant des *feature flags*, des métadonnées spécifiques au locataire et une architecture de plugins qui permet un comportement par locataire sans bifurcation de code. Nous concevons des points d'extensibilité au niveau de la thématique de l'UI, du moteur de flux de travail et des couches d'intégration afin que les locataires puissent avoir une image de marque unique, des règles métier et des connexions tierces, le tout géré via la configuration. Cela permet à votre équipe d'ingénierie de maintenir une base de code unique tout en prenant en charge des exigences clients diverses.