Drupal multisite : architecture, domaines, performances et maintenance (guide 2026)

Drupal multisite : l’architecture qui tient dans la durée (domaines, perfs, maintenance)

Gérer 5, 10 ou 50 sites Drupal peut vite devenir un cauchemar… ou au contraire une mécanique bien huilée. Tout se joue dans le choix d’architecture (multisite natif vs alternatives), la stratégie de domaines, et une discipline de déploiement/mises à jour.

Si votre objectif est d’héberger Drupal sans vous battre avec l’infra au quotidien, vous pouvez aussi déployer Drupal sur adgents.cloud (application Drupal) : déploiement en 1 clic, scaling CPU/RAM, et sauvegardes automatiques.

Multisite Drupal : de quoi parle-t-on exactement ?

Dans Drupal, “multisite” (au sens classique) signifie :

• une base de code partagée (même core + mêmes dépendances)
• plusieurs “sites” distincts (chacun avec ses paramètres)
• le plus souvent une base de données par site (donc une isolation de contenu et d’utilisateurs)

Ce modèle n’est pas le seul : pour certains besoins (notamment partage d’utilisateurs/contenus), on peut aussi préférer une approche “un seul site” + modules (ex : Domain Access).

Multisite natif vs Domain Access : comment choisir

Le bon choix dépend surtout de :

• votre besoin de partage (utilisateurs, contenus, taxonomies)
• votre besoin d’isolation (performance, incidents, déploiements)
• le nombre de sites et le niveau d’autonomie des équipes

Option A — Multisite natif (DB séparées)

Pertinent si :

• vous voulez isoler les sites (un pic de trafic sur A ne casse pas B)
• vous acceptez que chaque site ait son back-office
• vous avez besoin de thèmes/variantes par site, sans impacter les autres

Points d’attention :

• vous ne partagez pas “magiquement” les utilisateurs ou le contenu
• vous devez standardiser votre manière de déployer (sinon c’est la dérive)

Option B — Domain Access (1 DB, plusieurs domaines)

Pertinent si :

• vous cherchez un pilotage centralisé (mêmes users / mêmes contenus)
• vous acceptez qu’une base unique concentre les risques (perfs + point de défaillance unique)

En pratique, Domain Access peut être excellent quand l’organisation veut une gouvernance très centralisée, mais il faut être rigoureux sur la performance et les règles éditoriales.

Option C — Industrialiser (usine à sites)

Au-delà d’un certain volume, ce n’est pas la “technique Drupal” qui sauve, c’est l’industrialisation :

• gabarits (thèmes, modules, profils)
• déploiement automatisé
• conventions (naming, variables d’environnement, monitoring)

Si vous avez déjà un site Drupal à mettre en production, commencez par ce guide : Installer Drupal avec Docker Compose (prod) : HTTPS, DB, volumes.

Stratégie de domaines : sous-domaines, domaines, sous-dossiers

En multisite, les 3 approches les plus fréquentes :

• 1 domaine par site : site-a.fr, site-b.fr
• sous-domaines : a.exemple.fr, b.exemple.fr
• sous-dossiers (rare en vrai multisite) : exemple.fr/a, exemple.fr/b

Recommandation pragmatique :

• choisissez 1 domaine ou 1 sous-domaine par site
• évitez les sous-dossiers si vous avez des contraintes SEO, de cache, ou des reverse proxies multiples

Comment Drupal “route” vers le bon site (sites.php)

Drupal détermine quel site servir via un mapping domaine → dossier de site.

Concrètement, vous retrouvez souvent ce type d’organisation :

• web/sites/sites.php
• web/sites/site1/settings.php
• web/sites/site2/settings.php

Chaque site a ses identifiants de base de données, ses clés, et ses réglages.

Performance : les pièges les plus courants en multisite

Le multisite ne rend pas Drupal “lent” par nature. Les lenteurs viennent surtout de la variabilité entre sites et du manque de garde-fous.

1) Cache et reverse proxy

• activez les caches Drupal (et vérifiez qu’ils sont cohérents entre environnements)
• mettez un reverse proxy propre (Nginx/Traefik)
• si vous avez du trafic, réfléchissez à un cache HTTP en amont

Pour un diagnostic concret, vous pouvez croiser avec : Drupal lent : optimiser (cache, Twig, DB, CDN) + 15 correctifs.

2) Base de données : isolement ≠ miracle

Même avec une DB par site, vous pouvez vous tirer une balle dans le pied si :

• toutes les DB sont sur le même serveur sans capacité suffisante
• les requêtes sont mal indexées
• la maintenance (VACUUM/ANALYZE/optimisations) n’est pas suivie

3) Fichiers et médias

• les fichiers public:// doivent être persistants
• si vous mutualisez un stockage, gardez une séparation claire par site

Déploiement et mises à jour : la discipline qui évite la catastrophe

En multisite, l’erreur classique : “on met à jour un site, on verra pour les autres”. Résultat : dérives et incompatibilités.

Bonnes pratiques simples :

• 1 codebase = 1 version : vous déployez la même release partout
• les différences doivent être des variables (settings/env), pas des commits à la main
• prévoyez un staging (au minimum) pour valider modules + thèmes

Pour sécuriser la partie opérationnelle, ce guide complète bien le sujet : Drupal en production : sécurité (updates, modules, WAF) — guide 2026.

Maintenance : ce qu’il faut standardiser dès le début

Si vous voulez que l’architecture tienne 2 ans (et pas 2 semaines), standardisez :

• la convention de nommage des sites
• les variables sensibles (clés, DB, SMTP)
• les sauvegardes (DB + fichiers) avec tests réguliers
• l’observabilité (logs, erreurs, métriques)

Et si vous préparez une migration d’une version majeure, gardez ce plan sous la main : Migrer Drupal (7/8/9→10) : plan, risques, rollback, staging.

Vidéo (FR) : voir un multisite en action

Si vous préférez un pas-à-pas en français (même si c’est une version plus ancienne, les concepts restent utiles) : .

Héberger une plateforme multisite sans se compliquer la vie

Si votre besoin principal est d’avoir un Drupal fiable (mises à l’échelle, sauvegardes, et exploitation simple), vous pouvez déployer sur adgents.cloud et garder la main sur l’essentiel : start/stop, scaling CPU/RAM, sauvegardes automatiques, et rétention longue.

Pour démarrer rapidement : adgents.cloud (application Drupal).