Plugin cassé après MAJ WordPress : rollback propre

Ton site est blanc ou cassé après une mise à jour de plugin

Ça arrive en quelques secondes : tu cliques sur “Mettre à jour” dans le tableau de bord, la page se rafraîchit, et là — écran blanc, erreur 500, ou le site s’affiche n’importe comment. Le plugin vient de casser quelque chose. Bonne nouvelle : dans 95 % des cas, c’est récupérable sans toucher à une seule ligne de code, et sans perdre tes contenus.

Voici les causes les plus fréquentes, puis les solutions du plus simple au plus technique.

Pourquoi une mise à jour de plugin casse le site

• Conflit de version PHP : le plugin a été mis à jour pour PHP 8.2, ton hébergeur tourne encore en PHP 7.4.
• Conflit avec un autre plugin : deux plugins modifient la même fonction WordPress et la dernière version a changé la priorité des hooks.
• Conflit avec le thème : le plugin s’appuyait sur une fonction de ton thème qui a changé de nom ou disparu.
• Base de données incohérente : la mise à jour modifie le schéma de la BDD mais le script de migration échoue à mi-chemin.
• Limite mémoire PHP dépassée : la nouvelle version du plugin consomme plus de RAM et dépasse le memory_limit de ton hébergement. Si tu veux comprendre comment ajuster cette directive (et les autres comme max_execution_time), l’article sur l’erreur critique WordPress détaille tout ça.

Solution 1 — Désactiver le plugin directement en FTP (si l’admin est inaccessible)

C’est la première chose à faire quand tu ne peux plus accéder à /wp-admin.

1. Connecte-toi à ton serveur via FTP (FileZilla, Cyberduck) ou via le gestionnaire de fichiers de ton hébergeur (cPanel, Plesk, o2switch…).
2. Va dans wp-content/plugins/.
3. Repère le dossier du plugin mis à jour — par exemple woocommerce/ ou elementor/.
4. Renomme le dossier : woocommerce/ → woocommerce_DESACTIVE/.

WordPress ne trouvant plus le dossier, il désactive automatiquement le plugin et retire l’erreur. Ton admin redevient accessible. Renomme ensuite le dossier comme avant si tu veux le réactiver manuellement plus tard.

Variante si tu sais exactement quel plugin est en cause : depuis phpMyAdmin, va dans la table wp_options, cherche la ligne active_plugins, et retire manuellement le plugin de la valeur sérialisée. C’est plus chirurgical mais nécessite d’être à l’aise avec la BDD.

Solution 2 — Revenir à la version précédente du plugin (rollback)

Une fois l’admin accessible, ne réactive pas le plugin cassé — fais-en un rollback.

Option A : WP Rollback (le plus simple)

1. Installe le plugin gratuit WP Rollback depuis l’annuaire WordPress.
2. Va dans Extensions → Extensions installées.
3. Sous le plugin fautif, un nouveau lien “Rollback” apparaît.
4. Clique, choisis la version précédente dans la liste, confirme.

WP Rollback télécharge l’ancienne version directement depuis le dépôt officiel wordpress.org et remplace les fichiers. C’est propre, c’est réversible.

Option B : rollback manuel via FTP

1. Va sur wordpress.org/plugins/{nom-du-plugin}/advanced/ (remplace {nom-du-plugin} par le slug réel).
2. Dans la section “Advanced Options”, trouve le sélecteur de version et télécharge le .zip de la version précédente.
3. Via FTP, supprime le dossier du plugin dans wp-content/plugins/.
4. Décompresse le .zip et upload le dossier proprement.
5. Réactive le plugin depuis wp-admin.

Solution 3 — Restaurer une sauvegarde (quand le rollback ne suffit pas)

Si la mise à jour a corrompu des données en BDD (migrations partielles, tables modifiées), revenir au code seul ne suffira pas. Il faut restaurer une sauvegarde complète.

Avant de restaurer, vérifie deux choses :

• La sauvegarde date d’avant la mise à jour.
• Elle contient à la fois les fichiers et la base de données.

Restaurer via ton hébergeur

La plupart des hébergeurs FR (o2switch, LWS, OVH, Infomaniak…) proposent des snapshots quotidiens dans leur panel. C’est souvent le chemin le plus rapide :

• o2switch : cPanel → JetBackup → sélectionne la date, restaure fichiers + BDD séparément.
• OVH Hosting : Hébergement → Bases de données → Restaurer depuis l’espace client.

Restaurer via un plugin de sauvegarde

Si tu as UpdraftPlus, BlogVault ou All-in-One WP Migration actif, tu peux restaurer depuis leur interface dédiée — en supposant que la sauvegarde est stockée hors serveur (Google Drive, S3, Dropbox).

Note sur la maintenance : si tu n’as pas de sauvegarde récente à ce stade, c’est le signal d’alarme. L’article sur la maintenance d’un site web en 2026 explique pourquoi une sauvegarde automatique quotidienne hors-serveur n’est pas optionnelle.

Solution 4 — Identifier le vrai coupable quand plusieurs plugins ont été mis à jour

Si tu as mis à jour 5 plugins d’un coup (ce qui arrive quand on clique “Tout mettre à jour”), la désactivation en masse est la bonne approche :

1. Via FTP, renomme le dossier wp-content/plugins/ en plugins_backup/.
2. Crée un nouveau dossier plugins/ vide.
3. Recopie les dossiers des plugins un par un, en testant le site après chaque ajout.
4. Quand le site casse, tu as ton coupable.

Lent mais infaillible.

Comment éviter ça la prochaine fois

Un environnement de staging

Un site de staging est une copie de ton site en production, sur une URL privée. Tu y testes les mises à jour avant de les appliquer en prod. La plupart des hébergeurs Premium (Kinsta, WP Engine, Infomaniak) proposent un staging en un clic. Sur un hébergement mutualisé classique, tu peux utiliser le plugin WP Staging.

Les mises à jour contrôlées

• N’utilise jamais “Tout mettre à jour” en une fois — tu perds la traçabilité.
• Mets à jour un plugin à la fois, en testant entre chaque.
• Consulte le changelog avant de mettre à jour : si la version mineure contient “breaking changes” ou “database migration”, sois doublement prudent.
• Active les mises à jour automatiques uniquement pour les correctifs de sécurité, jamais pour les versions majeures.

La sauvegarde pré-mise à jour

UpdraftPlus permet de déclencher une sauvegarde manuelle avant toute mise à jour. Prends cette habitude : 30 secondes de sauvegarde, potentiellement 2 heures de récupération évitées.

Quand passer la main à un pro

Si après le rollback et la restauration de sauvegarde le site est toujours inaccessible — ou si tu n’as aucune sauvegarde exploitable — la récupération devient chirurgicale : analyse des logs PHP (/wp-content/debug.log si WP_DEBUG_LOG est actif), inspection de la BDD, reconstruction partielle. C’est faisable, mais ça demande du temps et une lecture précise des erreurs. À ce stade, comprendre ce que tu peux exiger de ton agence ou prestataire — notamment l’accès aux logs et aux sauvegardes — peut changer radicalement la vitesse de résolution.