Mises à jour WordPress : pourquoi il ne faut jamais « tout mettre à jour » un vendredi soir

Le bouton « Tout mettre à jour » est probablement responsable de plus de sites cassés
que tous les pirates réunis. Chez EVICO, une partie des appels d’urgence que nous recevons commence
par la même phrase : « j’ai fait les mises à jour hier soir et depuis, écran blanc ».
Le paradoxe, c’est que ne PAS mettre à jour est encore pire — la moitié des failles à fort
impact sont exploitées dans les 24 heures suivant leur divulgation (Patchstack), et
les plus recherchées en 5 heures. Il ne faut donc ni cliquer les yeux fermés, ni attendre :
il faut un protocole. Voici le nôtre, transposable tel quel.

Pourquoi les mises à jour cassent des sites

Comprendre le mécanisme aide à s’en protéger. Un site WordPress, c’est le cœur + un thème + 15 à
40 extensions, écrits par des équipes différentes qui ne se concertent pas. Chaque mise à jour peut
introduire :

• →Une incompatibilité entre extensions — le cas le plus courant : l’extension A mise à jour ne fonctionne plus avec la version actuelle de l’extension B.
• →Une rupture avec le thème, surtout les thèmes achetés il y a des années et jamais suivis, ou les thèmes enfants avec du code personnalisé.
• →Un changement de comportement volontaire : une extension qui refond son interface ou change ses réglages par défaut — le site marche, mais plus comme avant.
• →Une exigence de version PHP : l’extension exige PHP 8.2, votre serveur est en 7.4 — erreur fatale immédiate.

Aucun de ces risques n’est une raison de ne pas mettre à jour. Ce sont des raisons de mettre à
jour proprement.

Règle 1 : jamais sans sauvegarde restaurable

Pas « une sauvegarde existe quelque part chez l’hébergeur » : une sauvegarde
que vous savez restaurer, en minutes. La différence se mesure exactement le jour où
l’écran devient blanc. Notre pratique : sauvegarde fichiers + base immédiatement avant chaque
session de mise à jour, conservée jusqu’à validation complète. (Sur la stratégie de sauvegarde
elle-même, voir notre guide de la méthode
3-2-1.)

Règle 2 : jamais tout d’un coup

« Tout mettre à jour » applique 20 mises à jour en une passe. Si le site casse, laquelle
est en cause ? Vous voilà à restaurer, puis à réappliquer une par une… ce qu’il fallait faire
dès le départ. Notre ordre de passage :

• 1. Les extensions, une par une, en commençant par celles de sécurité et celles marquées « mise à jour de sécurité » — un rechargement du site entre chaque.
• 2. Le thème — avec une vigilance particulière si des personnalisations existent hors thème enfant (elles seront écrasées).
• 3. Le cœur WordPress — versions mineures (6.9.4 → 6.9.5) sans hésiter, versions majeures avec un peu de recul (voir règle 4).
• 4. PHP en dernier, séparément, un autre jour : c’est le changement au plus fort potentiel de casse, à tester extension par extension.

Règle 3 : jamais le vendredi soir (le vrai sens de la règle)

La règle n’est pas une superstition de développeurs : on met à jour quand on est en
mesure de constater un problème ET de le réparer. Le vendredi 18 h, un formulaire de
contact cassé le reste jusqu’au lundi — trois jours de contacts perdus sans que personne ne s’en
aperçoive. Le créneau idéal : en début de matinée un jour ouvré, hors pic de trafic, avec une
heure devant soi. Pour un e-commerce, hors périodes de forte vente, évidemment.

Règle 4 : lire avant de cliquer

Règle 5 : vérifier après — vraiment

Recharger la page d’accueil ne suffit pas. Notre checklist post-mise à jour :

• →Les pages clés : accueil, page contact, 2-3 pages de contenu, une fiche produit le cas échéant.
• →Les parcours critiques : envoi réel du formulaire de contact (jusqu’à la réception de l’e-mail), ajout au panier et passage de commande en mode test.
• →La console du navigateur (F12) : des erreurs JavaScript apparues signalent souvent un conflit silencieux.
• →Le backoffice : édition d’une page, upload d’une image.

Dix minutes, montre en main. C’est le prix pour découvrir le problème vous-même plutôt que par un
client — ou pire, par personne, pendant des semaines.

Règle 6 : l’environnement de test pour ce qui est sensible

Pour les sites à enjeu (e-commerce, fort trafic), les mises à jour majeures se testent d’abord sur
une copie de staging — la plupart des bons hébergeurs en proposent en un clic. On y
applique tout, on vérifie, puis on rejoue en production. C’est le standard professionnel ; c’est
aussi, très concrètement, ce qui distingue une maintenance
sérieuse d’un robot qui clique.

Et les mises à jour automatiques ?

Notre position nuancée : oui pour les versions mineures du cœur (comportement
par défaut de WordPress, sûr) et pour les petites extensions sans enjeu ;
non pour les extensions critiques (paiement, panier, formulaires, cache) sur un site
à enjeu — précisément parce que personne ne vérifie derrière. L’automatique sans vérification, c’est
la panne silencieuse garantie un jour ou l’autre : 60 % des sites WordPress de PME
françaises contiennent déjà au moins une extension obsolète à faille connue — souvent parce qu’une
mise à jour automatique a échoué sans que personne ne le voie.

Sources : Patchstack, State of WordPress Security in 2026 (exploitation <24 h,
failles les plus ciblées en 5 h) ; politique de mises à jour automatiques de
WordPress.org ; protocole de maintenance EVICO.