Un clic sur « Mettre à jour maintenant » un vendredi à 17 h. L'écran blanc arrive. Personne ne sait quel plugin vient de changer. La dernière sauvegarde date de trois semaines — non testée. Ce scénario n'est pas une malédiction WordPress : c'est l'absence de process traitée comme de l'agilité.
Mettre WordPress à jour est une compétence d'exploitation, pas une corvée cliquable. Le but n'est pas d'être à jour à tout prix — c'est d'être à jour sans surprise.
Les trois couches — et leurs risques respectifs
| Couche | Fréquence | Risque typique |
|---|---|---|
| Core WordPress | Régulière | Rare seul, conflit avec vieux plugins |
| Plugins | Très fréquente | Fonctionnalité cassée, fatal error |
| Thème / builder | Variable | CSS layout, templates custom |
| PHP hébergeur | Annuelle | Incompatibilité silencieuse puis crash |
Mettre à jour le core sans tester les plugins, c'est changer le moteur sans vérifier les courroies.
Process minimal qui tient la route
Inventoriez plugins actifs, versions, lesquels sont critiques métier (paiement, formulaires, SEO). Créez un staging identique : même PHP, mêmes extensions. Sauvegarde immédiate avant prod — fichiers + base, avec restauration déjà testée une fois.
Ordre d'exécution en staging puis prod : core, plugins un par un ou par lot homogène, thème en dernier, purge cache après chaque étape. Smoke test : connexion admin, homepage, panier, formulaire, paiement test si e-commerce.
Mises à jour automatiques : où placer le curseur
Micro-sécurité core : parfois oui sur sites simples. WooCommerce et page builders : non sans test staging. Documentez qui décide, qui valide, quelle fréquence.
Alignez version PHP avec Choisir une version de PHP avant une montée majeure.
Le sommet : la production n'est pas un environnement de test
Les équipes sans temps d'exploitation repoussent les mises à jour — puis un CVE force une montée en urgence. Mieux vaut un petit process régulier qu'un rattrapage un week-end.
Décider et avancer sans angle mort
Créez ou demandez un staging chez l'hébergeur. Testez une restauration de backup ce mois-ci. Fixez un calendrier (ex. mardi 10 h, hors promo). Tenez un changelog interne plugins/core. Préparez rollback : accès FTP, renommage dossier plugin.
Voir WordPress managé si vous externalisez une partie du cycle.
Questions fréquentes
Dans quel ordre mettre à jour WordPress ?
Sauvegarde complète, puis core, plugins, thème — en staging d'abord si possible. Ne jamais enchaîner plusieurs changements sans point de restauration intermédiaire.
Faut-il activer les mises à jour automatiques ?
Auto pour micro-sécurité core parfois pertinent. Plugins majeurs et WooCommerce : non sans test staging.
Comment tester sans environnement staging ?
Clone local ou sous-domaine minimal — jamais vendredi soir direct en production.
Que faire si une mise à jour casse le site ?
Restauration backup ou désactivation plugin via FTP — procédure préparée à l'avance, pas improvisée pendant la panne.
WordPress se met à jour tout seul en théorie. En pratique, seul un process humain évite que la production devienne le laboratoire.