WordPress vise à nouveau trois versions majeures en 2026 : premières pistes pour 7.0, IA, admin et PHP

Le rythme des versions majeures de WordPress n’est jamais un sujet purement “calendaire” : il dit beaucoup de l’état du projet, de sa capacité de delivery, et des arbitrages (techniques, humains, parfois juridiques) qui pèsent sur le Core. Lors du dernier Core Committers Check-in (réunion trimestrielle), les core committers et le leadership du projet ont discuté de la cadence 2026, du cadrage de WordPress 7.0, du redesign de l’interface d’administration, et de la place que l’IA pourrait prendre dans la roadmap.

Point clé : l’intention partagée est de revenir à trois versions majeures en 2026. C’est un changement notable par rapport à ce qui avait été annoncé plus tôt dans l’année, quand l’Executive Director Mary Hubbard avait indiqué qu’une seule major sortirait en 2026, en évoquant des “ongoing legal matters” (en lien avec la procédure impliquant WP Engine) et la réduction des contributions d’Automattic au Core.

La discussion s’est tenue sous la Chatham House Rule : autrement dit, on peut relayer les informations et idées partagées, mais sans attribuer les propos à des personnes spécifiques.

Retour à trois versions majeures : ce qu’on sait déjà sur le calendrier 2026

D’après les notes de réunion publiées sur Make WordPress Core, l’intention est de reprendre une cadence à trois releases majeures l’an prochain, avec WordPress 7.0 ciblé pour mars ou avril.

Une sortie en février a été écartée pour des raisons très pragmatiques : cela pousserait Beta 1 au tout début janvier, période où une partie importante des contributeurs est encore en congés. En plus, plusieurs fonctionnalités en cours n’auraient pas été prêtes dans les temps.

Aligner les releases sur des événements “flagship” : idée séduisante, mais pas encore un plan

Le groupe a aussi discuté d’un alignement potentiel des futures versions majeures avec des événements phares (dans l’esprit du lancement de WordPress 6.9 pendant le State of the Word). Sur le papier, c’est attractif pour la communication et la coordination communautaire.

Mais dans les faits, caler une release autour de déplacements, de fuseaux horaires, et surtout de la disponibilité du release squad et des contributeurs ajoute une couche de complexité. Résultat : c’est une possibilité, pas une décision actée, et le sujet est marqué pour discussions ultérieures.

WordPress 7.0 : fonctionnalités envisagées (et ce qui pourrait glisser depuis 6.9)

Plusieurs éléments initialement dans le périmètre de WordPress 6.9 ont été évoqués comme candidats possibles pour 7.0. On retrouve notamment :

• Template activation (activation de templates).
• Le bloc Tabs (Tabs block).
• Des capacités côté client pour l’Abilities API (une API visant à standardiser et exposer des “capacités” utilisables par l’écosystème).
• L’édition de médias côté client (client-side media editing), également mentionnée parmi les pistes.

Cela dit, le sujet qui a pris le plus de place est clairement l’initiative IA : le WordPress AI Client.

Le WordPress AI Client : la brique IA qui pourrait viser le Core

Le WordPress AI Client est présenté comme l’un des quatre “Building Blocks” (briques fondationnelles) de l’AI Team. Et surtout : il est désormais considéré pour une intégration au Core.

Une première version, 0.1.0, est sortie récemment. L’idée : fournir un client natif WordPress, agnostique du provider (c’est-à-dire non lié à un prestataire IA en particulier), que plugins et thèmes peuvent utiliser pour interagir avec des services d’IA.

Techniquement, il s’agit d’une adaptation du PHP AI Client aux conventions WordPress. Concrètement, le client :

• s’appuie sur la WordPress HTTP API (la couche standard de WordPress pour effectuer des requêtes HTTP).
• centralise les clés API via un écran dédié “AI Credentials”.
• gère la sélection de modèles sans obliger les extensions à “hardcoder” (coder en dur) un provider spécifique.

Les prochaines itérations prévues (dans les versions futures du client) incluent :

• le support de l’Abilities API.
• des endpoints REST (REST endpoints) dédiés.
• un Prompt Builder côté client (outil pour construire des prompts côté navigateur / interface).

C’est précisément cet aspect “fondation” qui rend le client IA attractif pour le Core : il crée un cadre commun et encourage l’écosystème à construire sur des bases cohérentes (notamment autour de l’Abilities API). Les notes de réunion résument l’enjeu : placer ces APIs au bon endroit permettrait de débloquer beaucoup de possibilités, autant pour les développeurs que pour les propriétaires de sites.

Contraintes : WordPress veut rester agnostique, et l’intégration “provider-only” ne tiendrait pas

Les committers ont aussi insisté sur un point de gouvernance technique : WordPress “will always remain agnostic”. En pratique, intégrer un modèle spécifique ou ne supporter qu’une partie des services tiers ne serait pas soutenable à long terme.

Des pistes plus long terme ont été mentionnées, notamment l’émergence possible de modèles “machine-based” ou “browser-level” (modèles exécutés localement ou au niveau du navigateur). Mais aucune direction n’a été tranchée durant cette réunion.

Avant de décider : des cas d’usage “WordPress par défaut” à clarifier

Avant toute décision d’intégration au Core, les contributeurs veulent cadrer des use cases clairs dans un “WordPress par défaut”, par exemple :

• rechercher dans la médiathèque des médias correspondant à un sujet précis (reconnaissance/description de contenu).
• générer des newsletters à partir de contenus récents.

Redesign de l’admin : plutôt une modernisation visuelle qu’une refonte totale

Autre point discuté : le redesign de l’interface d’administration WordPress. La consigne transmise est importante : l’objectif ne serait pas une refonte complète, mais plutôt une “fresh coat of paint” – en clair, une modernisation visuelle et un rafraîchissement de l’existant.

Cette précision fait écho à la réunion trimestrielle de juillet, où plusieurs options avaient été évoquées pour tester le redesign :

• le proposer comme expérimentation dans le plugin Gutenberg.
• ou le sortir sous forme de plugin séparé, façon “MP7”, clin d’œil à MP6 (l’approche “feature as a plugin” de 2013 qui a fortement influencé le redesign admin de WordPress 3.8).

Ce chantier s’inscrit dans la Phase 3 : Collaboration de la roadmap Gutenberg. Le travail a été initié dès 2023, lorsque Matías Ventura (Gutenberg Lead Architect) a partagé une vision de modernisation de l’expérience admin, puis a présenté des layouts lors du State of the Word 2023.

À noter : un aperçu précoce du redesign, initialement envisagé en parallèle de WordPress 6.9, a été mis de côté en septembre, après une mise à jour de la roadmap indiquant que ce n’était “no longer planned based on the current state of work”.

À ce stade, il n’y a toujours pas de timeline annoncée pour l’arrivée d’un admin redesign dans WordPress. Et pour mémoire : la dernière grosse mise à jour de l’admin remonte à plus de dix ans, avec WordPress 3.8.

PHP minimum : des “raisons convaincantes” pour viser PHP 7.4, sans décision actée

La réunion a également abordé un sujet récurrent côté Core : relever la version minimale de PHP supportée, avec PHP 7.4 comme cible discutée.

Les arguments avancés sont surtout des limites très concrètes :

• les anciennes versions de PHP forcent WordPress à conserver de la compatibilité, ce qui ajoute du bloat (du poids/complexité) et ralentit le développement.
• PHP 7.4 rapprocherait la codebase d’un typage plus cohérent, et rendrait le code plus facile à comprendre, autant pour les développeurs que pour des systèmes d’IA (analyse, génération, assistance).
• de nombreux SDK IA tiers exigent déjà des versions PHP plus récentes ; garder un minimum trop bas empêche le projet de les utiliser.

L’échange a été cadré comme une recherche d’équilibre : progresser techniquement tout en gardant les utilisateurs “à bord” et en évitant de laisser des sites sur le bord de la route. Aucune décision n’a été prise pendant cette session.

Ce qui doit encore être tranché (suivi annoncé après la réunion)

Dans les éléments de suivi listés à l’issue de la réunion, on retrouve plusieurs chantiers organisationnels et de roadmap :

• proposer des formats de réunion plus ouverts et semi-ouverts.
• publier le planning des releases 2026.
• confirmer les fonctionnalités ciblées pour WordPress 7.0 (et possiblement 7.1).
• évaluer si coordonner les releases avec des événements en présentiel est réellement praticable.