Vous l’avez sûrement remarqué, un chiffre apparaît parfois à côté de « Mises à jour » dans le menu de wp-admin.
Chez beaucoup de propriétaires de sites, il reste affiché pendant des semaines, parce que personne ne leur a expliqué ce que ça signifie et ce qui se passe s’ils cliquent, ou pas.
Le délai pèse plus lourd que le rythme
Une faille devient dangereuse à partir du moment où quelqu’un la publie. Elle devient alors publique et accessible aux robots qui parcourent le web à la recherche des sites qui n’ont pas encore appliqué le correctif.
Le rapport State of WordPress Security in 2026 de Patchstack mesure ce délai : environ la moitié des vulnérabilités à fort impact sont exploitées dans les 24 heures qui suivent leur divulgation. Pour les plus ciblées, la première attaque tombe cinq heures après.
Si vous faites le calcul basé sur un cycle hebdomadaire : vous ouvrez votre tableau de bord le lundi. Une faille publiée le mardi vous laisse six jours de fenêtre. Ce qui décide du risque, c’est l’écart entre la publication du correctif et le moment où vous vérifiez les mises à jour à faire.
Donnez-vous une règle :
| Nature de la mise à jour | Délai cible | Pourquoi |
|---|---|---|
| Version mineure du cœur (6.9.1 vers 6.9.2) | Automatique | Corrections de sécurité, risque de casse proche de zéro |
| Correctif de sécurité d’une extension | 24 à 48 h | La fenêtre d’exploitation se compte en heures |
| Version majeure du cœur (6.9 vers 7.0) | 2 à 4 semaines | Le temps que vos extensions publient leur version compatible |
| Extension sans mention de sécurité | Cycle mensuel | Fonctionnalités et corrections de confort |
| Thème | Cycle mensuel | Modifications visuelles à vérifier après coup |
Attention à l’excès inverse. Si vous appliquez une version majeure le jour de sa sortie, vous faites partie de ceux qui en découvrent les régressions, parfois avant même que les développeurs de vos extensions aient publié leurs versions compatibles. Un correctif de sécurité se rattrape en quelques heures, alors que le reste gagne à mûrir pendant que d’autres essuient les plâtres.
Vérifiez aussi que personne n’a désactivé les mises à jour mineures du cœur, qui s’appliquent seules depuis WordPress 3.7. C’est un des premiers réglages que nous rétablissons sur les sites dont nous reprenons la maintenance. Un prestataire prudent les avait coupées des années plus tôt, puis plus personne n’y a touché.
Deux facteurs font varier votre risque
On vous dira que tout dépend du type de site. C’est surtout vrai pour le coût d’une panne. Un blog et une boutique reçoivent les mêmes attaques automatisées, sur les mêmes extensions, et ce qui change entre les deux tient à la prudence que vous avez intérêt à mettre avant de cliquer.
Le nombre d’extensions actives
Chaque extension ajoute du code qui s’exécute à chaque chargement de page. Elles se croisent et se marchent parfois dessus. Nous appelons ça des interférences. Leur nombre grimpe plus vite que celui des extensions, puisque chaque nouvelle venue peut heurter toutes celles qui étaient déjà là.
Avec cinq extensions, vous mettez à jour sans y penser. À partir d’une trentaine, il vous faut une méthode : un ordre de passage, et une vérification entre chaque.
Comptez vos extensions actives, puis celles que vous avez utilisées ce mois-ci. L’écart entre les deux chiffres, c’est du risque que vous portez pour rien.
L’écart avec la version courante
Celui-là passe sous les radars, et c’est lui qui produit les situations les plus coûteuses.
Une extension en retard d’une version se met à jour sans histoire. La même en retard de trois versions majeures ne se met plus à jour, elle se migre : les développeurs ont changé la structure des données entre-temps, retiré des fonctions, modifié des comportements par défaut. Vous cliquez sur le même bouton. Cette fois, la sauvegarde préalable conditionne l’opération.
Passé un certain écart, la mise à jour relève de la refonte technique, avec le budget et le calendrier qui vont avec. Nous voyons arriver des sites à ce stade, où le propriétaire a repoussé pendant deux ans par crainte de casser quelque chose. Vingt minutes par mois auraient suffi à éviter le chantier, mais personne ne le lui avait dit.
Comment le vérifier chez vous
Vous pouvez faire le point vous-même en quelques minutes. Quatre relevés, tous depuis wp-admin, sans rien installer.
- Tableau de bord, puis Mises à jour. Notez le nombre d’éléments en attente. Au-delà de dix, vous avez un retard structurel plutôt qu’un oubli de la semaine.
- Extensions. Pour chaque ligne en attente, comparez le numéro installé et le numéro disponible. Un écart sur le premier chiffre, de 3.2 à 4.1, signale une version majeure, donc une opération à préparer.
- Outils, puis Santé du site. WordPress y liste les composants obsolètes, la version de PHP et les extensions abandonnées. L’écran existe depuis la version 5.2 et peu de gens l’ouvrent.
- Extensions, colonne de description. WordPress signale les extensions sans mise à jour depuis plus de deux ans. Leur développeur a cessé de les suivre, et aucune version corrigée n’arrivera.
Notez ces quatre chiffres quelque part. Vous les comparerez au relevé suivant.
Mettre à jour sans environnement de test
Vous avez sûrement lu qu’il faut d’abord tester sur une préproduction. La plupart des hébergements mutualisés n’en proposent pas, et rares sont les propriétaires de sites qui en configurent une. Voici comment faire avec un accès FTP et rien d’autre.
- Lancez une sauvegarde complète, fichiers et base de données, et vérifiez qu’elle est partie vers un stockage externe.
- Avant de cliquer, notez le numéro de version installé. Écrivez-le quelque part. C’est ce numéro qui vous permettra de revenir en arrière.
- Mettez à jour une seule extension.
- Rechargez la page d’accueil, une page interne, et testez la fonction que l’extension pilote. Un formulaire s’envoie, un panier s’ajoute, une galerie s’affiche.
- Passez à la suivante.
Pour revenir en arrière sur une extension du dépôt officiel : ouvrez sa fiche sur wordpress.org, descendez jusqu’à la section des versions précédentes, téléchargez celle que vous aviez notée. En FTP, renommez le dossier de l’extension dans wp-content/plugins/, puis déposez l’ancienne version à côté. Le site retrouve son état antérieur sans passer par la restauration complète.
Avertissement. Cette manœuvre remet le code en arrière, sans toucher aux données. Si l’extension a modifié sa structure en base pendant la mise à jour, l’ancienne version peut ne pas savoir relire ce qu’elle trouve. Les extensions de boutique et de formulaires entrent dans ce cas. Pour celles-là, la restauration de la sauvegarde reste la seule voie de retour.
Les limites de cette méthode
Le retour à une version antérieure suppose que l’extension vienne du dépôt officiel. Les extensions premium ne publient pas d’archive publique : il vous faut avoir gardé le fichier .zip de la version précédente, ou disposer d’une licence active pour le redemander à l’éditeur. Téléchargez et archivez ce fichier avant chaque mise à jour d’extension payante.
Les hébergements WordPress managés appliquent parfois les mises à jour à votre place et bloquent l’accès FTP à wp-content/plugins/. Le retour en arrière passe alors par leur interface, avec leurs délais et leurs conditions.
Rien de ce qui précède ne s’applique à un site déjà très en retard. Rattraper trente extensions abandonnées depuis deux ans se prépare, se chiffre et se teste sur une copie du site. Dans cet état, une mise à jour lancée depuis le tableau de bord casse le site plus souvent qu’elle ne le répare.
Pour aller plus loin
- Mise à jour WordPress ratée : si vous êtes déjà passé de l’autre côté et que le site ne répond plus.
- Sécurité WordPress : pour situer les mises à jour dans l’ensemble des mesures qui protègent un site.
- PHP 8.x et WordPress : la version de PHP suit la même logique de retard accumulé.
Publié par L’Agence Oueb le 18 juin 2026, réécrit le 18 août 2026, testé sur WordPress 7.03 et PHP 8.3. Chiffres issus du rapport State of WordPress Security in 2026, Patchstack.
