500 : c’est le nombre de sites d’un réseau multisite WordPress géré par une agence pour un groupement de franchises, chacun basé sur un même kit Elementor de référence, avec des variations de contenu propres à chaque franchisé mais une identité visuelle commune. À cette échelle, la moindre modification du kit partagé devient un événement à gouverner avec la même rigueur qu’un déploiement de code en production.
Cet article décrit l’arborescence retenue pour organiser ce multisite et la procédure de déploiement progressif mise en place, avec son mécanisme de rollback. Il ne traite pas de la gestion des utilisateurs et des rôles au niveau du réseau multisite, ni des choix d’hébergement qui sous-tendent cette infrastructure, deux sujets distincts.
Arborescence retenue
reseau-multisite/
├── site-reference/ (site 1, jamais visible publiquement)
│ └── kit Elementor "franchise-v3" (source de vérité)
├── sites-pilotes/ (10 sites, premiers exposés à un nouveau kit)
├── sites-lot-a/ (150 sites, deuxième vague de déploiement)
├── sites-lot-b/ (150 sites, troisième vague)
└── sites-lot-c/ (190 sites, déploiement final)
Le site de référence n’est jamais accessible publiquement : il sert uniquement de bac à sable pour concevoir et valider chaque nouvelle version du kit avant toute diffusion. Chaque kit exporté depuis ce site de référence est versionné (franchise-v3, franchise-v4) et archivé, jamais écrasé.
Le principe du déploiement progressif
Un nouveau kit n’est jamais déployé sur les 500 sites simultanément. Il est d’abord importé sur les dix sites pilotes, sélectionnés pour leur diversité de contenu (un site avec beaucoup d’images, un site très textuel, un site avec un formulaire complexe), afin de révéler rapidement un éventuel effet de bord que le site de référence, plus simple, n’aurait pas manifesté.
Étapes du déploiement
- Import du kit sur les sites pilotes, via WP-CLI, en script parcourant la liste des identifiants de sites concernés
- Observation d’une période d’au moins 48 heures, avec surveillance des retours du support client et des journaux d’erreurs
- Extension au lot A (150 sites), puis lot B après validation, puis lot C en dernier
- Journal de déploiement tenu à jour, associant chaque lot à l’heure exacte de bascule
Le script WP-CLI d’import s’appuie sur la commande native d’import de kit exposée par Elementor, exécutée site par site dans une boucle, avec un identifiant de site multisite passé en paramètre à chaque itération :
for site_id in $(cat lot-a-ids.txt); do
wp elementor kit import chemin/vers/franchise-v4.zip --url="$site_id"
done
Le rollback : préparé avant, pas improvisé après
Avant chaque déploiement, le kit précédemment actif sur chaque lot est exporté et archivé avec un horodatage précis, permettant un retour en arrière rapide en cas de problème détecté après bascule. Ce rollback consiste à réimporter l’archive du kit précédent avec la même commande WP-CLI, ciblée sur les seuls sites concernés par le lot posant problème.
Conseil maison : un rollback qui se prépare après l’incident arrive toujours trop tard. L’archive du kit précédent doit être générée et vérifiée avant même de lancer le déploiement du nouveau kit, jamais après coup dans l’urgence.
Ce que cette gouvernance a évité
Sur ce réseau, un déploiement de kit a révélé, dès la phase pilote, une régression sur les Global Colors qui rendait illisible le texte d’un bandeau promotionnel présent uniquement sur certains sites plus anciens. Le déploiement progressif a limité l’exposition à dix sites plutôt que cinq cents, et le rollback préparé en amont a permis un retour à la version précédente en moins de vingt minutes le temps de corriger le kit.
En résumé
Sur un multisite Elementor de grande taille, un kit partagé n’est jamais un simple fichier à réimporter à la légère : une arborescence claire séparant site de référence et lots de déploiement, associée à un rollback préparé en amont, transforme un risque potentiellement massif en un incident contenu et rapidement résolu.
