SOMMAIRE
Prévue le 8 décembre 2026, WordPress 7.2 clôt une année marquée par le retour à trois versions majeures. La 7.0, publiée en mai, a posé dans le cœur du CMS les fondations de l’intelligence artificielle ; la 7.1, en août, a introduit les styles responsive et les galeries dynamiques. La 7.2 relève davantage de la consolidation : elle prolonge ces chantiers, en referme certains et en laisse d’autres ouverts. La collaboration en temps réel en est explicitement exclue, et les fonctions d’IA continuent de mûrir dans une extension dédiée, qui doit démontrer leur usage réel avant toute intégration.
Le périmètre n’est pas encore figé : la première version candidate, attendue le 17 novembre, en marquera le gel. L’analyse qui suit s’appuie sur la feuille de route officielle et sur les tests publiés de la bêta 3. Elle distingue ce qui est effectivement présent de ce qui reste annoncé.
Le responsive, de la fonctionnalité à l’outil de production
Jusqu’à la version 7.1, adapter l’apparence d’un bloc à une tablette ou à un mobile imposait d’écrire du CSS ou de recourir à une extension. La 7.1 a intégré des états responsive dans l’éditeur, selon une logique descendante : les styles définis pour l’ordinateur s’appliquent aux écrans plus petits tant qu’ils ne sont pas redéfinis pour un appareil donné. Les points de rupture se configurent dans le fichier theme.json du thème (settings.viewport), et le réglage responsiveEditingEnabled permet de retirer cette possibilité aux contributeurs lorsque la cohérence graphique doit rester maîtrisée.
La 7.2 étend ces états à davantage d’outils de mise en forme, fluidifie le passage d’un affichage à l’autre et prévoit surtout une interface publique permettant aux blocs tiers de les prendre en charge. Ce dernier point conditionne l’usage en production : sur un site qui associe blocs natifs et blocs issus d’extensions, le comportement responsive restera hétérogène tant que leurs éditeurs n’auront pas adopté cette interface. La bêta 3 montre par ailleurs que le travail n’est pas achevé. Sur le bloc Galerie, le nombre de colonnes défini en aperçu mobile modifiait la valeur commune à tous les écrans, au lieu de créer une valeur propre au mobile.
Agence Wordpress, dans le cadre des projets que nous réalisons, le responsive reste aujourd’hui pris en charge pour l’essentiel par le thème, et les réglages de l’éditeur servent surtout à des correctifs ponctuels. La fonctionnalité répond pourtant à une attente réelle des clients exigeants en matière de mise en page, qui souhaitent travailler eux-mêmes la présentation de leurs contenus. Il ne s’agit pas de transformer l’éditeur en usine à gaz, mais de reconnaître que l’adaptation aux différents écrans fait partie intégrante de la conception d’un site, et non d’une option de mise en forme. C’est l’une des finalisations que nous attendons de ce cycle.
Les lightbox de galerie, une dette technique ancienne
Nous le constatons dans le cadre de nos réalisations : lorsqu’un visiteur agrandit une image de galerie, la lightbox native affiche l’image au format retenu dans la galerie, souvent recadré ou réduit, et non le fichier d’origine. Le résultat est une image tronquée ou insuffisamment nette, alors que la médiathèque dispose de la version en haute définition. Le sujet n’est pas nouveau : dès l’introduction de la lightbox native en 2023, les contributeurs relevaient que l’image en pleine résolution n’était pas encore transmise à la lightbox.
La feuille de route de la 7.2 mentionne bien les lacunes de la lightbox de galerie, mais parmi les sujets ouverts aux contributeurs, sans responsable désigné. Une correction dans cette version paraît donc peu probable. Sur les sites où l’image porte le propos, qu’il s’agisse de tourisme, de patrimoine, de culture ou d’artisanat, nous devons recourir à une extension tierce, ou à une extension développée en interne, pour compenser ce défaut.
Les identifiants d’API enfin stockés de manière chiffrée
Les extensions qui se connectent à des services tiers (paiement, envoi d’emails, connecteurs d’IA) conservent aujourd’hui leurs clés d’API dans la table des options, le plus souvent en clair. La 7.2 introduit une API dédiée à ces secrets : les fonctions wp_set_secret() et wp_get_secret() enregistrent des valeurs chiffrées, et l’outil de santé du site signale l’absence d’une clé de chiffrement propre à l’installation (WP_SECRETS_KEY). L’interface d’administration est annoncée pour une version ultérieure, et la commande WP-CLI correspondante n’était pas encore disponible lors des tests de la bêta 3.
Sur nos développements sur mesure, ces clés sont aujourd’hui placées hors de la base de données, dans le fichier wp-config.php ou dans des variables d’environnement. Ces solutions protègent les identifiants, mais relèvent de conventions propres à chaque projet. L’API Secrets apporte un mécanisme natif et commun, dont la portée dépendra de son adoption par les éditeurs d’extensions.
L’éditeur, entre héritage des styles visible et relecture intégrée
Plusieurs évolutions visent la compréhension de l’éditeur plutôt que l’ajout de fonctions. Les réglages de chaque bloc affichent désormais les valeurs héritées des styles globaux, à côté des modifications locales : un contributeur peut ainsi comprendre d’où provient la taille ou la couleur d’un titre, et mesurer la portée d’un changement avant de l’appliquer. Les styles globaux couvrent aussi les éléments de formulaire (champs, listes déroulantes, boutons), et une ombre portée rejoint les outils de typographie.
Les notes, introduites avec WordPress 6.9, s’affichent dans la marge du contenu et acceptent des réactions. Le mode suggestion annoncé, qui permettrait de proposer une modification que l’auteur accepte ou refuse, n’était pas encore visible dans la bêta 3. S’il aboutit, il offrira un circuit de relecture intégré, utile lorsque plusieurs intervenants valident un même contenu.
Deux blocs sont par ailleurs au programme : une liste de définitions, destinée aux glossaires et fiches techniques, et la table des matières, expérimentale depuis 2022, retirée de la 7.1 au dernier moment et reconstruite pour être générée côté serveur. Ni l’un ni l’autre n’était enregistré dans la bêta 3.
Performance, sécurité et administration
Moins visibles, d’autres chantiers concernent directement l’exploitation des sites : le remplacement de la concaténation des scripts et feuilles de style par du préchargement, des images responsives mieux adaptées (testables aujourd’hui via l’extension Enhanced Responsive Images), un mode de réauthentification avant les actions les plus sensibles, dont le détail n’est pas encore publié, et une meilleure gestion des mots de passe d’application. Côté administration, les notifications doivent être mieux restituées par les lecteurs d’écran et plus simples à fermer au clavier. Ces évolutions restent à confirmer dans la version finale.
Les metaboxes des extensions, un angle mort de l’éditeur
Les extensions qui complètent l’éditeur, en particulier celles consacrées au référencement comme Yoast SEO ou SEOPress, présentent leurs réglages sous forme de metaboxes, ces panneaux affichés sous le contenu. Ces réglages sont devenus essentiels, mais leur intégration est de plus en plus masquée dans l’éditeur de blocs, où ils ne trouvent pas de place naturelle. Le risque est de voir se multiplier les boutons ajoutés par chaque extension à la barre d’outils, ce qui n’est pas satisfaisant. Il s’agit, à nos yeux, moins d’un bug que d’un véritable sujet d’expérience utilisateur, auquel les prochaines versions devront apporter une réponse. La feuille de route de la 7.2 n’aborde les metaboxes que sous l’angle de leur réorganisation, avec la possibilité de désactiver leur déplacement, et ne prévoit pas de chantier sur leur intégration dans l’éditeur.
Les sujets qui restent sans calendrier
La liste des sujets ouverts aux contributeurs, sans responsable désigné, recoupe plusieurs difficultés que connaissent les équipes chargées de maintenir des sites WordPress : la récupération des blocs invalides, encore souvent bloquante après la mise à jour d’une extension ; la refonte de l’édition des champs personnalisés ; des contrôles de date natifs dans le panneau de publication ; le paramétrage de la page d’accueil entre articles récents et page statique. Leur présence dans la feuille de route signale qu’ils sont identifiés, non qu’ils seront traités à court terme. La migration vers React 19, préparée en coulisses, ne devrait pas non plus aboutir entièrement dans cette version.
Mettre à jour : prérequis et précautions
Les prérequis techniques restent ceux de la 7.1 : PHP 7.4 et MySQL 5.5.5 au minimum, une version récente de PHP demeurant préférable pour la sécurité comme pour les performances. Le report de React 19 limite le risque d’incompatibilité pour les blocs développés sur mesure. Sur les sites dont nous assurons la maintenance, chaque version majeure est d’abord testée en préproduction, et son déploiement attend la publication de la première version de maintenance. Cette règle vaut pour tout site critique : vérifier sur une copie le comportement des extensions principales, puis déployer une fois les premiers correctifs publiés.
Mis à jour le
