Mettre à jour WordPress sans casser son site

Chaque version corrige des failles publiquement documentées. Le jour où le correctif sort, la faille devient connue de tous, robots compris. Les relevés du secteur sont constants : l’essentiel des vulnérabilités signalées concerne les extensions, loin devant le cœur du CMS. Le danger ne vient donc presque jamais de WordPress lui-même, mais des briques ajoutées autour.

S’y ajoutent trois enjeux concrets. La compatibilité : les versions récentes de PHP ne tournent qu’avec du code entretenu. La performance, car chaque version majeure améliore le rendu des pages. La conformité enfin : un site sans correctif est difficile à défendre après un incident touchant des données personnelles.

Le cœur reçoit des versions mineures, correctives et sans danger, et des versions majeures qui font évoluer des fonctions internes. Les mineures s’appliquent automatiquement sans crainte. Les majeures méritent un test préalable : un thème ancien ou une extension abandonnée peut s’appuyer sur une fonction supprimée.

Les extensions restent le poste le plus sensible. Une boutique WooCommerce en cumule souvent vingt à quarante, écrites par des éditeurs différents et de qualité inégale. Le thème pose un problème à part : modifié directement dans ses fichiers, il perd ses personnalisations à la première mise à jour. D’où le recours à un thème enfant ou à un thème sur mesure versionné.

Aucune intervention ne commence sans une sauvegarde fraîche et vérifiée : les fichiers et la base de données, pris au même instant. Une sauvegarde de fichiers seule ne sert à rien si la base a été modifiée pendant l’opération.

Trois points séparent la sauvegarde rassurante de la sauvegarde utile. Elle est stockée ailleurs que sur le serveur du site. Elle est datée et conservée plusieurs jours, pour remonter avant un problème découvert tardivement. Surtout, elle a déjà été restaurée au moins une fois : jamais testée, elle n’est qu’une hypothèse. C’est tout l’objet d’une maintenance préventive régulière, qui contrôle ce filet avant d’en avoir besoin. Mettre à jour WordPress sans lui revient à travailler sans issue de secours.

La préproduction est une copie du site, sur une adresse privée fermée à l’indexation. On y applique les mises à jour en premier, on parcourt les pages clés, on passe une commande de test, on vérifie le rendu sur mobile. Trente minutes de contrôle évitent une journée de panique en production.

À vérifier systématiquement : l’accueil et deux ou trois pages de contenu, le tunnel de commande si le site vend, les formulaires et leur arrivée en boîte mail, et la console du navigateur pour repérer les erreurs JavaScript silencieuses. Si le site dialogue avec une application Symfony ou un outil métier, on contrôle aussi les échanges par API.

Cela arrive, même avec une méthode rigoureuse. Deux réflexes suffisent. Ne pas enchaîner d’autres manipulations, qui brouillent le diagnostic. Puis identifier ce qui a changé en dernier : la cause s’y trouve presque toujours.

En pratique, désactiver la dernière extension traitée et la réinstaller dans sa version précédente résout la majorité des cas. Si l’écran reste blanc et l’administration inaccessible, on neutralise les extensions en renommant leur dossier depuis le gestionnaire de fichiers de l’hébergeur, puis on les réactive une par une. Un diagnostic méthodique vaut toujours mieux qu’une réparation improvisée. Si rien n’y fait, la sauvegarde prend le relais.

WordPress sait appliquer seul ses mises à jour. Faut-il le laisser faire ? Sur un site vitrine simple, automatiser les versions mineures du cœur et quelques extensions de confiance réduit le risque de retard. Sur une boutique WooCommerce ou un site connecté à un outil métier, l’automatisme complet est déconseillé : une mise à jour passée à trois heures du matin, sans personne pour vérifier la commande suivante, coûte vite très cher.

Le compromis tient en trois lignes : automatiser les correctifs de sécurité du cœur, recevoir une alerte pour le reste, traiter les versions majeures lors d’une intervention planifiée. C’est le principe d’un contrat de maintenance WordPress : un rendez-vous mensuel pour mettre à jour WordPress, tester et documenter, plutôt qu’une pile de notifications ignorées.