Maintenance Drupal multi-sites

L'architecture multi-sites de Drupal est l'une de ses forces les plus sous-estimées. Un seul codebase, un seul dépôt Git, une seule chaîne de déploiement, mais plusieurs sites distincts qui partagent les mêmes modules, le même core et souvent les mêmes thèmes de base. Pour une organisation qui gère un portefeuille de sites (filiales, marques, antennes régionales, sites événementiels), c'est un levier de rationalisation considérable. Mais cette mutualisation a une contrepartie directe : ce qui touche le code touche tout le monde en même temps.

C'est précisément ce qui rend la maintenance d'un multi-site différente de celle d'un site isolé. Les bénéfices de l'architecture (un seul code à mettre à jour) sont indissociables de son principal risque opérationnel (une mise à jour qui se passe mal se propage partout). Cet article explique les spécificités de la maintenance multi-sites, le workflow de validation site par site, l'automatisation qui rend l'ensemble viable et le rôle décisif des tests automatisés.

La spécificité fondamentale : un composer update impacte tous les sites

Sur une installation multi-sites classique, tous les sites partagent le répertoire vendor/ et le code des modules. Quand vous lancez un composer update, vous ne mettez pas à jour un site, vous mettez à jour le code commun à l'ensemble des sites hébergés sur ce codebase.

# Cette commande affecte tous les sites du multi-site, pas un seul
composer update drupal/core-recommended --with-all-dependencies

La conséquence est simple à énoncer et lourde à gérer : une mise à jour de sécurité du core, une montée de version d'un module partagé ou un correctif de dépendance se répercutent simultanément sur dix, vingt ou cinquante sites. Si le module mis à jour introduit une régression, elle ne touche pas un site, elle touche tous ceux qui activent ce module.

C'est là que la nuance entre code partagé et configuration spécifique devient centrale. Les sites partagent le code, mais chacun possède sa propre base de données, sa propre configuration, ses propres modules activés et son propre thème. Un module peut être actif sur le site A, désactivé sur le site B et configuré différemment sur le site C. Une même mise à jour produit donc des effets différents selon le site. Vérifier un seul site et conclure que tout va bien est une erreur d'appréciation fréquente sur ce type d'architecture.

Le workflow de test par site

Le principe directeur de la maintenance multi-sites tient en une phrase : on met à jour une fois, on valide N fois. Le composer update est mutualisé, mais la validation, elle, ne peut pas l'être. Chaque site doit être vérifié individuellement parce que chacun expose une combinaison unique de modules actifs, de configuration et de contenu.

Concrètement, le workflow s'articule autour de Drush en mode multi-site, qui permet de cibler un site précis ou de boucler sur l'ensemble du portefeuille.

# Lister les sites déclarés dans sites.php
drush site:alias

# Cibler un site précis pour appliquer les updates de base de données
drush @site_a updatedb -y
drush @site_a config:status

# Reconstruire le cache d'un site donné
drush @site_a cache:rebuild

Après un composer update, la séquence à dérouler pour chaque site est la même : appliquer les mises à jour de base de données (updatedb), vérifier l'état de la configuration (config:status), reconstruire les caches et contrôler que les pages et parcours clés répondent correctement. Multiplié par le nombre de sites, cet enchaînement représente le coeur de l'effort de maintenance, et c'est exactement le point qui ne passe pas à l'échelle quand il est fait manuellement.

Sur un portefeuille de quinze à vingt sites, une validation manuelle sérieuse mobilise facilement une journée entière de travail à chaque cycle de mise à jour. À cette échelle, deux dérives apparaissent : soit la maintenance devient trop coûteuse pour être faite régulièrement, soit elle est faite mais bâclée, ce qui revient à exposer le portefeuille à des régressions silencieuses. Notre approche de la maintenance Drupal traite précisément ce point en industrialisant la partie répétitive du workflow.

L'automatisation : la condition de viabilité

Pour qu'un multi-site reste maintenable dans la durée, la répétition doit être automatisée. L'idée n'est pas de remplacer le jugement humain, mais de retirer aux humains tout ce qui est mécanique et reproductible pour leur laisser uniquement les décisions qui comptent.

Boucler sur les sites. Plutôt que d'exécuter manuellement la même séquence sur chaque site, un script itère sur la liste des sites et applique les opérations post-update à chacun.

# Appliquer updatedb et rebuild sur l'ensemble des sites
for site in site_a site_b site_c; do
  drush @$site updatedb -y
  drush @$site cache:rebuild
done

Industrialiser le déploiement. Le déploiement d'un nouveau code sur le multi-site suit un enchaînement déterministe : récupération du code, composer install, puis pour chaque site updatedb, import de configuration (config:import) et reconstruction du cache. Cet enchaînement gagne à être scripté une fois et rejoué à l'identique à chaque cycle, ce qui élimine l'oubli d'une étape sur un site particulier.

drush @site_a config:import -y
drush @site_a updatedb -y
drush @site_a cache:rebuild

Standardiser plutôt que personnaliser. Plus les sites partagent des conventions communes (structure de configuration, nommage, modules de base), plus l'automatisation est simple et fiable. Les écarts entre sites sont la principale source de friction d'un multi-site. Les réduire est un investissement de maintenance à part entière.

L'automatisation transforme la nature du travail : on passe d'une exécution manuelle répétée à une supervision d'un processus reproductible. C'est ce changement qui permet de tenir un rythme de mises à jour de sécurité régulier sans que la charge explose avec le nombre de sites.

Les backups par site

La mutualisation du code ne doit jamais se traduire par une mutualisation des sauvegardes. Chaque site possède sa propre base de données et son propre répertoire de fichiers (sites/site_a/files), et c'est à ce niveau que la sauvegarde doit opérer. Un backup par site, c'est la garantie de pouvoir restaurer un site sans toucher aux autres.

# Dump de la base d'un site précis, fichiers exclus du dump SQL
drush @site_a sql:dump --result-file=/backups/site_a-$(date +%F).sql

La règle pratique est de sauvegarder chaque base individuellement et de versionner ou archiver les répertoires de fichiers par site. Avant toute opération risquée (montée de version majeure, mise à jour d'un module structurant), un backup frais et site par site est non négociable. En cas de problème sur un seul site après un update partagé, vous restaurez ce site précis pendant que les autres continuent de tourner. Sans cette granularité, un incident isolé peut contraindre à des restaurations globales inutilement lourdes.

Le monitoring : voir tous les sites d'un coup

Un multi-site ne se surveille pas comme un site unique multiplié par N. Il faut une vue d'ensemble qui permette de repérer en un coup d'oeil quel site est en difficulté. Le monitoring pertinent couvre plusieurs dimensions par site : la disponibilité (le site répond-il en HTTP 200), les erreurs applicatives (logs Drupal, erreurs PHP), l'état de la configuration (écart entre la config exportée et la config active) et les mises à jour de sécurité en attente.

# Vérifier les mises à jour de sécurité disponibles, site par site
drush @site_a pm:security

L'enjeu est de détecter le problème localisé avant l'utilisateur final. Sur un portefeuille, un site secondaire peu fréquenté peut rester cassé plusieurs jours si rien ne le signale. Un tableau de bord qui agrège l'état de tous les sites, couplé à des alertes par site, transforme la maintenance réactive (on corrige quand un utilisateur se plaint) en maintenance proactive (on corrige avant que ça se voie). C'est la différence entre subir le multi-site et le piloter.

Les tests automatisés : ce qui rend le multi-site opérationnellement viable

Tout converge vers un même constat : la validation site par site est le goulot d'étranglement d'un multi-site, et c'est exactement le problème que les tests automatisés résolvent. Sans tests, vérifier N sites après chaque composer update ne passe pas à l'échelle. Avec tests, la même validation s'exécute en quelques minutes et de manière fiable.

Le principe est d'écrire une suite de tests qui valide les parcours critiques, puis de l'exécuter contre chaque site du multi-site. Les sites partageant le code mais pas la configuration, la suite doit tenir compte des spécificités de chacun : un module actif sur un site et absent d'un autre implique des tests conditionnels. Un pipeline bien conçu parallélise l'exécution et valide l'ensemble du portefeuille en une fraction du temps qu'exigerait une vérification manuelle.

# Exécuter la suite de tests pour chaque site du portefeuille
for site in site_a site_b site_c; do
  drush @$site test:run --uri=https://$site.example.com
done

Le gain est double. D'abord la confiance : un composer update cesse d'être une opération anxiogène pour devenir une routine dont le résultat est connu en quelques minutes pour tous les sites. Ensuite la régularité : comme la validation devient peu coûteuse, les mises à jour de sécurité peuvent être appliquées au rythme où elles sortent, ce qui réduit la fenêtre d'exposition. C'est ce mécanisme qui fait basculer le multi-site d'une architecture théoriquement élégante mais lourde à maintenir vers une architecture réellement durable. Notre service de tests automatisés Drupal est pensé pour ce cas de figure, avec un pipeline qui itère sur l'ensemble des sites et produit un rapport clair par site.

En résumé

Le multi-site Drupal est un excellent choix d'architecture pour gérer un portefeuille de sites avec un code mutualisé. Sa maintenance repose sur une discipline précise : comprendre qu'un update partagé impacte tout le monde, valider chaque site individuellement, automatiser la répétition, sauvegarder par site et surveiller l'ensemble en continu. Les tests automatisés sont la pièce qui tient tout l'édifice, parce qu'ils rendent la validation à grande échelle rapide et fiable. Bien outillé, un multi-site de vingt sites se maintient avec une charge proche de celle d'un site unique, et c'est tout l'intérêt de l'approche.

Vous gérez une architecture Drupal multi-sites et vous voulez en sécuriser la maintenance dans la durée ? Parlons de votre projet : on établit ensemble un diagnostic et un plan adapté à votre portefeuille.