La plupart des choix d’architecture coûtent moins cher à revoir qu’à débattre indéfiniment. Vous pouvez changer de file d’attente, remplacer un framework, migrer d’un cloud à l’autre : c’est coûteux, perturbant, mais surmontable.
La multi-location est différente. La façon dont vous séparez les données des clients impacte chaque requête, chaque migration, chaque procédure de sauvegarde et de restauration, chaque questionnaire de sécurité d’entreprise. Changer ce choix plus tard revient à réécrire la couche de données d’un système en production.
Il vaut donc la peine d’y consacrer une heure maintenant. Voici les trois modèles, comparés sans détour.
Modèle 1 : schéma partagé
Une base de données, un ensemble de tables, une colonne tenant_id partout. Toutes les requêtes filtrent par locataire.
- Coût : le plus bas, de loin. Une seule base à exploiter, sauvegarder, optimiser.
- Exploitation : la plus simple. Une migration, appliquée une fois, et tous les locataires sont sur le schéma courant.
- Montée en charge : excellente pour de nombreux petits locataires. C’est ainsi que l’on sert dix mille clients de façon rentable.
- Isolation : la plus faible. Un seul oubli de
WHERE tenant_id = ?entraîne une fuite de données inter-locataires. - Voisinage bruyant : réel. Le rapport volumineux d’un locataire peut dégrader l’expérience de tous.
- Restauration par locataire : réellement complexe. Restaurer les données d’un client à partir d’une sauvegarde partagée relève de la microchirurgie.
Le risque d’isolation se maîtrise, mais il doit l’être structurellement, pas par discipline individuelle. Imposer la gestion de la multi-location au niveau le plus bas possible : sécurité au niveau des lignes dans la base de données, ou couche d’accès aux données qui rend impossible toute requête non filtrée. Ne jamais compter sur la vigilance de chaque développeur. La revue de code ne suffit pas comme contrôle de sécurité à grande échelle.
À retenir de cet article : rendez la requête non filtrée impossible à écrire, pas seulement déconseillée. Chaque fuite de schéma partagé que nous avons étudiée venait d’une requête oubliée.
Modèle 2 : schéma par tenant
Une base de données, un schéma distinct par locataire. Même serveur, espaces de noms séparés.
- Coût : toujours faible — une seule instance de base de données.
- Isolation : nettement meilleure. Un accès inter-locataires nécessite une erreur volontaire, pas un simple oubli.
- Restauration par locataire : réalisable, contrairement au schéma partagé.
- Exploitation : c’est ici que ça se complique. Les migrations doivent s’exécuter pour chaque schéma et supporter d’en traiter des centaines. Une migration à moitié réussie sur 400 schémas, c’est une vraie mauvaise journée.
- Limite de montée en charge : les bases de données commencent à peiner dès quelques milliers de schémas — le pool de connexions et le catalogue deviennent alors les points de blocage.
C’est le compromis pragmatique, adapté aux plateformes comptant de quelques dizaines à quelques centaines de locataires, chacun ayant un poids commercial. C’est aussi le modèle souvent choisi pour de mauvaises raisons : parce qu’il semble plus sûr que le schéma partagé, sans que personne n’ait évalué le coût des outils de migration nécessaires.
Modèle 3 : base de données par tenant
Chaque locataire dispose de sa propre base de données, parfois même de sa propre infrastructure.
- Isolation : la plus forte possible, et la plus simple à justifier lors d’un audit de sécurité.
- Conformité : le modèle qui répond clairement aux exigences de localisation des données : la base de ce locataire est à Francfort, celle-là à Virginie.
- Sauvegarde, restauration et export par locataire : trivial. Supprimer un client à son départ l’est tout autant, ce qui compte plus qu’on ne le pense.
- Voisinage bruyant : inexistant. Un locataire ne peut pas impacter la performance d’un autre.
- Coût : le plus élevé, et il croît linéairement avec le nombre de locataires, non avec l’usage.
- Exploitation : la plus lourde. Migrations, supervision, sauvegardes et mises à jour se multiplient ; une automatisation avancée devient indispensable dès que le nombre de locataires augmente.
Ce modèle se justifie dans un seul cas : des clients grands comptes dont le processus d’achat l’exige. Si vos acheteurs envoient des questionnaires de sécurité sur la localisation physique des données et le partage d’infrastructure, c’est la réponse attendue — et cela peut décider du contrat.
Comment choisir
Passez ces questions en revue dans l’ordre :
- Qui est le client ? Des milliers de petits locataires orientent vers le schéma partagé. Quelques grandes entreprises vers une base dédiée par locataire. Un mélange appelle un modèle hybride — voir ci-dessous.
- Qu’exige réellement la conformité ? Pas ce qui semble le plus sûr. Lisez les obligations. La localisation des données et l’absence d’infrastructure partagée sont des exigences précises avec des réponses précises ; l’anxiété diffuse n’en est pas une.
- À quel prix vendez-vous ? La base dédiée par locataire impose un coût plancher par client. Si ce plancher représente une part significative de votre prix mensuel, ce modèle n’est pas adapté à ce segment.
- Quelle est votre capacité opérationnelle ? Choisir un modèle d’isolation que votre équipe ne peut pas automatiser, c’est choisir l’indisponibilité.
- Quelle est la probabilité d’une restauration par locataire ? Si un client peut supprimer accidentellement ses propres données, le schéma partagé posera problème.
L’hybride, et pourquoi il s’impose souvent
La plupart des plateformes aboutissent à un modèle mixte : schéma partagé pour l’offre en libre-service, bases dédiées pour les clients grands comptes qui le demandent. C’est une destination fréquente et légitime.
C’est aussi bien plus simple à atteindre si vous l’anticipez. Concevoir dès le départ une couche de résolution de locataire capable de router vers une base partagée ou dédiée coûte très peu au début et rend le modèle hybride possible par la suite. Le vrai coût, c’est de le rajouter dans un code qui supposait une seule chaîne de connexion.
En cas de doute, construisez un schéma partagé derrière une abstraction capable de router par locataire. Vous bénéficiez du modèle économique aujourd’hui et gardez la possibilité du modèle dédié plus tard — ce qui est l’inverse de la situation habituelle.
Ce qui vous lie dans tous les cas
Quel que soit le modèle choisi, ces décisions s’y figent et méritent la même attention :
- Identité du locataire dans votre couche d’authentification. Adapter la multi-location sur un modèle d’authentification mono-locataire est douloureux : décidez d’emblée si un utilisateur peut appartenir à plusieurs locataires.
- Exposition des identifiants de locataire dans les URLs et APIs. Modifier cela plus tard casse les intégrations mises en place par vos clients.
- Emplacement de la configuration par locataire. Dans les données du locataire ou dans un registre central ? Les deux fonctionnent ; les mélanger non.
- Gestion d’une fusion ou d’une scission de locataire. Rare, mais très difficile si le modèle de données ne l’a jamais prévu : les clients rachètent parfois d’autres clients.
- Modèle de traitement des tâches en arrière-plan. Files d’attente par locataire, ordonnancement équitable et limites de débit par locataire sont bien plus simples à concevoir qu’à ajouter après coup.
La question sous-jacente
Les équipes arrivent souvent à cette décision parce que quelqu’un a demandé : nos données sont-elles sécurisées ? — et choisissent l’isolation maximale comme assurance. Ce réflexe se comprend, mais il est coûteux.
L’isolation n’est qu’un des contrôles. Une plateforme base-par-locataire avec un contrôle d’accès faible, sans journalisation ni cloisonnement administratif, est moins sûre qu’un schéma partagé bien conçu avec sécurité au niveau des lignes et autorisation stricte. Choisissez le modèle de multi-location selon les besoins et l’économie ; la sécurité s’achète séparément, de façon délibérée et à plusieurs niveaux.
C’est le type de décision que nous traitons avant toute ligne de code — voir ce que coûte réellement une plateforme Node.js sur mesure pour comprendre son impact budgétaire. Notre pratique Node.js et notre équipe full-stack travaillent ce point avec les clients, car la réponse dépend de faits commerciaux qu’eux seuls connaissent. Lorsque les acheteurs sont régulés — comme en finance ou en santé — les exigences de conformité tranchent généralement.
Questions fréquentes
Quel modèle de multi-tenance choisir au lancement d’un nouveau SaaS ?
Schéma partagé, derrière une couche de résolution de tenant capable de router vers une base de données dédiée par la suite. Ce choix minimise le coût initial tout en gardant la possibilité d’évoluer vers un modèle plus coûteux — l’inverse de la situation dans laquelle la plupart des équipes se retrouvent piégées.
Comment éviter les fuites de données entre tenants dans un schéma partagé ?
Faites respecter la séparation des tenants sous l’application : sécurité au niveau des lignes dans la base de données, ou couche d’accès aux données où il est impossible d’écrire une requête non scindée. Compter sur le fait que les développeurs ajoutent une clause WHERE n’est pas un contrôle, et la revue de code ne passe pas à l’échelle.
Quand le modèle une base de données par tenant justifie-t-il son coût ?
Quand l’achat par une entreprise l’exige — résidence des données dans une juridiction précise, ou garantie documentée d’infrastructure non partagée. Si vos clients posent ces questions dans leurs questionnaires de sécurité, ce modèle permet de conclure la vente. Sinon, c’est une assurance coûteuse.
Peut-on changer de modèle de multi-tenance plus tard ?
Oui, mais à un coût important. Il faut réécrire la couche d’accès aux données, migrer les données clients en production et revalider chaque requête, tout en maintenant la plateforme en service. Concevoir une abstraction de routage dès le départ réduit fortement ce coût ; ne pas en avoir donne l’impression d’une décision irréversible.
La multi-tenance a-t-elle un impact sur les performances ?
Avec un schéma partagé, oui : la charge d’un tenant peut dégrader les autres, d’où l’importance de limiter le débit par tenant et d’ordonnancer les tâches équitablement. Les bases de données dédiées éliminent ce problème mais augmentent la surface opérationnelle à maintenir.
Faites valider la décision avant de lancer le développement
Dites-nous qui sont vos clients et ce que demande leur service achats, nous vous indiquerons le modèle réellement adapté à votre activité — le plus économique, le plus souvent. Contactez notre équipe : réponse sous un jour ouvré.