Fin octobre
Commencer les essais sur un environnement isolé dès la première bêta et suivre les premières notes techniques.
Traitement en cours…
Évolution du CMS
WordPress 7.2 doit conclure le cycle des versions majeures du CMS en 2026. Sa feuille de route mêle évolutions éditoriales, nouvelles API, sécurité et arrivée du thème Ipsum, mais plusieurs éléments restent à confirmer.
Au 24 septembre 2026, WordPress 7.2 est toujours en développement. La première bêta est attendue entre le 20 et le 22 octobre, avant une version finale actuellement ciblée entre le 8 et le 10 décembre.
La feuille de route publiée le 18 septembre annonce le thème Ipsum, des changements dans l’éditeur, de nouvelles API et plusieurs chantiers de sécurité. Leur présence dans la version finale n’est toutefois pas garantie : l’enjeu immédiat consiste à identifier les dépendances du site et à organiser les tests en préproduction.
WordPress 7.2 doit être la dernière version majeure du CMS publiée en 2026. Son calendrier prévoit quatre bêta, trois Release Candidates puis une sortie finale en décembre. Ces dates restent susceptibles d’évoluer en fonction des tests et des décisions de l’équipe chargée de la version.
| Étape | Date prévue |
|---|---|
| Beta 1 | 20 au 22 octobre 2026 |
| Beta 2 | 27 au 29 octobre 2026 |
| Beta 3 | 3 au 5 novembre 2026 |
| Beta 4 | 10 au 12 novembre 2026 |
| Release Candidate 1 | 17 au 19 novembre 2026 |
| Release Candidate 2 | 24 au 26 novembre 2026 |
| Release Candidate 3 | 1er au 3 décembre 2026 |
| Version finale | 8 au 10 décembre 2026 |
La Beta 1 marquera une étape importante : les efforts devront alors se concentrer principalement sur les tests et la correction des anomalies plutôt que sur l’ajout de fonctionnalités. Les premières Dev Notes destinées aux développeurs commenceront aussi à paraître.
Commencer les essais sur un environnement isolé dès la première bêta et suivre les premières notes techniques.
Vérifier les extensions, les thèmes, les workflows éditoriaux et les intégrations au fil des bêta et des RC.
Valider les composants critiques avec une Release Candidate proche de la version attendue en production.
Déployer seulement après sauvegarde, validation en préproduction et préparation d’un retour arrière.
L’un des changements les plus visibles devrait être l’arrivée d’Ipsum, le thème proposé pour accompagner WordPress 7.2. Pensé comme une toile blanche orientée vers le blogging, il doit fonctionner immédiatement tout en restant largement personnalisable dans le Site Editor.
Ce choix rompt avec la convention annuelle suivie par Twenty Twenty-Two, Twenty Twenty-Three, Twenty Twenty-Four et Twenty Twenty-Five. Les futurs thèmes par défaut pourraient désormais recevoir leur propre nom et évoluer lorsqu’un nouveau design le justifie, plutôt qu’au seul rythme du calendrier.
Ipsum privilégie une présentation minimaliste, plusieurs variations de styles et des modèles destinés à être transformés depuis l’éditeur de site.
La présentation initiale indique que les combinaisons proposées visent la conformité WCAG AA. La revue technique doit néanmoins se poursuivre avant la sortie.
L’apparence et le fonctionnement actuels d’Ipsum ne doivent pas être considérés comme définitifs. Les thèmes blocs et le Full Site Editing placent désormais le thème par défaut dans le rôle d’une base de conception adaptable plutôt que dans celui d’un design figé.
WordPress précise que les fonctionnalités annoncées sont activement développées, sans garantir qu’elles seront toutes intégrées à la version finale. Toute décision technique doit donc être réévaluée à partir des bêta, des Dev Notes et des Release Candidates.
Les Notes, qui permettent de commenter directement des blocs, doivent continuer à évoluer. La feuille de route mentionne des propositions de modifications pouvant être acceptées ou refusées, des réactions par emoji et un accès plus direct depuis la barre d’outils des blocs.
Pour une équipe éditoriale, ces mécanismes peuvent rattacher les remarques au contenu concerné et réduire certains échanges menés en dehors du CMS. Ils ne doivent toutefois pas être confondus avec une coédition simultanée.
L’édition collaborative en temps réel n’est volontairement pas prévue dans la feuille de route de WordPress 7.2. Des choix architecturaux restent à traiter parallèlement au développement de cette version.
WordPress travaille à reconstruire le panneau de réglages des articles et des pages autour de DataForm. L’image mise en avant, l’extrait, le statut, la date, l’auteur, le modèle et les options ajoutées par des extensions doivent progressivement être représentés avec cette fondation commune.
L’objectif est d’obtenir une interface plus cohérente, notamment entre l’inspecteur et l’édition rapide du Site Editor. Pour les développeurs de plugins, cette évolution peut toutefois révéler des intégrations fragiles.
Une extension fondée sur une API publique résiste généralement mieux aux évolutions de l’administration qu’une extension ciblant directement le DOM ou les classes CSS internes.
WordPress a lancé le 17 septembre un appel spécifique aux développeurs. La majorité des principales API d’extension doivent continuer à fonctionner, mais l’ancien emplacement PluginPostExcerpt est déprécié et n’est pas actuellement porté vers le nouvel inspecteur. La migration recommandée passe par PluginDocumentSettingPanel.
Au 23 septembre, les filtres liés au sélecteur de média et à l’image mise en avant avaient également été intégrés dans la branche de développement, avec une arrivée annoncée dans Gutenberg 24.1. Les extensions SEO, éditoriales et de gestion de contenu sont particulièrement concernées.
Le chantier ne se limite pas à la présentation de l’administration. Une Fields API est ciblée pour WordPress 7.2 afin que les extensions puissent enregistrer leurs champs et les afficher dans différentes interfaces sans reconstruire chaque écran séparément.
Le Site Editor doit lui aussi devenir extensible. WordPress prépare une fondation permettant aux plugins d’enregistrer leurs propres écrans et réglages au moyen d’une configuration côté serveur. Les extensions liées au SEO, aux contenus structurés, au design ou aux paramètres globaux pourraient ainsi mieux s’intégrer aux interfaces natives.
L’objectif est de diminuer le code spécifique nécessaire et d’améliorer la cohérence entre les différentes interfaces d’administration.
Les extensions complexes pourraient s’insérer plus naturellement dans l’éditeur de site au lieu de construire systématiquement leur propre page.
Il faudra attendre la bêta et les Dev Notes pour connaître les API effectivement stabilisées. Les développements qui utilisent des fonctions internes ou dépendent de la structure HTML actuelle devront être examinés avec attention.
WordPress 7.2 doit prolonger les possibilités responsives introduites dans WordPress 7.1. La roadmap prévoit d’étendre les contrôles disponibles selon les états responsives et de proposer une API publique pour que les blocs tiers puissent utiliser les mêmes mécanismes.
L’affichage des styles hérités doit également devenir plus lisible. Lorsqu’une couleur est définie globalement pour les paragraphes, l’éditeur devrait mieux montrer cette valeur et la distinguer d’un réglage appliqué à un seul bloc.
L’interface doit faciliter la personnalisation des boutons, champs texte, listes de sélection, labels et de certains états interactifs. Une partie du support existe déjà dans theme.json, mais l’objectif est de rendre ces possibilités accessibles sans modifier directement ce fichier ni ajouter du CSS.
Le bloc Table des matières, longtemps expérimental, doit se stabiliser avec un rendu dynamique côté serveur afin de maintenir la cohérence entre l’éditeur et le site public. Un nouveau bloc Description List doit produire les éléments sémantiques dl, dt et dd, adaptés notamment aux glossaires, définitions et fiches techniques.
WordPress poursuit le traitement d’images dans le navigateur, l’élargissement des formats pris en charge et le travail sur les performances. Le sélecteur de médias doit faciliter la navigation dans les grandes médiathèques, tandis que les galeries devraient gagner de nouvelles possibilités de tri.
L’éditeur de médias doit aussi mieux suivre les relations entre une image originale et ses variantes recadrées. Ces évolutions seront surtout à observer sur des sites éditoriaux disposant de nombreuses ressources.
La roadmap mentionne le remplacement de la concaténation de certains scripts et feuilles de style par des mécanismes de prefetch, ainsi que des améliorations relatives aux images responsives. Aucun gain universel ne peut cependant être déduit de ces travaux.
Les résultats dépendront toujours du thème, des extensions, de l’hébergement, du cache, des images, de la base de données, des scripts tiers et de la configuration du serveur. Les comparaisons devront être menées après stabilisation, dans des conditions reproductibles.
Une Secrets API est proposée pour fournir un mécanisme commun de stockage des clés d’API et autres informations sensibles, avec une prise en charge par WP-CLI. Son interface graphique complète serait prévue pour une version ultérieure.
WordPress explore aussi un « sudo mode », c’est-à-dire une nouvelle authentification avant certaines actions administratives sensibles. Ce chantier n’en est qu’à ses premiers travaux et ne doit pas être annoncé comme acquis pour décembre.
La proposition vise à éviter que chaque extension ne développe seule son propre mécanisme pour conserver des identifiants externes ou des clés d’API.
Le principe du « sudo mode » consiste à demander une confirmation supplémentaire avant certaines opérations particulièrement sensibles.
Les pistes comprennent une meilleure détection des environnements HTTPS ou locaux, des notifications lors de l’ajout d’un mot de passe d’application, des protections supplémentaires selon certains rôles et un travail sur l’attribut SameSite des cookies.
La présence d’une section consacrée à l’intelligence artificielle dans la roadmap ne signifie pas qu’un assistant génératif sera intégré à WordPress 7.2. Les fonctionnalités doivent d’abord démontrer leur adoption et leur utilité dans le plugin AI avant une éventuelle intégration au Core.
Les expérimentations mentionnées portent notamment sur les « abilities », l’adaptateur MCP, WebMCP, les permissions des agents, les embeddings, la recherche sémantique et le streaming. Ces travaux ne sont pas garantis dans WordPress 7.2.
Une version majeure doit être évaluée sur une copie représentative du site. Les parcours métier, les rôles, les extensions critiques et les intégrations externes comptent davantage qu’un simple contrôle visuel de la page d’accueil.
Les extensions SEO, de workflow, de publication, de gestion de champs ou de Custom Post Types devront être vérifiées avec DataForm. WordPress propose déjà un protocole de test avec Gutenberg 24.0 ou une version de développement plus récente.
theme.jsonLes Global Styles, les états responsives et les réglages locaux peuvent interagir avec les personnalisations existantes. Les tests doivent couvrir les principales pages et les composants réutilisés, pas uniquement un modèle.
Un parcours réussi avec un compte administrateur ne garantit pas son fonctionnement pour un éditeur, un auteur, un rôle personnalisé ou une intégration externe. Pour les sites riches en images, il faudra aussi comparer le poids des pages, les Core Web Vitals, les variantes générées, le lazy loading, le temps de chargement de l’administration et la navigation dans la médiathèque.
La préparation peut commencer avant la première bêta par un inventaire de la version de WordPress et de PHP, du thème actif et de son éventuel thème enfant, des extensions, du code personnalisé, des intégrations externes, des tâches CRON, du cache et des sauvegardes disponibles.
C’est également le moment de retirer les extensions inutilisées et de vérifier que les composants indispensables sont toujours maintenus.
Documenter les dépendances, vérifier les sauvegardes et assainir l’installation existante.
Installer WordPress 7.2 uniquement en développement ou en préproduction, suivre les Dev Notes et analyser les erreurs PHP et JavaScript.
Rejouer les scénarios critiques et vérifier que les éditeurs des extensions et thèmes indispensables annoncent leur compatibilité.
Prévoir une sauvegarde vérifiée, un plan de retour arrière et une fenêtre de contrôle après le déploiement.
Il n’est pas nécessaire de suspendre la création ou la refonte d’un site jusqu’en décembre. Si une mise en production est prévue autour de cette période, il est néanmoins pertinent d’intégrer WordPress 7.2 au calendrier de validation.
Le choix d’extensions maintenues, l’utilisation des API publiques, un thème correctement développé, une préproduction fidèle et une procédure de mise à jour reproductible restent les meilleures protections contre les évolutions futures du CMS.
WordPress 7.2 s’annonce davantage comme une étape de maturation de l’éditeur et de ses fondations techniques que comme une version articulée autour d’une seule fonctionnalité spectaculaire. Ipsum sera probablement sa nouveauté la plus visible, mais DataForm, les API destinées aux plugins, l’extensibilité du Site Editor et les travaux de sécurité peuvent avoir davantage d’effets sur les projets professionnels.
La stratégie la plus prudente consiste à suivre la stabilisation de la version, à lire les Dev Notes et à préparer des tests représentatifs. La roadmap ne doit pas être traitée comme la liste définitive de ce qui sera livré en décembre.
DÉVELOPPEMENT WEB
Migration PHP, mise à jour de CMS ou évolution de framework : identifiez les points de compatibilité et validez les parcours essentiels avant la mise en ligne.
Saisissez au moins 2 caractères pour lancer la recherche.