Multi-tenant vs single-tenant : enjeux juridiques

Par David Joseph Atias, avocat au Barreau de Paris · LinkedIn · Juillet 2026

Le choix entre multi-tenant et single-tenant paraît purement technique. Il est pourtant lourd de conséquences juridiques. L’architecture multi-tenant, où une seule instance héberge tous les clients, optimise les coûts mais concentre les risques de fuite entre clients. L’architecture single-tenant, où chaque client a son instance dédiée, renforce l’isolation mais coûte plus cher. Ce choix engage la sécurité des données (article 32 du RGPD), la confidentialité, la réversibilité et la responsabilité. Cet article décrypte les enjeux juridiques de ces deux architectures, leur cadre légal et les critères pour choisir et sécuriser le bon modèle.

SOMMAIRE

1. Pourquoi le choix d’architecture est stratégique en 2026
2. Comprendre les deux architectures
3. Les 6 enjeux juridiques clés
4. Tableau comparatif des deux modèles
5. Les 5 pièges à éviter
6. Pourquoi faire appel à Atias Avocats
7. FAQ — Questions fréquentes

1. Pourquoi le choix d’architecture est stratégique en 2026

Le choix d’architecture SaaS n’est pas qu’une décision d’ingénieurs. Il détermine le niveau de protection des données et la liberté du client. Trois dynamiques renforcent son importance en 2026.

1.1 La généralisation du SaaS mutualisé

La quasi-totalité des logiciels professionnels sont désormais en SaaS. Pour des raisons de coût, le modèle mutualisé domine très largement le marché. La plupart des clients ignorent pourtant l’architecture réelle de leurs outils. Or, cette architecture conditionne la sécurité de leurs données. Comprendre ce modèle devient donc essentiel pour évaluer le risque réel d’une solution avant de la souscrire.

1.2 Le durcissement des exigences de sécurité

Les contrôles CNIL et la directive NIS2 (Règlement UE 2022/2555) renforcent les exigences de cybersécurité. L’isolation des données entre clients devient un point d’attention central. Une faille de cloisonnement dans une telle architecture peut exposer les données de nombreux clients à la fois. L’enjeu de sécurité est donc démultiplié. Le choix et l’audit de l’architecture deviennent des composantes de la conformité.

1.3 La sensibilité croissante aux données

Les entreprises sont de plus en plus attentives à la localisation et à l’isolation de leurs données. Les secteurs réglementés (santé, finance, défense) imposent des exigences strictes. Pour ces données, le single-tenant ou une isolation renforcée s’impose souvent. Le choix d’architecture devient ainsi un critère de sélection des fournisseurs. Pour aller plus loin, consultez nos services en matière de contrats commerciaux et IT.

2. Comprendre multi-tenant et single-tenant

Avant d’aborder le droit, il faut comprendre les deux architectures. Cette distinction technique est la clé de tous les enjeux juridiques qui suivent.

2.1 L’architecture multi-tenant

Dans ce modèle (multi-locataire), une seule instance de l’application sert tous les clients. Ces clients sont appelés tenants, c’est-à-dire locataires. Leurs données cohabitent dans une base partagée, séparées par des identifiants. C’est une isolation logique : la séparation est assurée par le logiciel, non par des serveurs distincts. Ce modèle réduit fortement les coûts et simplifie la maintenance, d’où sa domination du marché SaaS.

2.2 L’architecture single-tenant

En architecture single-tenant (mono-locataire), chaque client dispose de sa propre instance dédiée. Son application et sa base de données lui sont réservées. C’est une isolation renforcée, parfois physique (serveurs distincts). Ce modèle offre une meilleure séparation, une personnalisation accrue et un contrôle facilité de la localisation des données. En revanche, il coûte plus cher et complexifie la maintenance pour l’éditeur.

2.3 Les modèles intermédiaires

La réalité est souvent nuancée. Entre le modèle mutualisé pur et le modèle dédié pur existent des modèles hybrides. Par exemple, une base de données dédiée par client mais une application partagée. Ou un chiffrement avec une clé propre à chaque client dans une base commune. Ces approches cherchent à combiner les avantages des deux modèles. Le contrat doit décrire précisément le modèle réellement mis en œuvre.

2.4 L’enjeu central : l’isolation des données

Quel que soit le modèle, l’isolation des données est l’enjeu décisif. Elle garantit qu’un client ne peut jamais accéder aux données d’un autre. Dans ce modèle, cette isolation repose entièrement sur la qualité du logiciel. Une faille peut donc avoir des conséquences massives. C’est pourquoi le niveau réel d’isolation doit être vérifié, documenté et garanti contractuellement, indépendamment du modèle affiché.

3. Les 6 enjeux juridiques clés

Le choix d’architecture emporte six enjeux juridiques majeurs. Chacun doit être analysé et traduit dans le contrat SaaS.

3.1 La sécurité des données (article 32 du RGPD)

Le premier enjeu est la sécurité. L’article 32 du RGPD impose des mesures adaptées au risque. En architecture mutualisée, le cloisonnement entre clients est une mesure de sécurité essentielle. Le contrat et l’annexe TOMS (mesures techniques et organisationnelles) doivent décrire précisément comment cette isolation est assurée. Une sécurité défaillante engage la responsabilité du fournisseur comme du client responsable de traitement.

3.2 La confidentialité et la fuite inter-clients

Le deuxième enjeu est la confidentialité. Le risque propre au modèle mutualisé est la fuite inter-clients : une faille permettant à un client de voir les données d’un autre. Ce scénario est gravissime, car il viole la confidentialité de plusieurs clients simultanément. Le contrat doit donc imposer des garanties d’étanchéité et prévoir les conséquences d’une telle violation. La confidentialité est un engagement central du fournisseur.

3.3 La localisation des données

Le troisième enjeu est la localisation. En architecture mutualisée, les données de tous les clients sont hébergées ensemble, parfois hors de l’Union européenne. Cela soulève la question des transferts internationaux et de l’arrêt Schrems II de la CJUE (C-311/18). Le single-tenant facilite le contrôle de la localisation. Le contrat doit préciser où les données sont hébergées et les garanties applicables aux éventuels transferts hors UE.

3.4 La réversibilité des données

Le quatrième enjeu est la réversibilité. Récupérer ses données est plus complexe en modèle mutualisé, car elles sont mêlées à celles des autres clients. L’extraction exige des outils dédiés pour isoler les seules données du client. Le contrat doit prévoir une clause de réversibilité précise : format, périmètre, délais, assistance. Sans elle, le client risque l’enfermement, incapable de migrer vers une autre solution.

3.5 La responsabilité en cas d’incident

Le cinquième enjeu est la responsabilité. En cas de fuite inter-clients, qui répond ? Le fournisseur, au titre de son obligation de sécurité, et le client, comme responsable de traitement. Le contrat doit clarifier la répartition des responsabilités et les plafonds applicables. Une clause limitative trop large peut être écartée si elle vide l’obligation essentielle de sécurité de sa substance (article 1170 du Code civil).

3.6 L’articulation avec l’IA

Le sixième enjeu, spécifique à 2026, concerne l’IA. De nombreux SaaS mutualisés ajoutent des fonctions d’IA. La question devient sensible : les données d’un client servent-elles à entraîner un modèle partagé avec d’autres ? Ce scénario peut créer une contamination des données entre clients. Le contrat doit l’encadrer strictement, en cohérence avec le Règlement UE 2024/1689 (AI Act). Pour aller plus loin, consultez nos services en matière de protection des données personnelles.

4. Tableau comparatif des deux modèles

Le tableau ci-dessous compare le multi-tenant et le single-tenant sur les critères juridiques et opérationnels décisifs.

5. Les 5 pièges à éviter

Au-delà de la théorie, plusieurs pièges récurrents fragilisent le choix et l’encadrement de l’architecture. Les identifier permet de sécuriser sa décision.

5.1 Ignorer l’architecture réelle de la solution

Le premier piège est l’ignorance. Beaucoup de clients souscrivent un SaaS sans savoir s’il est multi-tenant ou single-tenant. Or, ce choix conditionne le risque. Avant de signer, il faut interroger le fournisseur sur son architecture et le niveau d’isolation. Cette information doit figurer au contrat. Souscrire à l’aveugle, c’est accepter un risque que l’on ne mesure pas.

5.2 Croire que single-tenant signifie automatiquement sécurisé

Le deuxième piège est la fausse sécurité. Le single-tenant isole mieux, mais il n’est pas magiquement sûr. Une instance dédiée mal sécurisée reste vulnérable. À l’inverse, un modèle mutualisé bien conçu peut offrir une excellente protection. La sécurité dépend de la qualité réelle des mesures, pas seulement du modèle. Il faut donc évaluer les mesures concrètes, et non se fier à l’étiquette de l’architecture.

5.3 Négliger la clause de réversibilité en modèle mutualisé

Le troisième piège concerne la sortie. En modèle mutualisé, extraire ses données est complexe car elles sont mêlées à celles des autres. Sans clause de réversibilité précise, le client risque l’enfermement. Le contrat doit imposer un format d’export, un périmètre clair et une assistance. Cette vigilance est encore plus cruciale en architecture mutualisée qu’en instance dédiée. La réversibilité se négocie avant la signature, jamais après.

5.4 Omettre l’analyse de la localisation des données

Le quatrième piège est la localisation. En architecture mutualisée, les données peuvent être hébergées hors de l’Union européenne, sans que le client le sache. Cela déclenche les règles sur les transferts internationaux (arrêt Schrems II). Il faut vérifier où sont stockées les données et quelles garanties s’appliquent. Une clause de localisation précise est indispensable, surtout pour les données sensibles.

5.5 Sous-estimer l’entraînement de l’IA sur les données mutualisées

Le cinquième piège, spécifique à 2026, concerne l’IA. Dans un SaaS mutualisé, les données de tous les clients peuvent servir à entraîner un modèle commun. Cela crée un risque de contamination entre clients. Le contrat doit interdire ou strictement encadrer cet usage, en cohérence avec l’AI Act. Ce point de vigilance est devenu central dès lors qu’une fonction d’IA est intégrée à une architecture mutualisée.

6. Pourquoi faire appel à Atias Avocats

Analyser les enjeux juridiques d’une architecture mutualisée ou dédiée exige une combinaison rare de compétences : maîtrise du RGPD et de la sécurité (article 32, isolation, annexe TOMS), compréhension technique des architectures SaaS (isolation logique, physique, modèles hybrides), connaissance des transferts internationaux (arrêt Schrems II) et des enjeux de l’AI Act lorsque le SaaS intègre de l’IA. Cette double culture juridique et technique est précisément la valeur ajoutée d’un cabinet spécialisé en contrats IT et protection des données.

Atias Avocats accompagne éditeurs SaaS, DSI, DPO, RSSI, directions achats, fondateurs et grands groupes sur l’ensemble du sujet : note d’analyse du choix d’architecture, audit de conformité de l’architecture et de l’isolation, rédaction des clauses contractuelles (sécurité, isolation, réversibilité, responsabilité), articulation avec l’annexe TOMS et le DPA, accompagnement des éditeurs sur la traduction contractuelle de leur architecture. Pour aller plus loin, consultez nos services en matière de contrats commerciaux et IT.

Conclusion

Le choix d’architecture dépasse de loin la simple décision technique. Il engage la sécurité, la confidentialité, la localisation, la réversibilité et la responsabilité. Les six enjeux juridiques présentés ici, combinés à la vigilance sur les cinq pièges classiques, offrent un référentiel directement utilisable par DSI, DPO, RSSI et directions juridiques pour évaluer et sécuriser une solution SaaS.

L’investissement requis pour analyser et encadrer ce choix est sans commune mesure avec le coût d’une fuite inter-clients ou d’une réversibilité impossible. À l’heure de NIS2 et de l’IA, l’architecture d’un SaaS n’est plus un détail d’ingénierie : c’est un déterminant de la conformité et de la liberté du client. Le réflexe à adopter est clair : connaître l’architecture réelle, vérifier l’isolation, sécuriser la réversibilité, contrôler la localisation et encadrer l’IA. C’est précisément cette analyse qui transforme un choix subi en décision maîtrisée.

FAQ — Questions fréquentes

Quelle est la différence entre multi-tenant et single-tenant ?

La différence porte sur le mode d’hébergement des clients d’un logiciel SaaS. En architecture multi-tenant (multi-locataire), une seule instance de l’application et de sa base de données est partagée entre tous les clients, appelés tenants (locataires). Les données de chaque client sont séparées de façon logique, par des identifiants, mais elles cohabitent dans la même infrastructure. En architecture single-tenant (mono-locataire), chaque client dispose de sa propre instance dédiée de l’application et de sa base de données, isolée physiquement ou logiquement des autres. Le multi-tenant offre des coûts réduits et une maintenance simplifiée. Le single-tenant offre une isolation renforcée et une personnalisation plus poussée, mais à un coût supérieur. Le choix entre les deux emporte des conséquences juridiques majeures, notamment en matière de sécurité, de confidentialité et de réversibilité des données.

Le multi-tenant est-il conforme au RGPD ?

Oui, le multi-tenant peut être parfaitement conforme au RGPD, à condition que l’isolation des données soit rigoureuse. L’article 32 du RGPD impose des mesures de sécurité adaptées au risque, dont le cloisonnement effectif des données entre clients. Une architecture bien conçue garantit qu’un client ne peut jamais accéder aux données d’un autre. Le risque spécifique du modèle mutualisé est la fuite inter-clients : une faille de cloisonnement exposant les données d’un tenant à un autre. Ce risque doit être maîtrisé par des mesures techniques (séparation logique, contrôle d’accès, chiffrement) documentées dans l’annexe TOMS du contrat. Pour des données très sensibles, le single-tenant ou une isolation renforcée peut être préférable. La conformité ne dépend donc pas du modèle en soi, mais de la qualité réelle de l’isolation mise en œuvre.

Quel modèle choisir pour des données sensibles ?

Pour des données sensibles, le single-tenant est souvent privilégié, mais ce n’est pas une règle absolue. Les données de santé, financières ou stratégiques exigent une isolation maximale. Le single-tenant, en dédiant une instance à chaque client, réduit le risque de fuite inter-clients et facilite la localisation des données. Il permet aussi une personnalisation des mesures de sécurité. Cependant, une architecture mutualisée dotée d’une isolation forte (chiffrement par client, séparation stricte) peut suffire, y compris pour des données sensibles, si elle est correctement auditée. Le choix dépend du niveau de risque, des exigences réglementaires sectorielles (par exemple l’hébergement certifié pour la santé) et de la tolérance de l’entreprise. L’analyse juridique et technique doit précéder la décision, et le contrat doit refléter le modèle retenu et ses garanties.

Le multi-tenant complique-t-il la réversibilité ?

Oui, le multi-tenant peut compliquer la réversibilité, c’est un point de vigilance majeur. La réversibilité est la capacité de récupérer ses données et de migrer vers une autre solution en fin de contrat. En architecture mutualisée, les données d’un client sont mêlées à celles des autres dans une base partagée. Leur extraction propre exige donc des outils spécifiques pour isoler les seules données du client concerné, sans exposer celles des autres. En single-tenant, l’extraction est plus simple car l’instance est dédiée. Le contrat doit, dans tous les cas, prévoir une clause de réversibilité précise : format d’export, périmètre exact des données, délais, assistance, et suppression certifiée après transfert. Sans cette clause, un client en architecture mutualisée peut se retrouver prisonnier de la solution, faute de pouvoir récupérer proprement ses données.

Contact : david@atiasavocats.com | LinkedIn: David Joseph Atias | https://www.atiasavocats.com | 42 rue de la Clef, 75005 Paris

Atias Avocats — Contrats IT, SaaS, Protection des données, Sécurité