L’essentiel à retenir ℹ️
Officiellement, seule la dernière version de WordPress est supportée : la 7.1.4, sortie le 28 octobre 2026. Par courtoisie, l’équipe sécurité rétroporte encore les correctifs du cœur jusqu’à la branche 4.7 : le même jour sont sorties la 7.0.8, la 5.8.19 ou la 4.7.39. Les branches 3.7 à 4.6 ne reçoivent plus rien depuis décembre 2022 et juillet 2025. Une version de WordPress obsolète reste exposée par ses extensions, son thème et PHP, que ces rétroportages ne couvrent pas. Repérez votre version dans Tableau de bord > Mises à jour, puis migrez par paliers sur une copie de test.
Votre site affiche encore « Version 5.8 » en bas de l’administration, et tout fonctionne ? Si la réponse est oui, cet article est pour vous. Le 28 octobre 2026, WordPress a publié la 7.1.4 avec 22 correctifs de sécurité. Le même jour sortait la 5.8.19, pour une branche lancée à l’été 2021.
Rassurant ? En partie seulement. Je vous explique ce que ces correctifs couvrent vraiment sur une version de WordPress obsolète, pourquoi les mises à jour automatiques vous laissent coincé, et comment rejoindre la version actuelle sans tout casser.
Branche, version majeure, version mineure : de quoi parle-t-on ?
Un numéro comme 5.8.18 se lit en deux morceaux. Les deux premiers chiffres (5.8) désignent la branche, c’est-à-dire la version majeure, celle qui apporte de nouvelles fonctions. Le dernier compte les versions mineures : maintenance et sécurité, sans nouveauté visible. Passer de 5.8 à 5.9 change de branche, passer de 5.8.17 à 5.8.18 non. Tout le reste de l’article découle de cette distinction.
Votre ancienne version reçoit-elle encore des correctifs ?
La règle officielle tient en une phrase, répétée dans chaque note de version : seule la version la plus récente de WordPress est activement supportée. Tout le reste relève de la courtoisie. Quand une faille du cœur est corrigée, l’équipe sécurité reporte le correctif « si nécessaire » vers les anciennes branches encore éligibles, aujourd’hui jusqu’à la 4.7. Aucune durée n’est garantie.
Concrètement, au 28 octobre 2026, ça donne trois situations :
- Branche 7.1 : la seule supportée. Version à jour : 7.1.4.
- Branches 4.7 à 7.0 : correctifs de sécurité du cœur par courtoisie. Le 28 octobre 2026, chacune a reçu sa version corrective (7.0.8, 5.8.19 ou 4.7.39 par exemple).
- Branches 3.7 à 4.6 : plus aucun correctif. Les 3.7 à 4.0 ont été abandonnées le 1er décembre 2022, les 4.1 à 4.6 en juillet 2025.
Motif invoqué les deux fois : moins de 1 % des sites concernés, pour un rétroportage qui mobilisait l’équipe sécurité à chaque alerte. Soyons clairs, rien n’empêche la même décision pour la 4.7 et les suivantes. Aucune annonce en ce sens à ce jour, mais je ne parierais pas un site client là-dessus.
Ce que ces correctifs ne couvrent pas
Un rétroportage ne touche que le cœur de WordPress. Vos extensions et votre thème suivent leur propre calendrier, et leurs auteurs ciblent les versions récentes. En pratique, la plupart des alertes de sécurité que je vois passer concernent des extensions, pas le cœur. PHP non plus n’est pas couvert : une branche 4.7 corrigée tourne toujours sur des versions de PHP abandonnées depuis des années. Et seuls les correctifs de sécurité redescendent, pas les corrections de bugs.
Au passage, les branches anciennes ne reçoivent pas toujours tous les correctifs. La 7.1.4 corrige 22 failles, la 5.8.19 n’en reprend que six et la 4.7.39 deux. C’est logique, puisque le correctif n’est reporté que là où la faille existe. Ce que la branche actuelle apporte en plus est détaillé dans mon bilan de WordPress 7.1.
Trouver votre version exacte
Trois endroits suffisent :
- Tableau de bord > Mises à jour : la page indique votre version et celle qui est disponible.
- Le pied de page de l’administration : en bas à droite de chaque écran, la mention « Version » suivie du numéro complet.
- Le bloc D’un coup d’œil du tableau de bord, qui affiche la version et le thème actif.
Si vous avez un accès SSH, WP-CLI répond en une ligne :
# Affiche la version de WordPress installée
wp core version
# Ajoute la version de la base de données et du paquet TinyMCE
wp core version --extraAdministration inaccessible et pas de SSH ? Ouvrez par FTP le fichier wp-includes/version.php : la variable $wp_version contient le numéro.
Pourquoi les mises à jour automatiques ne vous sortent jamais de votre branche
« Mon site se met à jour tout seul, donc il est à jour. » C’est le malentendu que je rencontre le plus souvent. Par défaut, WordPress installe automatiquement les versions mineures (maintenance et sécurité), mais pas les versions majeures sur les sites installés avant WordPress 5.6. Votre site passe donc de 5.8.17 à 5.8.18 sans vous demander votre avis, puis reste en 5.8 pour toujours.
Les installations neuves depuis la 5.6 ont les mises à jour majeures activées d’office. Mais un réglage peut les avoir coupées : la constante WP_AUTO_UPDATE_CORE dans wp-config.php (la valeur 'minor' limite aux versions mineures, false bloque tout), une extension ou votre hébergeur. Le cas des extensions est traité à part dans mon guide sur les mises à jour automatiques des plugins.
Dernier verrou, le plus sournois : PHP. Si votre serveur tourne sur une version de PHP trop ancienne, l’écran des mises à jour vous l’annonce et refuse le passage à la version récente.
Le vrai nœud du problème : PHP
WordPress 7.1 exige au minimum PHP 7.4, un seuil relevé avec la 7.0. Le site officiel recommande PHP 8.3 ou plus récent, et précise que PHP 7.4 est en fin de vie. La 7.1 est donnée compatible de PHP 7.4 à 8.5.
Ce minimum ne garantit rien côté sécurité. Le projet PHP ne publie plus de correctifs pour les versions antérieures à PHP 8.2. Les failles PHP2Shell du 21 octobre 2026 n’ont été corrigées que dans PHP 8.2, 8.3, 8.4 et 8.5. Un site en PHP 7.4 ou 8.1 reste donc exposé, même avec un WordPress à jour.
À l’autre bout, les vieilles branches n’ont été testées qu’avec les PHP de leur époque. La 4.7 s’arrête à PHP 7.1, la 5.8 à PHP 8.0. Ça pique dans les deux sens. Votre hébergeur retire PHP 7.x ? Le vieux site risque l’erreur critique. Vous restez en PHP ancien ? La mise à jour de WordPress vous est refusée. La sortie passe donc par une montée alternée : un peu de WordPress, un peu de PHP, et ainsi de suite.
Migrer par paliers : la méthode
Techniquement, WordPress sait sauter de la 3.7 à la dernière version en un clic. La documentation officielle conseille pourtant de monter par étapes dès que l’écart dépasse deux versions majeures, pour limiter les risques sur la base de données. Elle découpe le trajet en paliers : 3.7 à 4.0, 4.1 à 4.8, 4.9 à 5.2, 5.3 à 6.2, 6.3 à 6.8. Voici l’ordre que je suis :
- Sauvegarde complète (fichiers et base), puis vérification qu’elle se restaure. Ma méthode est dans le guide pour sauvegarder un site WordPress.
- Copie de test (staging, préproduction en français) : jamais de saut de branches directement sur le site en ligne.
- Inventaire des extensions et du thème : pour chacun, la date de dernière mise à jour et les versions de WordPress et de PHP exigées. Une extension abandonnée depuis 2020 se remplace avant la migration, pas après.
- Montée par palier : dernière version mineure de chaque palier, mise à jour de la base, puis extensions et thème, puis contrôle des pages clés, des formulaires et du journal d’erreurs.
- Montée de PHP entre deux paliers, dès que la version de WordPress atteinte le supporte.
- Bascule en production une fois la copie de test arrivée en 7.1.4 sans erreur, puis activation des mises à jour majeures automatiques.
Pour un site en 5.8, ça donne par exemple : 5.8 sous PHP 7.4, puis 6.2, puis 6.8, passage en PHP 8.3, et enfin 7.1.4. Sur la copie de test, WP-CLI fait le travail palier par palier :
# Sur la copie de test uniquement, après sauvegarde
# Palier 1 : dernière version de la branche 6.2
wp core update --version=6.2.15
wp core update-db
# Palier 2 : dernière version de la branche 6.8
wp core update --version=6.8.12
wp core update-dbLes numéros de dernière version de chaque branche figurent sur la page des versions de WordPress.org. Pour le déroulé détaillé d’une mise à jour (prérequis, désactivation des extensions, retour arrière), je ne vais pas me répéter : tout est dans mon guide de la mise à jour WordPress sans casser votre site.
Ce que je ferais à votre place
Si votre site est en 4.6 ou avant, c’est une urgence : il ne reçoit plus aucun correctif. Entre 4.7 et 7.0, vous êtes protégé sur le cœur, par courtoisie et pour une durée inconnue, et pas sur le reste. Je ne considère pas ça comme une stratégie. Une faille du cœur comme celle de la 7.0.4 via Imagick rappelle que la version à jour reste la seule vraiment suivie.
Trois actions pour cette semaine : notez votre version exacte et celle de PHP (dans Outils > Santé du site > Infos), faites une sauvegarde que vous savez restaurer, puis planifiez la montée sur une copie de test. Et si je ne devais garder qu’un conseil : commencez par l’inventaire des extensions, car c’est presque toujours là que la migration coince.
Foire aux questions
Non. L’équipe sécurité de WordPress a cessé de corriger les branches 4.1 à 4.6 en juillet 2025, et les branches 3.7 à 4.0 depuis le 1er décembre 2022. Seules les branches 4.7 et suivantes reçoivent encore des correctifs du cœur, par courtoisie.
Non. Ils ne concernent que les fichiers du cœur de WordPress. Les extensions et les thèmes dépendent de leurs auteurs, qui visent les versions récentes de WordPress et de PHP. Un site resté sur une vieille branche finit souvent avec des extensions qui ne se mettent plus à jour.
C’est techniquement possible, mais la documentation officielle conseille de monter par paliers dès que l’écart dépasse deux versions majeures. Le saut direct échoue aussi si votre PHP est inférieur à 7.4, minimum exigé par WordPress 7.1. Testez toujours sur une copie du site.
Parce que les mises à jour automatiques activées par défaut sur les sites installés avant WordPress 5.6 ne concernent que les versions mineures, à l’intérieur de la même branche. Le passage à une version majeure doit être activé dans Tableau de bord, Mises à jour, ou lancé à la main.
Personne ne le sait, aucune date n’est annoncée. L’équipe sécurité a déjà coupé les branches 3.7 à 4.0 en décembre 2022, puis 4.1 à 4.6 en juillet 2025, quand elles pesaient moins de 1 % des sites. Considérez que l’arrêt peut tomber à chaque nouvelle version.
WordPress.org recommande PHP 8.3 ou plus récent. Le minimum technique reste PHP 7.4, mais le projet PHP ne publie plus de correctifs de sécurité pour les versions antérieures à 8.2. Vérifiez la vôtre dans Outils, Santé du site, Infos, Serveur.
Oui. Quand une version mineure est disponible, l’écran Outils, Santé du site la classe en problème critique, avec un badge Sécurité. Une version majeure disponible apparaît seulement en amélioration recommandée, ce qui explique que beaucoup de sites restent bloqués sur leur branche.
Toutes les versions sont archivées sur la page Releases de WordPress.org. Elles servent à reconstruire une copie de test ou à monter par paliers, pas à installer un site neuf : une branche ancienne n’est plus suivie que par courtoisie, et pas du tout avant la 4.7.
