Architecture multi-tenant : base partagée ou instance par client

À retenir

• Base partagée : une seule base, un identifiant de client sur chaque ligne. Le moins cher à exploiter, le plus simple à faire évoluer, et celui qui demande le plus de rigueur sur l’étanchéité.
• Schéma par client : une base, un espace de nommage par client. Isolation plus lisible, migrations plus lourdes, plafond autour de quelques centaines de clients.
• Instance par client : tout en double. Isolation maximale, coût maximal, et chaque mise à jour doit être déployée autant de fois qu’il y a de clients.
• L’étanchéité se garantit au niveau de l’accès aux données, pas dans le code applicatif. Un filtre que chaque développeur doit penser à écrire est un filtre qui sera oublié un jour.
• Le test qui compte n’est pas « est-ce que ça marche », c’est « est-ce qu’un client voit un autre client ». Il s’automatise, et il doit tourner à chaque livraison.
• Quatre opérations décident du modèle : restaurer un seul client, supprimer un seul client, migrer le schéma, et chiffrer les données d’un client en particulier.
• Passer d’un modèle à l’autre coûte entre 15 et 40 jours selon la taille de l’application. C’est pour cela que le choix se fait au cadrage : voir le prix d’un SaaS B2B.

C’est la première décision d’architecture d’un logiciel vendu à plusieurs entreprises, et c’est aussi celle qu’on prend le plus souvent par défaut. « On fera une base par client, c’est plus propre » est la phrase la plus coûteuse qu’on puisse prononcer au démarrage d’un SaaS.

Voici les trois modèles, ce qu’ils coûtent, et les quatre opérations qui tranchent réellement entre eux.

Les trois modèles

Modèle	Comment ça marche	Isolation	Coût d’exploitation
Base partagée	Une base, un identifiant de client sur chaque ligne	Logique, garantie par le filtrage d’accès	Le plus faible
Schéma par client	Une base, un espace de nommage par client	Structurelle à l’intérieur d’une même base	Moyen, croît avec le nombre de clients
Instance par client	Application et base dupliquées pour chaque client	Physique, totale	Le plus élevé, linéaire

Le graphique dit l’essentiel : le coût de la base partagée croît très lentement avec le nombre de clients, celui de l’instance par client croît en ligne droite. À dix clients, l’écart se voit. À cinquante, il décide de la rentabilité du produit.

Pourquoi l’instance par client semble simple et ne l’est pas

L’argument est séduisant : aucune donnée partagée, donc aucun risque de fuite entre clients, et un client difficile peut être isolé sur une infrastructure dédiée. Tout cela est vrai. Ce qui est tu, c’est le reste.

• Chaque mise à jour se déploie autant de fois qu’il y a de clients. À trois clients c’est un détail, à trente c’est un métier, et le jour où une migration échoue sur le client vingt-trois, vous avez deux versions du logiciel en production.
• Les coûts fixes se multiplient. Chaque instance paie son serveur, sa base, ses sauvegardes et sa surveillance, même pour un client qui utilise le produit une heure par semaine.
• Le support devient un travail d’enquête. Reproduire un problème suppose de savoir sur quelle instance, dans quelle version, avec quelle configuration.
• Les évolutions transversales deviennent impossibles. Ajouter une fonctionnalité à tout le monde demande de la déployer partout, et donc d’avoir maintenu tout le monde sur la même version, ce qui ne se produit jamais spontanément.

L’instance par client reste le bon choix dans un cas précis : quand un client l’exige contractuellement, souvent pour une raison de localisation ou de certification. C’est alors une option payante du produit, pas son architecture par défaut.

Comment garantir l’étanchéité sans y penser

Avec une base partagée, tout repose sur une règle : aucune requête ne doit pouvoir lire les données d’un autre client. La question n’est pas de savoir si on l’écrit, c’est de savoir ce qui se passe le jour où un développeur l’oublie.

Approche	Ce qui se passe quand on oublie le filtre	Verdict
Filtre écrit dans chaque requête	La requête renvoie les données de tous les clients	À proscrire
Filtre centralisé dans la couche d’accès	Impossible d’écrire une requête sans filtre	Le minimum acceptable
Filtre appliqué par la base elle-même	La base refuse de renvoyer la ligne, quelle que soit la requête	La garantie la plus forte

La troisième ligne est la seule qui transforme une discipline en garantie. Les bases de données modernes savent appliquer des règles de visibilité au niveau des lignes, en fonction du client pour lequel la session travaille. Le filtre n’est plus une convention d’équipe, c’est une propriété du système.

Et surtout, cela se teste. Un test automatisé qui ouvre une session au nom du client A et tente de lire une donnée du client B doit échouer. Ce test doit tourner à chaque livraison : c’est le seul qui protège contre la régression la plus grave d’un SaaS B2B.

Les quatre opérations qui tranchent

Le choix ne se fait pas sur l’élégance, il se fait sur ces quatre gestes du quotidien.

Opération	Base partagée	Instance par client
Restaurer un seul client au jour d’avant	Difficile : il faut extraire ses lignes d’une sauvegarde globale	Trivial : on restaure son instance
Supprimer définitivement un client	Demande un balayage de toutes les tables, à outiller	Trivial : on détruit l’instance
Migrer le schéma de données	Une seule migration	Autant de migrations que de clients
Isoler physiquement un client exigeant	Impossible sans sortir du modèle	Natif

Les deux premières lignes sont celles qu’on découvre trop tard. Restaurer un seul client sans toucher aux autres est une demande qui arrive toujours, et elle s’outille : des exports par client, programmés, et une procédure de réinjection. Quelques jours de travail, à prévoir au cadrage plutôt qu’en urgence.

La suppression définitive n’est pas qu’une question technique : c’est une obligation. Un client qui s’en va peut demander l’effacement de ses données, et le RGPD impose de pouvoir le faire. Une architecture où personne ne sait lister toutes les tables contenant des données d’un client est une architecture non conforme. Voir aussi la liste à vérifier avant mise en ligne.

Comment choisir, en trois questions

Question	Si oui	Si non
Un client vous impose-t-il contractuellement une infrastructure dédiée ?	Instance pour celui-là, base partagée pour les autres	Continuez
Visez-vous plus de vingt clients à trois ans ?	Base partagée, sans hésiter	Continuez
Vos clients ont-ils des volumes de données très inégaux ?	Base partagée, avec un découpage prévu pour les plus gros	Base partagée

Dans presque tous les cas, la réponse est la base partagée. Le modèle hybride, base partagée pour la majorité et instance dédiée pour les deux ou trois clients qui la paient, est la configuration que nous rencontrons le plus souvent sur les produits matures. Elle n’a de sens que si elle a été prévue dès le départ, parce qu’elle suppose que le code fonctionne dans les deux situations.

Questions fréquentes

Peut-on changer de modèle plus tard ?

Oui, et cela coûte entre 15 et 40 jours selon la taille de l’application, parce que le changement touche chaque accès aux données. Le sens le plus coûteux est de passer d’instances séparées à une base partagée : il faut fusionner des données qui ont dérivé, avec des identifiants qui se télescopent. L’inverse est plus simple, et c’est une raison de plus de commencer partagé.

La base partagée est-elle moins sûre ?

Elle l’est si l’étanchéité repose sur la discipline des développeurs. Elle ne l’est pas si le filtrage est appliqué par la base elle-même et vérifié par un test automatisé à chaque livraison. La question n’est pas le modèle, c’est le niveau auquel la garantie est posée.

Que répondre à un client qui exige « sa » base de données ?

D’abord comprendre ce qu’il protège : c’est presque toujours une exigence de conformité ou de localisation, pas une préférence technique. Ensuite proposer une réponse à son besoin réel, chiffrement dédié, localisation garantie, ou instance dédiée facturée en option. Accepter d’emblée une instance par client pour un seul demandeur, c’est transformer son exigence en architecture pour tout le monde.

Et pour les sauvegardes ?

Avec une base partagée, la sauvegarde est globale : rapide, simple, peu coûteuse. Ce qui demande du travail, c’est la restauration partielle. On la prépare avec des exports par client programmés, qui servent aussi à la réversibilité et à la suppression définitive. Trois usages pour un seul outillage.

À partir de combien de clients le modèle compte-t-il vraiment ?

La bascule se sent vers cinq ou six clients pour le déploiement, et vers vingt pour le coût. En dessous, tous les modèles fonctionnent, ce qui explique que beaucoup de produits démarrent sur une architecture qui ne tiendra pas. Le choix doit être fait pour l’année trois, pas pour le premier client.

Le schéma par client est-il un bon compromis ?

C’est un compromis réel, avec un plafond. Il offre une isolation plus lisible qu’une base partagée et évite la multiplication des instances. En revanche chaque migration de schéma se répète pour chaque client, et au-delà de quelques centaines, les outils eux-mêmes commencent à peiner. C’est un bon choix pour un produit qui vise des dizaines de clients, pas des milliers.

Glossaire

• Multi-tenant : une seule application sert plusieurs entreprises clientes, dont les données restent étanches. C’est la définition technique d’un SaaS.
• Locataire : une entreprise cliente du produit, avec ses utilisateurs et ses données. À ne pas confondre avec un utilisateur.
• Filtrage au niveau des lignes : règle appliquée par la base de données elle-même, qui limite les lignes visibles selon le locataire de la session.
• Migration de schéma : modification de la structure de la base. Elle se joue une fois en base partagée, autant de fois qu’il y a de clients en instances séparées.
• Modèle hybride : base partagée pour la majorité des clients, instance dédiée pour ceux qui l’exigent et la paient.

Sources

• Règlement général sur la protection des données, chapitre IV · effacement et restitution des données · CNIL
• Guide de la sécurité des données personnelles · cloisonnement et gestion des accès · CNIL
• Informatique en nuage · confier ses données à un service hébergé · CNIL
• Tarifs Stripe en France · facturation récurrente d’un SaaS · Stripe
• Les TIC et le commerce électronique dans les entreprises en 2024 · INSEE

À lire aussi sur le blog

• Combien coûte un SaaS B2B sur mesure · le multi-tenant parmi les quatre postes invisibles
• Sécurité et RGPD d’une application métier · l’étanchéité comme mesure de sécurité
• Combien coûte l’hébergement d’une application · le coût par client, chiffré
• Le cas CollectMyRatings · un multi-tenant à trois niveaux, en production
• Transformer un outil interne en SaaS · le multi-tenant comme prérequis

Aller plus loin avec nous

• SaaS et plateformes B2B · architecture multi-locataire, MVP en 8 à 14 semaines, à partir de 25 000 €
• Tierce maintenance applicative · à partir de 145 € par mois
• Un premier échange sous 48 h · on regarde votre produit et combien de clients il doit tenir