Vous développez une plateforme SaaS destinée à plusieurs entreprises clientes. Chacune doit accéder à ses propres données, sans jamais voir celles des autres. La façon dont vous concevez cette séparation conditionne votre capacité à signer de grands comptes, vos coûts d'hébergement, votre conformité RGPD, et la quantité de travail qu'il faudra pour faire évoluer votre produit. C'est ce qu'on appelle l'architecture multi-tenant.
Ce guide explique les concepts de base, compare les principales stratégies techniques, et aide les créateurs de SaaS à choisir l'architecture adaptée à leur contexte, sans décider à leur place ce qui convient à chaque situation.
• Un tenant est un client de votre plateforme (une entreprise, une organisation, un compte).
• L'architecture multi-tenant permet de servir plusieurs tenants avec une infrastructure commune, en isolant leurs données.
• Il existe quatre grandes stratégies, chacune avec des avantages et des limites réels ; aucune n'est universellement supérieure.
• PostgreSQL Row Level Security est un outil utile, pas un substitut à une architecture bien pensée.
• La décision doit être prise au démarrage : la migrer après coup est coûteuse.
Sommaire
1. Qu'est-ce qu'un tenant ?
2. Single-tenant ou multi-tenant : quelle différence ?
3. Avantages du multi-tenant
4. Limites et risques
5. Les quatre stratégies de base de données
6. Schéma de principe
7. PostgreSQL Row Level Security
8. Bonnes pratiques
9. Comment choisir votre architecture
10. Erreurs fréquentes
11. Checklist avant de démarrer
12. Questions fréquentes
13. Sources et références
Qu'est-ce qu'un tenant ?
Le mot tenant (locataire en anglais) désigne un client de votre plateforme : une entreprise, une association, un compte avec ses propres utilisateurs. Chaque tenant utilise votre logiciel dans son propre contexte : ses données, ses utilisateurs, parfois sa configuration spécifique.
La gestion des tenants consiste à s'assurer que chacun d'eux n'accède qu'à ce qui lui appartient. Un tenant A ne doit jamais voir, modifier ou supprimer les données du tenant B, même si les deux partagent le même logiciel et la même infrastructure.
Single-tenant ou multi-tenant : quelle différence ?
Une architecture single-tenant déploie une instance distincte du logiciel pour chaque client : un serveur séparé, une base de données séparée, un environnement isolé. C'est le modèle des logiciels installés "on-premise" ou des solutions hébergées à la demande avec un déploiement par client.
Une architecture multi-tenant fait tourner le même logiciel pour tous les clients sur une infrastructure commune. Chaque client a l'impression d'utiliser son propre outil, mais les ressources sont mutualisées. C'est le modèle de la quasi-totalité des SaaS modernes.
| Critère | Single-tenant | Multi-tenant |
|---|---|---|
| Infrastructure | Une instance par client | Infrastructure mutualisée |
| Coût d'hébergement | Proportionnel au nombre de clients | Mutualisé (économies d'échelle) |
| Isolation des données | Maximale par conception | Dépend de la stratégie choisie |
| Déploiement de mises à jour | Chaque instance séparément | Une seule mise à jour pour tous |
| Personnalisation par client | Possible par instance | Plus complexe à gérer |
| Complexité opérationnelle | Élevée à grande échelle | Centralisée |
Avantages du multi-tenant
- •Mutualisation de l'infrastructure : les coûts de serveur, de base de données et de réseau sont partagés entre tous les clients. Plus vous avez de clients, plus le coût unitaire par client diminue.
- •Déploiement simplifié : une seule version du logiciel tourne pour tout le monde. Une mise à jour, un correctif, une nouvelle fonctionnalité : tout s'applique en une seule opération.
- •Maintenance centralisée : pas besoin de gérer dix, cent ou mille instances séparées. Les sauvegardes, la supervision, les mises à jour de sécurité sont centralisées.
- •Capacité à faire évoluer le produit plus vite : sans la charge opérationnelle de la multiplication d'instances, les équipes peuvent se concentrer sur le développement de nouvelles fonctionnalités.
- •Meilleure utilisation des ressources : les pics de charge d'un client peuvent être compensés par des creux chez d'autres, ce qui permet de dimensionner l'infrastructure plus finement.
Limites et risques à anticiper
- •Isolation insuffisante des données : si l'architecture n'est pas correctement conçue, une erreur dans le code peut exposer les données d'un client à un autre. C'est le risque principal.
- •Mauvaise gestion des permissions : sans un système de contrôle rigoureux, un utilisateur pourrait accéder à des données d'un autre tenant par manipulation de requêtes ou d'identifiants.
- •Effet « noisy neighbor » : un client qui génère une charge anormalement élevée (requêtes intensives, import massif de données) peut dégrader les performances pour les autres clients qui partagent la même infrastructure.
- •Personnalisation complexe : plus un client demande des configurations spécifiques (champs personnalisés, workflows particuliers, règles métier propres), plus la gestion du multi-tenant se complique.
- •Sauvegardes et restauration par client : restaurer les données d'un seul client sans affecter les autres est techniquement plus difficile en architecture partagée.
- •Conformité et localisation des données : certains secteurs ou pays exigent que les données soient stockées dans une zone géographique précise, ce qui peut nécessiter de segmenter l'infrastructure par région.
Les quatre stratégies de base de données
Stratégie 1 : Base partagée, tables partagées
Tous les clients utilisent les mêmes tables, avec une colonne tenant_id (ou organisation_id) qui identifie à qui appartient chaque ligne. Chaque requête doit filtrer sur ce champ. C'est la stratégie la plus simple à développer initialement.
- •Avantage : développement rapide, coûts d'hébergement minimaux, une seule version de la structure à maintenir.
- •Risque principal : une erreur de filtre dans le code peut exposer des données d'un client à un autre ; ce risque existe à chaque nouvelle requête écrite.
- •Limite pour les grands comptes : difficile à certifier pour des clients qui exigent une isolation forte (secteur bancaire, santé, industrie réglementée).
- •Complexité RGPD : en cas d'audit ou de demande de suppression, il faut identifier et effacer toutes les lignes d'un tenant dans toutes les tables.
Stratégie 2 : Base partagée, schémas séparés
Chaque client dispose de son propre schéma (espace de nommage) dans la même base de données. Les tables ont la même structure pour tous, mais elles sont cloisonnées par schéma. C'est un bon équilibre entre isolation et coût pour une application SaaS B2B standard.
- •Avantage : l'isolation est nettement meilleure : une requête mal construite ne peut pas traverser les données de deux tenants.
- •Avantage : conforme aux exigences de la majorité des entreprises moyennes et acceptable pour de nombreux audits.
- •Inconvénient : les migrations de structure doivent être appliquées sur chaque schéma, ce qui nécessite des outils d'automatisation dès le départ.
- •Limite : peut ne pas suffire pour des clients très exigeants sur l'isolation physique des données.
Stratégie 3 : Base de données séparée par client
Chaque client dispose de sa propre base de données, sur sa propre instance. C'est l'isolation maximale — et le modèle le plus proche du single-tenant, mais avec une gestion centralisée du déploiement. C'est souvent requis pour les logiciels CRM ou ERP sur mesure déployés chez des clients grands comptes.
- •Avantage : isolation totale. Un problème sur la base d'un client n'affecte jamais les autres.
- •Avantage : permet de signer des clients très exigeants (secteur bancaire, santé, défense, collectivités).
- •Avantage : possible de proposer des niveaux de service différents par client.
- •Inconvénient majeur : coût d'hébergement proportionnel au nombre de clients, peu économique à grande échelle.
- •Inconvénient : déploiements, migrations et opérations plus complexes à orchestrer.
Stratégie 4 : Approche hybride
Certaines plateformes combinent les stratégies : les clients standard partagent une base commune (stratégie 1 ou 2), tandis que les grands comptes ou les clients soumis à des contraintes réglementaires spécifiques disposent de leur propre base (stratégie 3). L'API centrale gère le routage vers l'environnement de données approprié.
Cette approche est plus complexe à concevoir et à opérer, mais elle permet d'adapter le niveau d'isolation au profil et aux exigences de chaque client.
| Critère | Tables partagées | Schémas séparés | Bases séparées | Hybride |
|---|---|---|---|---|
| Développement initial | Simple | Moyen | Élevé | Élevé |
| Coût d'hébergement | Très faible | Faible à moyen | Proportionnel aux clients | Variable |
| Niveau d'isolation | Logique (code) | Physique partiel | Physique total | Selon le tier |
| Conformité grands comptes | Souvent insuffisante | Acceptable pour la majorité | Acceptée dans tous les secteurs | Flexible |
| Complexité opérationnelle | Faible | Moyenne | Élevée | Très élevée |
| Idéal pour | MVP, B2C, petites équipes | SaaS B2B standard | Secteurs réglementés, grands comptes | Plateformes multi-segments |
Schéma de principe
PostgreSQL Row Level Security
La Row Level Security (RLS) est une fonctionnalité de PostgreSQL qui permet de définir des règles de sécurité directement au niveau de la base de données. Une fois activée sur une table, chaque requête — même une requête SQL directe — est filtrée automatiquement selon la politique définie. Un utilisateur ne peut voir que les lignes pour lesquelles la politique l'y autorise.
Dans le cadre du multi-tenant, la RLS peut être utilisée pour s'assurer que chaque tenant n'accède qu'à ses propres lignes, indépendamment de ce que le code applicatif fait (ou oublie de faire). La documentation de PostgreSQL sur la Row Level Security et celle de Supabase sur la RLS détaillent son fonctionnement et ses cas d'usage.
• L'authentification des utilisateurs (qui reste la première ligne de défense)
• Les contrôles applicatifs (vérification des droits dans le code)
• Les audits de sécurité (tests réguliers de l'isolation)
• Les tests automatisés qui vérifient qu'un tenant ne peut pas accéder aux données d'un autre
La RLS est une couche de défense supplémentaire, précieuse, mais pas une solution complète à elle seule.
Bonnes pratiques
- •Ajouter un tenant_id systématique à chaque table qui contient des données de clients, dès le début du projet, sans exception.
- •Définir une politique de permissions explicite : qui peut lire, écrire, modifier, supprimer, pour chaque type de ressource et chaque rôle d'utilisateur.
- •Écrire des tests automatisés d'isolation : vérifier régulièrement, de façon automatique, qu'un tenant ne peut pas accéder aux données d'un autre, même en manipulant des identifiants.
- •Mettre en place des journaux d'audit : consigner les accès aux données sensibles pour permettre la traçabilité en cas d'incident ou d'audit client.
- •Configurer des quotas par tenant : limiter les ressources consommables par client (nombre de requêtes, stockage, utilisateurs) pour prévenir l'effet noisy neighbor.
- •Superviser l'activité par tenant : détecter les comportements anormaux (pic de consommation, tentatives d'accès à des ressources non autorisées).
- •Séparer physiquement les données sensibles : pour les clients dont le contrat l'exige, prévoir la stratégie technique correspondante dès l'architecture initiale.
- •Planifier la stratégie de migration dès le départ : si vous commencez avec une stratégie simple, concevez le code de façon à faciliter la migration vers une stratégie plus rigoureuse.
Comment choisir votre architecture
Il n'existe pas d'architecture universellement supérieure. Le choix dépend de votre contexte. Voici les principaux facteurs à prendre en compte :
| Contexte | Architecture recommandée | Raison principale |
|---|---|---|
| MVP ou prototype, cible non déterminée | Tables partagées avec tenant_id | Rapidité de développement, coût minimal |
| SaaS B2B, PME et ETI, secteur standard | Schémas séparés | Bon équilibre isolation / coût / conformité |
| SaaS B2B, grands comptes ou secteur réglementé | Bases séparées par client | Isolation maximale, conformité aux audits |
| Plateforme mixte (différents segments de marché) | Hybride | Adapter l'isolation au profil de chaque client |
| Très forte personnalisation par client | Bases séparées ou hybride | La personnalisation profonde est plus simple instance par instance |
Erreurs fréquentes lors de la création d'un SaaS
- 1.Choisir la stratégie la plus simple pour le MVP et ne pas anticiper la migration : commencer avec des tables partagées est raisonnable, à condition de prévoir dès le départ comment évoluer si un client l'exige.
- 2.Oublier le tenant_id dans certaines tables : une table oubliée devient un risque d'isolation. Toutes les tables de données métier doivent être couvertes.
- 3.Faire confiance uniquement au code pour l'isolation : sans tests automatisés qui vérifient l'isolation, une modification du code peut silencieusement créer une fuite de données.
- 4.Ne pas traiter la RLS comme une couche de défense supplémentaire : elle ne se substitue ni à l'authentification ni aux contrôles applicatifs.
- 5.Ignorer les implications RGPD au moment de l'architecture : localisation des données, suppression à la résiliation, registre des traitements : ces contraintes sont plus faciles à respecter quand l'architecture les a anticipées.
- 6.Promettre une isolation forte sans la vérifier : certaines startups affirment à leurs clients une isolation complète sans avoir les mécanismes techniques pour la garantir.
Checklist avant de démarrer
- •Quelle est ma cible cliente : B2C, PME, ETI, grands comptes, secteur réglementé ?
- •Quelles sont les exigences d'isolation contractuelles ou réglementaires de mes clients cibles ?
- •Quelle stratégie de base de données ai-je choisie, et pour quelles raisons ?
- •Le tenant_id est-il présent dans toutes les tables de données métier ?
- •Ai-je défini les politiques de permissions par rôle et par ressource ?
- •Des tests d'isolation automatisés sont-ils prévus dans la suite de tests ?
- •La stratégie de journalisation et d'audit est-elle en place ?
- •Ai-je anticipé la procédure de suppression des données à la résiliation d'un client ?
- •Mon fournisseur d'hébergement est-il en UE si mes clients l'exigent ?
- •Si je commence avec une stratégie simple, ai-je conçu le code pour faciliter une migration future ?
Questions fréquentes
Une architecture multi-tenant est-elle moins sécurisée qu'une architecture single-tenant ?+
Faut-il une base de données par client pour mon SaaS B2B ?+
PostgreSQL RLS suffit-il à isoler les données entre tenants ?+
Peut-on faire évoluer une architecture single-tenant vers du multi-tenant ?+
Quelle architecture choisir pour un MVP SaaS ?+
Sources et références
Les informations techniques de cet article s'appuient sur les documentations officielles suivantes :
• PostgreSQL — Row Security Policies
• Supabase — Row Level Security
• AWS Well-Architected Framework — SaaS Lens
• Microsoft Azure Architecture Center — Multitenant architecture
En résumé
L'architecture multi-tenant est l'une des décisions les plus structurantes d'un SaaS B2B. Elle conditionne votre capacité à signer des clients exigeants, vos coûts d'exploitation, et la complexité de votre conformité RGPD. Il n'existe pas de bonne architecture universelle : le choix dépend de votre cible, de votre secteur et de votre budget. Ce qui est certain, c'est que cette décision se prend au démarrage — la corriger après coup représente un chantier majeur.
Vous construisez une application web sur mesure ou une plateforme SaaS et vous vous posez la question de l'architecture multi-tenant ? Décrivez-nous votre projet — nous pouvons vous aider à choisir l'approche adaptée à votre contexte et à votre cible.