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

WordPress 7.0 devait sortir le 9 avril 2026, mais le 31 mars, Matías Ventura, architecte principal de Gutenberg, a annoncé un report de quelques semaines pour finaliser l'architecture de la base de données de la collaboration en temps réel. 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 RC2, publiée le 26 mars, confirmait l'ampleur du chantier : édition en temps réel multi-utilisateurs (optionnelle, à activer), infrastructure IA native, gestionnaire de polices natif, nouveaux blocs natifs (Icon, Breadcrumb), 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 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 : 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, mais désactivée par défaut. Un réglage dans Réglages > Écriture permet de l'activer. L'équipe Core a jugé la fonctionnalité suffisamment stable, mais souhaite davantage de retours dans des contextes variés (extensions, hébergements) avant de l'activer par défaut dans une future version majeure. 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.

Quelques précisions techniques depuis la RC2 : la constante WP_ALLOW_COLLABORATION dans wp-config.php active ou désactive la fonctionnalité (en complément du réglage admin). La limite est fixée à 2 utilisateurs simultanés sur le même contenu. Le transport repose sur du HTTP polling pur, pas de WebRTC ni WebSocket par défaut. Et si vous utilisez des meta boxes classiques (les anciennes boîtes de saisie sous l'éditeur), elles sont incompatibles avec le mode collaboratif : WordPress désactive automatiquement la collaboration quand des meta boxes sont détectées. Source : Real-Time Collaboration in the Block Editor (Make Core, 10 mars 2026).

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.

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 est entièrement retiré de WordPress 7.0 et reporté à une future version, probablement WordPress 7.1 en 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, cette généralisation a été reportée à WordPress 7.1. Le site editor et le template editor restent en iframe dans 7.0 (comme dans 6.9), mais l'éditeur d'articles conserve son comportement actuel. Source : Iframed Editor Changes in WordPress 7.0 (Make Core, 24 février 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).

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 devait sortir le 9 avril 2026, lors du WordCamp Asia à Mumbai (Jio World Convention Centre, plus de 3 000 participants attendus). C'était la première fois qu'une release majeure était prévue en live lors d'un WordCamp : la cérémonie de lancement était programmée à 11h45 IST le jour du Contributor Day. Matt Mullenweg y reste confirmé comme speaker invité.

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, la RC3 le 2 avril.

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 finale (date reportée, 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, le report de l'éditeur en iframe permanent à la 7.1 (un sursis pour adapter vos blocs), la transition DataViews pour les plugins qui modifient les listes d'administration, les nouveaux blocs natifs (Icon, Breadcrumb), 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, une fois activée dans Réglages > Écriture, réduira 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 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.

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.

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 sortie était prévue le 9 avril 2026 lors du WordCamp Asia à Mumbai, mais a été reportée de quelques semaines 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 3 RC. 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 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.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 ?

Oui, la co-édition en temps réel est intégrée au core de WordPress 7.0 (c'est d'ailleurs la finalisation de son architecture qui a causé le report de la date de sortie), mais désactivée par défaut. Activez-la dans Réglages > Écriture ou via la constante WP_ALLOW_COLLABORATION dans wp-config.php. Limite actuelle : 2 utilisateurs simultanés, et les meta boxes classiques désactivent automatiquement la collaboration.

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.