500 sites, un seul thème actif sur l’ensemble du réseau multisite : chaque mise à jour de ce thème, même mineure, s’applique instantanément à l’intégralité de ces sites dès sa publication, sans étape intermédiaire par défaut dans WordPress. Sur un réseau de cette taille, opéré par une agence pour le compte de plusieurs centaines de clients internes ou d’établissements affiliés, cette absence de granularité transforme le moindre bug de régression en incident généralisé plutôt qu’en problème localisé.
Ce billet décrit l’arborescence retenue pour organiser ce thème partagé, ainsi que la procédure de déploiement progressif avec rollback mise en place pour limiter ce risque structurel. Il ne traite ni la gestion des utilisateurs du multisite, ni les questions d’hébergement de l’infrastructure sous-jacente.
Le problème structurel d’un thème unique sur un grand réseau
Un réseau multisite WordPress activant un thème réseau applique généralement la même version de ce thème à tous les sites qui l’utilisent. Sur un réseau de cinq ou dix sites, une régression touche un périmètre limité et se corrige rapidement. Sur 500 sites, la même régression touche potentiellement des centaines d’organisations distinctes en simultané, avec des remontées de support qui affluent en quelques minutes sur tous les canaux à la fois.
Arborescence retenue pour le thème partagé
L’organisation du code du thème sépare strictement le cœur commun des personnalisations propres à certains sous-groupes de sites, en s’appuyant sur les mécanismes de personnalisation par site déjà natifs à WordPress (options de thème, theme_mod).
theme-reseau/
├── style.css
├── functions.php
├── inc/
│ ├── core/
│ │ ├── class-theme-reseau-core.php
│ │ └── class-theme-reseau-personnalisation.php
│ ├── cohortes/
│ │ ├── cohorte-a.php # Sites pilotes, reçoivent les nouveautés en premier
│ │ ├── cohorte-b.php # Sites standards, deuxième vague
│ │ └── cohorte-c.php # Sites à fort trafic, dernière vague
│ └── compat/
│ └── retrocompat-v3.php # Ponts de compatibilité pour anciennes versions
├── templates/
└── patterns/Le dossier cohortes/ ne contient pas de code métier différent par cohorte — il contient uniquement la logique de bascule de fonctionnalités (feature flags), permettant d’activer une nouveauté du thème sur un sous-ensemble de sites avant de la généraliser.
Le déploiement progressif par cohortes
Plutôt qu’un déploiement en un seul bloc, chaque mise à jour du thème suit une séquence en trois vagues, espacées dans le temps pour laisser apparaître d’éventuelles régressions avant qu’elles ne touchent l’ensemble du réseau.
- Cohorte A (sites pilotes, environ 20 sites) : sites internes de l’agence et sites de clients ayant explicitement accepté ce rôle de test, sur lesquels la nouvelle version du thème est déployée en premier, avec surveillance renforcée pendant 48 heures
- Cohorte B (sites standards, environ 400 sites) : déploiement uniquement après validation de la cohorte A, sur la majorité du réseau
- Cohorte C (sites à fort trafic, environ 80 sites) : déploiement en dernier, sur les sites où une régression aurait l’impact business le plus élevé, une fois la confiance maximale acquise sur les deux premières vagues
La bascule d’une cohorte à l’autre repose sur un indicateur de version de thème stocké par site, comparé au numéro de version cible via une tâche planifiée qui active progressivement la mise à jour, plutôt que sur un remplacement brutal des fichiers pour l’ensemble du réseau en une seule opération.
Mécanisme technique de bascule
function reseau_version_theme_cible_pour_site( $site_id ) {
$cohorte = get_blog_option( $site_id, 'reseau_cohorte', 'b' );
$calendrier = array(
'a' => '2025-10-29',
'b' => '2025-10-31',
'c' => '2025-11-04',
);
if ( strtotime( $calendrier[ $cohorte ] ) <= time() ) {
return 'nouvelle';
}
return 'stable';
}Le rollback : préparé avant, pas improvisé après
Le rollback ne doit jamais être une procédure improvisée en pleine crise. Avant le premier déploiement en cohorte A, la version stable précédente reste disponible en parallèle de la nouvelle, référencée par un simple changement de constante plutôt que par une réinstallation complète de fichiers.
Un rollback qui prend plus de cinq minutes à exécuter sur un réseau de cette taille n’est pas un rollback utilisable en situation réelle. Testez-le à froid, hors incident, avant de vous y fier en production.
- Conservation des deux dernières versions stables du thème dans des dossiers distincts et versionnés
- Bascule de version pilotée par une constante de configuration, jamais par un remplacement manuel de fichiers
- Répétition périodique de l’exercice de rollback en environnement de préproduction, indépendamment de tout incident réel
En résumé
Sur un multisite de cette échelle, la gouvernance des mises à jour de thème compte autant que la qualité du code lui-même. Un découpage en cohortes, une bascule pilotée par configuration plutôt que par remplacement de fichiers, et un rollback testé à froid réduisent drastiquement le risque qu’une régression mineure se transforme en incident touchant 500 sites simultanément.
