Une mise à jour de plugin a cassé le site : le rollback propre

La mise à jour s'installe, la page se recharge, et une fonctionnalité clé ne répond plus : formulaire disparu, tunnel de commande qui boucle, éditeur qui refuse de s'ouvrir. Réponse directe : ne recliquez pas sur « mettre à jour » et ne réinstallez rien par-dessus — vous mélangeriez l'ancien et le nouveau code. La bonne manœuvre est de redescendre proprement à la version qui marchait (via WP Rollback ou par FTP), après avoir sauvegardé la base, puis de remonter en testant. Voici la procédure exacte.

Pourquoi ne pas réinstaller par-dessus ?

Une mise à jour qui casse laisse le site dans un état intermédiaire. Empiler une nouvelle version ou réinstaller le plugin par-dessus superpose deux versions de code et rend le diagnostic bien plus difficile. La règle : on redescend proprement avant de remonter.

Comment revenir à la version précédente ?

La méthode la plus simple pour une extension du dépôt WordPress.org : le plugin gratuit WP Rollback, qui ajoute un lien « Rollback » à côté de chaque extension et réinstalle n'importe quelle version antérieure. En WP-CLI, c'est direct :

# revenir à une version précise
wp plugin install mon-plugin --version=3.4.1 --force

Cette méthode ne couvre que les extensions publiées sur WordPress.org. Pour un plugin premium (ACF Pro, un thème payant, une extension sur mesure), il faut le .zip de la version précédente — d'où l'importance de garder les archives de vos licences.

Le rollback manuel par FTP

Sans WP-CLI ni plugin, la bascule se fait à la main, et un détail compte :

1. Récupérez le .zip de la version qui fonctionnait (dépôt WordPress.org → « Versions avancées », ou votre compte éditeur).
2. Par FTP, renommez le dossier actuel (mon-plugin → mon-plugin_bug) au lieu de le supprimer.
3. Décompressez l'ancienne version à sa place.
4. Rechargez l'admin : WordPress détecte la version restaurée.

Renommer plutôt que supprimer, c'est le filet de sécurité qui vous permet de revenir en arrière si la bascule elle-même tourne mal.

Le piège qui fait perdre des données : la migration de base

Voici l'écueil qu'on voit le plus souvent en intervention. Un rollback de fichiers ne touche pas la base de données. Or certaines mises à jour migrent la base (nouveau format de tables, options réécrites). Redescendre le code sans redescendre la base crée des incohérences silencieuses. Donc, avant toute manipulation, exportez la base :

wp db export sauvegarde-avant-rollback.sql

Un export SQL via phpMyAdmin ou une sauvegarde UpdraftPlus fait aussi l'affaire. Sans lui, un rollback peut laisser le site à moitié cassé, sans retour possible.

Checklist du rollback sûr

• [ ] Base de données exportée avant toute manipulation
• [ ] Dossier du plugin renommé (pas supprimé)
• [ ] Version précédente réinstallée (WP Rollback / WP-CLI / .zip)
• [ ] Site vérifié : la fonctionnalité cassée est revenue ?
• [ ] Cause notée (changelog de la version fautive) avant de retenter

Comment remonter sans reproduire le problème ?

Une fois le site rétabli, ne relancez pas la mise à jour à l'aveugle :

• Sauvegarde complète (fichiers + base) avant tout.
• Mise à jour testée d'abord sur une préproduction ou une copie locale, pas en direct.
• Lecture du changelog : une version majeure signale souvent la rupture de compatibilité qui vous a cassé.
• Une extension à la fois, en vérifiant le site entre chaque.

Questions fréquentes

Un rollback de plugin fait-il perdre des données ?

Le rollback des fichiers ne touche pas la base. Le risque de perte apparaît quand la mise à jour a migré la base : redescendre le code sans la base crée des incohérences. C'est pourquoi on exporte toujours la base avant, pour pouvoir revenir à l'état exact d'avant.

Comment revenir en arrière sans WP Rollback ?

En WP-CLI avec wp plugin install <slug> --version=X.Y.Z --force, ou manuellement par FTP en remplaçant le dossier du plugin par le .zip de l'ancienne version (en renommant l'actuel plutôt que de le supprimer).

Peut-on downgrader un plugin premium ?

Oui, mais seulement si vous avez conservé le .zip de la version précédente (les dépôts premium ne gardent pas toujours l'historique). Gardez systématiquement les archives de vos extensions payantes — c'est ce qui rend un rollback possible.

Faut-il une préproduction pour mettre à jour ?

Idéalement oui, surtout pour les extensions critiques (e-commerce, paiement). Tester la mise à jour sur une copie avant la production évite la panne en direct. À défaut, sauvegardez et mettez à jour une extension à la fois.

Quand faire appel à HelpApp Pro

Quand la mise à jour a migré la base et que le rollback laisse le site à moitié cassé, la remise en cohérence demande de savoir exactement ce que la version a changé — une heure de regard expérimenté évite une journée de tâtonnements. HelpApp Pro reprend ces situations sans refonte. Décrivez le contexte via le devis en ligne, ou consultez notre page bugs CMS.