Architecture & Sécurité
Qu’est-ce que Multitenant Architecture (Architecture multi-locataires) ?
Architecture logicielle où une seule instance d’application sert plusieurs clients (tenants) : chaque client perçoit un espace dédié (données, paramètres, marque) tout en partageant la même infrastructure et le même code.
Définition simple
C'est comme un immeuble avec des appartements cloisonnés mais une même gaine technique : un toit, des compteurs et des clés séparés par locataire. Architecture logicielle où une seule instance d’application sert plusieurs clients (tenants) : chaque client perçoit un espace dédié (données, paramètres, marque) tout en partageant la même infrastructure et le même code. Typique des SaaS : un produit, des milliers de clients sans déployer une instance par client. Les modèles vont du partage total (même base de données, isolation par identifiant tenant) au partage partiel (schéma ou base par tenant). Les enjeux : isolation des données, performance, facturation et personnalisation par tenant.
Comment ça marche ?
Chaque requête est associée à un tenant (via sous-domaine, header, token). L’application filtre toutes les requêtes (lecture, écriture) par cet identifiant. Les données sont soit dans des tables partagées avec une colonne tenant_id, soit dans des bases ou schémas dédiés par tenant.
Impact business
Le multitenant est la base économique du SaaS : coûts d’infrastructure et de déploiement partagés, mises à jour déployées une fois pour tous. Pour une entreprise qui lance un SaaS, le choix du modèle (DB partagée vs base par client) impacte la scalabilité, la conformité (RGPD, données par pays) et la complexité. Un bon multitenant permet de grandir sans multiplier les serveurs et les maintenances. Sur des charges PME comparables, une plateforme multitenant bien dimensionnée affiche couramment un coût d'infrastructure par client dix à cent fois inférieur à celui d'autant d'instances dédiées mono-tenant — avant même de compter les mises à jour et la supervision.
Bonnes pratiques
- Toujours filtrer par tenant_id (ou équivalent) au niveau requête. Tester l’isolation (tentative d’accès cross-tenant). Documenter le modèle (shared DB, schema per tenant, DB per tenant) et les critères de choix.
Erreurs communes
- Oublier de filtrer une requête par tenant (fuite de données entre clients). Surcharger une base partagée sans stratégie de sharding ou de séparation. Mélanger des données sensibles de tenants dans les logs ou le cache.
Prompt IA
Contexte : type de SaaS [B2B / B2C], contraintes [isolation données / conformité]. Explique l’architecture multitenant en une phrase. Compare partage total (une DB, colonne tenant_id) vs base par tenant. Donne 3 avantages et 2 risques (fuite de données, charge). Indique comment isoler les données et les paramètres par client.
SERVICE LIÉ
Passer de la définition à un projet concret.
Application web & SaaS
Approfondir ce sujet dans le cadre d’un accompagnement adapté à votre contexte.
À LIRE AUSSI
Guides plus complets sur le blog.
QUESTIONS FRÉQUENTES
Aller plus loin sur Multitenant Architecture (Architecture multi-locataires).
Oui, à condition que l’isolation des données soit garantie (un client ne peut pas accéder aux données d’un autre) et que les traitements (sauvegarde, suppression, export) soient prévus par tenant. Le modèle multitenant n’empêche pas la conformité si les processus sont clairs.
Base partagée (tenant_id) : moins de coût, plus simple à déployer ; attention à l’isolation et à la charge. Base (ou schéma) par client : meilleure isolation, utile pour gros clients ou contraintes légales ; plus de coût et de complexité opérationnelle.