L’onglet est ouvert depuis ce matin. Le chiffre en rouge dans la barre latérale de votre tableau de bord WordPress indique 14, parfois 17, parfois 23. Plugins, thème, core : tout attend. Vous avez noté de le faire « ce week-end » ou « en fin de mois ». Ce réflexe de reporter les mises à jour WordPress en lot mensuel est une habitude héritée d’une époque où les failles mettaient des semaines à être exploitées. En 2024, Patchstack a recensé 7 966 nouvelles vulnérabilités dans l’écosystème WordPress, soit une hausse de 34 % par rapport à 2023. Certaines de ces failles ont été exploitées activement dans les heures suivant leur divulgation publique. Votre planning mensuel ne protège plus rien : il crée une fenêtre d’exposition de 30 jours que les scanners automatisés savent très bien utiliser.
Ce que les chiffres Patchstack 2024 changent à votre routine
96 % des vulnérabilités recensées en 2024 provenaient de plugins, 4 % de thèmes. Le core WordPress lui-même n’a affiché que 7 failles sur l’année, aucune critique. Le risque ne vient donc pas de WordPress mais de ce que vous y avez ajouté : Elementor, WooCommerce, Contact Form 7, WPForms, tous les plugins actifs sur votre site sont des vecteurs potentiels.
Plus préoccupant : parmi les développeurs de plugins notifiés d’une vulnérabilité par Patchstack, plus de la moitié n’avaient pas publié de correctif avant la divulgation officielle. Ce qui signifie que la mise à jour vers la version corrigée ne peut parfois intervenir qu’après que la faille a déjà été rendue publique et donc activement scannée.
La conséquence directe pour votre planning : l’unité de temps pertinente n’est plus le mois. C’est la semaine pour les mises à jour courantes et moins de 48 heures pour les patches de sécurité critiques.
Distinguer les trois types de mises à jour pour calibrer les délais
Traiter toutes les mises à jour WordPress avec la même urgence est une erreur autant que de les ignorer. Une montée de version mineure du core (6.7.1 vers 6.7.2) n’a pas le même niveau d’urgence qu’un patch de sécurité sur un plugin de formulaire exposé à des injections SQL.
- Patches de sécurité critiques (core ou plugin avec CVE publiée) : appliquer dans les 24 à 48 heures. Tester sur environnement de staging si possible mais ne pas bloquer plusieurs jours pour ça.
- Mises à jour mineures de plugins et thèmes (corrections de bugs, améliorations) : hebdomadaire. Choisissez un créneau fixe, par exemple chaque lundi matin et passez les mises à jour en lot.
- Versions majeures du core WordPress (6.6, 6.7, 6.8) : attendre 7 à 10 jours après la sortie officielle, le temps que les plugins majeurs soient compatibles et que les premiers retours de la communauté remontent. Tester obligatoirement sur staging.
Ce découpage par niveau de criticité remplace avantageusement le « je fais tout en même temps le dernier vendredi du mois ». Il réduit les conflits de compatibilité entre plugins parce que vous n’empilez pas 15 mises à jour simultanées et il concentre l’attention là où le risque est réel.
Mettre en place le créneau hebdomadaire sans y passer deux heures
La raison principale pour laquelle les propriétaires de sites WordPress repoussent les mises à jour, c’est la crainte de casser quelque chose. Cette crainte est légitime : un plugin incompatible avec une nouvelle version du core peut faire tomber l’affichage d’une page en quelques secondes. La solution n’est pas d’éviter les mises à jour, c’est de les faire dans le bon ordre et avec un filet de sécurité.
Protocole pour votre créneau hebdomadaire :
- Déclenchez une sauvegarde complète (base de données + fichiers) avant de commencer. Des outils comme UpdraftPlus ou BlogVault permettent de lancer ça en un clic depuis le tableau de bord.
- Mettez à jour le core WordPress en premier s’il y a une mise à jour disponible.
- Mettez à jour les plugins de sécurité et d’authentification en second (Wordfence, iThemes Security, plugin de formulaire de contact).
- Mettez à jour les plugins fonctionnels ensuite (WooCommerce, Elementor, ACF).
- Mettez à jour le thème en dernier.
- Vérifiez visuellement les pages principales du site (accueil, page de contact, boutique si applicable) avant de fermer.
Ce protocole prend 20 à 30 minutes sur un site standard. Si vous avez un environnement de staging (disponible chez la majorité des hébergeurs WordPress managés comme Kinsta, WP Engine ou o2switch), faites d’abord les mises à jour là-bas et synchronisez vers la production seulement si tout est stable.
Automatiser sans déléguer aveuglément
WordPress propose les mises à jour automatiques des versions mineures du core depuis la version 3.7. Depuis la version 5.5, cette logique a été étendue aux plugins et aux thèmes via une interface dédiée dans le tableau de bord. L’activation se fait depuis le tableau de bord ou directement dans le fichier wp-config.php avec la constante WP_AUTO_UPDATE_CORE.
En pratique, activer les mises à jour automatiques pour les patches de sécurité du core est raisonnable : WordPress n’envoie des mises à jour automatiques que pour les versions de maintenance (6.7.1, 6.7.2) et les correctifs de sécurité, jamais pour les versions majeures. Le risque de régression est faible.
Pour les plugins en revanche, l’automatisation est à manier avec plus de prudence. Un plugin majeur comme WooCommerce peut introduire des changements de schéma de base de données dans une mise à jour mineure. Si vous activez les mises à jour automatiques sur tous les plugins, assurez-vous au minimum que vos sauvegardes automatiques sont déclenchées avant (certains hébergeurs le font, d’autres non : vérifiez votre configuration).
La configuration recommandée pour un site vitrine ou un blog : mises à jour automatiques activées pour le core, désactivées ou avec notification email pour les plugins. Vous recevez une alerte, vous décidez. Ce n’est pas du « set and forget » total mais c’est moins chronophage qu’un audit mensuel en catastrophe.
Les erreurs qui transforment une mise à jour en incident
Les problèmes après mise à jour ne surviennent pas au hasard. Ils suivent des patterns prévisibles, et les mêmes reviennent systématiquement.
Mettre à jour simultanément des plugins interdépendants est le plus courant. Si vous mettez à jour WooCommerce et une extension WooCommerce Subscriptions en même temps sans tester la compatibilité, vous cumulez deux variables. Si quelque chose casse, vous ne savez pas lequel des deux est en cause. Faites les mises à jour une par une lorsque des plugins ont des dépendances connues.
Deuxième pattern fréquent : l’absence de sauvegarde vérifiée. Beaucoup de sites ont un plugin de sauvegarde installé mais dont les sauvegardes n’ont jamais été testées en restauration. Ouvrez UpdraftPlus ou votre outil de backup, prenez la dernière sauvegarde disponible et vérifiez qu’elle est complète (taille cohérente, date récente, fichiers de base de données présents). Faites ça une fois par mois.
Moins évident mais tout aussi destructeur : mettre à jour le thème d’un site sur lequel des personnalisations ont été faites directement dans les fichiers du thème parent. Une mise à jour de thème écrase ces modifications. Si vous n’utilisez pas un thème enfant ou un système de hooks, vos personnalisations disparaissent à chaque mise à jour.
Construire votre planning de maintenance 2025-2026
- Quotidien (automatique) : surveillance de l’uptime via un outil comme UptimeRobot (gratuit jusqu’à 50 monitors). Vous recevez un SMS ou un email si le site tombe.
- Hebdomadaire (manuel, 20 minutes) : créneau fixe, protocole décrit plus haut, sauvegarde déclenchée avant.
- Mensuel (manuel, 1 heure) : vérification des performances (temps de chargement via Google PageSpeed Insights), audit des comptes utilisateurs WordPress (désactiver les comptes inactifs), test de restauration de sauvegarde, revue des logs d’erreur si votre hébergeur les expose.
Les grandes versions de WordPress ne rentrent pas dans cette routine. Elles sortent environ trois fois par an. Chacune mérite une procédure dédiée avec test complet sur staging.
Les 7 966 vulnérabilités recensées par Patchstack en 2024 ne distinguent pas les sites selon leur taille : elles ciblent tous les sites WordPress accessibles. Votre site de 500 visiteurs par mois est aussi intéressant pour un scanner automatisé qu’un site à 50 000 visiteurs.
Ouvrez votre tableau de bord WordPress maintenant, déclenchez une sauvegarde et passez les mises à jour en attente.
