Tenir la maintenance WordPress de plusieurs clients, c’est un calendrier et un ordre de gestes, pas une après-midi où l’on clique sur Mettre à jour partout. Le geste de base, pour un site, est toujours le même : sauvegarde des fichiers et de la base, essai sur une copie, mise à jour, contrôle de trois URL, puis production. Le calendrier dit quel site passe quel mardi, et qui est là pour revenir en arrière si l’accueil ne répond plus 200.
Grouper avant de cliquer
Classez les sites sur une feuille : hébergeur, version de PHP, version de WordPress, présence d’une copie de préproduction, créneau convenu avec le client. Les sites d’un même hébergeur et d’une même version de PHP se suivent : une extension incompatible avec PHP 8.2 se verra au premier, pas au douzième sous une forme différente.
Ne mettez pas le vendredi soir dans le calendrier. Le retour arrière demande quelqu’un encore là, et un client joignable si le formulaire ou le paiement change de comportement. Un mardi matin, avec la fenêtre annoncée, est un créneau. Le contrat, s’il existe, doit citer ce créneau. En dehors, vous n’enchaînez pas une majeure parce que la notification est apparue à 18 h.
Les mises à jour mineures du cœur peuvent rester automatiques. Notez-le sur la feuille pour ne pas les refaire à la main. Les majeures, les extensions et le thème passent par le créneau. Une extension dont la licence a expiré ne se mettra pas à jour : la feuille a une colonne licence pour ne pas le découvrir au milieu du créneau.
L’ordre d’une session
- Annoncez le début au contact du client si le contrat le prévoit. Posez un 503 seulement si le site doit réellement être fermé. Beaucoup de mises à jour n’ont pas besoin de fermer le site. Ne posez pas un 503 par habitude.
- Sauvegardez fichiers et base, et vérifiez que l’archive n’est pas vide. Le contrôle de cette archive est un sujet en soi : une sauvegarde de taille nulle n’est pas un filet.
- Sur la copie, mettez à jour. Commencez par le cœur si une majeure est décidée, puis les extensions, puis le thème. Évitez de tout lancer d’un seul clic groupé la première fois que vous voyez le site : en cas d’échec, vous ne savez pas laquelle a cassé la page.
- Contrôlez la copie : accueil en 200,
wp-login.php, envoi d’un formulaire vers une boîte de test, page principale (offre, panier, prise de rendez-vous). - Reproduisez en production. Recontrôlez les mêmes URL. Si l’accueil n’est pas 200, retour arrière depuis la sauvegarde de l’étape 2, puis notez l’extension en cause. Vous ne réparez en live pendant que les autres sites du matin attendent.
Le détail d’une sauvegarde WordPress vérifiable est dans vérifier une sauvegarde WordPress. Les extensions à regarder de plus près avant de les mettre à jour, parce qu’elles concentrent les correctifs de sécurité, sont listées dans plugins WordPress ciblés.
Le journal de session
Chaque site a quatre lignes dans le journal du jour : version avant, version après, sauvegarde (identifiant ou horodatage), contrôles (accueil, connexion, formulaire) avec le code ou le mot reçu pour le mail de test. Une case vide n’est pas un succès. C’est un contrôle non fait.
| Colonne | Exemple de valeur | À ne pas écrire |
|---|---|---|
| Cœur | 6.5.2 vers 6.5.3 | à jour |
| Extensions | 4 mises à jour, slugs dans le CSV | RAS |
| Sauvegarde | snapshot 2026-09-12 09:04, taille non nulle | faite |
| Contrôles | accueil 200, login OK, mail de test reçu | ça a l’air bon |
| Retour arrière | non, ou oui à 09:41 | rien, si vous êtes revenu en arrière sans le dire |
Le journal se range avec le CSV des extensions. Le mois suivant, vous voyez quelles mises à jour ont déjà échoué une fois. Vous ne redécouvrez pas l’incompatibilité en production.
Ce qui use l’équipe, et se retire du créneau
Les sites sans copie et sans sauvegarde identifiable ne rentrent pas dans le mardi des autres. Ils ont d’abord une session pour créer la copie et la sauvegarde. Les mélanger, c’est accepter de sauter le retour arrière. Les sites dont personne n’a le compte administrateur attendent aussi : vous ne mettez pas à jour via un compte partagé reçu par e-mail le matin même.
Une base devenue lente après les mises à jour n’est pas un détail à ignorer jusqu’au prochain trimestre. Si le contrôle montre un temps de réponse qui a changé d’ordre de grandeur sur l’admin, ouvrez le sujet base à part, comme dans performance de la base WordPress, plutôt que d’enchaîner les sites suivants en faisant semblant de ne pas l’avoir vu.
Le livrable est le calendrier plus le journal de session. Quand le journal est vide un mardi, la maintenance n’a pas eu lieu, même si les pastilles de l’admin sont revenues au calme toutes seules.