SaaS mono-tenant ou multi-tenant : quelle architecture ?

Le multi-tenant fait partie des trois décisions qu'on ne peut pas annuler à bas coût — nous le défendions dans choisir sa stack technique SaaS. Voici la version complète : les options, ce qui impose réellement les plus coûteuses, et la partie que la plupart des comparatifs oublient.

Les trois modèles

Schéma partagé. Une base, un jeu de tables, une colonne tenant_id sur chaque ligne. Chaque requête filtre dessus. Le moins cher à exploiter, le plus simple à administrer, et le choix par défaut de la plupart des SaaS B2B.

Un schéma par client. Une base, mais chaque client dispose de ses propres tables. Séparation plus forte, et possibilité de sauvegarder ou restaurer un client sans toucher aux autres. Le coût d'exploitation croît avec le nombre de clients — les migrations s'exécutent désormais N fois.

Une base par client. Séparation complète. Isolation maximale, conformité facile à démontrer, et de loin le plus coûteux à exploiter. Chaque changement de schéma devient une opération de flotte.

Ce qui compte vraiment

Voici ce que la plupart des comparatifs manquent. Votre modèle d'isolation ne vaut que ce que vaut son application, et dans le schéma partagé, c'est précisément là que les équipes se blessent.

Une colonne tenant_id ne protège rien en soi. Elle protège quand chaque requête filtre dessus — et « chaque requête, pour toujours, y compris celle écrite un vendredi à 18 h par un nouvel arrivant » n'est pas une propriété qu'on obtient par la discipline. C'est une propriété qu'on obtient par la structure.

Rendez-la structurelle, pas mémorielle :

• Row-level security dans la base, pour que la couche de données elle-même refuse de renvoyer les lignes d'un autre client, même si le code applicatif oublie. C'est le contrôle le plus puissant du modèle partagé.
• Une seule couche d'accès qui applique toujours la portée du tenant, avec interdiction des requêtes brutes en dehors.
• Un test qui tente de lire les données d'un autre client et fait échouer le build s'il y parvient. Peu coûteux, et il attrape la régression la plus importante.

Sans cela, le schéma partagé n'est qu'à une clause WHERE oubliée de laisser fuiter des données entre clients — le bug le plus dommageable qu'un SaaS puisse livrer.

Ce qui impose réellement une isolation plus lourde

Ni l'échelle, ni la préférence. Ceci :

1. Un contrat qui l'exige. Un client grand compte dont la revue de sécurité impose une base dédiée. C'est la raison réelle la plus fréquente, et c'est une question commerciale, pas technique.
2. La résidence des données. Des clients dont les données doivent rester dans un pays donné. Il faut une séparation par région quoi qu'il arrive.
3. La restauration par client. Si « restaurer ce client à hier » est une vraie exigence, le schéma partagé rend cela véritablement pénible.
4. Des clients très inégaux. Un client détenant cent fois plus de données que les autres dégradera l'infrastructure partagée pour tout le monde.
5. Des régimes réglementaires attendant une séparation physique démontrable.

Si rien de tout cela ne s'applique, le schéma partagé est presque certainement le bon choix, et il tient bien plus loin que les fondateurs ne l'imaginent.

L'hybride dont personne ne parle

Vous n'êtes pas obligé de choisir la même chose pour tout le monde. Mutualisez la majorité des clients en schéma partagé, et isolez les rares qui l'exigent.

C'est ce vers quoi convergent généralement les SaaS B2B matures : la longue traîne des clients en libre-service partage l'infrastructure, tandis qu'une poignée de grands comptes obtient des bases dédiées parce que leurs contrats l'imposent.

Cela coûte davantage en complexité d'exploitation — deux chemins à maintenir — mais cela évite de facturer chaque client comme s'il était le plus exigeant. Prévoyez-le tôt même sans l'utiliser : gardez la résolution du tenant à un seul endroit, pour que pointer un client vers une autre base devienne un changement de configuration et non un refactoring.

Quel sens de migration est le plus facile

À savoir avant de choisir :

• Partagé → isolé est faisable. Extraire un client vers sa propre base est une migration bien comprise. Désagréable, pas architecturale.
• Isolé → partagé est pénible. Fusionner des bases séparées suppose de réconcilier des collisions d'identifiants et des divergences de schéma accumulées pendant que chacune vivait sa vie.

Donc, en cas de doute réel, commencez en partagé. L'option la moins chère est aussi la plus réversible, ce qui est rare et mérite d'en profiter.

Le choix par défaut honnête

Pour la plupart des SaaS B2B : schéma partagé, row-level security appliquée dans la base, portée du tenant gérée dans une couche d'accès unique, et un test qui prouve que l'isolation tient. Ajoutez des bases dédiées quand un contrat ou un régulateur l'exige, pas parce que cela rassure.

Le modèle d'isolation est une décision plus petite que la rigueur avec laquelle vous appliquez celui que vous avez choisi. Un schéma partagé avec row-level security au niveau de la base est plus sûr en pratique qu'une base par client où la logique d'aiguillage peut se tromper de base.

Si vous voulez un second avis sur le multi-tenant avant qu'il ne soit gravé dans chaque requête que vous écrirez, c'est exactement le genre de décision qui mérite une conversation. Découvrez notre approche du développement SaaS, ou contactez-nous.