Comment déployer cinq cents sites WordPress de collectivités, chacun avec ses propres extensions, son propre thème enfant et parfois ses propres pages personnalisées, sans maintenir cinq cents fichiers de configuration de déploiement distincts ? L’architecture initiale de ce réseau, héritée d’une croissance progressive site par site, comptait effectivement une configuration de pipeline dupliquée pour chaque commune, copiée-collée depuis la précédente puis légèrement adaptée. Cette approche, viable à cinquante sites, devenait ingérable à cinq cents : toute évolution commune (mise à jour de PHP, changement d’outil de build) nécessitait de la répercuter manuellement sur des centaines de fichiers.
La refonte retenue s’appuie sur un principe simple à énoncer, plus complexe à mettre en œuvre correctement : un seul pipeline générique, paramétré par un fichier de manifeste propre à chaque site, qui déclare uniquement ce qui distingue ce site du comportement par défaut.
Arborescence du système retenu
infrastructure-collectivites/
├── pipeline/
│ ├── deploy.yml # pipeline generique unique
│ └── scripts/
│ ├── build-site.sh
│ └── verifier-sante.sh
├── sites/
│ ├── commune-a/
│ │ ├── manifeste.json # specificites propres a ce site
│ │ └── theme-enfant/
│ ├── commune-b/
│ │ ├── manifeste.json
│ │ └── theme-enfant/
│ └── ... (500 sites)
└── configuration-commune/
├── extensions-standard.json
└── php-version.txt
Le fichier de manifeste, seul point de variation
Chaque site ne porte que ce qui le distingue du comportement par défaut du réseau : extensions supplémentaires spécifiques à ce site, version de PHP dérogatoire si une extension ancienne l’impose encore, domaine et sous-répertoire de déploiement. Tout ce qui n’est pas déclaré explicitement dans ce manifeste hérite de la configuration commune, ce qui garantit qu’une évolution appliquée à la configuration commune se propage automatiquement à tous les sites qui n’ont pas explicitement dérogé.
{
"site_id": "commune-a",
"domaine": "commune-a.exemple-collectivites.fr",
"extensions_supplementaires": ["formulaire-demarches-en-ligne"],
"php_version_derogation": null,
"theme_enfant": "theme-enfant-commune-a"
}
Le pipeline générique : une boucle paramétrée
Le pipeline lui-même ne contient aucune référence à un site en particulier. Il reçoit en paramètre l’identifiant du site à déployer, charge le manifeste correspondant, fusionne sa configuration avec la configuration commune, puis exécute la même séquence de build et de déploiement quel que soit le site traité. Cette séquence reste strictement identique d’un site à l’autre ; seule la donnée qui l’alimente change.
- Chargement de la configuration commune, puis surcharge par les valeurs déclarées dans le manifeste du site.
- Construction de l’image ou de l’archive de déploiement à partir de cette configuration fusionnée.
- Exécution d’un contrôle de santé post-déploiement identique pour tous les sites, avec seuils de tolérance identiques.
Centraliser la montée de version du cœur
La montée de version de WordPress ou de PHP pour l’ensemble du réseau se pilote désormais depuis la configuration commune, sans toucher à un seul fichier de manifeste individuel, sauf pour les sites ayant explicitement déclaré une dérogation. Une montée de version se déploie par lots successifs (voir notre méthode de bascule progressive), en modifiant une seule valeur dans configuration-commune/php-version.txt, ce qui aurait nécessité, dans l’ancienne architecture, une modification répétée dans des centaines de fichiers distincts.
Gérer les exceptions sans casser le modèle
Certains sites du réseau utilisent encore une extension ancienne incompatible avec la dernière version de PHP déployée sur le reste du parc. Plutôt que de dupliquer leur pipeline entier pour cette seule contrainte, leur manifeste déclare simplement une dérogation de version PHP, appliquée uniquement à leur propre déploiement sans affecter la logique générique du pipeline ni les autres sites.
Un pipeline paramétré ne supprime pas la diversité réelle d’un parc de cinq cents sites ; il la rend explicite et localisée, plutôt que diluée dans des centaines de copies presque identiques d’un même fichier.
Notre verdict
Ce passage d’une configuration dupliquée par site à un pipeline unique paramétré a demandé environ six semaines de refonte, mais il a réduit le temps de déploiement d’une montée de version commune de plusieurs jours à quelques heures, et surtout supprimé le risque d’oubli qui existait mécaniquement dès qu’une modification devait être répercutée manuellement sur des centaines de fichiers distincts.
