WordPress 7 : tout ce qui change avec la version la plus ambitieuse depuis Gutenberg

WordPress 7.0 "Armstrong" est sorti le mercredi 20 mai 2026. Le 31 mars, Matías Ventura, architecte principal de Gutenberg, avait annoncé un report de la date initiale du 9 avril pour finaliser l'architecture de la base de données de la collaboration en temps réel – la date définitive a été confirmée le 22 avril, avec deux nouvelles RC ajoutées au calendrier (8 et 14 mai). Le 8 mai 2026, après les retours de fuzz testing remontés sur la table wp_collaboration, Matt Mullenweg a tranché : la co-édition en temps réel est retirée du milestone 7.0, sans version cible annoncée pour son retour (Make WordPress Core). 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 livre tout de même les briques structurantes de la Phase 3 du projet Gutenberg – Notes asynchrones, infrastructure IA, modernisation admin – sans la co-édition synchrone qui devait en être le clou.

La RC2, publiée le 26 mars, confirmait l'ampleur du chantier prévu : édition en temps réel multi-utilisateurs, infrastructure IA native, gestionnaire de polices natif, nouveaux blocs natifs (Icon, Breadcrumb), refonte progressive de l'administration, et montée en version PHP. Le 8 mai, la co-édition temps réel a finalement été extraite du périmètre de 7.0 – le reste tient. Voici ce que WordPress 7.0 change concrètement, dans sa version définitive, 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 WordPress, a confirmé son report à 2026.

Automattic a parallèlement réduit ses contributions au core WordPress de près de 3 500 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. Source : WordPress 6.9 "Gene" (WordPress.org News, 2 décembre 2025).

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 : pourquoi la collaboration en temps réel a été retirée de 7.0

WordPress 7.0 devait franchir 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 asynchrones) 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 visait 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. Le 8 mai 2026, Matt Mullenweg a tranché : la co-édition en temps réel ne sort pas avec 7.0. Voici ce qui s'est passé, et ce que ça veut dire pour la suite.

Ce qui était prévu : l'architecture Yjs + CRDT + table dédiée

L'ambition était claire – 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". Techniquement, WordPress s'appuyait sur Yjs, une bibliothèque CRDT (Conflict-free Replicated Data Types) dont l'auteur, Kevin Jahns, est sponsorisé par Automattic. 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 – un avantage décisif pour l'écosystème WordPress, où les installations vont du mutualisé à 3 € jusqu'à l'enterprise.

Le transport par défaut était le HTTP polling, compatible avec n'importe quel hébergement PHP sans WebSocket requis. La RC2 confirmait des limites volontaires : limite à 2 utilisateurs simultanés, désactivation automatique en présence de meta boxes classiques, fonctionnement réservé à l'éditeur de blocs (pas l'éditeur classique). Et surtout, une nouveauté structurelle : la table wp_collaboration (ticket #64696), première nouvelle table dans WordPress depuis wp_termmeta en 2015. C'est précisément cette couche de stockage qui a fini par déclencher le retrait.

Les cinq préoccupations techniques de Matt Mullenweg

Dans l'annonce officielle publiée le 8 mai 2026 sur Make WordPress Core par annezazu (Architecture & Open Source Director chez Automattic), cinq préoccupations sont rapportées comme justifiant la décision de Matt Mullenweg :

"citing concerns around surface area, race conditions, server load, memory efficiency, and recurring bugs found through fuzz testing"

annezazu, Make WordPress Core, 8 mai 2026 (résumé des préoccupations exprimées par Matt Mullenweg sur Slack)

• Surface area – trop de code touché, trop de chemins de régression possibles. Une feature qui s'étend dans toute l'API REST, le Block Editor, le store JS et le schéma BDD multiplie mécaniquement les risques de bug à la moindre évolution future du core.
• Race conditions – deux éditeurs qui modifient le même paragraphe à 50 ms d'écart peuvent produire un état incohérent si la synchronisation n'est pas atomique. Le CRDT résout théoriquement ce problème côté client, mais la couche de persistance MySQL réintroduit des fenêtres de course difficiles à reproduire en CI.
• Server load – le polling HTTP toutes les 2-3 secondes × N éditeurs × M articles ouverts = explosion combinatoire de requêtes. Sur un mutualisé à 3 € ou un site à fort trafic éditorial, c'est un risque DOS auto-infligé.
• Memory efficiency – les métadonnées de synchronisation stockées via post_meta (avant la migration vers la table dédiée) gonflaient le cache objet WordPress et pouvaient invalider les caches persistants en bloc dès qu'un éditeur ouvrait un article. Bug structurel, pas correctif rapide.
• Recurring bugs found through fuzz testing – les tests aléatoires (fuzz testing) ont révélé des comportements non scénarisés que les tests unitaires ne capturaient pas. Quand le fuzz remonte des bugs récurrents en RC, ce n'est pas un détail : c'est un signal que l'espace d'états du système est mal maîtrisé.

Lue ensemble, cette liste raconte une feature qui marche en démo et qui craque en charge réelle. C'est exactement le scénario qu'une release stable n'a pas le droit de livrer à 42 % du web.

La décision : stabilité avant promesse

"This is a difficult decision, especially given the amount of work that has gone into the feature, but it is being made in service of shipping a stable and reliable WordPress 7.0 release for our users."

annezazu, Make WordPress Core, 8 mai 2026 (formulation rapportant la décision de Matt Mullenweg, pas une citation directe)

L'annonce a été publiée par annezazu (Automattic) sur Make WordPress Core, à 12 jours de la sortie. Le calendrier 7.0 a été maintenu : code freeze le 19 mai, release officielle le mercredi 20 mai 2026. Ce n'est pas un report de version – c'est un retrait de feature. Et c'est, à mes yeux, la bonne décision : livrer une RTC instable aurait coûté plus cher à WordPress (en confiance, en support, en patches d'urgence) qu'un deuxième tour de roadmap propre.

Et après ? Le scénario feature plugin

La position officielle reste positive sur le principe – annezazu écrit explicitement "yes to shipping it" à terme. Le scénario probable, déjà rodé sur d'autres chantiers Phase 3, c'est une feature plugin : extraire le code RTC du core, le publier comme extension officielle, l'éprouver à grande échelle pendant 6 à 12 mois, puis tenter une réintégration dans une release future une fois les cinq préoccupations adressées. Aucune version cible n'a été annoncée – pas même 7.1 (août 2026) ni 7.2 (décembre 2026). annezazu conclut sobrement, en réponse à un commentaire de Luke Carbis sur le post :

"That will need to be discussed when the dust settles as part of getting broader feedback going forward."

annezazu, commentaire sur Make WordPress Core, 8 mai 2026

Pratique : pas de constante WP_ALLOW_COLLABORATION à activer dans la 7.0 finale, pas de table wp_collaboration créée à l'installation, pas de réglage RTC dans Réglages > Écriture. Tout l'investissement Yjs reste utile pour la suite – il n'est ni jeté, ni perdu. Il attend la prochaine fenêtre.

Ce qui survit dans 7.0 : les Notes asynchrones

La Phase 3 ne sort pas vide : la brique asynchrone de la collaboration, livrée dans 6.9, est enrichie dans 7.0. C'est le seul morceau de Phase 3 qui arrive comme prévu le 20 mai.

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.

Le nom officiel de cette refonte : " Modern ". Palette épurée, contraste renforcé, typographie retravaillée, application uniforme sur tous les écrans (y compris en multisite). Pas une révolution visuelle, mais le premier vrai pas vers l'interface annoncée pour la Phase 3 – et l'occasion pour les développeurs de plugins de vérifier que leurs écrans custom ne décalent pas par rapport au nouveau standard. Source : Guide des changements techniques de WordPress 7.0 (JB Audras, 15 mai 2026).

Conformité WCAG 2.2

WordPress 7.0 documente explicitement plusieurs ajustements alignés sur la norme WCAG 2.2 : préremplissage du champ de réinitialisation de mot de passe avec le compte enregistré dans le navigateur, désactivation automatique des transitions visuelles quand prefers-reduced-motion est actif côté système, support de word-break sur la classe .screen-reader-text pour une meilleure restitution par les lecteurs d'écran. Pour un site institutionnel ou un service public soumis au RGAA, c'est une bonne nouvelle pour l'audit annuel. Source : Guide des changements techniques de WordPress 7.0 (JB Audras, 15 mai 2026).

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.

Visual Revisions : comparer les changements visuellement

WordPress 7.0 ajoute un système de révisions visuelles directement dans l’éditeur de blocs. Au lieu de comparer du texte brut ligne par ligne, vous voyez les modifications sous forme d’overlays colorés sur les blocs eux-mêmes : vert pour les blocs ajoutés, rouge pour les blocs supprimés, jaune pour ceux dont les réglages ont été modifiés.

La comparaison fonctionne en deux temps : un premier passage identifie les blocs touchés, puis une analyse rich-text détaillée montre les changements à l’intérieur de chaque bloc. Pour les équipes éditoriales qui gèrent des dizaines de révisions par article, c’est un gain de temps considérable. Source : What’s new for developers? (March 2026) (Developer Blog).

Traitement média côté client : reporté à WordPress 7.1

Le traitement média côté client devait être l'une des nouveautés marquantes de WordPress 7.0 : exploiter les capacités du navigateur pour redimensionner et compresser les images avant l'upload, via une version WebAssembly de la bibliothèque libvips. La promesse était séduisante – moins de charge serveur, des formats modernes, un workflow plus fluide.

La réalité a rattrapé l'ambition. Lors du cycle RC, l'équipe a constaté que la bibliothèque vips ajoutait environ 13 Mo au package d'installation (sur un total passé de ~20 Mo à ~33 Mo entre WordPress 6.9 et les premières betas de 7.0). Les performances côté navigateur se sont révélées catastrophiques : 19 secondes pour traiter un JPEG, jusqu'à 55 secondes pour un AVIF sur un MacBook M4 Pro. La décision a été prise dans la Beta 6 : le traitement média côté client a été entièrement retiré de WordPress 7.0 et reporté à WordPress 7.1, attendue pour le 19 août 2026. Source : WordPress 7.0 Release Candidate 1 delayed (Make Core, 19 mars 2026).

Éditeur en iframe permanent : reporté à WordPress 7.1

L'éditeur d'articles en iframe permanent était prévu pour WordPress 7.0. Le principe : tous les éditeurs basés sur les blocs (template, site, article) devaient fonctionner en iframe pour séparer proprement les styles UI des styles de blocs et thèmes. Finalement, la généralisation forcée a été reportée à WordPress 7.1, mais une étape intermédiaire est bien dans 7.0 : l'éditeur d'articles passe automatiquement en iframe dès lors que tous les blocs de l'article utilisent la version 3 de l'API Block ou supérieure. Tant qu'un seul bloc v1 ou v2 subsiste, l'éditeur conserve son rendu non-iframé pour préserver la rétrocompatibilité. Le site editor et le template editor, eux, restent en iframe dans 7.0 comme dans 6.9. Sources : Iframed Editor Changes in WordPress 7.0 (Make Core, 24 février 2026) et Guide des changements techniques de WordPress 7.0 (JB Audras, 15 mai 2026).

Pour les développeurs de blocs custom qui accèdent au document global en JavaScript ou en CSS, c'est un sursis. Vous avez jusqu'à la 7.1 (août 2026) pour adapter vos blocs. Le guide de migration est déjà disponible dans le handbook WordPress, autant s'y mettre maintenant.

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.

Bloc Icon natif

WordPress 7.0 introduit un bloc Icon qui permet d’insérer des icônes SVG directement dans le contenu, sans plugin. Le bloc s’appuie sur une nouvelle API server-side (WP_Icons_Registry) et un endpoint REST dédié (/wp/v2/icons) pour rechercher et filtrer les icônes disponibles. L’éditeur affiche une modale de sélection avec les icônes du package wordpress/icons, personnalisables en couleur, taille et fond. Le support pour les collections d’icônes tierces est prévu pour WordPress 7.1. Source : WordPress 7.0 Beta 1 (WordPress.org News) et What’s new for developers? (March 2026) (Developer Blog).

Bloc Titres unifié et raccourci /titre

Le bloc Titre devient un seul bloc avec des variantes pour les six niveaux (H1 à H6), activables ou désactivables depuis l'inspecteur. Un raccourci slash dédié (/titre) apparaît dans l'outil d'insertion. Plus besoin de jongler entre six blocs distincts pour structurer un article. Source : Guide des changements techniques de WordPress 7.0 (JB Audras, 15 mai 2026).

Bloc Couverture : vidéos en arrière-plan

Le bloc Couverture accepte désormais des vidéos comme arrière-plan de section, pas seulement des images. Trois précautions avant de l'utiliser en production : la performance (poids du fichier, autoplay sur mobile), l'accessibilité (contraste du texte superposé, désactivation pour prefers-reduced-motion) et les droits d'auteur sur la vidéo utilisée. Source : Guide des changements techniques de WordPress 7.0 (JB Audras, 15 mai 2026).

Bloc Paragraphe : mise en page en colonnes

Le texte d'un paragraphe peut maintenant être réparti sur plusieurs colonnes (style magazine), sans recourir à un bloc Colonnes imbriqué ni à du CSS personnalisé. Utile pour des pages d'accueil éditoriales ou des pages longues type livre blanc. Source : Guide des changements techniques de WordPress 7.0 (JB Audras, 15 mai 2026).

Gallery Lightbox : navigation entre images

Le bloc Gallery s’enrichit d’une lightbox avec navigation intégrée : boutons précédent/suivant et support des flèches clavier pour passer d’une image à l’autre sans fermer la visionneuse. Les images dont la lightbox est désactivée sont automatiquement sautées. Un ajout discret mais bienvenu pour les portfolios et les galeries de produits. Source : WordPress 7.0 Beta 1 (WordPress.org News).

Block Visibility : affichage conditionnel par écran

Nouveauté discrète mais puissante : WordPress 7.0 ajoute des contrôles de visibilité par viewport sur chaque bloc. Trois breakpoints fixes : mobile (≤480px), tablette (480-782px), desktop (>782px). Vous pouvez masquer un bloc sur mobile sans le supprimer, ou n'afficher un CTA que sur desktop. Les breakpoints seront configurables dans WordPress 7.1, et une intégration theme.json est prévue. Source : Block Visibility in WordPress 7.0 (Make Core, 15 mars 2026).

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).

Pattern Editing : contentOnly par défaut

WordPress 7.0 change le comportement par défaut de l’édition des patterns non-synchronisés et des template parts : ils passent en mode contentOnly. Concrètement, quand un éditeur ouvre un pattern, il ne voit que les champs de contenu (texte, images) sans les contrôles de mise en page – les attributs de design sont regroupés dans des menus flyout avec les icônes des blocs correspondants. L’objectif : réduire le bruit visuel et éviter les modifications de design accidentelles. Les administrateurs peuvent désactiver ce comportement via le filtre PHP disableContentOnlyForUnsyncedPatterns. Source : Pattern Editing in WordPress 7.0 (Make Core, 15 mars 2026).

Gestionnaire de polices natif

WordPress 7.0 intègre un gestionnaire de polices natif accessible depuis Apparence > Polices. Jusqu'ici réservée aux block themes, la Font Library fonctionne désormais avec tous les types de thèmes (block, classique, hybride). L'interface propose trois onglets : Library pour parcourir les polices installées, Upload pour ajouter vos propres fichiers, et Installer des polices pour télécharger des Google Fonts directement depuis l'admin.

L'intérêt principal : les polices sont hébergées localement sur votre serveur, 100 % RGPD-compliant. Plus besoin de plugin tiers type OMGF ou Local Google Fonts. Le gestionnaire est aussi accessible via la Command Palette (Ctrl+K), un raccourci appréciable pour les créateurs de contenu. Source : WordPress 7.0 Beta 1 (WordPress.org News).

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 mercredi 20 mai 2026. La sortie était initialement prévue le 9 avril 2026 lors du WordCamp Asia à Mumbai (Jio World Convention Centre, plus de 3 000 participants attendus). Le calendrier a finalement été étendu – RC3 le 8 mai, RC4 le 14 mai, code freeze le 19 mai – pour permettre des tests de performance supplémentaires sur la collaboration temps réel. Matt Mullenweg est resté speaker invité du WordCamp Asia, et la cérémonie de lancement initialement prévue à 11h45 IST le jour du Contributor Day a été reportée à la date définitive.

Le cycle de développement a été dense : Beta 1 le 20 février, puis six betas (dont une supplémentaire ajoutée après le report de la RC1 du 19 au 24 mars, la Beta 3 avec 148 corrections et la Beta 5 avec 101+ corrections et le raccourci Command Palette ⌘K/Ctrl+K dans la barre d'administration). La Beta 6 a retiré le traitement média côté client pour réduire la taille du package. La RC1, initialement prévue le 19 mars, a été reportée au 24 mars pour trois raisons : performances de la collaboration temps réel, taille du package d'installation, et retrait du traitement média côté client. La RC2 suit le 26 mars, puis le calendrier a été étendu pour permettre des tests de performance supplémentaires : RC3 le 8 mai, RC4 le 14 mai, code freeze le 19 mai, et release officielle le mercredi 20 mai 2026.

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 côté client (reportés de 7.0), l'extensibilité des connecteurs IA pour les fournisseurs tiers, 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 la release du 20 mai 2026 (initialement prévue le 9 avril), 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'iframe conditionnel sur l'éditeur d'articles dans 7.0 (déclenché dès que tous les blocs de l'article passent en API v3+, avec généralisation forcée toujours reportée à la 7.1), la transition DataViews pour les plugins qui modifient les listes d'administration, les nouveaux blocs natifs (Icon, Breadcrumb, Titres unifié, Couverture vidéos, Paragraphe colonnes), le thème admin " Modern " à éprouver sur les écrans custom de vos plugins, 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 – mais pas autant qu'annoncé en mars. Les Notes asynchrones intégrées à l'éditeur, enrichies dans cette version, peuvent remplacer les aller-retours sur Google Docs pour les validations de contenu (commentaires sur passages spécifiques via les fragment notes, mentions @, notifications digest). La co-édition synchrone – celle qui aurait permis à deux rédacteurs de travailler en simultané sur le même paragraphe – a été retirée du milestone 7.0 le 8 mai. Pour les workflows multi-rédacteurs, le verrouillage classique reste donc en vigueur dans 7.0 : un seul éditeur en écriture à la fois.

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 des révisions visuelles avec overlays colorés pour comparer les changements. 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 dès que possible.

J'ai installé la bêta WordPress 7.0 sur mes environnements de test dès février 2026 et j'ai suivi le cycle depuis. Le 20 mai, j'ai déployé la version finale sur quelques sites en production : pas de régression observée, pas d'extension cassée, dashboard plus réactif au chargement. Bilan terrain honnête : la 7.0 est plus sereine à adopter que beaucoup de versions mineures passées.

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, a franchi un cap significatif – c'est probablement le changement le plus structurant pour l'avenir de WordPress.

Les connecteurs IA débarquent dans l'interface

Durant le cycle de développement, 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, propulsé par la bibliothèque wordpress/php-ai-client, un SDK PHP partagé et agnostique en termes de fournisseur. 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, avec OpenAI, Claude (Anthropic) et Gemini (Google) comme connecteurs préconfigurés. L’architecture sous-jacente, baptisée Connectors API, est conçue pour aller au-delà de l’IA – elle pourra à terme gérer les connexions à n’importe quel service externe (CRM, paiement, données tierces). En revanche, l’extensibilité pour les fournisseurs tiers n’est pas encore disponible dans WordPress 7.0 : les développeurs ne peuvent pas encore ajouter leurs propres connecteurs via l’écran d’administration. Cette couche d’extensibilité, actuellement expérimentale dans Gutenberg, est attendue pour WordPress 7.1. Source : Introducing the Connectors API in WordPress 7.0 (Make Core, 18 mars 2026).

Un point qui grince : trois fournisseurs, trois Californiens. Pas de Mistral AI dans la première fournée. Pour un CMS utilisé par plus de 42 % 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, les nouveaux blocs natifs 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. Pour tirer parti de ces évolutions dès le jour J, se former à WordPress avec un formateur certifié Qualiopi reste le moyen le plus efficace de ne rien rater.

---

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. Mise à jour du 15 mai 2026 sur la base de son Guide des changements techniques de WordPress 7.0 publié le jour même sur fr.wordpress.org – référence officielle francophone pour la sortie du 20 mai.

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 ?

WordPress 7.0 sort le mercredi 20 mai 2026. La sortie était initialement prévue le 9 avril 2026 lors du WordCamp Asia à Mumbai, mais a été décalée pour finaliser l'architecture de la collaboration en temps réel. 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). Le cycle a compté 6 betas et 4 RC (24 et 26 mars, 8 et 14 mai), avec un code freeze le 19 mai. Le Field Guide WordPress 7.0 compile toutes les Dev Notes.

WordPress 7 est-il gratuit ?

Oui, WordPress reste 100% gratuit et open source. La mise à jour est 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.2 et 7.3 ne sont plus supportées (PHP 7.0 et 7.1 étaient déjà abandonnées). La version recommandée est PHP 8.3 pour des performances et une sécurité optimales.

La collaboration en temps réel est-elle prête ?

Non, plus dans WordPress 7.0. Le 8 mai 2026, la co-édition en temps réel a été retirée du milestone 7.0 à la demande de Matt Mullenweg, après remontées de bugs en fuzz testing et préoccupations sur la charge serveur, l'efficacité mémoire, les race conditions et la surface d'attaque (annonce officielle). WordPress 7.0 est sorti néanmoins le 20 mai 2026, sans RTC, sans constante WP_ALLOW_COLLABORATION, sans table wp_collaboration. La fonctionnalité reviendrait probablement sous forme de feature plugin dédié, sans version cible annoncée. Les Notes asynchrones (commentaires sur passages, mentions @, notifications digest), elles, sont bien dans 7.0. Détails dans la section Phase 3.

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.

Article original sur WPFormation