Site WordPress cassé après une mise à jour : revenir en arrière sans tout restaurer

Le message de WordPress, « L’extension a bien été mise à jour », confirme seulement que les nouveaux fichiers sont en place. La compatibilité affichée sur l’écran des mises à jour ne garantit pas davantage que votre site fonctionnera, et WordPress précise qu’elle est simplement déclarée par l’auteur de l’extension.

Trouver la mise à jour en cause

WordPress ne garde aucune trace des mises à jour faites : l’écran Tableau de bord, puis Mises à jour, ne montre que celles qui restent à faire. Pour les mises à jour automatiques, ce sont les e-mails envoyés à l’adresse e-mail d’administration du site qui servent de journal :

• « Certaines extensions ont été mises à jour automatiquement », un message qui affirme « Vous n’avez rien de plus à faire. » et indique, pour chaque extension, l’ancienne et la nouvelle version ;
• « Votre site a été mis à jour vers WordPress 7.1 », quand c’est WordPress lui-même qui a changé ;
• « Certaines mises à jour d’extensions ont échoué », qui peut signaler un retour en arrière automatique (nous y revenons plus bas).

Comparez leur heure d’envoi à celle de la panne. Pour une mise à jour faite à la main, il faut s’en souvenir, ou demander à la personne qui l’a lancée.

L’e-mail qui annonce une mise à jour de WordPress oriente aussi la recherche. Sur le forum wpfr.net, un message de février 2025 raconte qu’un soir, l’annonce du passage du site à WordPress 6.7.2 est arrivée par e-mail, et que depuis, le site affiche une erreur 500, une page d’erreur du serveur. La désactivation des extensions, un changement de thème et la restauration de la base de données sont restés sans effet. L’e-mail désignait pourtant la bonne piste. La mise à jour automatique avait laissé les fichiers de WordPress incomplets (la discussion sur wpfr.net), et notre article sur l’erreur 500 explique comment les réparer.

La nature de la panne indique aussi où chercher. Une page blanche ou le message « Il y a eu une erreur critique sur ce site. » signale une erreur dans le code du site, et notre article sur l’erreur critique explique comment trouver l’extension fautive, même sans accès à l’administration. Si la mise en page est déformée sans aucun message d’erreur, commencez par vider les caches, celui de votre extension de cache et celui de l’hébergeur. Une copie de page conservée par le cache peut encore appeler d’anciens fichiers de mise en forme, remplacés par la mise à jour.

Mettre l’extension en cause hors circuit

Désactivez l’extension mise à jour juste avant la panne, ou chacune à son tour si l’e-mail en cite plusieurs. Si le site fonctionne de nouveau, vous avez trouvé l’extension en cause. Trois gestes se ressemblent, sans avoir les mêmes conséquences :

• Désactiver, depuis l’écran Extensions : l’extension s’arrête, ses réglages restent.
• Renommer le dossier de l’extension, dans wp-content/plugins, quand l’administration ne s’affiche plus. Passez pour cela par le gestionnaire de fichiers de votre hébergeur. Rien n’est effacé, et une fois son nom d’origine rétabli, il suffira de réactiver l’extension.
• Supprimer, depuis l’administration : WordPress demande « Confirmez-vous vouloir supprimer … et ses données ? ». La suppression déclenche le programme de désinstallation prévu par l’auteur, qui peut effacer les réglages de l’extension, voire toutes ses données. WooCommerce fait exception : sauf réglage contraire, ses données restent en place. Pour toutes les autres, n’utilisez ce bouton que si vous êtes certain de ne plus avoir besoin de l’extension.

Revenir à la version précédente

Une extension gratuite, publiée sur wordpress.org

1. Sur fr.wordpress.org, ouvrez la page de l’extension, puis le lien « Vue avancée ». Le bloc « Versions précédentes » propose les anciennes versions, avec un avertissement : elles « peuvent ne pas être sûres ou stables ». Choisissez celle d’avant la mise à jour et cliquez sur « Télécharger ».
2. Dans votre administration : Extensions, « Ajouter une extension », puis « Téléverser une extension ». Choisissez le fichier, puis « Installer maintenant ».
3. WordPress répond « Cette extension est déjà installée. », compare les deux versions et vous met en garde. Cliquez sur « Remplacer l’extension actuelle par celle que vous avez téléversée ».
4. Si ses mises à jour automatiques sont activées, cliquez ensuite sur « Désactiver les mises à jour auto », dans la liste des extensions. Sans cela, WordPress la remettra à jour lors d’une de ses vérifications, qui ont lieu deux fois par jour.

L’extension WP Rollback fait la même chose en un clic, mais sa version gratuite ne connaît que les extensions de wordpress.org. Comme le téléversement, elle remet les fichiers de l’ancienne version, mais pas la base de données d’avant (voir plus bas). Ses auteurs déconseillent en outre tout retour en arrière directement sur le site en ligne. Faites-le d’abord sur une copie du site si vous le pouvez.

Une extension payante

Faute de « Vue avancée », l’ancienne version se télécharge depuis votre compte client chez l’éditeur, ou depuis l’extension elle-même, comme le permet Elementor pour sa version Pro. Notez dès maintenant où retrouver vos identifiants de compte chez l’éditeur, pour ne pas avoir à les chercher le jour d’une panne.

WordPress lui-même

Le bouton « Réinstaller la version » de l’écran Mises à jour réinstalle la version actuelle, jamais une plus ancienne. Revenir en arrière demande une sauvegarde, ou un outil en ligne de commande réservé aux techniciens. Mieux vaut d’ailleurs garder la nouvelle version de WordPress et agir sur l’extension qui n’est pas compatible avec elle.

Le piège : la base de données ne revient pas en arrière

Réinstaller l’ancienne version d’une extension rétablit ses fichiers, mais pas les changements que sa mise à jour a faits dans la base de données, où WordPress range vos contenus, vos réglages et vos commandes. Si la mise à jour n’a rien changé dans la base, c’est sans conséquence. Si elle a transformé la façon dont l’extension range ses données, l’ancienne version risque de ne plus s’y retrouver.

Selon la documentation de WooCommerce, revenir à une version plus ancienne peut rendre les données incohérentes si la structure de la base a changé, et il faut alors restaurer une sauvegarde de la base qui correspond à la version visée (documentation WooCommerce, en anglais). WordPress, quand vous téléversez une ancienne version, vous demande aussi de sauvegarder la base et les fichiers avant de poursuivre.

Or, sur une boutique, restaurer la base d’avant la mise à jour efface les commandes, les clients et les mouvements de stock enregistrés depuis. D’où l’intérêt d’une sauvegarde faite juste avant la mise à jour, pas seulement la veille au soir : moins il s’écoule de temps, moins il y a à perdre. Passez aussi une commande de test après chaque mise à jour de WooCommerce ou d’une extension de paiement, comme le recommande la documentation de WooCommerce.

Pourquoi WordPress ne vous a pas protégé

WordPress a pourtant trois filets de sécurité. Aucun ne couvre pleinement le cas qui nous occupe, celui d’une mise à jour qui s’installe correctement puis casse quelque chose. Seul le troisième en rattrape une partie.

• Pour WordPress lui-même, depuis 2013 : si les nouveaux fichiers ne peuvent pas être copiés pendant une mise à jour automatique (disque plein, par exemple), WordPress tente de revenir à la version précédente.
• Pour les extensions et les thèmes mis à jour à la main, depuis WordPress 6.3 : l’ancienne version est mise de côté le temps de l’installation, et remise en place seulement si l’installation échoue. La note des développeurs de WordPress est explicite : cette copie ne servira pas à revenir en arrière après une mise à jour réussie (note officielle, en anglais). Et quand vous cliquez sur « mettre à jour maintenant », dans la liste des extensions, l’extension reste active pendant l’opération. Si la nouvelle version provoque une erreur, vos visiteurs la voient aussitôt.
• Pour les extensions mises à jour automatiquement, depuis WordPress 6.6 : WordPress ouvre votre page d’accueil juste après, et remet l’ancienne version en place si une erreur fatale, c’est-à-dire une erreur grave dans le code, empêche cette page de s’afficher. C’est le seul des trois filets qui agit après une installation réussie, mais il ne concerne que les extensions actives et ne regarde que la page d’accueil. Et, comme après un retour en arrière fait à la main, WordPress retentera la mise à jour à sa vérification suivante.

L’e-mail qui suit un retour en arrière automatique reste prudent. Il vous demande de vérifier votre site, en ajoutant « Il est possible que tout fonctionne. », puis précise que « s’il y a eu une erreur fatale lors de la mise à jour, la version précédente a été restaurée ».

Tout ce qui n’est pas une erreur fatale passe au travers des trois filets. Fin 2024, une règle ajoutée par WordPress 6.7.1 pour l’affichage des images en a ainsi déformé sur certains sites, sans la moindre erreur à détecter.

Le jour où c’est WordPress qui change

La version 7.1 de WordPress est sortie le 19 août 2026. Sur une partie des sites équipés de WP Rocket, une extension payante qui accélère le chargement des pages, elle a provoqué une erreur critique sur tout le site, même quand l’extension était à jour. L’erreur n’apparaissait qu’en présence de certaines autres extensions ou de certains thèmes. L’éditeur a publié un correctif dès le lendemain matin (documentation WP Rocket, en anglais). Le problème était pourtant signalé publiquement depuis le 6 juillet, sur une version de test de WordPress 7.1.

Aucun des trois filets ne pouvait servir. La nouvelle version de WordPress s’était installée sans erreur, et WP Rocket n’avait pas été mis à jour. Sur certains sites, personne n’avait même demandé ce passage à 7.1 (notre article sur WordPress 7 explique pourquoi). Revenir à une version antérieure de WP Rocket n’aurait servi à rien, puisque toutes les versions antérieures au correctif provoquaient la même erreur. En attendant ce correctif, l’éditeur conseillait de désactiver l’extension en renommant son dossier.

Couper les mises à jour n’est pas la solution

Après une mauvaise surprise, la tentation est forte de tout couper. Sur les forums, on conseille parfois d’ajouter une ligne dans wp-config.php, qui contient les réglages principaux du site.

Si une seule extension pose problème, coupez seulement sa mise à jour automatique, comme indiqué plus haut, le temps que l’éditeur la corrige.

Une mise à jour peut aussi être bloquée quand votre hébergement utilise une version trop ancienne de PHP, le langage de programmation de WordPress. Notre article sur WordPress 7 explique comment la vérifier et en changer sans casser le site.

Lors des prochaines mises à jour

Après chaque mise à jour, regardez votre page d’accueil, les pages qui présentent vos services, votre formulaire de contact et votre panier. Faites aussi un envoi de test depuis le formulaire, qui peut s’afficher parfaitement et ne plus rien transmettre.

L’ordre des mises à jour compte moins que votre capacité à annuler celle qui casse. La documentation de WordPress n’en impose aucun. Celle de WooCommerce en propose un pour les boutiques : WooCommerce d’abord, puis ses extensions, le thème et enfin les extensions de paiement.

Questions fréquentes

Pourquoi la mise à jour a-t-elle cassé mon site alors que l’extension se dit compatible ?

Parce qu’une panne peut naître de la rencontre entre deux extensions, ou entre une extension et le thème, et qu’aucun auteur ne peut tester toutes les combinaisons.

Faut-il refaire la mise à jour qui a cassé le site ?

Oui, mais une fois que l’éditeur a publié un correctif, annoncé dans le journal des modifications de l’extension. Réactivez alors ses mises à jour. Sinon, les failles découvertes ensuite dans l’ancienne version ne seront jamais corrigées chez vous.

Comment savoir si une extension se met à jour toute seule ?

Regardez la colonne « Mises à jour automatiques » de la liste des extensions. Si elle affiche le lien « Désactiver les mises à jour auto », elles sont activées. Quand une nouvelle version attend, WordPress précise même le délai, avec la mention « Mise à jour automatique planifiée dans … ».

L’ancienne version plante aussi. Que faire ?

Deux explications sont possibles : la mise à jour a modifié la base de données, ou la panne vient d’ailleurs. Laissez l’extension désactivée et cherchez le fichier en cause dans le journal d’erreurs de votre hébergeur ; notre article sur l’erreur critique explique où le trouver. Si c’est bien l’extension, écrivez à son éditeur. Restaurer la base d’avant la mise à jour règle le premier cas, au prix de ce qui a été enregistré depuis.