wp plugin update mon-extension-etat-civil --version=4.2.0 — cette commande, lancée une fois, suffit pour un site. Elle ne suffit plus du tout pour un parc de cinq cents mairies et intercommunalités, chacune hébergée sur son propre serveur, souvent derrière un pare-feu qui interdit toute connexion entrante depuis l’extérieur du réseau territorial.
C’est la contrainte structurante de ce type de parc : on ne peut pas « pousser » une mise à jour vers un site de collectivité comme on le ferait vers un VPS ouvert. Les DSI mutualisées imposent des règles de flux sortant uniquement, des listes blanches d’IP, parfois une revue de sécurité avant chaque changement de version. Concevoir un mécanisme de mise à jour groupée dans ce contexte revient à accepter cette isolation plutôt qu’à la contourner.
Le principe : tirer, jamais pousser
Le point de départ technique est simple à énoncer : chaque site interroge périodiquement un serveur de mise à jour central, jamais l’inverse. On s’appuie sur le mécanisme standard de WordPress, en enregistrant un filtre sur pre_set_site_transient_update_plugins pour injecter la réponse d’un serveur privé plutôt que celle de WordPress.org. Le site effectue une requête HTTP sortante planifiée via wp_schedule_event, ce qui reste compatible avec un pare-feu qui n’autorise que le trafic sortant en HTTPS vers un domaine précis.
Le serveur de mise à jour, lui, ne connaît jamais l’adresse IP entrante d’un site de mairie : il se contente de répondre à des requêtes identifiées par un jeton par instance, stocké en base et régénéré à chaque rotation de clé annuelle imposée par certaines DSI.
Vagues de déploiement et quorum de succès
Livrer les cinq cents sites en même temps est le meilleur moyen de provoquer cinq cents incidents simultanés si un bug apparaît. La bonne pratique consiste à découper le parc en vagues, typiquement par taille de collectivité ou par ancienneté d’installation, et à n’avancer à la vague suivante que si un quorum de succès est atteint sur la précédente.
- Vague canari : dix sites volontaires, suivis manuellement pendant vingt-quatre heures.
- Vague intermédiaire : cent sites, avec seuil d’échec toléré fixé à deux pour cent.
- Vague générale : le reste du parc, uniquement si les seuils précédents sont respectés.
serveur-maj-central/
├── api/
│ ├── verifier-version.php (répond au ping sortant du site)
│ └── recevoir-statut.php (reçoit succès/échec par vague)
├── vagues/
│ ├── canari.json (10 sites)
│ ├── intermediaire.json (100 sites)
│ └── generale.json (reste du parc)
└── cles/
└── par-collectivite.db (un jeton, une clé, par site)
Chaque site remonte un statut après application de la mise à jour : succès, échec avec message, ou absence de réponse après un délai donné. Ce statut transite par le même canal sortant que la vérification de version, sous forme d’un petit appel wp_remote_post vers un point d’API de télémétrie, jamais par un accès entrant vers le site lui-même.
Rollback automatique et snapshot avant application
Un parc de collectivités ne tolère pas qu’un agent d’accueil découvre un formulaire d’état civil cassé un lundi matin. Avant toute mise à jour, le mécanisme copie le dossier du plugin actif dans un répertoire d’archive horodaté, hors de la racine web. Si le statut remonté après mise à jour indique une erreur fatale — détectée via un test de santé applicatif exécuté juste après l’activation — le site restaure automatiquement l’archive et journalise l’incident.
function mc_snapshot_avant_maj( $chemin_plugin ) {
$archive = WP_CONTENT_DIR . '/maj-archives/' . basename( $chemin_plugin ) . '-' . time();
copy_dir( WP_PLUGIN_DIR . '/' . $chemin_plugin, $archive );
update_option( 'mc_derniere_archive_maj', $archive, false );
}
add_action( 'upgrader_pre_install', function( $true, $hook_extra ) {
if ( isset( $hook_extra['plugin'] ) ) {
mc_snapshot_avant_maj( $hook_extra['plugin'] );
}
return $true;
}, 10, 2 );
Isolation des identifiants entre collectivités
Chaque collectivité conserve sa propre clé d’API vis-à-vis du serveur de mise à jour, distincte de celle de ses voisines, même si toutes tournent sur la même version de l’extension. Cette isolation évite qu’une clé compromise sur un site expose l’ensemble du parc, et permet de révoquer l’accès d’un seul site — par exemple lors d’une fin de contrat avec une commune — sans toucher aux autres.
Sur ce type de parc, la question n’est jamais « comment pousser vite » mais « comment être sûr qu’un site isolé peut refuser sans bloquer les autres ». La conception doit partir de cette hypothèse par défaut.
Ce que ce mécanisme ne couvre pas
Deux sujets restent volontairement hors du périmètre de cette architecture. La gestion des alias en ligne de commande pour piloter plusieurs installations depuis un poste d’administrateur relève d’un autre outil du quotidien, pas d’un mécanisme de diffusion réseau. De la même façon, la stratégie de mise à jour du cœur WordPress lui-même suit un canal distinct, généralement laissé aux mises à jour mineures automatiques natives, pendant que le canal décrit ici ne concerne que l’extension métier partagée.
En résumé
Un parc de cinq cents sites de collectivités impose de renverser le réflexe habituel : le site tire sa mise à jour au lieu de la recevoir, la validation se fait par vagues avec un quorum mesurable, et chaque échec déclenche un retour arrière automatique plutôt qu’un ticket de support. Ce n’est pas plus compliqué qu’un déploiement classique, c’est simplement plus lent par construction, et c’est précisément ce qui le rend fiable.
