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 tenants et de votre échelle. MicrocosmWorks recommande généralement une approche de base de données partagée avec schémas séparés (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 des bases de données par tenant (database-per-tenant) pour les clients des secteurs réglementés comme la santé ou la finance où une stricte ségrégation des données est exigée. Nos architectes évaluent vos besoins de conformité, le nombre de tenants prévu et les modèles de requêtes avant de recommander le modèle de tenancy approprié.
MicrocosmWorks met en œuvre la limitation de débit (rate limiting) consciente des tenants, le pooling de connexions (connection pooling) avec des quotas par tenant, et l'isolation des ressources au niveau de la couche de calcul pour prévenir les problèmes de « voisin bruyant » (noisy-neighbor). Nous utilisons des techniques telles que le fair queuing pondéré (weighted fair queuing) et des niveaux de cache (caching tiers) spécifiques aux tenants afin qu'un pic soudain d'un client n'entraîne pas de latence pour les autres. Pour les tenants de niveau entreprise, nous pouvons provisionner des partitions de calcul dédiées tout en maintenant le plan de contrôle (control plane) partagé intact.
MicrocosmWorks propose des services de conception et d'implémentation d'architecture à des tarifs de conseil compris entre 15 et 45 $/heure, selon la complexité et l'ancienneté de l'équipe requise. Un engagement typique d'architecture SaaS multi-tenant — couvrant la conception de la base de données, l'isolation des tenants, l'authentification et les pipelines de déploiement — dure de 8 à 16 semaines avec une équipe multifonctionnelle. Nous définissons la portée de chaque projet avec une phase de découverte à prix fixe afin que vous ayez une visibilité complète des coûts avant de vous engager dans la réalisation.
MicrocosmWorks construit des pipelines automatisés de provisionnement de tenants 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 (seed data) 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 tenant obtienne un environnement entièrement configuré sans intervention manuelle. Cette approche permet à nos clients de passer de 10 à 10 000 tenants sans modifier le processus d'intégration (onboarding).
MicrocosmWorks met en œuvre une couche de personnalisation pilotée par la configuration (configuration-driven customization layer) utilisant des feature flags, des métadonnées spécifiques aux tenants et une architecture de plugins qui permet un comportement par tenant sans embranchement de code (code branching). Nous concevons des points d'extensibilité au niveau du theming de l'interface utilisateur (UI theming), du moteur de workflow (workflow engine) et des couches d'intégration afin que les tenants puissent avoir une marque unique (branding), des règles métier et des connexions tierces, le tout géré par la configuration. Cela permet à votre équipe d'ingénierie de maintenir une seule base de code (codebase) tout en prenant en charge diverses exigences client.