J'ai regardé des équipes passer des mois à débattre de l'architecture multi-tenant par rapport à multi-site, pour finalement choisir la mauvaise et passer six mois supplémentaires à migrer. C'est l'une de ces décisions qui semble abstraite jusqu'à ce que vous soyez trois sprints après et que vous réalisiez que vos éditeurs de contenu peuvent accidentellement publier sur la mauvaise marque, ou que votre pipeline de déploiement prend 45 minutes parce que vous reconstruisez douze sites alors que seul un a changé.

Ce n'est pas une comparaison théorique. J'ai construit les deux modèles -- parfois pour le même client quand le premier choix n'a pas fonctionné. Laissez-moi vous expliquer ce qui compte vraiment pour prendre cette décision.

Table of Contents

Multi-Tenant vs Multi-Site Architecture: How to Decide

Defining the Terms Clearly

Ces termes sont utilisés de manière imprecise, donc clarifions les choses.

Multi-Tenant Architecture

Une instance d'application sert plusieurs tenants (marques, clients, régions). Ils partagent le même codebase, la même base de données (généralement), et le même déploiement. L'isolation des tenants se fait au niveau de la couche application -- via des middleware, des schémas de base de données, ou du filtrage au niveau des lignes.

Pensez à un immeuble d'appartements. Tout le monde partage la structure, la plomberie et l'électricité. Mais chaque unité a sa propre serrure.

Multi-Site Architecture

Chaque site est une instance d'application distincte avec son propre codebase (ou un fork d'un codebase partagé), sa propre base de données, et son propre pipeline de déploiement. Ils peuvent partager un système de design ou une bibliothèque de composants, mais ils sont déployés et exploités indépendamment.

C'est plus comme un lotissement. Même constructeur, plans similaires, mais chaque maison se tient sur ses propres fondations.

The Hybrid Zone

Honnêtement, la plupart des systèmes de production se situent quelque part entre les deux. Vous pourriez avoir un CMS multi-tenant alimentant du contenu à des frontends déployés indépendamment. Ou un codebase partagé qui est déployé en tant qu'instances distinctes par tenant. La vraie question n'est pas « lequel » mais « où sur le spectre ».

When Multi-Tenant Architecture Wins

L'architecture multi-tenant excelle quand vos sites se ressemblent plus qu'ils ne diffèrent.

Strong Brand Consistency Requirements

Si vous gérez 15 sites régionaux pour la même marque et que le design doit rester verrouillé, multi-tenant est votre allié. Un seul codebase signifie une seule source de vérité pour les composants, les mises en page et les modèles d'interaction. Quand l'équipe de marque met à jour les styles de boutons, cela se déploie partout.

Rapid Scaling to New Tenants

J'ai travaillé avec une plateforme de franchise qui devait lancer de nouveaux emplacements chaque semaine. Avec multi-tenant, ajouter un nouveau site était une entrée de base de données et un enregistrement DNS. Aucune nouvelle infrastructure, aucun nouveau déploiement. Le délai de lancement est passé de deux semaines à environ 30 minutes.

Centralized Content Operations

Quand vous avez une petite équipe de contenu gérant plusieurs propriétés, multi-tenant garde tout au même endroit. Les éditeurs se connectent à un seul système, changent de contexte, et gèrent le contenu sur tous les tenants. Pas besoin de jongler avec les identifiants pour une douzaine d'instances CMS.

Shared Feature Development

Chaque fonctionnalité que vous construisez bénéficie à tous les tenants simultanément. Corrections de bogues, améliorations de performances, nouvelles intégrations -- déployez une fois, bénéficiez partout. Le ROI sur les efforts de développement est multiplicatif.

When Multi-Site Architecture Wins

Multi-site gagne quand vos sites doivent diverger significativement.

Radically Different User Experiences

Si la marque A est une vitrine de commerce électronique et la marque B est une publication de contenu, les forcer dans un seul codebase crée un désordre. J'ai vu des codebases multi-tenant où 60% du code était derrière des conditions spécifiques au tenant. À ce stade, vous n'avez pas une application -- vous en avez plusieurs mauvaises qui partagent un repo.

Different Technology Requirements

Peut-être qu'un site a besoin de Next.js pour son expérience dynamique et orientée application, tandis qu'un autre est un site riche en contenu qui est parfait pour Astro. Multi-site laisse chaque propriété utiliser le bon outil. Nous avons construit des portfolios où certains sites tournent sur Next.js et d'autres sur Astro, tous tirant d'un CMS headless partagé.

Independent Release Cycles

Quand différentes unités commerciales possèdent différents sites et qu'ils doivent déployer selon leurs propres calendriers, multi-tenant crée un goulot d'étranglement. Un déploiement pour la nouvelle fonctionnalité du tenant A ne devrait pas nécessiter des tests de régression des tenants B à Z. Multi-site donne à chaque équipe l'autonomie.

Regulatory or Data Isolation

Certaines industries exigent une isolation de données stricte -- non seulement une séparation au niveau de la couche application, mais des bases de données physiquement distinctes, potentiellement dans différentes régions. Les projets de santé, finance et gouvernement exigent souvent cela. Multi-site rend la conformité simple car l'isolation est architecturale, pas seulement logique.

Different Performance Profiles

Si un tenant obtient 10 millions de visites mensuelles et un autre 50 000, partager l'infrastructure signifie que vous sur-fournissez soit pour le petit tenant soit que vous sous-fournissez pour le grand. Les déploiements distincts vous permettent de dimensionner correctement chaque propriété.

Multi-Tenant vs Multi-Site Architecture: How to Decide - architecture

The Decision Framework

Voici le cadre que j'utilise réellement avec les clients. Notez chaque facteur pour votre situation :

Factor Favors Multi-Tenant Favors Multi-Site
Similarité des sites 80%+ UI/fonctionnalités partagées Moins de 50% partagé
Nombre de propriétés 10+ sites Moins de 5 sites
Taux de croissance Ajouter des sites fréquemment Stable, rarement ajouter
Structure de l'équipe Une équipe centrale Équipes indépendantes par site
Modèle de contenu Identique ou quasi-identique Significativement différent
Besoins de conformité Exigences standard Isolation stricte des données
Stack technologique Même framework partout Différents frameworks nécessaires
Cadence de release Les déploiements coordonnés OK Déploiements indépendants requis
Profondeur de personnalisation Niveau thème (couleurs, logos) Structurel (mises en page, fonctionnalités)
Budget Optimiser pour l'efficacité Optimiser pour la flexibilité

Si vous notez principalement dans une colonne, la décision est claire. Si vous êtes divisé au milieu, vous regardez probablement une approche hybride -- et c'est fine.

Architecture Patterns in Practice

Soyons concrets sur ce que cela ressemble en code.

Multi-Tenant with Next.js

Le modèle le plus courant que j'utilise est la résolution de tenant basée sur middleware :

// middleware.ts
import { NextRequest, NextResponse } from 'next/server';

const TENANT_MAP: Record<string, string> = {
  'brand-a.com': 'brand-a',
  'brand-b.com': 'brand-b',
  'brand-c.com': 'brand-c',
};

export function middleware(request: NextRequest) {
  const hostname = request.headers.get('host') || '';
  const tenantId = TENANT_MAP[hostname] || 'default';
  
  // Pass tenant context via headers
  const response = NextResponse.next();
  response.headers.set('x-tenant-id', tenantId);
  
  // Rewrite to tenant-specific paths if needed
  const url = request.nextUrl.clone();
  url.pathname = `/${tenantId}${url.pathname}`;
  
  return NextResponse.rewrite(url);
}

Ensuite, vos composants de page extraient la configuration spécifique au tenant :

// lib/tenant-config.ts
export async function getTenantConfig(tenantId: string) {
  // Could be from database, CMS, or config files
  return {
    theme: await fetchTheme(tenantId),
    navigation: await fetchNavigation(tenantId),
    features: await fetchFeatureFlags(tenantId),
    locale: await fetchLocaleConfig(tenantId),
  };
}

Cela fonctionne bien jusqu'à ce que vos tenants commencent à avoir besoin de structures de pages différentes, de stratégies de récupération de données différentes, ou d'intégrations tierces différentes. C'est à ce moment que la logique conditionnelle commence à s'insinuer.

Multi-Site with Shared Packages

Pour multi-site, j'utilise un monorepo avec des packages partagés :

├── apps/
│   ├── brand-a/          # Next.js app
│   ├── brand-b/          # Astro app  
│   └── brand-c/          # Next.js app
├── packages/
│   ├── ui/               # Shared component library
│   ├── cms-client/       # Shared CMS integration
│   ├── analytics/        # Shared analytics wrapper
│   └── config/           # Shared TypeScript/ESLint config
├── turbo.json
└── package.json

// turbo.json
{
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": [".next/**", "dist/**"]
    },
    "deploy": {
      "dependsOn": ["build"]
    }
  }
}

Turborepo (ou Nx) gère le graphe de dépendances afin que vous ne reconstruisiez que ce qui a changé. La marque A obtient une nouvelle fonctionnalité ? Seule la marque A se reconstruit et se déploie. Le package UI partagé est mis à jour ? Tout ce qui en dépend se reconstruit.

The Hybrid: Multi-Tenant CMS, Multi-Site Frontend

C'est honnêtement mon modèle préféré pour la plupart des scénarios. Vous obtenez la gestion de contenu centralisée avec des déploiements frontends indépendants :

┌─────────────────────┐
│   Headless CMS      │
│  (Sanity/Contentful)│
│   Multi-tenant      │
│   content spaces    │
└──────┬──────┬───────┘
       │      │
   ┌───┘      └───┐
   ▼              ▼
┌──────┐    ┌──────┐
│Site A│    │Site B│
│Next.js│   │Astro │
└──────┘    └──────┘

Les éditeurs de contenu obtiennent une seule connexion et peuvent gérer toutes les propriétés. Les développeurs obtiennent des codebases indépendants et des pipelines de déploiement. C'est le meilleur des deux mondes pour les équipes qui en ont le budget.

CMS Considerations

Votre choix de CMS contraint significativement -- ou enable -- votre décision architecturale.

Multi-Tenant CMS Support

CMS Multi-Tenant Model Multi-Site Support Pricing Impact
Sanity Datasets per tenant Excellent (multiple datasets in one project) Free tier: 2 datasets; paid from $99/mo
Contentful Spaces per tenant Good (organization-level management) Each space counts toward plan; $300+/mo
Strapi Single DB, filtered by tenant Manual implementation needed Self-hosted, scales with infrastructure
Hygraph Environments and stages Native multi-site content federation From $199/mo for team plans
WordPress (headless) WordPress Multisite Mature but complex Hosting costs scale per site
Payload CMS Collection-level multi-tenancy Growing support (v3.0+) Self-hosted, open source

Le modèle de dataset de Sanity est particulièrement élégant pour les configurations multi-tenant. Chaque tenant obtient son propre dataset avec son propre schéma, mais ils vivent sous un seul projet. Vous pouvez partager des définitions de schéma entre datasets tout en permettant des personnalisations spécifiques au tenant. À grande échelle (10+ tenants), cela garde vos opérations de contenu sensées.

L'approche de Contentful d'espaces distincts fonctionne mais devient coûteuse rapidement. Chaque espace sur un plan Team coûte de l'argent réel, et vous regardez minimum $300/mois avant même de commencer à ajouter des espaces.

Content Modeling Implications

Avec multi-tenant, votre modèle de contenu doit accueillir tous les tenants. Cela signifie généralement :

  • Un champ tenant ou brand sur chaque type de contenu
  • Des règles de validation spécifiques au tenant
  • La modélisation de permissions prudente afin que les éditeurs voient uniquement le contenu de leur tenant
  • Du contenu partagé (comme « paramètres globaux ») qui doit être scoped au tenant

Avec multi-site, chaque site a son propre modèle de contenu. Plus simple par site, mais vous perdez la capacité de partager du contenu sur les sites sans une couche supplémentaire de syndication de contenu.

Performance and Scaling

Multi-Tenant Performance Characteristics

Le plus gros risque avec multi-tenant est le problème du « voisin bruyant ». Si le tenant A lance une campagne virale et le trafic augmente 10x, tous les tenants le ressentent. Stratégies d'atténuation :

  • Caching de périphérie par tenant : Utilisez le réseau edge de Vercel ou de Cloudflare avec des clés de cache qui incluent l'identificateur du tenant
  • ISR avec revalidation tenant-aware : Ne revalidez que les pages du tenant dont le contenu a changé
  • Rate limiting par tenant : Protégez les ressources partagées de tout tenant individuel les surchargeant
// next.config.js - ISR with tenant-aware revalidation
export async function generateStaticParams() {
  const tenants = await getAllTenants();
  const paths = [];
  
  for (const tenant of tenants) {
    const pages = await getTenantPages(tenant.id);
    paths.push(...pages.map(page => ({
      tenant: tenant.slug,
      slug: page.slug,
    })));
  }
  
  return paths;
}

Multi-Site Performance Characteristics

Chaque site se met à l'échelle indépendamment. C'est la bonne nouvelle. La mauvaise nouvelle est que vous gérez N pipelines de déploiement, N tableaux de bord de monitoring, et N ensembles de budgets de performance. À 20+ sites, la surcharge opérationnelle devient le goulot d'étranglement, pas la performance de l'application.

À partir des benchmarks que j'ai effectués en 2025, voici approximativement ce à quoi s'attendre sur Vercel :

Metric Multi-Tenant (1 app, 10 tenants) Multi-Site (10 apps)
Cold start (Edge) 20-50ms 20-50ms per site
Build time 8-15 min (all tenants) 2-4 min per site
Incremental build 30-90s 30-90s per site
Memory per instance 256-512MB shared 256-512MB each
Monthly Vercel cost (Pro) ~$20 ~$200 ($20 × 10)

Cette différence de coût est significative. Multi-tenant sur un seul plan Vercel Pro à $20/mois vs. multi-site nécessitant soit une Entreprise soit une organisation créative des projets.

Cost Analysis

Parlons des chiffres réels pour un portefeuille de 10 sites sur 12 mois.

Multi-Tenant Cost Estimate

Line Item Monthly Cost Annual Cost
Vercel Pro (1 project) $20 $240
Sanity Team (1 project, 10 datasets) $99 $1,188
Development (initial build) -- $40,000-60,000
Maintenance (ongoing) $2,000 $24,000
Total Year 1 -- $65,428-$85,428

Multi-Site Cost Estimate

Line Item Monthly Cost Annual Cost
Vercel Pro (10 projects) $200 $2,400
Sanity Team (10 projects) $990 $11,880
Development (initial build, shared packages) -- $50,000-80,000
Maintenance (ongoing, 10 sites) $4,000 $48,000
Total Year 1 -- $112,280-$142,280

Multi-tenant est environ 40-60% moins cher, principalement en raison de la réduction du fardeau de maintenance. Mais ces chiffres s'inversent si la complexité multi-tenant entraîne plus de bogues, un développement de fonctionnalités plus lent, ou une migration difficile plus tard.

Vous voulez une estimation plus précise pour votre situation spécifique ? Nous décomposons les coûts d'architecture en détail lors de notre processus de découverte.

Migration Strategies

Parfois, vous commencez avec une approche et devez basculer. Voici comment le faire sans tout brûler.

Multi-Tenant → Multi-Site

C'est la direction de migration la plus courante. Signes que vous en avez besoin :

  • Le code spécifique au tenant dépasse 30% du codebase
  • Les déploiements sont bloqués par les tests de régression cross-tenant
  • Les équipes se marchent sur les pieds mutuellement

La stratégie :

  1. Extrayez d'abord le code partagé dans des packages (composants UI, utilitaires, client CMS)
  2. Créez une structure monorepo autour de l'app existante
  3. Bifurquez l'app pour le tenant le plus divergent
  4. Déplacez progressivement les autres tenants vers leurs propres apps
  5. Supprimez la logique de commutation de tenant de chaque app à mesure qu'elle devient autonome

Multi-Site → Multi-Tenant

Moins courant mais cela arrive, généralement quand une entreprise acquiert plusieurs marques et veut consolider les opérations.

  1. Auditez tous les sites pour les modèles partagés (vous en trouverez plus que prévu)
  2. Construisez la bibliothèque de composants partagés à partir des meilleures implémentations
  3. Créez l'app multi-tenant avec le site le plus simple d'abord
  4. Migrez les sites un à un, validant la parité à chaque étape
  5. Décommissionnez les apps individuels à mesure que les tenants se déploient

Les deux migrations sont perturbantes. Budgétisez 3-6 mois et des efforts de test significatifs. C'est exactement pourquoi obtenir la bonne décision initiale compte -- ce n'est pas juste un choix architectural, c'est un engagement.

Si vous faites face à cette décision et voulez en discuter avec quelqu'un qui l'a déjà fait, contactez-nous.

FAQ

Quelle est la différence entre l'architecture multi-tenant et multi-site ?

Multi-tenant utilise une seule instance d'application pour servir plusieurs marques ou clients, avec l'isolation des tenants gérée au niveau de la couche application. Multi-site déploie des instances d'application distinctes pour chaque site, partageant potentiellement du code via un monorepo et des bibliothèques de composants. La distinction clé est si vous exécutez une application ou plusieurs.

Puis-je utiliser un CMS multi-tenant avec un frontend multi-site ?

Absolument, et c'est souvent la meilleure approche. Un CMS headless comme Sanity avec plusieurs datasets vous donne la gestion de contenu centralisée, tandis que les déploiements frontends distincts donnent à chaque site l'indépendance en termes de choix technologiques, calendriers de déploiement et mise à l'échelle de performance. Ce modèle hybride fonctionne particulièrement bien quand vos sites partagent la structure de contenu mais ont besoin d'expériences utilisateur différentes.

Comment l'architecture multi-tenant affecte-t-elle le SEO ?

Les apps multi-tenant servent du contenu différent selon le domaine ou le sous-domaine, que les moteurs de recherche gèrent bien tant que vous implémentez correctement les URLs canoniques, les métadonnées uniques par tenant, et les sitemaps distincts. Le risque est la duplication accidentelle de contenu sur les tenants -- assurez-vous que votre génération de sitemap et votre robots.txt sont tenant-aware. Du point de vue du SEO, les moteurs de recherche ne se soucient pas si vos sites partagent un codebase ; ils se soucient du contenu et du markup qu'ils reçoivent.

Multi-tenant est-il moins cher que multi-site ?

Généralement oui, souvent 40-60% moins cher en coûts d'hébergement et de maintenance. Vous payez pour un seul déploiement, une seule configuration de monitoring, et un seul ensemble d'infrastructure. Cependant, multi-tenant peut devenir plus cher en temps de développement si vos tenants divergent significativement, car la complexité de gérer la logique spécifique au tenant croît de façon non linéaire. Le point d'équilibre dépend de la ressemblance réelle de vos sites.

Quelle approche est meilleure pour WordPress multisite headless ?

WordPress Multisite est intrinsèquement multi-tenant -- une installation WordPress, plusieurs sites. Si vous utilisez WordPress comme CMS headless, le réseau Multisite vous donne la gestion de contenu centralisée. Votre frontend peut ensuite être soit multi-tenant (une app Next.js), soit multi-site (des apps distinctes par site WordPress). Pour la plupart des projets basés sur WordPress, je recommanderais le hybride : WordPress Multisite comme CMS, des déploiements frontends distincts par site.

Comment gérer l'authentification partagée dans une app multi-tenant ?

Utilisez un fournisseur d'authentification centralisé (Auth0, Clerk, ou NextAuth.js) avec la gestion de session tenant-aware. Le token d'auth devrait inclure le contexte du tenant, et votre middleware devrait valider que l'utilisateur authentifié a accès au tenant demandé. La sécurité au niveau des lignes dans votre base de données (Supabase et Neon supportent tous les deux cela) ajoute une deuxième couche de protection contre les fuites de données cross-tenant.

Quel est le nombre maximum de tenants qu'une app multi-tenant peut gérer ?

Il n'y a pas de limite stricte, mais des limites pratiques émergent autour des temps de build et de la complexité opérationnelle. Avec Next.js ISR sur Vercel, j'ai vu des apps multi-tenant gérer efficacement 50+ tenants. Au-delà de 100 tenants, vous voudrez considérer l'ISR à la demande plutôt que la pré-génération de toutes les pages, et vous aurez besoin de stratégies de caching sophistiquées. Les plateformes SaaS comme Shopify exécutent effectivement des milliers de tenants, mais elles ont investi des années dans cette infrastructure.

Dois-je utiliser un monorepo pour l'architecture multi-site ?

Presque toujours oui. Un monorepo avec Turborepo ou Nx vous donne les avantages de partage de code de multi-tenant (composants partagés, utilitaires, configurations) avec l'indépendance de déploiement de multi-site. La clé est de garder les packages partagés bien définis et versionnés. Sans monorepo, vous finissez avec du code copié-collé à travers les repos qui diverge immédiatement et devient un cauchemar de maintenance en quelques mois.