En bref
Une architecture multi-tenant (ou multilocataire) fait tourner une seule instance d'un logiciel pour plusieurs clients, dont les données restent séparées logiquement. En single-tenant, chaque client dispose de sa propre instance. Le choix influe sur la personnalisation, les mises à jour, l'isolation des données et le prix.
Définition
Un « tenant » est un locataire : un client, avec ses utilisateurs et ses données. Dans une architecture multi-tenant (on lit aussi « multi tenant » ; en français, multilocataire), tous les locataires partagent le même code, la même application et souvent la même infrastructure, comme les occupants d'un immeuble partagent les murs, l'escalier et la chaudière. Chacun a sa clé et son appartement : ses données sont cloisonnées par le logiciel.
La plupart des offres SaaS fonctionnent ainsi : l'éditeur maintient un seul produit, le met à jour une fois pour tous et répartit les coûts d'exploitation entre ses clients. Le terme décrit la façon dont le logiciel est construit et déployé ; il ne dit rien du niveau de service ni de la sécurité. Le partage existe aussi plus bas dans la pile des modèles IaaS, PaaS, SaaS : un serveur physique de cloud héberge souvent les machines virtuelles de plusieurs clients.
Multi-tenant ou single-tenant
En single tenant, chaque client reçoit sa propre instance : une application et une base dédiées, parfois sur un serveur dédié, avec un prix en conséquence. Entre les deux existent des architectures mixtes, par exemple une application partagée avec une base de données par client : demandez à l'éditeur où passe la frontière dans son offre.
| Point | Multi-tenant | Single-tenant |
|---|---|---|
| Instance | Une seule, partagée entre les clients | Une par client |
| Données | Séparées logiquement par le logiciel | Séparées physiquement par l'instance |
| Personnalisation | Paramétrage dans les limites du produit | Plus large, parfois des développements spécifiques |
| Mises à jour | Au calendrier de l'éditeur, pour tous les clients | Calendrier souvent négociable, client par client |
| Prix | Généralement plus bas, coûts mutualisés | Plus élevé, infrastructure dédiée |
Ce que cela change pour l'acheteur
Dans une instance partagée, l'isolation des données repose sur le logiciel : contrôles d'accès, identifiant de locataire sur chaque enregistrement, parfois chiffrement par client. Une faille dans ce cloisonnement peut exposer plusieurs clients à la fois. Sa qualité ne se voit pas de l'extérieur et vous ne pouvez pas l'auditer vous-même : demandez des preuves (voir les questions plus bas).
Côté personnalisation, le produit est le même pour tous : vous disposez des champs, des workflows et des paramètres prévus par l'éditeur. Un besoin hors catalogue passe par une demande d'évolution, qui a d'autant plus de chances d'aboutir qu'elle intéresse d'autres clients. Si votre processus est spécifique, décrivez-le dès le cahier des charges et faites-le jouer en démonstration.
Les mises à jour arrivent sans projet de votre côté : l'éditeur déploie chaque version pour tous ses clients. En contrepartie, vous ne choisissez pas la date, et une fonction que vous utilisiez peut changer ou disparaître. Prévoyez au contrat un préavis pour les changements importants et un engagement de non-régression sur les fonctions dont vous dépendez.
Les ressources étant partagées, un client très gourmand peut en théorie ralentir les autres ; les éditeurs s'en protègent par des quotas et des plafonds. Si vos volumes sont élevés (documents, appels d'API, utilisateurs simultanés), demandez les limites applicables et faites-les figurer dans le SLA.
Les questions à poser à l'éditeur
- Comment les données de chaque client sont-elles séparées : base commune avec identifiant de locataire, base ou schéma par client, chiffrement distinct ?
- Quels contrôles et quelles preuves : tests d'intrusion, rapports d'audit, certifications (ISO 27001, SOC 2), et que pouvons-nous en consulter ?
- Où sont hébergées les données, par quels sous-traitants, et sous quel droit (voir cloud souverain) ?
- Une instance dédiée est-elle possible, et à quel surcoût ?
- Quelles limites techniques s'appliquent à notre usage, et que se passe-t-il quand nous les atteignons ?
- Comment les mises à jour sont-elles annoncées, avec quel préavis, et peut-on tester une version avant son déploiement ?
- Quelles personnalisations sont garanties dans la durée, et lesquelles dépendent de la feuille de route ?
- Comment récupère-t-on ses données en fin de contrat, dans quel format et sous quel délai ?
Faites entrer les réponses dans le contrat ou ses annexes : un questionnaire de sécurité rempli avant la signature pèse peu si le contrat ne le reprend pas. Dans Naigo, la négociation permet de suivre ces sujets comme des objectifs (cible, limite, ligne rouge) et de comparer les offres de plusieurs éditeurs ; l'évaluation de leurs réponses reste de votre ressort.
Questions fréquentes
Le multi-tenant est-il moins sûr que le single-tenant ?
Pas par principe. Le multi-tenant repose sur la qualité du cloisonnement logiciel entre clients, le single-tenant sur la séparation des instances, et l'un comme l'autre peut être bien ou mal conçu. Demandez à l'éditeur ses mesures d'isolation, ses audits et ses certifications plutôt que de vous fier à l'étiquette.
Peut-on obtenir une instance dédiée pour un SaaS multi-tenant ?
Certains éditeurs la proposent en option, à un prix supérieur et parfois avec un rythme de mise à jour distinct. Ce n'est pas la règle : posez la question dès le cahier des charges, car la réponse change le budget et le calendrier.
Publié le 10 octobre 2026
