Avant de cliquer sur “Mettre à jour”
Une mise à jour majeure de WordPress (passage de 6.7 à 6.8, saut de PHP 8.1 à 8.3, refonte d’un page builder comme Elementor ou WPBakery) peut se dérouler sans le moindre souci. Elle peut aussi transformer, en quelques secondes, un site qui tournait parfaitement en écran blanc ou en erreur 500. La différence entre les deux scénarios ne tient presque jamais à la chance : elle tient à ce que tu as fait avant de cliquer. Cet article s’adresse à toute personne qui gère un site WordPress (auto-entrepreneur, PME, responsable marketing) et qui s’apprête à valider une mise à jour importante — core, PHP, thème ou builder. L’objectif : repartir avec une checklist précise, pas avec des vagues conseils de prudence.
Prérequis
- Accès admin WordPress complet (rôle administrateur)
- Accès à l’hébergement : FTP/SFTP ou SSH, et phpMyAdmin
- La liste des plugins actifs et leur version
- Un endroit sûr pour stocker une sauvegarde (pas seulement sur le même serveur)
- Idéalement, un environnement de staging (beaucoup d’hébergeurs comme o2switch ou Hostinger en proposent un en un clic)
1. Sauvegarder — et tester que la sauvegarde fonctionne
La sauvegarde seule ne protège de rien si elle est corrompue ou incomplète. Fais une sauvegarde complète : fichiers (dossier wp-content en priorité) et base de données. Un plugin comme UpdraftPlus ou Duplicator suffit largement, mais l’étape que presque tout le monde saute est celle-ci : télécharge l’archive et vérifie qu’elle s’ouvre, qu’elle contient bien la base de données récente et les médias. Une sauvegarde qui date de trois semaines ou qui s’arrête au dossier uploads ne sert à rien le jour où tu en as besoin.
Si tu utilises WP-Optimize pour nettoyer ta base régulièrement, c’est le bon moment pour vérifier que les tables optimisées n’ont pas cassé de relations — un nettoyage agressif juste avant une grosse mise à jour est une mauvaise idée, à faire plutôt en amont, à froid.
2. Vérifier la compatibilité de tout ce qui tourne
Avant toute mise à jour majeure, passe en revue trois éléments :
- Le thème : consulte le changelog du thème (ou du builder) pour la version cible. Un thème premium comme Divi, Avada ou un thème custom peut nécessiter une version PHP minimale précise.
- Les plugins : sur la page des mises à jour, WordPress indique généralement si un plugin n’a pas été testé avec la nouvelle version. Ne l’ignore pas — c’est souvent LE plugin qui causera l’incident.
- Les extensions critiques : WooCommerce, Contact Form 7, un plugin de cache. Ce sont ceux qui, en cassant, arrêtent des ventes ou des leads. Si tu vends en ligne, jette un œil aux erreurs WooCommerce courantes pour savoir à quoi t’attendre en cas de souci sur le tunnel d’achat.
Un thème ou un plugin abandonné depuis plus d’un an (pas de mise à jour, pas de réponse au support) est le signal le plus fiable d’un futur problème. Dans ce cas, la mise à jour majeure du core est souvent l’occasion de le remplacer plutôt que de croiser les doigts.
3. Noter précisément la version PHP actuelle
Une mise à jour majeure de WordPress s’accompagne souvent d’une recommandation, voire d’une obligation, de version PHP plus récente. Note la version actuelle (visible dans Outils > Santé du site > Informations dans WordPress), et vérifie la version cible attendue par le nouveau core, le thème et les plugins principaux. Un saut de PHP 7.4 à 8.3 peut faire disparaître des fonctions dépréciées utilisées par un vieux plugin — c’est une cause fréquente d’erreur critique après mise à jour. Si tu ne maîtrises pas bien ce sujet, la page sur les directives PHP WordPress détaille les limites (mémoire, temps d’exécution, upload) à surveiller au passage.
4. Désactiver temporairement les mises à jour automatiques
Le temps de l’opération, coupe les mises à jour automatiques de plugins et de thèmes (dans Réglages > Mises à jour automatiques, ou via un plugin comme Easy Updates Manager). L’idée : tu ne veux pas qu’un plugin se mette à jour tout seul pendant que tu es en train de valider manuellement le core, ni qu’une mise à jour automatique se déclenche la nuit qui suit une opération que tu voulais surveiller à froid. Tu réactiveras les mises à jour automatiques une fois que tout est stable, 24 à 48h après.
5. Choisir un créneau à faible trafic
Planifie l’opération en dehors des heures de pointe : tôt le matin, en soirée, ou un dimanche selon ton audience. Si le site vend en ligne ou génère des leads, un incident de dix minutes en pleine journée coûte largement plus cher qu’un créneau creux surveillé de près. Si tu es hébergé chez un prestataire mutualisé, vérifie aussi qu’aucune maintenance serveur n’est prévue au même moment — un cumul des deux événements complique inutilement le diagnostic en cas de souci.
6. Tester d’abord sur un environnement de staging
C’est l’étape la plus souvent zappée, et la plus rentable. La majorité des hébergeurs mutualisés proposent un clone en un clic (staging). Fais la mise à jour complète sur ce clone d’abord : core, PHP, thème, plugins, dans cet ordre ou groupés selon ton cas. Parcours les pages critiques (accueil, panier, formulaire de contact, articles avec blocs Gutenberg ou sections Elementor complexes). Si tout fonctionne sur le staging, tu peux répliquer la même opération sur le site en production avec un niveau de confiance réel — pas un pari.
7. Après la mise à jour : vérifier, et savoir revenir en arrière
Une fois la mise à jour appliquée en production, vérifie dans l’ordre : la page d’accueil, l’admin, le menu, un formulaire (Contact Form 7 ou natif), et si tu es en e-commerce, le tunnel de paiement complet. Si un problème apparaît, ne panique pas et procède par élimination : désactive les plugins un par un (via FTP en renommant leur dossier si l’admin est inaccessible), et compare avec la checklist de site inaccessible. Si rien ne fonctionne, la sauvegarde faite à l’étape 1 permet un retour arrière complet en quelques minutes — c’est exactement pour ce moment qu’elle a été testée.
Pièges courants
| Cause fréquente | Conséquence | Prévention |
|---|---|---|
| Sauvegarde jamais testée | Rollback impossible en urgence | Restaurer la sauvegarde sur un environnement test avant l’opération |
| Plugin abandonné non vérifié | Erreur critique après mise à jour | Vérifier changelog et date de dernière MAJ du plugin |
| Saut PHP trop brutal | Fonctions dépréciées cassées | Monter d’une version majeure à la fois si possible |
| Mise à jour en pleine journée | Perte de ventes/leads pendant l’incident | Choisir un créneau creux, prévenu à l’avance |
| Cache non vidé après MAJ | Ancienne version affichée, bugs fantômes | Vider le cache LiteSpeed ou équivalent après l’opération |
| Pas de staging | Découverte du problème en production | Toujours tester sur un clone avant, même 15 minutes suffisent |
Faut-il mettre à jour PHP et le core WordPress en même temps ?
Non, idéalement pas dans la même opération. Fais-les l’un après l’autre, avec une vérification du site entre les deux : ça isole immédiatement l’origine d’un éventuel problème.
Combien de temps garder l'ancienne sauvegarde après une mise à jour réussie ?
Au moins 7 à 15 jours. Certains bugs (formulaire, tri de produits, comportement d’un plugin) n’apparaissent qu’après plusieurs jours d’utilisation réelle.
Mon hébergeur ne propose pas de staging, comment faire ?
Crée un sous-domaine avec une copie manuelle des fichiers et de la base (via un plugin comme Duplicator), ou utilise un environnement local. C’est plus long, mais ça évite de tester en aveugle sur le site en production.
Puis-je automatiser toutes les mises à jour pour éviter d'y penser ?
Pour les mises à jour mineures de sécurité, oui, c’est même recommandé. Pour les mises à jour majeures (core, PHP, thème), non : elles méritent toujours une vérification manuelle, comme détaillé dans cette checklist.
Une mise à jour majeure bien préparée prend rarement plus d’une heure de vigilance supplémentaire. Un site cassé en pleine production, lui, coûte des heures de diagnostic, parfois des ventes perdues, et souvent une bonne dose de stress évitable. Si cette checklist te semble lourde à gérer à chaque fois, c’est probablement le signe qu’une maintenance régulière par abonnement — avec sauvegardes automatiques testées et mises à jour surveillées — vaut mieux qu’une checklist manuelle répétée à chaque version.
Ce problème, Peechy s'en occupe
Plutôt que de tout gérer seul, confiez votre site à une agence qui s'occupe de tout — hébergement, sécurité, maintenance et corrections. Encore plus simple en abonnement : on règle les soucis avant même que vous les remarquiez.
Confier mon site à Peechy