Tests Drupal multi-sites : la stratégie

Une instance Drupal qui alimente dix, quinze, vingt sites. Un seul composer update se propage à tous les sites en même temps. Une nouvelle version d'un module peut très bien fonctionner sur quinze sites et se comporter différemment sur les deux autres, simplement parce que les configurations et les modules activés diffèrent. La validation site par site devient alors particulièrement précieuse.

Avec un pipeline bien configuré, chaque site est validé individuellement en quelques minutes. Vous savez après chaque mise à jour quels sites passent, quels sites demandent un correctif et précisément où. Ce niveau de visibilité change radicalement la manière dont une équipe gère son architecture multi-sites. Cet article explique le défi spécifique du multi-site, l'architecture de tests qui fonctionne en pratique, comment mettre en place le pipeline CI et le retour sur investissement réel.

Le défi spécifique du multi-site

Un multi-site Drupal partage un codebase unique. Le même core, les mêmes modules, le même thème de base (souvent). Mais chaque site a sa propre base de données, sa propre configuration et sa propre URL. Cette mutualisation est l'intérêt même de l'architecture : un changement de code se déploie d'un coup sur tous les sites, ce qui rationalise considérablement la maintenance.

Cette force demande en contrepartie une validation rigoureuse. Un module mis à jour peut fonctionner sur le site A et avoir un comportement différent sur le site B, parce que les modules activés diffèrent, parce que les configurations de champs diffèrent ou parce qu'un thème custom dépend d'une API spécifique. La validation manuelle de N sites après chaque update n'est pas scalable. Au-delà de cinq sites, elle prend plusieurs heures. Au-delà de dix, elle devient le poste de travail dominant d'un cycle de maintenance.

Concrètement, sur une architecture de quinze sites, vérifier manuellement après un composer update que chaque site charge, que chaque formulaire fonctionne et que chaque parcours critique passe représente une journée complète de travail. Si la mise à jour est mensuelle, c'est deux semaines par an consacrées exclusivement à la validation. Ce coût est invisible mais bien réel.

Les tests automatisés transforment cette équation. La même validation devient une affaire de minutes, exécutée automatiquement à chaque cycle. Le temps humain est libéré pour des tâches à plus forte valeur ajoutée.

L'architecture de tests recommandée

Sur un multi-site, l'organisation des tests est aussi importante que les tests eux-mêmes. Une bonne architecture de tests sépare clairement ce qui est partagé et ce qui est spécifique à chaque site.

Tests partagés. Smoke tests communs à tous les sites (la page d'accueil charge, le formulaire de contact existe, l'authentification fonctionne). Ces tests sont écrits une fois et exécutés sur chaque site avec les paramètres adaptés.

Tests spécifiques par site. Formulaires custom propres au site, intégrations spécifiques (CRM, ERP, API tierces), fonctionnalités métier particulières. Chaque site a son fichier de tests qui décrit son comportement attendu.

Un fichier de configuration de tests par site. Quelles pages tester, quels formulaires valider, quelles fonctionnalités vérifier. Ce fichier est versionné dans le dépôt, à côté du code du site. C'est aussi une forme de documentation : un nouveau développeur qui rejoint le projet comprend immédiatement ce qui est attendu de chaque site.

Un pipeline CI qui itère sur tous les sites. Le pipeline lit la liste des sites depuis la configuration, exécute la suite de tests appropriée pour chacun et génère un rapport consolidé. Idéalement, les tests s'exécutent en parallèle pour minimiser le temps total.

Un dashboard consolidé. Vert ou rouge par site, avec drill-down sur les détails. C'est l'interface qui permet à l'équipe de voir en un coup d'œil l'état global du multi-site après chaque mise à jour.

Mise en place concrète

La configuration d'un pipeline de tests multi-sites suit quelques principes simples. Une fois ces principes en place, l'extension à de nouveaux sites devient triviale.

Boucle sur les sites. Le pipeline lit la liste des sites depuis un fichier de configuration (YAML, JSON ou variable d'environnement). Pour chaque site, il lance une suite de tests avec les bonnes variables : URL du site, base de données de test, credentials de test.

Parallélisation. Les tests de plusieurs sites s'exécutent en parallèle. La plupart des outils CI modernes (GitLab CI, GitHub Actions) supportent nativement la parallélisation par job. Pour 17 sites, un pipeline parallélisé sur 5 workers prend environ 3 fois moins de temps qu'un pipeline séquentiel.

Variables d'environnement par site. Chaque site a ses propres credentials de test (utilisateur de test, mot de passe, base de données de tests). Ces variables sont stockées dans les secrets du pipeline CI et injectées au moment de l'exécution.

Gestion des fixtures. Données de test spécifiques à chaque site : utilisateurs de test, contenus de test, configurations particulières. Les fixtures sont chargées automatiquement avant les tests et nettoyées après.

Reporting consolidé. Un agrégateur récupère les résultats de tous les sites et produit un rapport unique. Slack, email ou dashboard web : choisissez le format qui correspond à vos habitudes d'équipe.

Le workflow de maintenance avec tests

Une fois le pipeline en place, le cycle de maintenance change radicalement. Voici à quoi ressemble un cycle type sur un multi-site avec tests automatisés.

Le développeur lance composer update sur l'environnement de staging. Le pipeline de tests se déclenche automatiquement et roule sur tous les sites en quelques minutes. Le rapport est envoyé sur Slack avec un récapitulatif vert ou rouge par site.

Si tout est vert, le déploiement en production se fait avec confiance. Un second pipeline (smoke tests uniquement, plus rapide) roule sur production pour valider que le déploiement s'est bien passé.

Si un site est rouge, l'équipe sait précisément lequel et quel test échoue. Le correctif est ciblé : on regarde le test qui ne passe plus, on comprend la cause et on corrige. Le déploiement en production attend que tout soit vert.

Ce workflow transforme la maintenance d'un acte risqué et chronophage en routine fiable. Les forfaits de maintenance Drupal Pro et Premium intègrent ce type de validation, soit sur vos tests existants, soit avec une mise en place de tests de base si vous n'en avez pas encore.

Le retour sur investissement concret

Le coût initial d'un pipeline de tests pour un multi-site est non négligeable : 5 à 8 jours de travail pour l'audit, l'écriture des tests et la configuration du pipeline. Mais ce coût se rentabilise rapidement.

Un pipeline de tests pour 17 sites prend 10 à 15 minutes par cycle de maintenance. La vérification manuelle des mêmes 17 sites prend 8 à 10 heures. Sur un cycle mensuel, c'est 8 heures économisées chaque mois, soit environ 100 heures par an. Sur trois ans, c'est 300 heures de validation manuelle évitées.

L'investissement initial (5 à 8 jours) est amorti en 2 à 3 mois. Tout le reste est gain net. Et ce calcul ne compte pas les bénéfices indirects : plus de stabilité en production, plus de sérénité dans l'équipe et plus de confiance dans les mises à jour.

Sur un multi-site institutionnel ou commercial, où la disponibilité du service est un enjeu opérationnel quotidien, les tests automatisés sont l'un des investissements les plus rentables que vous pouvez faire sur votre infrastructure Drupal.

Pour explorer la mise en place de tests sur votre architecture multi-sites, consultez notre service tests automatisés Drupal ou contactez-nous pour un diagnostic personnalisé.