Mettre à jour WordPress vers une version majeure
Ce qui casse réellement lors d’un passage de version majeure — thème, extensions, PHP — et comment le vérifier avant de lancer la mise à jour en production.
Ce qu’une version majeure change réellement
Une version majeure de WordPress ne se limite pas à des correctifs de sécurité : elle peut changer le comportement du cœur, déprécier des fonctions PHP internes, ou modifier profondément l’éditeur de contenu. Deux bascules historiques illustrent bien l’ampleur possible d’un changement majeur : WordPress 5.0 a fait de l’éditeur par blocs Gutenberg l’éditeur par défaut à la place de l’éditeur classique, et WordPress 5.9 a introduit l’édition complète de site avec les thèmes à blocs. Un thème classique continue de fonctionner après 5.9 : ce n’est pas une bascule obligatoire, mais c’est le genre de changement de comportement qu’une version majeure peut introduire sans prévenir un site mal préparé.
Le passage à un nouvel éditeur mérite sa propre méthode, que je détaille sur la page dédiée à la bascule vers Gutenberg. Ici, je m’en tiens à la méthode générale de montée de version, applicable à toute version majeure, passée ou à venir.
Les causes réelles de panne après une montée de version
- Un thème construit sur des fonctions ou des hooks du cœur qui ont changé de comportement, voire disparu
- Une extension qui appelle une fonction PHP dépréciée par le cœur et génère une erreur fatale au lieu d’un simple avertissement
- Un plugin abandonné par son auteur, jamais testé sur la nouvelle version, qui casse silencieusement une fonctionnalité sans message d’erreur visible
- Un changement de comportement de l’éditeur ou de l’API REST qui rend incompatible une personnalisation faite sur mesure
Comment je conduis une montée de version majeure
-
Sauvegarde complète
Fichiers et base de données, avant toute manipulation. C’est la condition pour pouvoir revenir en arrière si le test révèle un problème sérieux.
-
Environnement de test
Je duplique le site sur un environnement séparé, avec la même configuration serveur que la production, avant de toucher à quoi que ce soit.
-
Vérification extension par extension
Je passe en revue chaque plugin actif et le thème : date de dernière mise à jour, compatibilité annoncée, changelog. Un plugin non maintenu depuis longtemps est le premier suspect.
-
Mise à jour sur l’environnement de test
Je lance la montée de version sur la copie, avec le débogage activé, pour voir apparaître les erreurs et avertissements avant qu’ils n’atteignent le site réel.
-
Vérification fonctionnelle complète
Je contrôle l’affichage du site, l’édition de contenu, le tunnel de commande WooCommerce si présent, et les formulaires, avant de valider la bascule.
-
Mise à jour en production
Une fois la copie validée, je reproduis la même mise à jour sur le site réel, à un moment de faible trafic.
Pages liées
-
Vérifier la compatibilité des extensions avant une mise à jour
La méthode pour savoir, avant de cliquer sur « mettre à jour », si un thème ou un plugin va survivre au passage à la nouvelle version.
-
Mettre à jour thème et extensions avant le cœur
L’ordre dans lequel mettre à jour thème, extensions premium et cœur WordPress, et pourquoi l’inverser cause la majorité des pannes constatées.
-
Passer à Gutenberg depuis l’éditeur classique
Ce que la bascule vers l’éditeur par blocs change concrètement, et comment la préparer sans perdre de mise en forme.
-
Préparer une mise à jour majeure
Le guide général de préparation, applicable à WordPress comme à d’autres cœurs logiciels.
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.