Définition
Une architecture multi-tenant est une architecture logicielle où une seule installation de l'application sert plusieurs entreprises clientes, appelées tenants, chacune n'accédant qu'à ses propres données. Elle s'oppose au mono-tenant, où chaque client reçoit sa propre installation. C'est ce qui rend le modèle SaaS viable : servir cent clients ne coûte pas cent fois plus cher, et un correctif déployé une fois profite à tout le monde.
Les trois modèles
Tous les SaaS sont multi-tenant, mais la manière de séparer les données varie du tout au tout. Le choix se joue sur un arbitrage entre le degré d'isolation et le coût d'exploitation.
Une base de données par client
Chaque client dispose de sa propre base, totalement séparée des autres. C'est le modèle le plus proche de ce que connaissent les éditeurs venus du logiciel installé.
Ce que ça apporte
Isolation maximale, facile à expliquer à un client méfiant, restauration d'un seul client sans toucher aux autres.
Ce que ça coûte
Le coût d'hébergement suit le nombre de clients. Chaque changement de structure de données doit être appliqué autant de fois qu'il y a de bases.
Un schéma par client
Une seule base de données, mais un espace de nommage séparé par client. Un compromis entre la séparation stricte et la mutualisation.
Ce que ça apporte
Bonne isolation logique pour un coût d'infrastructure contenu. Un client peut être extrait ou restauré individuellement.
Ce que ça coûte
Le nombre de schémas devient difficile à administrer au-delà de quelques centaines de clients, et les migrations restent multiples.
Une base partagée
Toutes les données cohabitent dans les mêmes tables, chaque ligne portant l'identifiant du client auquel elle appartient. C'est le modèle des SaaS grand public.
Ce que ça apporte
Le moins cher à héberger et le plus simple à faire évoluer : une migration s'applique une fois pour tous. Monte à des milliers de clients sans effort particulier.
Ce que ça coûte
L'isolation repose entièrement sur la rigueur du code. Une requête mal écrite peut exposer les données d'un client à un autre, ce qui impose des garde-fous systématiques.
Le comparatif
| Critère | Base par client | Schéma par client | Base partagée |
|---|---|---|---|
| Isolation des données | Maximale, physique | Forte, logique | Dépend du code |
| Coût d'hébergement | Croît avec chaque client | Modéré | Le plus bas |
| Mise à jour de la structure | Une fois par client | Une fois par client | Une seule fois |
| Restaurer un seul client | Simple | Simple | Délicat |
| Nombre de clients visé | Quelques dizaines | Quelques centaines | Milliers et plus |
| Terrain de prédilection | Grands comptes, données sensibles | B2B intermédiaire | Volume, libre-service |
Une nuance utile : ces modèles se mélangent. Rien n'interdit de faire tourner l'essentiel de vos clients en base partagée et de réserver une base dédiée aux quelques grands comptes qui l'exigent. Cette approche hybride coûte plus cher à maintenir, mais elle débloque des contrats qui seraient autrement hors de portée.
Quatre questions pour trancher
Combien de clients visez-vous à trois ans ?
C'est le critère qui tranche le plus vite. En dessous de cinquante clients, la base par client reste gérable. Au-delà de quelques centaines, la base partagée devient difficile à éviter.
Que vous impose votre marché ?
Certains secteurs et certains grands comptes exigent contractuellement une séparation physique des données. Quand cette exigence figure dans les appels d'offres que vous visez, elle décide à votre place.
À quelle fréquence votre produit évolue-t-il ?
Un produit qui change souvent souffre du modèle par client, où chaque évolution de structure se rejoue autant de fois qu'il y a de bases. La base partagée favorise les cycles courts.
Quelle est votre tolérance au risque de fuite ?
En base partagée, la séparation dépend du code. Cela se maîtrise avec des règles d'accès systématiques et des tests dédiés, mais cela demande une discipline qui doit exister dans l'équipe.
Ce que coûte une erreur de modèle
Changer de modèle d'isolation après le lancement est l'un des chantiers les plus lourds qu'un SaaS puisse rencontrer. Il touche la structure des données et, en même temps, tout le code qui les lit et les écrit. Sur un produit déjà en service, avec des clients qui travaillent dessus tous les jours, la migration se prépare sur des mois.
Le cas le plus fréquent est celui de l'éditeur parti sur une base par client parce que c'était rassurant, et qui découvre à cent clients que chaque évolution de son produit demande cent migrations. La facture de la bascule dépasse souvent celle du développement initial.
La conclusion pratique tient en une phrase : ce choix mérite quelques jours d'analyse au démarrage, quand il ne coûte encore que du temps de réflexion.
Les questions à poser à votre prestataire
Vous n'avez pas à savoir implémenter tout cela. En revanche, ces six questions vous diront assez vite si votre interlocuteur a déjà construit un SaaS ou s'il improvise.
- Quel modèle d'isolation proposez-vous, et pourquoi celui-là pour mon cas ?
- Comment garantissez-vous qu'un client ne peut pas accéder aux données d'un autre ?
- Comment restaure-t-on les données d'un seul client après une erreur de sa part ?
- Que se passe-t-il le jour où un client exige que ses données soient séparées ?
- Comment se déroule une mise à jour de structure quand j'aurai deux cents clients ?
- Peut-on changer de modèle plus tard, et qu'est-ce que ça coûterait ?
La sixième est la plus révélatrice. Un prestataire expérimenté répondra que c'est possible mais coûteux, et vous expliquera pourquoi. Celui qui répond que ce sera facile n'a jamais eu à le faire.
Pour aller plus loin
Si vous partez d'une page blanche, le socle multi-tenant fait partie des six briques détaillées dans la création de plateforme SaaS.
Si vous éditez déjà un logiciel installé chez vos clients et que la question se pose dans le cadre d'un passage à l'abonnement, voir transformer son logiciel en SaaS.
FAQ
Qu'est-ce qu'une architecture multi-tenant ?
C'est une architecture logicielle où une seule installation de l'application sert plusieurs entreprises clientes, appelées tenants, chacune n'accédant qu'à ses propres données. Elle s'oppose au modèle mono-tenant, où chaque client dispose de sa propre installation. Le multi-tenant est ce qui rend le modèle SaaS économiquement viable, puisque servir cent clients ne coûte pas cent fois plus cher.
Quel modèle multi-tenant choisir ?
Pour quelques dizaines de clients grands comptes avec des exigences fortes sur les données, une base par client. Pour un SaaS B2B classique visant quelques centaines de clients, un schéma par client offre un bon compromis. Pour un produit en libre-service visant le volume, une base partagée avec identifiant de client est le choix standard.
Peut-on changer de modèle après le lancement ?
Techniquement oui, mais c'est un des chantiers les plus coûteux qui soient, parce qu'il touche à la fois la structure des données et l'ensemble du code qui y accède. Passer d'une base par client vers une base partagée est le sens le plus fréquent, et le plus laborieux. C'est pour cette raison que le choix mérite quelques jours de réflexion au démarrage.
Le multi-tenant est-il compatible avec le RGPD ?
Oui, quel que soit le modèle retenu. Le règlement n'impose pas de séparation physique des bases, il impose des mesures adaptées au risque, la capacité à extraire ou effacer les données d'une personne, et une traçabilité des accès. Ces exigences se satisfont dans les trois modèles, avec des efforts d'implémentation différents.
Combien coûte la mise en place d'un socle multi-tenant ?
Sur une plateforme SaaS neuve, le socle d'isolation, de gestion des comptes et de facturation représente environ un tiers du budget de la première version, soit typiquement 15 000 à 25 000 euros sur un projet de 40 000 à 80 000 euros. Sur un logiciel existant à convertir, le montant dépend entièrement de la manière dont l'accès aux données a été écrit à l'origine.
Faut-il un modèle multi-tenant dès le MVP ?
Il faut au minimum que la structure des données le permette, même si toutes les fonctions ne sont pas construites. Ajouter un identifiant de client dès le départ coûte quelques jours. Le rajouter deux ans plus tard sur un produit en service coûte plusieurs mois.
Un modèle à arbitrer ?
30 minutes pour comprendre votre marché et votre horizon, et vous dire lequel des trois modèles tient la route dans votre cas.
Réserver un appel