WordPress 7.0 sort le 9 avril 2026 et franchit un cap décisif dans la Phase 3 de Gutenberg — la collaboration. Nouveautés majeures : co-édition en temps réel via Yjs (intégrée au core), Notes améliorées avec @mentions, Data Views modernisées, overlays de navigation personnalisables, bloc Breadcrumb natif, pseudo-classes dans theme.json, Interactivity API watch(), connecteurs IA natifs (OpenAI, Claude, Gemini), éditeur toujours en iframe, et PHP 7.4 minimum. Après une année 2025 ralentie par le conflit Automattic/WP Engine, cette version remet le projet sur les rails.
Pas le temps ? Faites-le analyser par l'IA
WordPress 7.0 sort le 9 avril 2026. Après une année 2025 agitée par le conflit juridique entre Automattic et WP Engine — même si les contributions au core n'ont pas réellement faibli (WordPress 6.8 a été livré dans les temps), cette version concrétise la Phase 3 du projet Gutenberg — celle qui transforme WordPress d'un outil d'édition solo en plateforme collaborative. La Beta 1, disponible depuis le 20 février, confirme l'ampleur du chantier : édition en temps réel multi-utilisateurs, infrastructure IA native, refonte progressive de l'administration, et montée en version PHP. Voici ce que WordPress 7.0 change concrètement pour les développeurs, les agences et les utilisateurs finaux.

Pourquoi WordPress 7.0 arrive avec un an de retard ?
Le calendrier initial prévoyait trois releases majeures en 2025 : WordPress 6.8 en avril, 6.9 en août, et 7.0 en novembre. Deux sur trois ont finalement vu le jour — mais avec du retard et des ambitions revues à la baisse. Le conflit entre Matt Mullenweg et WP Engine a absorbé une énergie considérable au sein de la communauté. WordPress 6.8 "Cecil" est sorti dans les temps en avril, tandis que 6.9 "Gene" a glissé d'août à décembre. Quant à WordPress 7.0, initialement prévu en novembre, Mary Hubbard, directrice exécutive du projet, a confirmé son report à 2026.
Automattic a parallèlement réduit ses contributions au core WordPress de près de 4 000 heures par semaine à 45 heures entre janvier et mai 2025 — un coup dur quand on sait que l'entreprise représente historiquement l'un des plus gros contingents de contributeurs. Malgré ce contexte, WordPress 6.9 "Gene" est sorti le 2 décembre 2025 avec des avancées concrètes : les Notes pour la collaboration asynchrone dans l'éditeur, l'Abilities API (système de permissions lisible par les machines et les agents IA), le bloc Accordion natif, un Command Palette élargi, et plus de 30 corrections d'accessibilité. Pas la release transformatrice initialement espérée pour l'été, mais bien plus qu'un simple correctif technique.
Ce retard a paradoxalement permis à WordPress 7.0 d'arriver plus mature. Les fonctionnalités ont eu le temps de décanter. Le plan publié par Matías Ventura, architecte principal de Gutenberg, positionne cette version comme un "point de rassemblement" pour les contributeurs plutôt qu'une promesse figée — une approche plus réaliste que les roadmaps ambitieuses du passé.
Phase 3 : la collaboration au cœur de WordPress 7.0
WordPress 7.0 franchit un cap décisif dans la Phase 3 du projet Gutenberg, dont les travaux ont débuté dès 2023 et les premières fonctionnalités (les Notes) ont été livrées dans WordPress 6.9, poursuivant une histoire entamée en 2003. Après le Block Editor (Phase 1, WordPress 5.0) et le Full Site Editing (Phase 2, abouti dans WordPress 6.3), cette troisième phase vise un objectif précis : faire de WordPress une plateforme où les équipes travaillent ensemble nativement, sans recourir à Google Docs pour la rédaction ou Slack pour les retours.
L'édition en temps réel : promesse et réalité technique
La fonctionnalité phare de WordPress 7.0, c'est l'édition collaborative en temps réel — à la manière de Google Docs. Plusieurs utilisateurs modifient simultanément le même article, voient les curseurs des autres, et observent les changements apparaître instantanément. Fini le "Cet article est verrouillé par un autre utilisateur" — la collaboration démarre automatiquement dès qu'un second rédacteur ouvre le même contenu.
Techniquement, WordPress s'appuie sur Yjs, une bibliothèque CRDT (Conflict-free Replicated Data Types) dont l'auteur, Kevin Jahns, est sponsorisé par Automattic. Le choix des CRDTs n'est pas anodin : contrairement à la Transformation Opérationnelle (OT) utilisée par Google Docs, les CRDTs permettent à chaque client de résoudre les conflits localement, sans serveur central. C'est un avantage décisif pour l'écosystème WordPress, où les installations vont du mutualisé à 3 € jusqu'à l'enterprise.
Le transport par défaut est le HTTP polling — une solution compatible avec n'importe quel hébergement PHP, sans WebSocket requis. L'intervalle de polling s'accélère dès qu'un second collaborateur rejoint l'édition. WordPress VIP teste une implémentation WebSocket avec ses clients enterprise depuis octobre 2025, et les hébergeurs peuvent proposer des transports plus performants via des plugins dédiés. C'est la bonne architecture : un socle universel, des couches d'optimisation optionnelles.
Le code a quitté le statut expérimental et est intégré au core de WordPress 7.0. Quelques limites subsistent : l'équipe d'accessibilité a signalé que l'implémentation actuelle ne répond pas encore pleinement aux standards WCAG du projet. La collaboration fonctionne dans l'éditeur de blocs (articles, pages) et dans l'éditeur de site — pas dans l'éditeur classique.
Les Notes : la collaboration asynchrone qui fonctionne déjà
Moins spectaculaires mais immédiatement utiles, les Notes représentent la première brique collaborative réellement livrée. Introduites dans WordPress 6.9, elles permettent d'ajouter des commentaires directement sur les blocs dans l'éditeur — un système de revue éditoriale intégré.
WordPress 7.0 enrichit considérablement ce système. Les fragment notes permettent désormais de sélectionner un passage de texte spécifique dans un paragraphe pour y associer un commentaire, au lieu de commenter un bloc entier. Les mentions avec "@" arrivent, ainsi que les notifications digest et un affichage optimisé pour les grands écrans.
Techniquement, chaque note est stockée comme un WP_Comment de type "note", ce qui signifie que les développeurs peuvent y accéder via les API de commentaires existantes. Pour un studio qui gère des dizaines de sites clients, cette approche s'intègre naturellement dans les workflows éditoriaux sans plugin tiers.
La refonte de l'administration: un premier "coup de peinture"
Le dashboard WordPress n'a pas connu de refonte visuelle complète depuis WordPress 3.8 (2013), même si WordPress 5.3 (2019) avait déjà apporté une refonte significative côté accessibilité (formulaires, boutons, couleurs). La modernisation de l'administration fait partie de la Phase 3, mais elle progresse délibérément — et c'est tant mieux.
Lors du meeting des Core Committers fin 2025, les participants ont été clairs : pas de refonte complète, mais un "nouveau coup de peinture" pour homogénéiser les écrans existants. WordPress 7.0 apporte des espacements cohérents, du filtrage inline sans rechargement de page, et un alignement visuel entre l'éditeur de blocs et les écrans d'administration classiques.
DataViews : l'avenir des listes d'administration
Le composant DataViews, introduit dès WordPress 6.5 et 6.6, continue de remplacer progressivement les traditionnelles WP List Tables. WordPress 7.0 ajoute un layout "activity" et pose les bases pour l'enregistrement de types tiers dans les releases futures. DataForm s'enrichit d'un layout "details", de nouveaux contrôles et d'un support de validation étendu.
Pour les développeurs de plugins, bonne nouvelle : la rétrocompatibilité est assurée pour les extensions qui hookent les vues de listing standard. Les WP List Tables classiques continuent de fonctionner en parallèle de DataViews, sans rupture.
Traitement média côté client : moins de charge serveur
WordPress 7.0 introduit le traitement média côté client, en exploitant les capacités du navigateur pour des tâches comme le redimensionnement et la compression d'images. Cette approche présente trois avantages concrets : utilisation de formats d'image plus avancés et de techniques de compression modernes, réduction de la charge sur le serveur web, et workflow média plus fluide pour les contenus existants comme les nouveaux.
Pour les hébergeurs et les administrateurs système, c'est une bonne nouvelle — moins de processing PHP signifie plus de marge de manœuvre côté serveur, surtout sur les environnements mutualisés. Pour les développeurs de plugins de gestion média, il faudra vérifier la compatibilité avec ce nouveau pipeline.
L'éditeur toujours en iframe : ce que ça change pour les développeurs
WordPress 7.0 impose l'éditeur d'articles en iframe permanent, quel que soit la version de l'API block utilisée. Depuis plusieurs versions, tous les éditeurs basés sur les blocs (template, site) fonctionnaient en iframe pour séparer les styles UI des styles de blocs et thèmes. L'éditeur d'articles faisait exception pour les blocs utilisant la version 2 de l'API block.
Ce changement technique peut sembler anodin pour les utilisateurs finaux, mais il impacte les développeurs dont les blocs personnalisés accèdent au document global en JavaScript ou en CSS. Un guide de migration est disponible dans le handbook WordPress pour adapter les blocs concernés.
PHP 7.4 minimum : la fin d'une époque
WordPress 7.0 abandonne officiellement le support de PHP 7.2 et 7.3 pour fixer le minimum à PHP 7.4. La version recommandée reste PHP 8.3 pour des performances et une sécurité optimales.
La décision suit la politique du projet : retirer les versions PHP dont l'usage combiné tombe sous les 5 %. Les données récentes montrent que PHP 7.2 et 7.3 représentent moins de 4 % des installations monitorées. PHP 7.4 a atteint sa fin de vie en novembre 2022 — ce ménage était attendu depuis longtemps.
Si votre hébergement tourne encore en PHP 7.3 ou inférieur, WordPress 7.0 ne s'installera tout simplement pas. C'est le moment de monter en version ou de changer d'hébergeur. Pour ceux qui sont déjà en PHP 8.x, aucune action n'est nécessaire — vous profiterez des optimisations de typage et de performances que cette montée en version minimale permet dans le core.
Nouvelles briques pour les thèmes et l’interactivité
Au-delà des grandes fonctionnalités, WordPress 7.0 livre plusieurs briques techniques qui changent concrètement le travail des développeurs de thèmes et de blocs.
Navigation Overlays personnalisables
Jusqu’à WordPress 6.9, le menu hamburger mobile affichait un overlay fixe impossible à personnaliser. WordPress 7.0 change la donne : l’overlay de navigation devient un template part éditable dans l’éditeur de site, avec un nouveau type de zone navigation-overlay.
Concrètement, vous pouvez construire votre overlay mobile comme n’importe quelle autre partie de template — y glisser des icônes sociales, un formulaire de recherche, un logo, des CTAs. Un nouveau bloc Navigation Overlay Close permet de placer le bouton de fermeture où bon vous semble et de le styliser librement.
Le comportement reste opt-in : si vous ne touchez à rien, le Navigation Block continue d’afficher l’overlay par défaut des versions précédentes. Pas de rupture, juste de la flexibilité en plus. Source : Customisable Navigation Overlays in WordPress 7.0 (Make Core, 4 mars 2026).
Bloc Breadcrumb natif
WordPress 7.0 intègre enfin un bloc Breadcrumb natif. Placez-le une fois dans votre header et il génère automatiquement le fil d’Ariane en suivant la hiérarchie de votre site. Deux options de base : afficher ou masquer le lien "Accueil", et choisir le séparateur.
Pour l’instant, le bloc ne fonctionne qu’avec les types de contenu hiérarchiques. Mais deux filtres permettent d’aller plus loin : block_core_breadcrumbs_items donne la main sur chaque élément du fil d’Ariane avant le rendu, et un second filtre contrôle la taxonomie et les termes utilisés pour les breadcrumbs basés sur les taxonomies. Pour les développeurs de plugins e-commerce (WooCommerce en tête), c’est une brique d’intégration attendue — fini les breadcrumbs codés en dur dans les thèmes. Source : Breadcrumb block filters (Make Core, 4 mars 2026).
Pseudo-classes dans theme.json
WordPress 7.0 ajoute le support des pseudo-classes CSS (:hover, :focus, :focus-visible, :active) directement dans theme.json. Vous pouvez définir les styles de survol et de focus pour vos blocs et leurs variations sans écrire une seule ligne de CSS personnalisé.
Attention, il s’agit bien de pseudo-classes (:hover) et non de pseudo-éléments (::before, ::after). Le support se limite aux quatre états interactifs listés — les autres pseudo-classes sont ignorées. Pour l’instant, l’API est réservée à theme.json : pas d’interface dans les Styles Globaux pour ces états dans la 7.0. Les développeurs de thèmes y gagnent en maintenabilité, les utilisateurs devront patienter pour une interface visuelle.
Interactivity API : watch()
L’Interactivity API, introduite dans WordPress 6.5, s’enrichit d’une nouvelle fonction watch(). Jusqu’ici, la directive data-wp-watch était liée au cycle de vie d’un élément DOM. watch() découple l’observation des valeurs réactives du DOM — idéal pour les effets de bord au niveau du store, le logging, ou la synchronisation entre stores.
La fonction retourne un callback unwatch pour arrêter l’observation. Le callback passé à watch() peut retourner une fonction de nettoyage, exécutée avant chaque ré-exécution et lors de l’arrêt via unwatch(). Combiné avec state.url, ça permet par exemple de tracker les navigations côté client pour l’analytics sans recharger la page. Source : Changes to the Interactivity API in WordPress 7.0 (Make Core, 4 mars 2026).
Contexte politique : où en est le conflit Automattic / WP Engine ?
On ne peut pas parler de WordPress 7.0 sans évoquer l'éléphant dans la pièce. Le conflit entre Matt Mullenweg et WP Engine a marqué l'année 2025 plus profondément que n'importe quelle feature technique.
Rappel des faits : en septembre 2024, Mullenweg qualifie publiquement WP Engine de "cancer de WordPress", reprochant à l'hébergeur de profiter de l'écosystème sans contribuer suffisamment en retour. Derrière le discours, une demande de redevance de 8 % sur les revenus liés aux marques WordPress. WP Engine riposte par un procès en octobre 2024, invoquant abus de pouvoir, diffamation et pratiques anticoncurrentielles.
L'escalade a eu des conséquences directes sur le projet. Automattic a réduit ses contributions au core pour les aligner sur celles de WP Engine (45 heures par semaine), puis licencié 16 % de ses effectifs en avril 2025. Des contributeurs historiques ont vu leurs comptes WordPress.org bloqués. L'accès de WP Engine à WordPress.org a été temporairement coupé avant qu'un juge ne le rétablisse par injonction préliminaire en décembre 2024.
En février 2026, le conflit reste ouvert. La majorité des plaintes de WP Engine ont survécu à la motion de rejet d'Automattic. WP Engine a déposé une plainte amendée de 175 pages intégrant des éléments issus de la phase de discovery. Un procès devant jury est programmé pour février 2027.
Ce qui compte pour la communauté WordPress : malgré cette turbulence, le projet a retrouvé un rythme de contribution suffisant pour relancer une cadence de trois releases majeures en 2026. L'affaire a aussi accéléré les réflexions sur la gouvernance du projet — la question de savoir si une seule entreprise devrait contrôler WordPress.org reste ouverte et légitime.
En tant que fondateur de WPServeur, j'observe cette situation depuis le cœur de l'écosystème francophone. Le conflit a créé de l'incertitude chez les hébergeurs spécialisés WordPress et chez les agences qui dépendent de la stabilité du projet. La reprise d'un cycle de releases normal avec WordPress 7.0 est un signal rassurant, mais la question de la gouvernance à long terme reste un sujet que toute la communauté doit suivre de près.
Calendrier 2026 : trois releases majeures au programme
WordPress retrouve sa cadence historique avec trois versions majeures en 2026, chacune alignée sur un événement communautaire majeur :
WordPress 7.0 sort le 9 avril 2026, lors du WordCamp Asia à Mumbai. WordPress 7.1 est prévu pour le 19 août, coïncidant avec le WordCamp US, avec un focus attendu sur les workflows média et des permissions utilisateur plus granulaires. WordPress 7.2 clôturera l'année vers décembre, au moment du State of the Word, avec des améliorations de collaboration basées sur les retours de 7.0/7.1 et les premières fondations de la Phase 4 — le multilingue natif.
Ce que WordPress 7.0 signifie pour votre workflow
Pour les développeurs
La priorité immédiate est le test. Entre le 20 février (Beta 1) et le 9 avril (release finale), il faut valider la compatibilité de l'intégralité du stack : thèmes, plugins, code personnalisé. Les points de vigilance principaux sont la compatibilité PHP 7.4 minimum, l'impact de l'éditeur toujours en iframe sur les blocs custom, la transition DataViews pour les plugins qui modifient les listes d'administration, le nouveau pipeline de traitement média côté client, les pseudo-classes dans theme.json (vérifiez que vos styles custom ne sont pas écrasés), et l'Interactivity API watch() pour les blocs interactifs.
Installez le plugin WordPress Beta Tester sur un environnement de staging, jamais en production. Testez les workflows critiques : publication, formulaires, checkout e-commerce, gestion des médias.
Pour les agences
WordPress 7.0 change la dynamique de la collaboration client. Les Notes intégrées à l'éditeur peuvent remplacer les aller-retours sur Google Docs pour les validations de contenu. La collaboration temps réel, même dans sa forme initiale, réduit les conflits de version quand plusieurs rédacteurs interviennent sur le même contenu.
Comme pour toute mise à jour majeure, testez la compatibilité sur un environnement de staging avant de mettre à jour en production — ni plus ni moins que pour WordPress 6.9 ou la future 7.1.
Pour les utilisateurs finaux
L'impact le plus visible sera dans l'éditeur : possibilité de laisser des commentaires contextuels sur le contenu, interface d'administration plus cohérente et moderne, et gestion des médias plus fluide. Si vous travaillez en équipe sur un site WordPress, c'est la première version qui prend vraiment ce besoin au sérieux.
Vérifiez auprès de votre hébergeur que votre version PHP est à jour. Si vous êtes en PHP 7.3 ou inférieur, planifiez la montée en version avant avril 2026.
Ce qu'on attend encore…
WordPress 7.0 pose des fondations solides, mais certains chantiers restent en cours. Le multilingue natif, évoqué régulièrement depuis la Phase 4 de la roadmap Gutenberg, n'est pas au programme de cette version. La refonte complète de l'administration arrivera progressivement sur les prochaines releases. L'intégration IA, via l'Abilities API et le MCP Adapter, vient justement de franchir un cap avec la Beta 2 — c'est probablement le changement le plus structurant pour l'avenir de WordPress.
Mise à jour Beta 2 : les connecteurs IA débarquent dans l'interface
Entre la Beta 1 du 19 février et cette Beta 2, le Client AI SDK a pris un virage. Ce qui n’était qu’une API technique réservée aux développeurs s’est transformé en écran de gestion visible dans l’administration WordPress. Le déclencheur : le meeting " WP 7.0 Product Review " lancé par la direction du projet. La décision qui en sort est limpide — embarquer des connecteurs prêts à l’emploi dans le CMS. Montrer quelque chose de concret aux utilisateurs, pas juste livrer une plomberie invisible.
Le résultat : un nouvel écran Settings > Connectors pour gérer les connexions aux fournisseurs d’IA. Les captures partagées par les développeurs montrent OpenAI, Claude (Anthropic) et Gemini (Google) comme connecteurs préconfigurés, bien que l’annonce officielle ne détaille pas la liste exacte. La page est hookable : n’importe quel développeur peut coder une extension pour brancher son propre fournisseur.

Un point qui grince : trois fournisseurs, trois Californiens. Pas de Mistral AI dans la première fournée. Pour un CMS utilisé par 43 % du web mondial, l’absence d’un acteur européen est un signal faible qu’on aurait préféré ne pas voir. Le standard est posé — à Mistral de publier son connecteur sur le repo WordPress.org.
L’infrastructure, c’est bien. Mais l’usage réel dépendra des développeurs de plugins. Les connecteurs ouvrent la porte, encore faut-il que quelqu’un construise quelque chose derrière. Ce qui compte : WordPress propose enfin une manière standardisée de gérer les échanges entre le CMS et les modèles de langage. Le reste suivra — ou pas.
WordPress 7.0 n'est pas une révolution visuelle. C'est une version d'infrastructure qui prépare WordPress pour les cinq prochaines années. La collaboration, la modernisation de l'administration, le traitement média repensé et le socle IA forment un ensemble cohérent. Après la turbulence de 2025, c'est exactement ce dont le projet avait besoin : moins de drama, plus d'ingénierie.
Cet article a été relu et corrigé sur la base des retours de Jean-Baptiste Audras, Core Committer WordPress et membre de l'équipe Core du projet WordPress.org. Merci à lui pour sa relecture technique.
Conseil : WordPress 7.0 sera une mise à jour majeure. Testez-la d’abord sur un environnement local ou un staging avant de l’appliquer en production.
Questions fréquentes sur WordPress 7
Quand sort WordPress 7.0 ?
La version finale sort le 9 avril 2026, lors du WordCamp Asia à Mumbai. La Beta 1 a été publiée le 20 février 2026. C’est le premier changement de version principale depuis WordPress 6.0 (mai 2022).
WordPress 7 est-il gratuit ?
Oui, WordPress reste 100% gratuit et open source. La mise à jour sera disponible directement depuis votre tableau de bord WordPress, comme pour toutes les versions précédentes.
Faut-il mettre à jour vers WordPress 7 immédiatement ?
Pas le jour J. Attendez quelques jours que les développeurs de thèmes et d’extensions testent la compatibilité. Faites une sauvegarde complète avant toute mise à jour, et testez sur un environnement de staging si possible.
WordPress 7 est-il compatible avec mon thème actuel ?
Les thèmes classiques (Astra, GeneratePress, OceanWP) et les Block Themes sont compatibles. Les constructeurs de pages (Elementor, Divi) fonctionnent aussi, mais vérifiez que vos extensions sont à jour avant la migration.
Quelle version de PHP est requise pour WordPress 7 ?
WordPress 7.0 exige PHP 7.4 minimum. Les versions PHP 7.0 à 7.3 ne seront plus supportées. L’idéal est de passer à PHP 8.1 ou 8.2 pour de meilleures performances.
La collaboration en temps réel est-elle prête ?
La Phase 3 (collaboration) débute avec WordPress 7.0 mais reste expérimentale. Le verrouillage de contenu par bloc (et non plus par page entière) sera la première brique. La co-édition complète arrivera dans les versions suivantes.
WordPress 7 remplace-t-il Gutenberg ?
Non. Gutenberg reste l’éditeur de WordPress. La version 7.0 intègre les avancées de Gutenberg Phase 3 (collaboration), après les Phases 1 (blocs) et 2 (Full Site Editing) déjà livrées.
Ces 7 templates, je les donne en formation payante. Ici, ils sont gratuits.
Sécurité, SEO, performance, contenu, maintenance — les outils que j'utilise en formation et en audit, avec les prompts IA pour aller 10x plus vite.
- 01Workflow contenu anti-IA
- 02Framework SEO Title/Meta/H1
- 03Audit Express 30 points
- 04Blindage sécurité 10 étapes
- 05PageSpeed 90+ sans plugin
- 06Calendrier maintenance IA
- 07Plan d'action 90 jours
1 email / 2 jours pendant 14 jours. Désabonnement en 1 clic.
Analyser avec l'IA
Partager

