---
term: 'Architecture de Base de Données Multi-Tenant'
seoTitle: 'Architecture de base de données multi-tenant : les 3 modèles comparés'
headline: "Qu'est-ce qu'une architecture de base de données multi-tenant ?"
slug: base-de-donnees-multi-tenant
category: database
shortDefinition: "L'architecture de base de données multi-tenant est un modèle qui stocke de nombreux clients dans une couche de données, isolés par ligne, schéma ou base dédiée."
relatedTerms:
  - tenant-isolation
  - multi-tenant-cloud-hosting
  - row-level-security
  - data-layer-vs-application-layer-security
  - database-schema
contrastsWith:
  - multi-tenant-cloud-hosting
aboutTerms:
  - 'Shared Schema (Pool)'
  - 'Schema-per-Tenant (Bridge)'
  - 'Database-per-Tenant (Silo)'
faq:
  - question: 'Quels sont les trois modèles de base de données multi-tenant ?'
    answer: "Le schema partagé — un seul jeu de tables, chaque ligne portant un identifiant de tenant ; le schema par tenant — une seule base, un namespace de tables distinct par client ; et la base par tenant — une séparation physique complète. Les guides d'architecture cloud nomment ces trois mêmes modèles pool, bridge et silo. Les systèmes réels les combinent de plus en plus, en répartissant les tenants entre les modèles selon leur taille et leurs besoins de conformité."
  - question: 'Base partagée ou base par tenant : laquelle choisir ?'
    answer: "Le choix par défaut qui fait consensus est le schema partagé, sauf si quelque chose impose l'isolation : exigences réglementaires, séparation contractuelle des données, forte personnalisation par tenant ou tenants assez gros pour nécessiter leurs propres ressources. Le schema partagé maximise la densité et minimise l'exploitation ; les bases par tenant maximisent l'isolation et multiplient tout le reste — migrations, sauvegardes, connexions, coût."
  - question: 'Combien de tenants chaque modèle peut-il gérer ?'
    answer: "Les plafonds pratiques tirés de l'expérience en production : la base par tenant tient confortablement jusqu'à quelques dizaines ou quelques centaines de tenants avant que l'exploitation ne domine ; le schema par tenant atteint les centaines, jusqu'à environ un millier, avant que les métadonnées et l'orchestration des migrations ne saturent ; le schema partagé passe à des milliers, voire des millions de tenants, et le sharding du schema partagé par tenant l'étend pratiquement sans limite."
  - question: "Comment empêcher un tenant de voir les données d'un autre tenant ?"
    answer: "Par la défense en profondeur, jamais par une clause WHERE seule. La restriction au tenant côté application (middleware ou filtres d'ORM) est la première couche ; la sécurité au niveau des lignes appliquée par la base de données est la seconde — des politiques qui filtrent chaque requête selon le tenant courant, quoi que l'application ait oublié. Dans les conceptions à schema partagé, un seul filtre oublié est une fuite de données entre tenants, c'est pourquoi la base de données elle-même doit appliquer la frontière."
  - question: 'Comment fonctionnent les migrations de schéma selon les modèles ?'
    answer: "Avec un schema partagé, une migration met à jour tous les tenants d'un coup — simple, avec un rayon d'impact à la hauteur. Avec un schema ou une base par tenant, la même migration doit s'exécuter une fois par tenant : des centaines d'exécutions qui demandent orchestration, suivi des versions et détection de dérive, puisqu'une exécution ratée laisse un tenant sur un schéma plus ancien. L'outillage de migration est la taxe cachée de l'isolation."
  - question: "Peut-on restaurer les données d'un seul tenant ?"
    answer: "Avec une base par tenant, trivialement — restaurez cette base à n'importe quel instant, sans toucher personne d'autre. Avec un schema partagé, c'est vraiment difficile : la sauvegarde contient tout le monde, donc vous restaurez sur une instance annexe et recopiez sélectivement les lignes du tenant. La restauration par tenant est l'un des arguments pratiques les plus forts que les grandes entreprises avancent en faveur de niveaux d'isolation."
  - question: 'Comment indexer une base de données multi-tenant à schema partagé ?'
    answer: "Placez l'identifiant de tenant dans chaque table — même là où il semble redondant — et mettez-le en tête de vos index composites, pour que chaque type de requête devienne « tenant d'abord ». Faire de la colonne de tenant la première partie de la clé primaire prépare aussi les données au sharding par tenant, qui est la voie de croissance standard."
  - question: "Qu'est-ce que le sharding par tenant ?"
    answer: "Répartir une conception à schema partagé sur plusieurs bases de données, toutes les lignes d'un même tenant résidant sur exactement un shard, avec un catalogue qui associe les tenants aux shards. On préserve ainsi la densité du schema partagé tout en plafonnant la taille de chaque base, et on peut déplacer les tenants très actifs vers des shards plus calmes. Le prix : le catalogue, l'outillage de rééquilibrage et la perte des requêtes triviales entre tenants."
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'PostgreSQL Row Security Policies'
    url: 'https://www.postgresql.org/docs/current/ddl-rowsecurity.html'
  - name: 'Multitenancy (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/Multitenancy'
  - name: 'Citus — distributed PostgreSQL (open source)'
    url: 'https://github.com/citusdata/citus'
  - name: 'Row-Level Security and Multi-Tenancy on MongoDB (Back4app Engineering)'
    url: 'https://www.back4app.com/multi-tenant-mongodb-row-level-security'
cta:
  title: "L'isolation des tenants dans la couche de données"
  text: "Back4app applique les frontières par tenant là où elles doivent être : des ACL sur chaque objet, des rôles par tenant, des permissions au niveau de la classe sur chaque schéma — vérifiés par la plateforme à chaque requête, sur les API comme dans le dashboard. Aucune clause WHERE à oublier."
  linkText: 'Commencez gratuitement'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-15'
translationKey: multi-tenant-database-architecture
---

**L'architecture de base de données multi-tenant est un modèle qui stocke de nombreux clients dans une couche de données, isolés par ligne, schéma ou base dédiée.** Ces trois niveaux d'isolation constituent tout l'espace de décision — le reste du sujet n'en est que la conséquence : comment s'exécutent les migrations, ce que coûte une restauration, où vit le noisy neighbor (voisin bruyant) et jusqu'où chaque modèle passe à l'échelle.

## Points clés

| Question | Réponse |
| --- | --- |
| Les trois modèles | Schema partagé (tenant ID par ligne) · schema par tenant · base par tenant |
| Le vocabulaire cloud | Les trois mêmes : pool · bridge · silo |
| Le choix par défaut | Schema partagé, sauf si la conformité ou l'échelle imposent l'isolation |
| Les plafonds pratiques | Silo : ~quelques centaines de tenants · bridge : ~1 000 · pool : des millions (avec sharding : illimité) |
| La règle absolue | Appliquer l'isolation dans la base de données, pas dans chaque requête |

## Les trois modèles, en SQL

```sql
-- Modèle 1 · Schema partagé ("pool") : un seul jeu de tables, le tenant sur chaque ligne
CREATE TABLE invoices (
  tenant_id uuid   NOT NULL,
  id        bigint GENERATED ALWAYS AS IDENTITY,
  total     numeric(10,2),
  PRIMARY KEY (tenant_id, id)      -- le tenant en tête : prêt pour l'index et le sharding
);
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_rows ON invoices
  USING (tenant_id = current_setting('app.tenant')::uuid);

-- Modèle 2 · Schema par tenant ("bridge") : une seule base, un namespace chacun
CREATE SCHEMA tenant_acme;          -- mêmes tables, répétées pour chaque tenant

-- Modèle 3 · Base par tenant ("silo") : séparation physique complète
CREATE DATABASE tenant_acme;        -- isolation la plus forte ; N exemplaires de tout
```

Sur un backend géré, la même garantie s'exprime sans SQL : le contrôle d'accès vit sur les données elles-mêmes, donc l'isolation tient sur chaque chemin — API, dashboard ou SDK :

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// The same query for every tenant — ACLs scope results server-side
const query = new Parse.Query('Invoice');
const invoices = await query.find({ sessionToken: user.getSessionToken() });
// Only rows this tenant's role can read come back. No WHERE clause to forget.
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// The same query for every tenant — ACLs scope results server-side
final query = QueryBuilder<ParseObject>(ParseObject('Invoice'));
final response = await query.query();
// The session's role decides which rows exist, before results leave the server
if (response.success) {
  print('${response.results?.length} invoices visible to this tenant');
}
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// The same query for every tenant — ACLs scope results server-side
let query = Invoice.query()
query.find { result in
  if case .success(let invoices) = result {
    print("\(invoices.count) invoices visible to this tenant")
  }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// The same query for every tenant — ACLs scope results server-side
val query = ParseQuery.getQuery<ParseObject>("Invoice")
query.findInBackground { invoices, e ->
  if (e == null) {
    Log.d("Billing", "${invoices.size} invoices visible to this tenant")
  }
}
```

## Schema partagé vs. schema par tenant vs. base par tenant

```mermaid
flowchart LR
  accTitle: Les trois modèles de base de données multi-tenant
  accDescr: Le schema partagé garde tous les tenants dans un seul jeu de tables, séparés par un tenant ID ; le schema par tenant donne à chaque tenant son propre namespace au sein d'une base ; la base par tenant donne à chaque tenant une base de données entièrement séparée.
  subgraph P["Schema partagé · pool"]
    p1["Un seul jeu de tables<br/>tenant_id sur chaque ligne"]
  end
  subgraph B["Schema par tenant · bridge"]
    b1["Une seule base<br/>un namespace par tenant"]
  end
  subgraph S["Base par tenant · silo"]
    s1["Une base par tenant<br/>séparation complète"]
  end
  P --> B --> S
```

| Dimension | Schema partagé | Schema par tenant | Base par tenant |
| --- | --- | --- | --- |
| Isolation | Logique, par ligne | Namespace | Physique |
| Plafond de tenants | Des millions | ~Centaines–1 000 | Dizaines–quelques centaines |
| Coût par tenant | Le plus bas | Intermédiaire | Le plus élevé |
| Migrations | Exécutées une fois, touchent tout le monde | Exécutées × N, orchestrées | Exécutées × N, orchestrées |
| Restauration par tenant | Difficile (copie sélective) | Modérée | Triviale (restaurer une base) |
| Noisy neighbor | Le plus exposé | Partiellement contenu | Éliminé |
| Personnalisation par tenant | La plus difficile | Possible par schéma | La plus facile |
| Onboarding d'un tenant | Insérer une ligne | Créer un schéma | Provisionner une base |

## Les pièges

- **L'indexation se fait « tenant d'abord ».** `tenant_id` figure dans chaque table — même là où les jointures le font paraître redondant — et ouvre chaque index composite : `(tenant_id, created_at)`, pas l'inverse. Chaque requête réelle est restreinte à un tenant ; les index doivent l'être aussi.
- **Les migrations se multiplient avec l'isolation.** La flexibilité du silo se paie d'une couche d'orchestration : suivi des versions par tenant, logique de nouvelle tentative, détection de dérive. Les équipes sous-estiment cette ligne plus que n'importe quelle autre du tableau.
- **La sécurité au niveau des lignes a ses petites lignes opérationnelles.** Les [politiques](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) s'appuient sur des paramètres par connexion, qui interagissent avec les modes de pooling de connexions — définissez le tenant par transaction, et testez le pooler. Auditez aussi quels rôles contournent RLS ; les chemins superutilisateur sont la faille classique.
- **L'arithmétique des connexions.** Un pool par base de tenant épuise vite les connexions ; les conceptions à schema partagé partagent un seul pool — un autre avantage discret du modèle pool, qui n'apparaît qu'à grande échelle.
- **L'asymétrie de restauration pousse à la répartition par niveaux.** "Pouvez-vous restaurer uniquement nos données à hier ?" est une question de contrat grand compte ; si la réponse doit être oui, ce tenant a sa place dans un silo — ce qui mène directement à l'hybride.

## Passage à l'échelle et état final hybride

La voie de croissance du modèle pool est le **sharding par tenant** : plusieurs bases à schema partagé, chacune contenant une partie des tenants, avec un catalogue qui associe tenant → shard (le projet open-source [Citus](https://github.com/citusdata/citus) a intégré cela dans PostgreSQL, y compris le déplacement d'un tenant très actif vers son propre nœud). Combiné à une répartition en tiers, cela donne l'architecture vers laquelle convergent la plupart des SaaS matures : le tier gratuit mutualisé, les tenants de taille moyenne mutualisés sur plusieurs shards, et les quelques tenants réglementés ou énormes en silo — **avec `tenant_id` conservé dans chaque schéma, partout**, pour que n'importe quel tenant puisse changer de tier sans refonte. La mobilité des tenants est la propriété à concevoir dès le premier jour ; il est presque impossible de l'ajouter après coup.

## Cas d'usage courants

- **SaaS B2B.** Le cas fondateur : chaque workspace, organisation ou équipe de votre produit est un tenant dans l'un de ces modèles.
- **Produits freemium à grande échelle.** Des milliers de petits tenants gratuits mutualisés à un coût marginal proche de zéro — l'économie qui rend les offres gratuites possibles.
- **Secteurs réglementés.** Des clients de la santé, de la finance et du juridique qui exigent contractuellement des silos — servis depuis la même base de code grâce à l'hybride.
- **Agences et plateformes.** Une application qui sert de nombreuses organisations clientes, chacune avec sa propre frontière.
- **Plateformes internes multi-équipes.** Les départements comme tenants sur des outils partagés — mêmes modèles, modèle de menace plus clément.

## Quel modèle devriez-vous choisir ? Matrice de décision

| Choisissez le schema partagé quand… | Choisissez le schema par tenant quand… | Choisissez la base par tenant quand… |
| --- | --- | --- |
| Les tenants sont nombreux et petits | Les tenants se comptent en centaines | Les tenants sont peu nombreux et grands |
| Le coût par tenant doit tendre vers zéro | Une isolation modérée vaut un peu d'exploitation | La conformité exige une séparation physique |
| Une seule migration doit mettre tout le monde à jour | Des ajustements de schéma par tenant sont nécessaires | La restauration par tenant est contractuelle |
| Inscription en self-service, onboarding instantané | Les tenants arrivent à un rythme humain | Chaque tenant justifie un provisionnement |
| Vous ferez du sharding en grandissant | Vous plafonnerez le nombre de tenants | Vous automatiserez les migrations × N |

Et la méta-réponse : choisissez par *niveau*, pas par entreprise — les conceptions hybrides placent chaque tenant dans le modèle le moins cher qui satisfait ses exigences, et le déplacent quand ces exigences changent.

## Limites et trade-offs

- **Schema partagé :** le besoin le plus fort d'une isolation appliquée par la base de données — un filtre oublié est une brèche, c'est pourquoi RLS ou les ACL de la couche de données sont non négociables, et non un durcissement optionnel.
- **Schema par tenant :** l'entre-deux inconfortable — une orchestration des migrations comparable à celle du silo, une isolation plus faible que celle du silo, et des limites de métadonnées de la base qui arrivent étonnamment tôt.
- **Base par tenant :** tout × N — migrations, sauvegardes, supervision, connexions, coût — et l'analytique entre tenants qui devient un projet de data engineering.
- **Les trois :** le contexte de tenant envahit tout (requêtes, caches, jobs, logs), et passer d'un modèle à l'autre coûte cher sans discipline des identifiants dès le premier jour : identifiants globalement uniques et colonnes `tenant_id` partout, même dans les silos.

## Les données multi-tenant sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l'authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Sa réponse à la règle absolue de cet article — appliquer l'isolation dans la base de données — ce sont des ACL par objet, des rôles par tenant et des permissions au niveau de la classe, vérifiés par la plateforme à chaque requête et depuis chaque surface, comme le montrent les onglets de code ci-dessus. C'est le modèle à schema partagé, débarrassé du risque de la clause WHERE ; l'[analyse d'ingénierie sur la sécurité au niveau des lignes](https://www.back4app.com/multi-tenant-mongodb-row-level-security) détaille le modèle complet sur une base de données documentaire, et la [vue côté hébergement](/glossary/fr/hebergement-multi-tenant/) du même sujet couvre le niveau d'infrastructure situé au-dessus.