WordPress non mis à jour depuis des années : partir du principe d'un accès
Même si rien n'est visible, une période non patchée a pu servir. Inspectez comme un incident, puis rattrapez le cœur. Mettre à jour un site encore sale casse plus qu'il ne ferme — les diffs mélangent malware et changelog.
Même si rien n'est visible, une période non patchée a pu servir. Inspectez comme un incident, puis rattrapez le cœur. Mettre à jour un site encore sale casse plus qu'il ne ferme.
Partir du principe d'un accès
Un WP 5.2 ou 4.9 en 2026 a traversé des dizaines de CVE. L'absence de défacement ne dit pas l'absence de backdoor. Traitez comme un WordPress piraté : copie, users, dates, mu-plugins, uploads PHP — puis seulement les mises à jour.
Les sites « ça marche encore, on n'y touche pas » sont le vivier des générateurs pharmacies. Google, lui, y passe.
Un WP 4.9 ou 5.2 en 2026 a traversé des dizaines de CVE. L'absence de défacement ne dit pas l'absence de backdoor. Inspectez comme un incident (copie, users, dates, mu-plugins, uploads PHP) puis seulement les mises à jour. Le bouton « tout mettre à jour » le jour J mélange changelog et payload : vous ne savez plus ce qui vient d'où. Une MAJ majeure sur un site sale produit des 500, des restaurations paniquées, et l'infection dans la restore.
Un WP 4.9 peut avoir un thème enfant de 2016 et Woo 3.x : trois rattrapages, pas un bouton. Le cœur d'abord (zip de la version en place, puis paliers), Woo ensuite seulement si le tunnel est isolé, le thème en dernier si nulled ou mort. Inverser, c'est un vendredi de 500.
Ne pas cliquer « tout mettre à jour » le jour J
Le bouton mélange 80 fichiers cœur, 40 plugins, un thème. Si un payload est dans `functions.php`, la MAJ du parent peut le laisser (enfant) ou, pire, vous ne savez plus ce qui vient du changelog. D'abord zip vs disque sur l'existant, retrait des ajouts, ensuite MAJ sur un arbre propre.
Une MAJ majeure (5.x → 6.x) sur un site sale : 500 partout, restaurations paniquées, infection dans la restore. Supprimer malware.
Inventaire gelé
Listez versions WP, PHP, chaque plugin, chaque thème. Ceux abandonnés : plan de sortie, pas une MAJ fantôme. File Manager, old PHPMyAdmin plugin, Duplicator : dehors. File Manager, Duplicator.
Exportez la liste extensions / thèmes / versions dans un tableur. Marquez abandonné / à jour / inconnu. File Manager, vieux phpMyAdmin, Duplicator installer : dehors dès la copie faite. Cet inventaire est le plan de rattrapage, pas le bouton unique.
Rattraper le cœur après comparaison
Remplacez le cœur par le zip de la version actuelle (celle du site), confirmez propre, puis montez les versions (5.8 → 5.9 → … ou un saut documenté) sur staging si le gap est énorme. Les gros sauts : lisez les notes (Gutenberg, jQuery, blocs).
Remplacez d'abord le cœur par le zip de la version actuellement en prod (celle du site), confirmez que rien n'a cassé, puis seulement montez. Un saut 5.2 → 6.7 d'un coup en prod un vendredi mélange Gutenberg, jQuery et les 500. Staging si le gap dépasse deux majeures.
Les notes de version Gutenberg / jQuery / blocs se lisent avant le saut 5 → 6. Un constructeur ancien peut exiger un intermédiaire. Staging, ou créneau boutique fermée. Le tableur versions est le plan, pas un slide.
Plugins : un par un, ou sortir
Les compatibles : MAJ après le cœur. Les autres : alternative. Trois sliders : un. Un SEO : un. Plugin vulnérable.
Un SEO, un builder, un cache. Pas trois sliders. Chaque MAJ de plugin après le cœur, une par une si le site est fragile, avec une note de ce qui casse. Les compatibles se mettent à jour ; les autres se remplacent. Trois heures de tri évitent un mois de « le site ne ressemble plus à rien ».
Base et Gutenberg
Les contenus classiques survivent. Les builders anciens peuvent se casser. Prévoyez du métier, pas seulement de la sécu. Sauvegarde base avant le saut de version.
PHP en même temps
Un WP 6.x sur PHP 7.2 : non. Montez PHP dans la fenêtre de rattrapage. PHP obsolète.
Puis la routine, vraiment
MAJ mensuelles, moins d'admins, plus de File Manager permanent, PHP uploads interdit. Un site figé cinq ans recommencera.
Ensuite la routine : MAJ mensuelles, moins d'admins, plus de File Manager permanent, PHP uploads interdit, PHP supporté. Un site figé cinq ans recommencera. Guide WordPress, créer un espace.
Woo ancien, Gutenberg, et le prestataire à 99 €
WooCommerce 3.x : même discours, plus le tunnel. Rattrapage plus long (HPOS, templates). Isolez le paiement si doute. WooCommerce. Les contenus classiques survivent à Gutenberg ; les builders anciens se cassent. Prévoyez du métier, sauvegarde base avant le saut.
Un prestataire « MAJ + sécu » à 99 € : demandez s'il compare les fichiers avant. Sinon c'est le bouton. Updraft sur le même serveur déjà infecté n'est pas un filet. Copie hors site.
On n'a jamais eu d'alerte : faites quand même la chasse courte (users, dates, mu-plugins, uploads) puis la MAJ. Créer un espace.
Plan de rattrapage sur deux semaines
Semaine 1 : incident (copie, chasse, comparable). Semaine 2 : cœur de la version actuelle puis paliers, plugins un par un, PHP, File Manager dehors, installer.php dehors. Pas tout le vendredi soir. Woo : tunnel isolé si le gap est énorme. Un tableur versions évite le bouton unique.
Puis la routine mensuelle. Un site figé cinq ans recommencera. Guide WordPress. Créer un espace.