WordPress 7.2 : les vraies avancées et ce qui reste à finir

La première bêta de WordPress 7.2 est disponible depuis le 20 octobre 2026. La version finale est prévue pour le 8 décembre et, à partir de Beta 1, le cycle entre dans une phase surtout consacrée aux tests et aux corrections. Autrement dit, le périmètre fonctionnel est désormais largement dessiné, même si des ajustements peuvent encore intervenir avant la sortie finale. WordPress 7.2 Beta 1 · calendrier officiel

Cette version contient beaucoup de nouveautés. Toutes n’ont toutefois pas le même poids. Certaines corrigent de vraies limites de l’éditeur ou posent des fondations utiles pour les développeurs. D’autres relèvent davantage du confort, de la finition ou de fonctions dont l’intérêt dépend fortement du type de site.

La question la plus intéressante n’est donc pas seulement « quoi de neuf dans WordPress 7.2 ? », mais plutôt : quelles évolutions vont réellement changer le travail quotidien, et quels angles morts restent encore visibles ?

Le responsive progresse, mais WordPress n’a pas encore terminé le chantier

WordPress 7.1 avait introduit les premiers styles par viewport. WordPress 7.2 élargit ce système : la Galerie peut désormais recevoir un nombre de colonnes, un recadrage et un ratio différents selon la taille d’écran, le réglage de position peut être défini par viewport et une API publique permet aux blocs tiers d’intégrer leurs propres contrôles dans ce mécanisme. Roadmap 7.2 · suivi Gutenberg #80388 · PR Galerie #82003

C’est une amélioration concrète. Pouvoir passer une galerie de quatre colonnes sur ordinateur à deux sur tablette puis une sur mobile répond à un besoin basique qui obligeait encore récemment à bricoler du CSS ou à choisir des blocs spécialisés.

Mais il ne faut pas présenter 7.2 comme l’arrivée d’un système responsive complet.

Le ticket de suivi de l’équipe GutenbergÉditeur de blocs de WordPress (et écosystème associé) pour composer pages et contenus., fermé au moment de Beta 1, indiquait explicitement que tous les contrôles ne seraient pas couverts dans cette version. Le nouveau ticket ouvert le 20 octobre pour poursuivre le chantier liste encore plusieurs zones incomplètes : certaines couleurs, le duotone, des options typographiques, plusieurs réglages de Cover ou Media & Text, la taille des icônes sociales ou encore plusieurs contrôles avancés. Il conserve aussi parmi les tâches ouvertes le remplacement de breakpoints codés en dur par une approche plus modulaire. Suivi responsive après Beta 1 #85243

La limite est donc importante à comprendre : WordPress permet mieux d’adapter des styles aux viewports existants, mais il ne propose pas encore l’équivalent d’un système de breakpoints totalement libre et homogène sur l’ensemble des outils de design.

Même l’interface reste en cours de maturation. Les contributeurs ont encore identifié le besoin de mieux signaler quand l’édition responsive est active et de rendre plus évident le viewport réellement modifié. Gutenberg #80388

Un point mérite en outre de rester sous surveillance : le guide officiel de test de 7.2 demande de tester du CSS personnalisé spécifique aux états responsive, alors que le ticket de suivi ouvert le même jour conserve encore le CSS personnalisé dans la liste des contrôles à prendre en charge. Le ticket précédent indiquait déjà le 7 octobre que ce travail était « in progress » dans la PR #83539. Les sources ne sont donc pas parfaitement alignées sur son état exact au moment de Beta 1. Il vaut mieux considérer cette capacité comme à vérifier dans les builds de 7.2, plutôt que comme définitivement acquise. Guide de test 7.2 · Gutenberg #80388 · PR #83539 · Gutenberg #85243

Les styles globaux deviennent enfin plus compréhensibles

L’une des évolutions les moins spectaculaires visuellement est aussi l’une des plus utiles.

Jusqu’ici, un bloc pouvait hériter d’une couleur, d’une taille de texte ou d’un autre réglage défini dans les Styles globaux sans que cette valeur apparaisse clairement dans son inspecteur. Il était donc facile de ne plus savoir si un réglage venait du thème, des Styles globaux ou d’une surcharge locale.

WordPress 7.2 affiche désormais les valeurs héritées directement dans les contrôles du bloc. Quand une valeur locale est supprimée, le contrôle revient à la valeur globale correspondante. Pour des sites un peu complexes, cette simple amélioration réduit une partie du flou qui s’était installé autour de theme.json et des différentes couches de styles. Guide de test 7.2

Un nouveau filtre permet également de n’afficher dans les Styles globaux que les blocs ayant été personnalisés. Là encore, l’intérêt est surtout opérationnel : retrouver rapidement ce qui a réellement été modifié devient beaucoup plus simple.

La possibilité de styliser les éléments de formulaire depuis les Styles globaux va dans le même sens. Boutons, champs texte, listes déroulantes et labels peuvent recevoir des réglages communs sans passer directement par du CSS ou par une édition manuelle de theme.json. Roadmap 7.2 · Guide de test 7.2

Ce sont des évolutions moins photogéniques qu’une nouvelle animation ou qu’un effet graphique, mais elles touchent à une faiblesse historique de l’éditeur : comprendre d’où vient réellement un style et savoir où le modifier.

WordPress 7.2 ne change pas le problème général des shortcodes dans l’éditeur

Il faut ici distinguer une limite ancienne de ce que la bêta apporte réellement. Ni la roadmap de 7.2, ni le billet Beta 1, ni le guide officiel de test ne présentent une évolution générale du bloc Shortcode. Ce sujet n’est donc pas une faiblesse révélée par la bêta : 7.2 ne change simplement rien au décalage qui subsiste entre l’édition de nombreux shortcodes et leur rendu côté front-end. Roadmap 7.2 · Beta 1 · Guide de test 7.2

La documentation officielle du bloc Shortcode explique son usage, mais ne décrit pas de mécanisme générique permettant de prévisualiser fidèlement dans l’éditeur la sortie produite par n’importe quel shortcode tiers. Documentation du bloc Shortcode

WordPress 7.1 a bien amélioré la situation, mais d’une autre manière : lorsqu’un shortcode enregistré correspond à un bloc connu — par exemple Galerie, Audio ou Vidéo — l’éditeur peut proposer une transformation vers ce bloc. Le shortcode [embed] peut également être converti en bloc Embed. Tests WordPress 7.1

C’est utile pour moderniser du contenu ancien. Ce n’est pas la même chose qu’afficher directement dans l’éditeur le résultat réel d’un shortcode arbitraire fourni par une extension.

Pour une équipe qui construit encore des modèles ou des compositions comprenant de tels shortcodes, le décalage peut donc subsister : l’éditeur représente le mécanisme, mais pas nécessairement le résultat final tel qu’il apparaîtra sur le site.

Il existe bien une piste à plus long terme. Le projet Shortblocks, encore au stade de chantier suivi dans Gutenberg, cherche précisément à créer des remplaçants plus structurés aux shortcodes. Parmi ses principes figure la possibilité d’afficher un placeholder dans l’éditeur puis, lorsque c’est possible, d’en révéler un aperçu rendu. Mais ce projet n’est pas annoncé comme une fonctionnalité de WordPress 7.2 et ne doit pas être présenté comme imminent. Shortblocks : ticket de suivi #73929

Les médias côté navigateur progressent, avec une limite selon le navigateur

WordPress 7.2 étend le traitement des images côté client à la médiathèque. Le navigateur peut redimensionner, compresser ou convertir certaines images avant leur envoi au serveur. Beta 1 · Roadmap 7.2

L’intérêt est moins visible que celui d’un nouveau bloc, mais potentiellement plus important sur des hébergements modestes. Une partie du travail ne dépend plus exclusivement des capacités de traitement d’image du serveur, ce qui peut réduire sa charge.

Il faut toutefois nuancer l’idée d’un comportement désormais homogène partout. Le guide de test de 7.2 cible explicitement les navigateurs Chromium pour le traitement local de formats comme AVIF, WebP ou HEIC et demande, sur Safari et Firefox, de vérifier le repli vers le traitement traditionnel côté serveur. La fonctionnalité améliore donc la robustesse générale du parcours d’upload, mais elle ne repose pas encore sur le même chemin technique dans tous les navigateurs. Guide de test 7.2

7.2 corrige aussi un vieux problème beaucoup plus facile à constater, mais par la voie du traitement côté navigateur : lorsque l’upload passe par ce chemin, les sous-tailles générées à partir de GIF et de WebP animés conservent leur animation, y compris recadrées. Le ticket historique côté serveur, ouvert en 2014, reste en revanche ouvert : rien n’indique que le repli serveur, utilisé notamment sur Safari et Firefox, bénéficie du même correctif. Trac #28474 · Guide de test 7.2

L’administration change sa manière de charger ses ressources

La performance ne se limite pas au traitement des médias. WordPress 7.2 modifie aussi la manière dont l’administration charge ses scripts et ses feuilles de style.

Le billet Beta 1 indique que WordPress cesse de regrouper ces ressources dans de gros fichiers et les charge individuellement afin de mieux profiter du cache du navigateur. Un mécanisme de prefetch anticipe également l’écran d’administration susceptible d’être ouvert ensuite et commence à charger ses ressources en avance, notamment lors des passages entre le tableau de bord, les listes de contenus et l’éditeur. Beta 1 · Trac #57548

C’est une évolution plus technique que spectaculaire, mais elle mérite davantage sa place dans la liste des améliorations structurantes qu’un simple effet visuel. Son gain réel dépendra naturellement du site, du navigateur et du nombre d’extensions qui ajoutent leurs propres ressources à l’administration.

Secrets API : une nouveauté importante que beaucoup d’utilisateurs ne verront jamais

WordPress 7.2 introduit également une Secrets API destinée aux extensions et aux intégrations qui doivent stocker des clés d’API ou d’autres identifiants sensibles. Jusqu’ici, WordPress ne proposait pas de mécanisme de premier niveau spécialement conçu pour cela. Proposition Secrets API · Guide de test 7.2

Cette API utilise notamment le chiffrement pour protéger les valeurs stockées et cherche à éviter leur exposition accidentelle dans des logs, des exports ou certaines réponses API.

Il n’y a pas encore d’écran de gestion dédié des secrets : la proposition renvoie cette interface à une version ultérieure. En revanche, 7.2 n’est pas totalement dépourvu d’interface autour de la fonction : Santé du site affiche déjà des tests dans l’onglet État et des informations de chiffrement dans l’onglet Infos, et la prise en charge par WP-CLIInterface en ligne de commande officielle pour administrer WordPress (MAJ, imports, cron…). fait partie de la version. Guide de test 7.2 · Proposition Secrets API

Pour l’écosystème de plugins, c’est probablement l’une des évolutions les plus structurantes de 7.2.

DataForms : moins spectaculaire aujourd’hui, plus important demain

L’inspecteur des réglages d’un article ou d’une page — statut, visibilité, date de publication, auteur, image mise en avant, extrait, modèle — est en cours de migration vers le système DataForm. Guide de test 7.2

À court terme, l’utilisateur peut avoir l’impression de retrouver surtout une nouvelle présentation de fonctions déjà connues. L’intérêt principal se situe ailleurs : WordPress cherche à uniformiser ses composants d’administration et à fournir une base plus extensible aux extensions.

C’est typiquement le genre d’évolution qui peut sembler secondaire dans une liste de nouveautés, mais qui compte davantage sur plusieurs versions qu’un effet graphique ajouté à un bloc.

Notes : mieux collaborer, mais le mode suggestion reste à confirmer

WordPress 7.2 améliore nettement les Notes : réactions emoji, filtrage, cartes minimisables, bouton Add Note persistant dans la barre d’outils du bloc et possibilité de conserver simultanément les Notes et les réglages du bloc à l’écran. Le guide de test mentionne aussi un travail spécifique sur les couleurs et les contrastes pour l’accessibilitéAccessibilité numérique : rendre les interfaces utilisables par le plus grand nombre (WCAG, sémantique, clavier).. Beta 1 · Guide de test 7.2

Une nuance est importante : la roadmap présentait le mode suggestion, permettant de proposer des modifications à accepter ou refuser, comme la pièce maîtresse de ce cycle. Or cette fonction n’est mentionnée ni dans le billet Beta 1 ni dans le guide officiel de test. Cette absence ne suffit pas à prouver qu’elle ne pourra pas arriver dans 7.2, mais elle interdit de la présenter comme acquise à ce stade. Roadmap 7.2 · Beta 1 · Guide de test 7.2

Il faut également éviter d’y voir l’arrivée d’une édition collaborative à la Google Docs. La roadmap de 7.2 indique explicitement que l’édition collaborative en temps réel n’est pas au programme de cette version, le chantier nécessitant encore des décisions architecturales. Roadmap 7.2

Les Notes deviennent donc plus sérieuses comme outil de revue, mais elles ne transforment pas encore WordPress en éditeur multi-utilisateur temps réel.

Ipsum arrive aussi avec WordPress 7.2

WordPress 7.2 embarque également Ipsum, son nouveau thème par défaut. Le projet le présente comme un thème blocs volontairement minimal, pensé comme une toile de fond à personnaliser plutôt que comme un design fortement préconçu. Roadmap 7.2 · Guide de test 7.2

Nous avons déjà détaillé ce changement et sa portée symbolique dans notre article « Ipsum : WordPress tourne la page des thèmes “Twenty” ».

Et les gadgets ?

Toutes les petites nouveautés ne sont pas inutiles. Leur portée n’est simplement pas la même.

Le nouveau widget On This Day, qui fait remonter d’anciens contenus publiés à la même date, peut être sympathique pour un média ou un site éditorial. Les redirections vers un contenu aléatoire peuvent encourager la découverte. Les ombres de texte, les palettes duotone ou d’autres nouveaux contrôles visuels donnent plus de latitude aux designers. Beta 1

Mais pour un site professionnel, ces fonctions ont moins d’impact structurel que la cohérence des styles, le responsive, la gestion des médias, les performances de l’administration, l’extensibilité de l’interface ou la sécurité des secrets.

C’est probablement la meilleure manière de lire WordPress 7.2 : une version où les progrès les plus importants sont souvent ceux qui rendent le système plus prévisible plutôt que ceux qui ajoutent le plus de boutons.

Une version utile, mais encore loin de clore plusieurs vieux sujets

WordPress 7.2 fait avancer plusieurs chantiers que l’éditeur traîne depuis longtemps. Le responsive devient plus crédible, les Styles globaux sont plus faciles à comprendre, les médias peuvent moins dépendre du serveur dans les navigateurs compatibles et l’administration continue de se structurer autour d’API et de mécanismes de chargement plus cohérents.

Mais plusieurs limites restent visibles.

Le responsive demeure partiel et lié à des contrôles ou breakpoints encore inégalement exposés. À côté de ces nouveautés, 7.2 ne change pas la limite historique du rendu général des shortcodes dans l’éditeur. Et plusieurs chantiers très visibles dans les feuilles de route — comme l’édition collaborative complète, ou le mode suggestion des Notes tel qu’il était présenté en septembre — ne doivent pas être considérés comme acquis sur la seule base de la roadmap.

Ce n’est pas nécessairement un défaut de 7.2. C’est plutôt le signe d’une version de consolidation : beaucoup de briques deviennent enfin plus cohérentes, mais WordPress n’a pas encore terminé la transition entre son héritage historique et l’expérience visuelle qu’il cherche à construire.