Architecture multi-sites Drupal

Une organisation qui gère cinq, dix ou vingt sites Drupal se pose tôt ou tard la même question : faut-il un projet distinct par site, ou un seul codebase partagé entre tous ? Drupal apporte une réponse native à ce problème depuis longtemps, le multi-site, qui permet de servir plusieurs sites indépendants à partir d'une seule installation de code. C'est une fonctionnalité puissante, parfois mal comprise et souvent confondue avec d'autres approches. Bien utilisée, elle réduit drastiquement le coût de maintenance d'un parc de sites. Mal utilisée, elle crée un couplage qui complique chaque évolution.

Cet article explique quand le multi-site a réellement du sens, comment s'articule son architecture concrète (sites.php, settings.php, bases de données et fichiers), comment se passent le déploiement et la maintenance, puis quelles alternatives méritent d'être considérées avant de s'engager. L'objectif est de vous donner les bons critères de décision, pas de vendre une solution unique.

Quand le multi-site a du sens

Le multi-site Drupal n'est pas une réponse universelle. Il brille dans un contexte bien précis et devient un fardeau hors de ce contexte. Trois conditions doivent idéalement être réunies.

Des sites similaires. Le multi-site partage un seul codebase : le même core, les mêmes modules contrib et le même code custom pour tous les sites. Il est donc pertinent quand vos sites se ressemblent fortement : un réseau de sites régionaux, les filiales d'un groupe, les facultés d'une université, les marques d'un même portefeuille. Plus les sites divergent dans leurs fonctionnalités, plus le codebase partagé devient un compromis difficile à tenir.

La même stack technique. Tous les sites tournent sur la même version de Drupal, les mêmes versions de PHP et la même chaîne de dépendances Composer. C'est précisément ce qui crée la valeur : une seule mise à jour bénéficie à l'ensemble du parc. Si un site doit rester figé sur une version ancienne pendant que les autres avancent, le multi-site perd son intérêt principal.

La même équipe. Un codebase unique implique une coordination unique. Le multi-site fonctionne bien quand une seule équipe technique pilote l'ensemble. Si chaque site appartient à une équipe autonome avec son propre rythme de livraison, le code partagé devient un point de friction permanent plutôt qu'un levier.

Quand ces trois conditions sont réunies, le multi-site offre un gain considérable : un seul dépôt à maintenir, une seule mise à jour de sécurité à appliquer et une cohérence technique garantie sur tout le parc. C'est exactement le scénario où la mutualisation paie.

L'architecture concrète

Le multi-site repose sur un principe simple : le code est partagé, les données et la configuration sont isolées par site. Voici comment chaque pièce s'assemble.

sites.php : l'aiguillage des domaines

Le fichier sites/sites.php est la table de routage. Il associe chaque domaine (ou sous-domaine) à un répertoire de configuration dans sites/. Quand une requête arrive, Drupal lit ce fichier pour déterminer quel site servir.

<?php
// sites/sites.php
$sites['www.marque-a.com'] = 'marque_a';
$sites['www.marque-b.com'] = 'marque_b';
$sites['filiale.exemple.org'] = 'filiale_exemple';

Chaque valeur pointe vers un dossier sous sites/, par exemple sites/marque_a/. C'est ce dossier qui contient la configuration propre au site.

settings.php par site

Chaque site possède son propre sites/<nom>/settings.php. Ce fichier définit la connexion à la base de données du site, son hash salt, le chemin de sa configuration synchronisée et tout réglage spécifique. Deux sites du même multi-site ont donc deux fichiers settings.php distincts, chacun pointant vers ses propres ressources.

<?php
// sites/marque_a/settings.php
$databases['default']['default'] = [
  'database' => 'drupal_marque_a',
  'username' => 'db_user',
  'host' => 'localhost',
  'driver' => 'mysql',
];
$settings['config_sync_directory'] = '../config/marque_a';

Une base de données par site

C'est le point le plus important pour comprendre l'isolation. Chaque site dispose de sa propre base de données. Le contenu, les utilisateurs, les permissions et la configuration active de la marque A sont totalement séparés de ceux de la marque B. Un site peut activer un module que l'autre laisse désactivé : la liste des modules actifs vit dans la base de données et dans la configuration exportée, pas dans le codebase. Le code est disponible pour tous, mais chaque site décide de ce qu'il active.

Fichiers séparés

Les fichiers téléversés (images, documents, médias) sont également isolés. Chaque site écrit dans son propre répertoire, typiquement sites/marque_a/files et sites/marque_b/files. Aucun risque qu'un média d'un site apparaisse sur un autre. Cette séparation vaut aussi pour les fichiers privés et les sauvegardes.

Le résultat est une architecture où un seul dossier de code sert N sites parfaitement étanches entre eux du point de vue des données, tout en partageant la moindre ligne de PHP.

Le déploiement

Déployer un multi-site, c'est déployer un seul codebase. Vous poussez le code une fois, sur un seul dépôt Git, et tous les sites en bénéficient instantanément puisqu'ils pointent vers le même répertoire. C'est l'un des grands avantages opérationnels de l'approche.

La nuance porte sur la configuration et la base de données. Après le déploiement du code, chaque site doit appliquer ses propres mises à jour de base de données et importer sa configuration. Un script de déploiement itère donc sur la liste des sites :

for site in marque_a marque_b filiale_exemple; do
  drush --uri="$site" updatedb -y
  drush --uri="$site" config:import -y
  drush --uri="$site" cache:rebuild
done

Le code part une seule fois, mais les opérations post-déploiement se répètent par site. C'est mécaniquement plus rapide qu'un déploiement de N projets indépendants, puisque l'étape la plus lourde (le build Composer et le transfert de code) ne se fait qu'une fois.

La maintenance

C'est ici que le multi-site révèle son intérêt le plus tangible. Un seul composer update met à jour le core et les modules pour l'ensemble du parc.

composer update drupal/core-* --with-all-dependencies

Une faille de sécurité publiée un mercredi soir se corrige une fois, pas vingt fois. Vous gérez un seul fichier composer.lock, une seule chaîne de dépendances, une seule version de PHP à faire évoluer. Pour une organisation qui suit attentivement les alertes de sécurité Drupal, c'est un gain de temps et de tranquillité majeur. C'est précisément le genre de mutualisation qui rend un contrat de maintenance Drupal bien plus efficace sur un parc multi-site que sur des installations dispersées.

La contrepartie est qu'une mise à jour impacte tous les sites en même temps. Un module qui se comporte mal après update peut affecter plusieurs sites d'un coup. C'est exactement pourquoi la validation automatisée devient indispensable sur ce type d'architecture. Un pipeline de tests automatisés Drupal qui itère sur chaque site et valide ses parcours critiques transforme un composer update risqué en opération routinière. Sans cette couverture, vérifier manuellement quinze ou vingt sites après chaque mise à jour n'est tout simplement pas viable à l'échelle. Avec elle, la mutualisation tient toutes ses promesses.

Les alternatives

Le multi-site n'est pas la seule façon de gérer plusieurs sites Drupal. Trois alternatives méritent d'être pesées.

Plusieurs instances indépendantes. Chaque site a son propre dépôt, son propre codebase, sa propre chaîne de dépendances. C'est l'opposé du multi-site : isolation maximale, autonomie totale. Chaque site peut tourner sur une version différente, activer ses propres modules sans contrainte et avancer à son rythme. Le prix à payer est la démultiplication de la maintenance : chaque mise à jour de sécurité se répète sur chaque instance. Cette approche convient quand les sites divergent fortement ou sont gérés par des équipes distinctes.

Multi-site Drupal contre multi-instance. L'arbitrage central tient en une phrase : le multi-site optimise la mutualisation, le multi-instance optimise l'autonomie. Le premier minimise l'effort de maintenance au prix d'un couplage fort. Le second maximise l'indépendance au prix d'une maintenance répétée. Il n'y a pas de bonne réponse dans l'absolu, seulement une réponse adaptée à votre contexte.

Les conteneurs. Une approche moderne consiste à packager chaque site Drupal dans son propre conteneur (Docker), orchestré par une plateforme comme Kubernetes. Chaque site reste isolé, mais l'infrastructure standardise le déploiement et facilite la mise à l'échelle. C'est une alternative au multi-site qui préserve l'isolation tout en industrialisant l'exploitation. Elle demande en revanche une maturité DevOps réelle et une équipe à l'aise avec l'orchestration de conteneurs. Pour un parc important géré par une équipe outillée, c'est souvent le meilleur compromis entre isolation et opérabilité.

Les arbitrages

Le choix d'architecture se résume à quelques tensions qu'il faut trancher en connaissance de cause.

Mutualisation contre isolation. Plus vous mutualisez le code, moins vous maintenez de choses, mais plus vous couplez le sort des sites entre eux. Plus vous isolez, plus chaque site est libre, mais plus vous répétez chaque opération. Votre position sur cet axe dépend de la similarité réelle de vos sites et de votre tolérance au couplage.

Vitesse de mise à jour contre risque partagé. Le multi-site rend les mises à jour rapides et globales. Cette rapidité est un atout uniquement si elle s'accompagne d'un filet de sécurité automatisé. Sans tests, la même vitesse qui vous fait gagner du temps peut propager un problème à tout le parc.

Coût d'exploitation contre flexibilité. Le multi-site et les conteneurs réduisent le coût d'exploitation par site à mesure que le parc grandit. Les instances indépendantes offrent une flexibilité maximale mais leur coût croît linéairement avec le nombre de sites.

En pratique, le multi-site reste un excellent choix pour un parc de sites homogènes gérés par une seule équipe, à condition de l'accompagner d'une stratégie de tests et d'un cycle de maintenance discipliné. Dès que les sites divergent franchement ou que plusieurs équipes entrent en jeu, les instances indépendantes ou les conteneurs deviennent plus pertinents. La meilleure architecture est celle qui correspond à votre organisation réelle, pas à un idéal technique.

Vous gérez un parc de sites Drupal et vous hésitez entre multi-site, instances indépendantes ou conteneurisation ? Parlons de votre projet : on évalue votre contexte et on vous aide à choisir l'architecture qui réduira vraiment votre coût de maintenance.