WordPress 7.2 est attendu le 8 décembre 2026. Pour les agences et les PME qui gèrent plusieurs sites, l’enjeu n’est pas de déployer dès maintenant chaque nouveauté repérée dans les annonces. Il s’agit plutôt de distinguer les changements déjà accessibles dans Gutenberg ou les versions de développement, les pistes encore prévues pour la prochaine version et les fonctions qui pourraient finalement être reportées.
Le récapitulatif publié en octobre par le blog officiel des développeurs WordPress met en avant plusieurs évolutions qui méritent une vérification ciblée : les réglages responsive des blocs, les styles des thèmes, l’affichage des galeries, certaines icônes et composants, ainsi que les outils de test de Playground. D’autres éléments, comme la refonte de wp_kses(), restent à suivre avec prudence, car leur arrivée dépend encore des résultats des tests. Voici comment transformer ces annonces en plan de contrôle utile, sans confondre expérimentation et changement déjà prêt pour la production.
Avant tout, distinguer les annonces du logiciel installé
WordPress 7.2 n’est pas encore la version à déployer
À la date de rédaction, le 3 novembre 2026, WordPress 7.2 est encore en préparation. Le calendrier cité dans le récapitulatif d’octobre prévoit une première version candidate le 17 novembre et une sortie finale le 8 décembre. Ces dates sont des repères de planification, pas une garantie que chaque fonctionnalité évoquée sera incluse. La feuille de route précise que les éléments listés sont activement étudiés, sans promettre leur intégration dans la version finale.
Une partie des changements signalés vient de Gutenberg 24.0 et 24.1, le plugin qui reçoit des évolutions de l’éditeur avant leur éventuelle intégration au cœur de WordPress. Une nouveauté visible dans Gutenberg ne signifie donc pas qu’elle est présente sur un site client en production, ni qu’elle sera activée de la même manière dans WordPress 7.2.
Créer un environnement de test maîtrisé
Pour tester sans risque, utilisez une copie de préproduction représentative : même thème, mêmes extensions importantes, mêmes types de contenus et mêmes rôles utilisateurs que sur le site réel. Faites une sauvegarde et évitez de tester une version de développement sur le site public. Si vous souhaitez explorer rapidement une fonction sans préparer un serveur, WordPress Playground peut fournir un environnement temporaire, mais il ne remplace pas un test complet avec l’hébergement, les extensions et les services externes du client.
Le compte rendu officiel recommande de tester avec la version de développement de WordPress et le Gutenberg le plus récent, ou de démarrer une instance Playground. Consultez le récapitulatif des nouveautés développeurs d’octobre 2026 pour vérifier le statut et le contexte des fonctionnalités citées.
Blocs et réglages responsive : vérifier le rendu, pas seulement l’éditeur
Les contrôles personnalisés par taille d’écran
Les états de style responsive introduits dans WordPress 7.1 s’ouvrent davantage aux blocs personnalisés avec Gutenberg 24.1. Des fonctions jusque-là privées deviennent accessibles aux développeurs de blocs, afin de proposer des réglages différents selon le point de rupture. Le récapitulatif mentionne notamment la possibilité de définir une hauteur minimale ou une position différente selon la taille de l’écran.
Pour une PME, l’effet concret dépend de son site : un bloc de bannière, un en-tête ou un bloc maison peut afficher des options nouvelles dans l’éditeur. Mais un réglage disponible ne garantit pas que le résultat est cohérent sur tous les appareils. Vérifiez les pages où ces blocs sont réellement utilisés et les contenus créés par les équipes éditoriales.
- Ouvrez une page représentative sur ordinateur, tablette et téléphone, puis contrôlez les espacements, les hauteurs et l’ordre des éléments.
- Modifiez un réglage dans l’éditeur, enregistrez, rechargez la page et confirmez que le résultat persiste.
- Testez les blocs réutilisés dans des modèles, des compositions et des pages de destination, pas uniquement dans un article vierge.
- Vérifiez qu’un réglage mobile ne crée ni texte masqué, ni débordement horizontal, ni bouton difficile à toucher.
Les supports de style et les ombres de texte
Gutenberg 24.1 active des options de style sur davantage de blocs du cœur : arrière-plans, dégradés, ombres, couleurs de liens ou de boutons, bordures et alignements. Certaines règles CSS écrites spécifiquement pour compenser l’absence de ces commandes peuvent alors entrer en concurrence avec les styles produits par l’éditeur ou le thème. Le risque n’est pas seulement visuel : une règle trop générale peut modifier plusieurs blocs à la fois.
Le support d’ombre de texte devient également plus complet pour les blocs Titre et Paragraphe, avec des préréglages définis par le thème. Contrôlez le contraste et la lisibilité, en particulier sur les textes posés sur une image. Pour les thèmes utilisant theme.json, comparez les styles enregistrés dans le thème avec les options que l’éditeur permet maintenant aux utilisateurs de modifier.
Thèmes, galeries et icônes : traquer les régressions CSS
Des styles plus larges et des classes différentes
Les changements de prise en charge des blocs peuvent rendre une partie de votre CSS personnalisée inutile, mais aussi révéler des conflits. Le billet officiel signale notamment l’ajout de classes liées à la couleur des liens dans les blocs Accordéon, Onglets, Panneau d’onglet et Modèle de publication. Si votre thème applique des règles précises à ces contenus, vérifiez que la spécificité CSS ne masque pas la couleur attendue ou ne détériore pas l’état de survol.
Une autre vérification concerne les icônes de l’interface : environ 330 icônes du cœur adoptent un dessin en traits plutôt qu’en aplats. Une règle CSS qui modifie leur propriété fill peut ne plus avoir l’effet souhaité. Dans les styles d’administration de vos extensions ou de votre thème, inspectez les règles visant les SVG et privilégiez une couleur adaptée au nouveau rendu. Les dépendances de composants liées aux icônes doivent également être mises à jour de façon cohérente.
Le bloc Galerie passe aussi par une variation en grille
Le bloc Galerie dispose d’une variation Grid dans Gutenberg 24.0, tandis que Flex reste le comportement par défaut et que les galeries existantes conservent leur mise en page tant qu’elles ne sont pas converties. Les règles CSS de la galerie sont désormais ciblées selon la classe de mise en page Flex. Un thème qui supposait que ces styles s’appliquaient à toutes les galeries mérite donc un test dans les deux modes.
Sur une page de test, créez une galerie Flex et une galerie Grid, puis examinez les colonnes, le recadrage et le ratio d’image à plusieurs tailles d’écran. Vérifiez aussi les légendes, l’espacement, l’ouverture des images et l’affichage des galeries déjà publiées. Ne modifiez pas toutes les pages d’un client pour tester : une page de préproduction contenant des exemples représentatifs suffit pour repérer les principaux écarts.
Le thème par défaut Ipsum
WordPress 7.2 doit proposer un nouveau thème par défaut nommé Ipsum. Son orientation est celle d’un thème de blog minimaliste, avec des variations de style qui modifient largement l’apparence générale. Cela ne signifie pas que les sites utilisant un thème personnalisé doivent migrer. Pour la plupart des PME, l’intérêt est surtout de vérifier le comportement des thèmes enfants, des modèles de blocs et des contenus dans un thème de référence, si leur maintenance ou leur compatibilité avec le thème par défaut fait partie du projet.
Playground et fonctions à surveiller : des tests plus pratiques
Tester des commandes et les courriels dans Playground
Les nouveautés de Playground mentionnées en octobre comprennent un terminal capable d’exécuter PHP et WP-CLI contre le site lancé, ainsi qu’un outil qui intercepte les messages envoyés par wp_mail() et les affiche dans le navigateur. Cela peut faciliter des essais rapides : vérifier une commande, observer le contenu d’un courriel de notification ou reproduire un problème sans configurer immédiatement un serveur de messagerie de test.
Il existe toutefois des limites importantes. Le terminal ne fournit pas de TTY et refuse les commandes interactives ou de longue durée. L’outil de courriel ne capture que les messages empruntant le chemin sendmail ; un envoi réalisé par SMTP ou par une API externe ne sera pas nécessairement visible. Utilisez donc Playground pour isoler un comportement, puis confirmez-le dans l’environnement technique réel du client.
Garder une attention particulière sur wp_kses()
Le changement le plus sensible pour certaines extensions est la reconstruction envisagée de wp_kses(), le mécanisme de filtrage HTML de WordPress, au-dessus de l’API HTML. Selon les résultats des tests, cette évolution vise WordPress 7.2 ou 7.3. Le nouveau traitement peut normaliser le balisage produit, supprimer le contenu de certains éléments script et style, et rejeter des contenus malformés dans des contextes comme SVG, MathML ou les commentaires.
Si une extension ou un thème compare, stocke ou teste le HTML après assainissement, construisez un test avec des exemples réels et contrôlez les différences de sortie. Ne considérez pas le filtre permettant de rétablir temporairement l’ancien analyseur comme une solution durable : la documentation le présente comme une échappatoire, et non comme un correctif de compatibilité. Tant que la version cible reste incertaine, documentez le risque et suivez les annonces du cycle de développement.
Checklist de préproduction avant WordPress 7.2
Pour organiser un contrôle proportionné, commencez par inventorier les sites et composants concernés : thème maison, blocs personnalisés, extensions développées en interne, styles d’administration et intégrations courriel. Testez d’abord les sites qui utilisent ces éléments, plutôt que de lancer une campagne uniforme sans critère.
- Préparer : réaliser une sauvegarde vérifiée et créer une copie de préproduction à jour.
- Inventorier : noter la version de WordPress, le thème, les extensions critiques et les personnalisations de blocs ou de CSS.
- Tester les blocs : contrôler les réglages responsive, les couleurs, ombres, arrière-plans, galeries Flex et Grid, ainsi que les contenus déjà publiés.
- Tester le thème : comparer les modèles, les classes et les règles CSS, notamment sur les liens et les icônes de l’administration.
- Vérifier les parcours : publier un contenu, envoyer un formulaire, contrôler les notifications, puis tester les parcours de navigation et les pages clés sur mobile.
- Examiner les extensions maison : rechercher les dépendances dépréciées et les traitements HTML qui pourraient être sensibles à la refonte de wp_kses().
- Consigner le résultat : noter l’environnement, les étapes, les anomalies et les corrections, puis refaire les tests après mise à jour.
Encadré pratique : classez chaque anomalie selon son impact. Un défaut d’affichage sur une page secondaire peut être planifié ; un formulaire qui ne transmet plus les demandes, un affichage illisible sur mobile ou un contenu filtré incorrectement doit bloquer la mise à jour du site concerné jusqu’à résolution.
Pour structurer cette démarche, Enovatic accompagne les entreprises en création et évolution de sites web et propose des formations WordPress pour aider les équipes à gérer leur site avec méthode.
Conclusion : anticiper sans précipiter la mise à jour
Les annonces d’octobre donnent aux agences et aux PME des pistes concrètes pour préparer WordPress 7.2 : tester les réglages responsive et les styles des blocs, contrôler les galeries et les icônes, et exploiter Playground pour des essais ciblés. Elles signalent aussi des changements encore conditionnels, en particulier autour de wp_kses(), qui demandent une veille plutôt qu’une conclusion hâtive.
La bonne approche consiste à séparer ce qui est déjà observable dans Gutenberg, ce qui est envisagé pour WordPress 7.2 et ce qui sera confirmé au fil des versions candidates. Préparez une préproduction, testez les fonctions réellement utilisées par vos clients et consignez les résultats. Pour discuter d’un audit ou d’un accompagnement avant la mise à jour, contactez l’équipe Enovatic.
Questions fréquentes
Quand WordPress 7.2 doit-il sortir ?
Le calendrier cité dans le récapitulatif officiel d’octobre prévoit une sortie finale le 8 décembre 2026, avec une version candidate le 17 novembre. Le calendrier peut évoluer : vérifiez les annonces officielles à l’approche de la mise à jour.
Les changements de Gutenberg 24.1 sont-ils déjà dans WordPress 7.2 ?
Pas automatiquement. Gutenberg reçoit des évolutions en amont du cœur de WordPress. Leur présence dans le plugin ne garantit ni leur intégration dans WordPress 7.2 ni leur activation sur votre site en production.
Faut-il adopter le thème Ipsum lors de la mise à jour ?
Non. Ipsum est annoncé comme le nouveau thème par défaut, pas comme une migration obligatoire. Les sites qui utilisent un autre thème peuvent le conserver, tout en testant les éventuelles interactions propres à leur thème et à leurs extensions.
Quels sites doivent tester la refonte de wp_kses() en priorité ?
En priorité, les sites qui utilisent des extensions ou des thèmes personnalisés filtrant du HTML, puis comparent, enregistrent ou testent le résultat. La cible annoncée est WordPress 7.2 ou 7.3 selon l’avancement des essais.
Sources
- developer.wordpress.org — https://developer.wordpress.org/news/2026/10/whats-new-for-developers-october-2026/
Besoin d’un accompagnement sur mesure ?
Nos experts en design, développement web et référencement accompagnent les entreprises belges au quotidien. Découvrez nos services de création de site web, nos formations professionnelles et nos réalisations.
Contactez-nous pour un devis gratuit.
Photo d'illustration : sarah b sur Unsplash.
