SaaS multitenant : choisir le bon modèle d’isolation des données

INTRODUCTION

Commencez par l’exigence d’isolation, pas par la base de données

Le bon modèle multitenant pour un SaaS est celui qui correspond aux vraies frontières de votre produit, à votre capacité opérationnelle et au risque de changement futur. Pour la plupart des MVP, la question n’est pas « quel modèle est le meilleur ? » mais plutôt « de quel niveau d’isolation avons-nous besoin maintenant, et qu’est-ce qui sera pénible à faire évoluer plus tard ? »

Une façon pragmatique de l’aborder : si les locataires se distinguent principalement par la propriété des données et les permissions, une conception à tables partagées avec une autorisation explicite des locataires peut suffire pour démarrer. Si vous anticipez une séparation plus forte entre clients, une charge d’administration plus importante ou des contrôles opérationnels par locataire, des schémas ou des bases de données distinctes peuvent avoir du sens. Aucune de ces options ne garantit la sécurité à elle seule ; l’application doit toujours assurer une autorisation côté serveur et des tests rigoureux.

Si vous prévoyez un développement web sur mesure pour un produit SaaS, c’est souvent l’une des premières décisions d’architecture à prendre. Cela influence aussi la façon dont vous cadrez la phase de découverte, construisez le MVP et planifiez les futures migrations. Pour les équipes travaillant avec un studio produit, il vaut la peine d’en discuter en parallèle des grandes décisions d’architecture en matière de développement web et de cadrage du MVP.

Comparez les trois modèles courants d’isolation des données

Voici une comparaison simple pour les fondateurs et les responsables produit qui évaluent un MVP SaaS :

Tables partagées

Les tables partagées sont généralement la voie la plus rapide pour un MVP. Elles gardent votre schéma compact et simplifient l’itération produit, car chaque fonctionnalité s’appuie sur un seul modèle de données. C’est souvent le bon choix lorsque vos premiers clients sont peu nombreux, que votre modèle de permissions est simple et que vous devez valider le produit avant d’ajouter de la complexité opérationnelle.

L’inconvénient est tout aussi clair : une erreur de filtrage des locataires peut exposer ou modifier des données entre clients. Le modèle dépend donc fortement d’un code applicatif discipliné et de règles de base de données bien appliquées.

Si vous utilisez PostgreSQL avec Supabase, la sécurité au niveau des lignes peut aider à imposer des règles d’accès côté base de données, mais elle ne constitue toujours qu’une couche de défense ; l’application doit transmettre correctement le contexte du locataire et utiliser une logique d’autorisation explicite. Le guide Supabase sur row-level security explique comment les politiques RLS contrôlent l’accès au niveau des lignes.

Schémas séparés

Les schémas offrent une solution intermédiaire. Vous conservez une seule base de données, mais les données de chaque locataire résident dans leur propre espace de noms. Cela peut clarifier certaines tâches opérationnelles, en particulier lorsque vous souhaitez une frontière plus visible entre clients sans gérer une base par locataire.

Le compromis, c’est la complexité. Les migrations deviennent plus difficiles, car chaque schéma doit recevoir les mêmes changements structurels. Le reporting et les analyses transverses entre locataires peuvent aussi devenir plus délicats. Pour les équipes produit, ce modèle convient souvent lorsque le nombre de locataires est limité ou lorsque certains clients ont besoin d’une séparation plus stricte qu’une conception à tables partagées ne le permet confortablement.

Bases de données séparées

Des bases de données séparées offrent des catalogues de données distincts. Elles peuvent toutefois partager un même serveur : l’isolation physique dépend de l’hébergement et du déploiement. Cela peut être utile lorsque les locataires sont volumineux, ont des attentes de conformité différentes ou nécessitent une isolation pour des raisons opérationnelles. Cela peut aussi réduire le rayon d’impact d’une erreur dans l’environnement d’un client.

Le coût se situe dans la charge de gestion. Vous avez désormais plus de sauvegardes, plus de migrations, plus de supervision et davantage de décisions opérationnelles. Pour un MVP, cela peut ralentir la livraison, sauf si le cas d’usage justifie fortement cette complexité.

Gardez les frontières entre locataires explicites dans l’application

Quel que soit le modèle d’isolation choisi, le système doit rendre l’appartenance au locataire explicite. Ne vous fiez pas à l’état du front-end, à des URL cachées ou à la dernière action d’un utilisateur pour déduire les droits d’accès.

Une base pratique consiste à :

1. Un utilisateur se connecte.
2. Le serveur détermine à quels locataires cet utilisateur appartient.
3. La requête est autorisée dans un contexte de locataire spécifique.
4. Tous les accès aux données sont filtrés par ce contexte de locataire.
5. Les tâches d’arrière-plan, les exports et les opérations de recherche utilisent la même frontière de locataire.

Ce dernier point est important. Les erreurs entre locataires apparaissent souvent en dehors du chemin principal requête/réponse : dans les exports CSV, l’indexation de recherche, les tâches en file d’attente, les tâches planifiées ou les outils d’administration. Si ces chemins n’appliquent pas les mêmes règles, le modèle d’isolation devient incohérent.

C’est là que l’autorisation côté serveur est la plus importante. On ne peut pas faire confiance au client pour décider à quel locataire il a le droit d’accéder. Le serveur doit imposer l’appartenance et les permissions avant toute lecture ou écriture sensible.

Si vous concevez aussi l’expérience produit autour d’espaces de travail clients ou de portails, il peut être utile d’examiner comment le multitenant influence l’UX et l’architecture de l’information dans un portail client ou une plateforme SaaS. Ce type de projet combine souvent conception produit et frontières architecturales.

Un cadre de décision concret

Utilisez cette liste de contrôle pour choisir le plus petit modèle qui répond à vos besoins :

Choisissez les tables partagées si :

• Vous construisez un MVP et devez avancer rapidement.
• Tous les locataires utilisent le même schéma de base.
• Votre équipe peut garder l’autorisation des locataires explicite dans le code et les règles de base de données.
• Vous êtes prêt à tester chaque chemin de données pour détecter les fuites entre locataires.

Choisissez les schémas séparés si :

• Vous voulez une séparation plus nette sans la surcharge de nombreuses bases de données.
• Vous pensez que l’administration spécifique à chaque locataire va devenir importante.
• Vous pouvez gérer des migrations répétées et la cohérence des schémas.
• Vous avez une raison de séparer les données logiquement, mais pas complètement sur le plan opérationnel.

Choisissez les bases de données séparées si :

• Les clients exigent une séparation opérationnelle ou organisationnelle plus forte.
• Vous pensez que les environnements des locataires vont diverger.
• Vous pouvez supporter le coût de migration et de maintenance.
• Le produit justifie cette complexité supplémentaire dès le départ.

Une règle utile : privilégiez le modèle le plus simple qui correspond encore à vos besoins clients et opérationnels. Ne réarchitecturez plus tard que lorsque le modèle actuel commence à créer une vraie friction, et non un inconfort hypothétique.

Exemple hypothétique : un portail client avec plusieurs espaces de travail

Imaginez un produit SaaS B2B dans lequel chaque entreprise cliente possède un espace de travail, et chaque espace comporte de nombreux utilisateurs. L’application doit gérer le partage de documents, des fils d’activité et des exports.

Une conception MVP raisonnable pourrait utiliser des tables partagées avec un tenant_id sur chaque table appartenant au locataire. Les utilisateurs appartiennent à un ou plusieurs espaces via une table d’adhésion. Chaque requête vérifie côté serveur l’appartenance de l’utilisateur avant de lire ou écrire des données. RLS peut être utilisé pour renforcer les restrictions au niveau des lignes dans la base de données.

Considérons maintenant les modes de défaillance :

• Un utilisateur devine l’ID d’un autre espace dans l’URL.
• Un endpoint de rapport exporte des lignes sans appliquer les filtres de locataire.
• Une tâche d’arrière-plan indexe des enregistrements de tous les locataires dans un seul espace de recherche.
• Un écran d’administration lit le mauvais locataire parce qu’il fait confiance à une entrée client.

L’architecture n’est pas mauvaise parce que ces risques existent ; elle ne l’est que si elle ne les traite pas. Les tables partagées peuvent très bien fonctionner ici si l’application applique systématiquement une autorisation tenant-aware et teste les chemins à risque.

Testez la frontière, pas seulement le chemin nominal

Pour le SaaS multitenant, les tests négatifs sont aussi importants que les tests positifs. Vous voulez la preuve que le système refuse l’accès quand il le doit.

Les cas de test utiles incluent :

• Lectures inter-locataires : un utilisateur du locataire A ne peut pas lire les enregistrements du locataire B.
• Écritures inter-locataires : un utilisateur du locataire A ne peut pas modifier les enregistrements du locataire B.
• Recherche : le locataire A ne peut pas voir le contenu du locataire B dans les résultats de recherche.
• Export : les exports CSV ou PDF n’incluent que les données du locataire actif.
• Tâches d’arrière-plan : les tâches en file d’attente ne traitent que les enregistrements du locataire prévu.
• Outils d’administration : les utilisateurs internes ont toujours besoin de règles claires pour le changement de locataire et le périmètre d’accès.

En cas d’utilisation de RLS, testez toute la chaîne de requête, et pas seulement une requête SQL directe. RLS peut aider au niveau de la base de données, mais votre API, vos workers et vos outils d’administration ont eux aussi besoin d’un contexte de locataire correct.

Quand revoir l’architecture

Vous n’avez pas besoin de surconcevoir le modèle initial, mais vous devez définir clairement quand changer de cap. Réexaminez l’architecture lorsque vous voyez un ou plusieurs de ces signes :

• Les migrations deviennent difficiles à appliquer de manière sûre sur tous les locataires.
• Un ou plusieurs clients ont besoin d’une séparation plus forte que celle fournie par le modèle actuel.
• La configuration spécifique à un locataire se transforme en divergence structurelle.
• Les tâches d’arrière-plan, la recherche ou les exports deviennent difficiles à maintenir en sécurité entre locataires.
• L’équipe passe trop de temps à défendre le modèle actuel au lieu de livrer de la valeur produit.

C’est le moment où un MVP à tables partagées peut évoluer vers des schémas ou des bases de données, ou encore où une configuration à schémas peut nécessiter une séparation opérationnelle plus poussée.

Planifiez l’étape suivante

Pour la plupart des fondateurs et des responsables produit, l’approche la plus sûre consiste à commencer par le modèle le plus simple qui rend malgré tout la propriété des locataires explicite, puis à faire respecter les frontières dans le serveur, la base de données et la suite de tests.

Une bonne liste de lancement est la suivante :

• Définir l’appartenance aux locataires et les règles d’autorisation avant l’implémentation.
• Choisir un seul modèle d’isolation des données et documenter pourquoi.
• Rendre le contexte du locataire explicite dans chaque chemin de requête.
• Ajouter des tests négatifs pour les lectures, les écritures, la recherche, les exports et les tâches.
• Vérifier si RLS ou des règles de base de données similaires peuvent renforcer l’autorisation applicative, et non la remplacer.
• Définir des déclencheurs de migration pour savoir quand reconsidérer l’architecture.

Si vous planifiez un MVP SaaS et souhaitez de l’aide pour choisir entre tables partagées, schémas ou bases de données séparées, nous pouvons discuter ensemble du produit, du modèle de données et du périmètre de lancement. Lancez la conversation : discuter de votre projet.