Mises à jour WordPress sans risque : le process d'une agence

Mises à jour WordPress sans risque : le process d'une agence

Une mise à jour WordPress casse un site de production plus souvent qu'on ne le croit — et presque toujours pour les mêmes raisons. Un conflit entre une extension et le core, une dépendance PHP abandonnée silencieusement, un hook modifié sans préavis : voilà les trois causes les plus fréquentes d'indisponibilité post-mise à jour. Le process décrit ici vous permet d'intervenir sur votre parc sans jamais exposer un site client à une coupure.

• Pourquoi une MAJ WordPress peut casser la prod
• Le process en 5 étapes d'une agence rigoureuse
• Automatiser avec WP-CLI : le script pour un parc
• Gérer les mises à jour sur un parc de 50 sites
• Indicateurs clés à suivre

Pourquoi une mise à jour WordPress peut casser la prod

Conflits entre plugins et thème

WordPress ne propose pas de gestion formelle des dépendances entre extensions. Quand un plugin passe en version majeure et modifie ses filtres ou ses actions, un autre plugin qui s'y accrochait peut produire une erreur fatale PHP ou simplement rendre certaines pages inaccessibles. Les thèmes construits sur des frameworks — Genesis, Divi, Avada — ajoutent une couche de risque supplémentaire : une mise à jour du framework peut casser des child themes modifiés par votre équipe, parfois sans aucun message d'erreur explicite.

Dépendances PHP et ruptures d'API

Depuis les versions récentes de WordPress, le core suit les exigences PHP plus strictement. Une mise à jour core peut imposer une version minimum de PHP au moment où un hébergeur est encore sur une version antérieure pour des raisons de compatibilité applicative. Sans environnement de test isolé, cette incompatibilité n'apparaît qu'en production. WP-CLI permet de détecter ces dépendances avant le déploiement, à condition de l'exécuter sur un staging à configuration identique à celle de la prod.

Le process en 5 étapes d'une agence rigoureuse

1. Inventaire et classification des plugins

Avant de lancer la moindre mise à jour, listez les composants disponibles avec WP-CLI :

wp plugin list --update=available --path=/var/www/mon-site --fields=name,version,update_version,status

Classez chaque mise à jour en deux catégories :

• Critique : core WordPress, WooCommerce, extensions de paiement, plugins de cache, constructeurs de pages — tout ce qui peut bloquer le checkout ou rendre le site inaccessible.
• Cosmétique : plugins d'analytics, de formulaires simples, d'optimisation d'images — les régressions sont visibles mais ne bloquent pas l'activité du client.

Les mises à jour critiques passent toujours par staging. Les cosmétiques peuvent être appliquées directement en production si une sauvegarde récente est confirmée.

2. Snapshot et sauvegarde avant intervention

Une sauvegarde nocturne ne suffit pas avant une mise à jour WooCommerce : des commandes peuvent avoir été passées dans l'intervalle. Générez un snapshot immédiatement avant l'intervention :

wp db export /tmp/pre-update-YYYYMMDD-HHMM.sql --path=/var/www/mon-site --quiet

Conservez aussi une copie du dossier wp-content si vous anticipez un conflit de fichiers thème. Sentinelo applique ce principe nativement : les mises à jour WordPress et WooCommerce ne s'exécutent qu'après confirmation d'une sauvegarde de moins de 24 heures — et le rollback du composant s'exécute automatiquement si le site cesse de répondre après la mise à jour.

3. Test sur staging et validation visuelle

Le staging doit être un clone exact de la production : même version de PHP, même configuration serveur, même base de données anonymisée. Appliquez d'abord les mises à jour sur staging :

wp core update --path=/var/www/staging

wp plugin update --all --path=/var/www/staging

wp theme update --all --path=/var/www/staging

Vérifiez ensuite les pages critiques : accueil, listing produits, checkout, espace client. Un outil comme Playwright ou Cypress peut automatiser la comparaison visuelle avant/après. Sans outil dédié, un script qui vérifie les codes HTTP sur une liste d'URLs critiques détecte les erreurs 500 avant que votre client ne les signale.

4. Déploiement en maintenance mode avec rollback prêt

Sur production, basculez d'abord en maintenance mode pour éviter les transactions partielles :

wp maintenance-mode activate --path=/var/www/mon-site

wp core update --path=/var/www/mon-site

wp plugin update --all --path=/var/www/mon-site

Vérifiez ensuite le code HTTP de retour du site. Si le site ne répond pas correctement, restaurez le dump créé à l'étape précédente : wp db import /tmp/pre-update-*.sql --path=/var/www/mon-site. WP-CLI ne conserve pas lui-même les versions précédentes des plugins — c'est votre snapshot qui joue ce rôle. Une fois la vérification passée, désactivez la maintenance :

wp maintenance-mode deactivate --path=/var/www/mon-site

Pour les sauvegardes gérées par Sentinelo et le fonctionnement du rollback automatique, consultez la page dédiée aux sauvegardes.

5. Rapport post-déploiement au client

Un compte-rendu minimaliste suffit : date de l'intervention, liste des composants mis à jour avec les versions avant et après, résultat (succès ou rollback avec le motif), prochaine fenêtre de maintenance planifiée. Évitez le vocabulaire technique brut dans les rapports client : « core 6.4.3 → 6.5.0 » est lisible pour un non-technicien ; les hashes de commit ne le sont pas. Le guide complet de la maintenance WordPress pour agences couvre aussi la facturation de ce service.

Automatiser avec WP-CLI : le script pour un parc

Sur un parc de plusieurs dizaines de sites, le process manuel est impraticable. Voici la structure d'un script shell qui applique le process complet sur une liste de sites WordPress hébergés sur le même serveur :

#!/bin/bash

set -euo pipefail

SITES=(/var/www/client-a /var/www/client-b /var/www/client-c)

RAPPORT="/tmp/rapport-maj-$(date +%Y%m%d).txt"

for SITE in "${SITES[@]}"; do

SLUG=$(basename "$SITE")

# Vérifier qu'une sauvegarde récente existe (moins de 24h)

if ! find "$SITE" -name "*.sql" -mmin -1440 | grep -q .; then

echo "SKIP $SLUG : pas de sauvegarde récente" | tee -a "$RAPPORT"

continue

fi

# Snapshot pré-update

BACKUP="/tmp/pre-$SLUG-$(date +%Y%m%d-%H%M).sql"

wp db export "$BACKUP" --path="$SITE" --quiet

# Maintenance mode + mises à jour

wp maintenance-mode activate --path="$SITE" --quiet

wp core update --path="$SITE" --quiet

wp plugin update --all --path="$SITE" --quiet

wp theme update --all --path="$SITE" --quiet

# Contrôle HTTP — rollback si le site ne répond plus

SITEURL=$(wp option get siteurl --path="$SITE")

HTTP=$(curl -s -o /dev/null -w "%{http_code}" "$SITEURL")

if [ "$HTTP" != "200" ]; then

echo "ROLLBACK $SLUG (HTTP $HTTP)" | tee -a "$RAPPORT"

wp db import "$BACKUP" --path="$SITE" --quiet

else

echo "OK $SLUG" | tee -a "$RAPPORT"

fi

wp maintenance-mode deactivate --path="$SITE" --quiet

done

Ce script suppose que vos sites sont hébergés sur le même serveur et que WP-CLI est installé globalement. Pour un parc distribué sur plusieurs serveurs, WP-CLI supporte l'exécution à distance via SSH : remplacez --path=/chemin par --ssh=user@serveur:port/chemin dans chaque commande.

La commande wp plugin update --all --dry-run --path=/var/www/mon-site liste les mises à jour disponibles sans rien déclencher — utile pour planifier une fenêtre de maintenance. La référence complète des commandes est disponible sur developer.wordpress.org/cli/commands.

Gérer les mises à jour sur un parc de 50 sites

Sur un parc de cette taille, l'enjeu n'est plus seulement technique mais organisationnel. Trois règles permettent de tenir la charge :

• Fenêtres de maintenance fixes par type de site : vitrines le mardi en début de nuit, boutiques e-commerce le mercredi hors pics commerciaux. Vos clients savent quand vous intervenez, vous évitez les mauvaises surprises en journée.
• Priorisation par criticité client : les sites WooCommerce actifs passent en premier — une transaction interrompue pendant la maintenance est le scénario à éviter. Les vitrines informatives à faible trafic passent en dernier.
• Traitement par lots homogènes : regroupez les sites qui partagent le même thème parent et les mêmes plugins clés. Si une mise à jour casse un site du lot sur staging, vous signalez le problème à tous les autres avant de les toucher.

Pour la comparaison des outils de gestion de parc — ManageWP, MainWP, WP Umbrella — leurs fonctionnements et leurs limites sont détaillés dans notre comparatif dédié. Pour les spécificités des mises à jour sur une boutique WooCommerce, le retour d'expérience sur un rollback WooCommerce en production couvre les scénarios les plus courants.

Le workflow complet : de l'inventaire au rapport post-déploiement.

Indicateurs clés à suivre

Un process de mise à jour mature se mesure. Deux indicateurs suffisent pour commencer :

Indicateur	Définition	Objectif initial
Temps moyen de mise à jour	Durée entre le déclenchement et la confirmation HTTP 200 post-déploiement	Moins de 10 minutes par site avec automatisation
Taux de rollback	Part des interventions ayant déclenché un rollback automatique ou manuel	À calibrer sur votre parc et son historique

Un taux de rollback élevé sur une période signale soit des plugins de mauvaise qualité dans votre parc, soit un staging insuffisamment représentatif de la production. Dans les deux cas, l'indicateur pointe vers une action corrective précise plutôt que vers un problème diffus.

La plateforme Sentinelo automatise chacune de ces étapes — snapshot pré-update, déploiement en fenêtre de maintenance configurable, rollback automatique si le site ne répond plus — pour WordPress, WooCommerce et PrestaShop. Essai gratuit 14 jours, sans carte bancaire.