WordPress 7.2 : la bêta et la date de sortie sont déjà calées

Vous avez un site qui tourne, des clients qui appellent, et une pastille rouge de mise à jour majeure qui tombe toujours le jour où vous n’avez pas le temps. Pour WordPress 7.2, la date est déjà posée : le 9 décembre. Vous disposez donc de plusieurs semaines pour préparer le terrain, au lieu de découvrir la nouvelle version en cliquant sans réfléchir.

À lire aussi : WordPress 7.0.4 : une mise à jour de sécurité à ne pas ignorer

Dans cet article, je vous dis ce qui est calé dans le calendrier, ce que la Secrets API annoncée avec cette version implique pour un site d’artisan ou de TPE, et la marche à suivre pour tester la bêta sur une copie sans toucher au site en ligne.

Ce qui est calé pour WordPress 7.2

Deux éléments sont publics à ce stade. Le premier : WordPress 7.2 est attendu le 9 décembre. Le second : une Secrets API est annoncée en approche pour cette version. Tout le reste (liste définitive des fonctionnalités, numéros de bêtas, éventuel report) se précisera au fil du cycle de développement.

Cette date s’inscrit dans une année 2026 chargée pour le cœur de WordPress. La version 7.0 est sortie le 20 mai 2026, suivie de correctifs (7.0.2 en juillet 2026), puis de la version 7.1 dont la feuille de route a été publiée en juin 2026 et la sortie organisée en juillet 2026. Avec 7.2 en décembre, cela fait trois versions majeures sur une même année.

Pour vous, la conséquence est simple : le rythme des majeures s’est resserré. Une politique de mise à jour improvisée, décidée dans l’urgence au moment où la notification apparaît, devient trois fois plus coûteuse qu’avant. Mieux vaut un créneau réservé à l’avance dans l’agenda.

La Secrets API, et ce qu’elle change pour un site de TPE

Une API (interface de programmation) est un jeu de fonctions standard que le cœur de WordPress met à disposition des extensions et des thèmes, pour qu’ils n’aient pas à réinventer chacun leur méthode. Un « secret », dans ce contexte, désigne une donnée d’authentification : clé d’API d’un service de paiement, jeton d’accès à un service d’intelligence artificielle, identifiants d’un service d’envoi d’e-mails.

Aujourd’hui, chaque extension fait à sa façon. Certaines stockent ces clés dans la base de données, parfois en clair, dans une table de réglages accessible à quiconque obtient un accès administrateur ou une copie de la base. D’autres demandent de les écrire dans le fichier de configuration. Une API dédiée dans le cœur vise à unifier cette pratique.

Sans connaître les détails techniques définitifs, une chose est utile dès maintenant : savoir où sont vos clés. Faites la liste des services connectés à votre site (paiement, réservation, facturation, formulaire, générateur de contenu) et repérez, pour chacun, l’écran de réglages où la clé a été collée. Cette liste vous servira le jour où vos extensions migreront vers le nouveau mécanisme.

Une clé d’API volée ne casse pas votre site : elle sert à consommer un service à votre place, souvent à vos frais. Traitez-la comme un moyen de paiement, pas comme un réglage.

Ce que les cycles 7.0 et 7.1 disent de la phase bêta

Une bêta est une version de test publiée avant la sortie officielle, destinée aux développeurs d’extensions, aux agences et aux personnes qui veulent signaler des anomalies. Elle n’est pas prévue pour un site qui reçoit des commandes ou des demandes de devis.

Les deux cycles précédents donnent une bonne idée du tempo. Pour WordPress 7.0, la bêta 1 est arrivée en février 2026, la série est allée jusqu’à la bêta 6 en mars 2026, et la sortie a eu lieu le 20 mai 2026 : plusieurs semaines de test avant la version finale. Pour WordPress 7.1, la feuille de route a été publiée en juin 2026 et quatre bêtas se sont enchaînées en juillet 2026, sur un cycle nettement plus court.

Autre enseignement, plus utile encore : la version .0 n’est jamais la fin de l’histoire. WordPress 7.0.2 est sortie en juillet 2026 pour corriger ce que le cycle de bêtas n’avait pas attrapé. Vous pouvez consulter la feuille de route publiée par l’équipe du cœur pour voir comment ces jalons sont annoncés, version après version.

Si vous voulez le détail des changements déjà en place dans la branche 7, je l’ai documenté dans mon article sur les nouveautés de WordPress 7.0 à tester en priorité.

Tester la bêta sans risquer votre site en ligne

Tester une bêta a un intérêt concret : découvrir en novembre qu’une extension de réservation ou un constructeur de pages ne suit pas, plutôt qu’en décembre avec un formulaire de contact hors service. Voici l’ordre dans lequel je procède.

1. Je crée une copie complète du site sur un sous-domaine de préproduction, fichiers et base de données, non indexable par les moteurs de recherche.
2. Je passe cette copie en version bêta, sans jamais toucher au site de production.
3. Je déroule les parcours qui rapportent : formulaire de devis, page de contact, tunnel de commande, prise de rendez-vous, connexion à l’espace client.
4. Je vérifie l’affichage sur mobile des modèles les plus visités, pas seulement de la page d’accueil.
5. Je note chaque anomalie avec l’extension ou le thème concerné, puis je signale le problème à son auteur.

Une bêta ne se met pas à jour vers la version finale dans de bonnes conditions : la copie de test sert à observer, pas à devenir votre futur site. Une fois le diagnostic posé, je la supprime et je repartirai de la production le jour de la mise à jour réelle.

Si votre hébergeur propose un environnement de préproduction en un clic, utilisez-le : c’est le moyen le plus rapide d’obtenir une copie fidèle sans manipuler de fichiers.

Votre checklist d’ici le 9 décembre

Trois mois, c’est largement assez pour aborder cette majeure sans stress, à condition de ne pas tout garder pour la dernière semaine.

• Vérifiez que vos sauvegardes se déclenchent bien et, surtout, testez une restauration : une sauvegarde jamais restaurée n’est qu’une hypothèse.
• Faites l’inventaire de vos extensions et thèmes, en notant la date de dernière mise à jour de chacun.
• Écartez dès maintenant ce qui n’est plus maintenu, en commençant par les thèmes, souvent oubliés comme je l’explique dans cet article sur les mises à jour de thèmes.
• Contrôlez la version de PHP de votre hébergement et demandez à votre hébergeur ce qu’il prévoit pour décembre.
• Appliquez la méthode que je détaille pour vérifier la compatibilité de vos extensions avant de migrer, elle reste valable pour 7.2.

Réservez enfin un créneau de deux heures dans la semaine qui suit le 9 décembre, en dehors de vos heures d’activité. Une mise à jour majeure lancée à midi entre deux chantiers, sans sauvegarde vérifiée, est la situation qui me vaut le plus d’appels en urgence.

Ce que je ferais cette semaine

Commencez par le plus rapide : ouvrez votre tableau de bord, notez le nombre d’extensions actives et repérez celles qui n’ont pas bougé depuis plus d’un an. Lancez une sauvegarde manuelle et téléchargez-la ailleurs que sur le serveur du site. Ces deux gestes prennent une demi-heure et couvrent l’essentiel du risque.

Ensuite, calez la date : le 9 décembre sert de repère, pas d’obligation. Si votre site vit de ses formulaires ou de ses commandes, un audit WordPress avant décembre vous dira quelles extensions vont poser problème, et dans quel ordre les traiter.

FAQ

WordPress 7.2 sortira-t-il vraiment le 9 décembre ?

C’est la date annoncée pour cette version. Les cycles de développement se décalent parfois de quelques jours quand une anomalie bloquante apparaît pendant la phase de bêtas. Retenez le 9 décembre comme repère de planification, et vérifiez le calendrier officiel en novembre avant de bloquer définitivement votre créneau d’intervention.

Dois-je installer 7.2 le jour de sa sortie ?

Rien ne l’impose. L’historique de la branche 7 montre que des correctifs suivent la version initiale, comme 7.0.2 publiée en juillet 2026 après la sortie du 20 mai. Attendre une à trois semaines, le temps que les auteurs d’extensions publient leurs propres mises à jour, est un choix raisonnable pour un site professionnel.

Faut-il être en 7.1 avant de passer en 7.2 ?

Passer par la version intermédiaire facilite le diagnostic : si quelque chose casse, vous savez quel saut en est la cause. Un site resté en 7.0 qui bascule directement en 7.2 cumule deux séries de changements, donc deux sources possibles de panne. Avancez par paliers, avec une sauvegarde entre chacun.

Comment vérifier qu’une extension suivra ?

Regardez sa fiche : date de dernière mise à jour, version de WordPress déclarée comme compatible, réactivité de l’auteur dans le forum de support. Une extension dont la dernière mise à jour précède la sortie de 7.0 en mai 2026 mérite un test attentif en préproduction, voire un remplacement avant décembre.

Mon site affiche une page blanche après la mise à jour, que faire ?

Restaurez d’abord la sauvegarde pour remettre le site en ligne, puis cherchez la cause à froid sur une copie. Si vous n’avez pas de sauvegarde, désactivez les extensions une par une via l’accès FTP en renommant leur dossier, puis basculez temporairement sur un thème par défaut pour isoler le responsable.