WordPress 7.1 : ce que cette version doit vraiment changer pour les utilisateurs

WordPress 7.1 arrive dans un contexte particulier. La version 7.0 devait ouvrir un nouveau chapitre pour l’éditeur, notamment avec l’édition collaborative en temps réel. Sa sortie a finalement été décalée de plusieurs semaines afin de résoudre des questions d’architecture, avant que cette fonctionnalité majeure soit retirée de la version finale pour des raisons de stabilité, de charge serveur et de gestion des conflits.

La sortie de WordPress 7.1, prévue le 19 août 2026, ne doit donc pas être regardée comme une simple mise à jour intermédiaire. Elle constitue plutôt un test de maturité : WordPress peut-il transformer plusieurs années d’évolution de Gutenberg en améliorations réellement perceptibles pour les utilisateurs, les agences et les équipes éditoriales ?

La RC1 permet déjà d’identifier les orientations de la version. Mais au-delà de la liste des nouveautés, plusieurs questions restent essentielles : l’éditeur va-t-il enfin proposer une vraie gestion responsive ? Comment WordPress compte-t-il réconcilier Gutenberg avec les extensions reposant encore sur des metaboxes ? Et le Full Site Editing peut-il devenir suffisamment contrôlable pour être confié sereinement à des équipes clientes ?

Le responsive : une fonction attendue depuis les débuts de Gutenberg

Gutenberg propose depuis longtemps des aperçus desktop, tablette et mobile. Pourtant, ces trois modes ont jusqu’ici surtout permis de visualiser le contenu à différentes largeurs, sans offrir un véritable système de conception responsive.

Lorsqu’un utilisateur modifie une taille de texte, une marge ou un espacement, la valeur s’applique généralement à tous les écrans. Il est donc possible de voir qu’un titre est trop grand sur mobile, mais pas nécessairement de le corriger pour ce seul affichage depuis l’interface native.

C’est l’un des paradoxes les plus durables de Gutenberg : l’éditeur se veut visuel, mais oblige encore régulièrement à écrire du CSS ou à utiliser une extension tierce pour réaliser des adaptations pourtant élémentaires.

La feuille de route de WordPress 7.1 reconnaît explicitement ce manque. Le projet travaille sur la possibilité d’appliquer des styles différents selon la taille de l’écran, aussi bien pour les styles globaux que pour une instance particulière d’un bloc. Les premiers cas d’usage cités sont précisément ceux rencontrés quotidiennement en production : réduire une taille de titre sur mobile, diminuer un padding ou modifier certaines couleurs selon le viewport.

Pour une agence WordPress, cette évolution est probablement plus importante qu’une grande partie des nouveautés visibles de la version.

Nous avons, comme beaucoup d’intégrateurs, dû développer nos propres outils pour permettre aux éditeurs de régler séparément les marges, les tailles typographiques ou certains positionnements. Ce type de développement maison répond à un besoin fonctionnel évident, mais il complexifie aussi la maintenance, la formation et la portabilité des sites.

Une gestion responsive intégrée au Core permettrait de réduire cette dépendance aux surcouches propriétaires. Elle rendrait également les thèmes blocs beaucoup plus crédibles pour des projets exigeants.

Il faudra toutefois juger la fonction sur plusieurs critères : la clarté de l’héritage entre desktop, tablette et mobile, la possibilité de revenir facilement à une valeur par défaut, la cohérence des breakpoints et la lisibilité des réglages dans l’inspecteur. Ajouter un champ différent par écran ne suffira pas si l’utilisateur ne comprend plus quelle valeur s’applique réellement.

WordPress 7.1 introduit par ailleurs de nouveaux supports de dimensions, comme la largeur minimale des blocs. Cette amélioration paraît plus technique, mais elle participe à la même logique : exposer dans l’éditeur des propriétés CSS courantes qui nécessitaient encore du code personnalisé.

Le responsive ne doit plus être considéré comme une option avancée. Il fait partie de la structure normale d’une page web. Gutenberg ne pourra devenir un véritable outil de conception tant que cette dimension restera partielle.

Metaboxes et extensions SEO : l’angle mort de la modernisation

La transition vers Gutenberg a toujours reposé sur un équilibre délicat : moderniser l’expérience sans casser l’immense écosystème construit autour de l’éditeur classique.

Cet équilibre devient plus fragile avec WordPress 7.

De nombreuses extensions utilisent encore des metaboxes pour afficher leurs interfaces dans l’écran d’édition. C’est notamment le cas de solutions SEO, de champs personnalisés ou d’outils métiers. Dans la nouvelle organisation de l’éditeur, ces interfaces peuvent se retrouver reléguées très bas dans la page, en dehors de la zone immédiatement visible.

Le problème n’est pas uniquement esthétique. Nous constatons déjà que certains utilisateurs pensent que leurs réglages SEO ont disparu. Ils ne voient pas la zone située sous le contenu ou ne comprennent pas qu’il faut faire défiler l’ensemble de l’éditeur pour la retrouver.

Une fonctionnalité toujours présente mais devenue difficile à découvrir constitue, en pratique, une régression d’usage.

Cette mise en retrait révèle aussi une tension plus profonde. L’architecture historique des metaboxes s’intègre mal aux nouvelles ambitions de Gutenberg, notamment à la synchronisation de plusieurs utilisateurs. Lors du cycle de WordPress 7.0, le projet indiquait que l’édition collaborative devait être désactivée lorsque certaines metaboxes étaient présentes. Les éditeurs d’extensions étaient encouragés à créer des passerelles ou à migrer vers des API Gutenberg plus modernes.

Cette direction peut se comprendre techniquement. WordPress ne peut pas construire indéfiniment ses nouvelles fonctionnalités autour de mécanismes hérités. Mais la transition ne peut pas reposer uniquement sur les développeurs d’extensions et, encore moins, sur les utilisateurs finaux.

Il manque aujourd’hui une stratégie d’interface plus claire pour les données complémentaires d’un contenu. Les informations SEO, les champs éditoriaux, les paramètres de diffusion ou les données métiers devraient disposer d’emplacements cohérents, identifiables et accessibles.

À terme, WordPress devra probablement aller plus loin qu’une simple compatibilité avec les metaboxes. Il devra définir un véritable modèle d’extension de l’éditeur : des panneaux capables d’être positionnés de manière prévisible, associés à des droits utilisateurs et intégrés aux mécanismes de sauvegarde, de révision et de collaboration.

Sans cela, chaque avancée de Gutenberg continuera de produire une période de flottement dans l’écosystème.

L’édition collaborative attendra encore

L’édition collaborative en temps réel devait être l’un des symboles de WordPress 7.0. La fonction devait permettre à plusieurs personnes de travailler simultanément sur un même contenu, à la manière de Google Docs.

La complexité technique du chantier a cependant entraîné l’allongement du cycle de WordPress 7.0. Le projet devait notamment trancher des questions de stockage, de synchronisation, d’invalidation du cache, de consommation mémoire et de compatibilité avec les infrastructures d’hébergement. La fonctionnalité a finalement été retirée avant la sortie.

WordPress 7.1 devait initialement reprendre le sujet. Une campagne de tests spécifique a même été lancée afin d’évaluer la collaboration dans des environnements et des usages réels. Mais le billet officiel a été mis à jour le 21 juillet : l’édition collaborative a également été repoussée au-delà de la version 7.1.

Cette prudence est probablement préférable à l’intégration précipitée d’une architecture fragile. Elle rappelle néanmoins qu’une fonctionnalité spectaculaire dans une démonstration n’est pas nécessairement la plus urgente pour la majorité des utilisateurs.

Sur beaucoup de sites WordPress, les difficultés quotidiennes concernent davantage la validation des contenus, la compréhension des rôles, l’accès aux réglages, la gestion des modèles ou la prévention des erreurs que la coédition en temps réel.

Les améliorations apportées aux Notes, aux suggestions et aux interactions asynchrones peuvent donc avoir un impact plus immédiat. Elles correspondent mieux à des workflows où un rédacteur prépare un contenu, un responsable le commente et un administrateur le publie à un autre moment. La feuille de route de WordPress 7.1 prévoit notamment des suggestions applicables, des réactions et des notifications enrichies.

La collaboration ne doit pas être réduite à la présence simultanée de plusieurs curseurs. Pour WordPress, le véritable enjeu est de construire un workflow éditorial complet, compréhensible et adaptable aux organisations.

Le Full Site Editing doit maintenant apprendre à se protéger

Le Full Site Editing a considérablement étendu le périmètre de l’éditeur. Un utilisateur peut désormais intervenir sur les en-têtes, les pieds de page, les modèles, les compositions et les styles globaux depuis une interface visuelle.

Cette liberté est séduisante. Elle représente aussi un risque important dans un contexte client.

Un utilisateur chargé de modifier un texte ne devrait pas nécessairement pouvoir altérer un modèle utilisé par plusieurs dizaines de pages. De la même manière, la personne autorisée à créer une page ne devrait pas automatiquement avoir accès à l’ensemble des styles globaux du site.

Aujourd’hui, les rôles et capacités historiques de WordPress ne traduisent pas toujours assez finement cette nouvelle réalité. Le FSE concentre dans une même interface des actions qui n’ont ni le même impact ni le même niveau de criticité.

Pour qu’il devienne réellement « user friendly », WordPress devra permettre aux agences et aux administrateurs de définir plus précisément :

• qui peut modifier le contenu d’un modèle ;
• qui peut modifier sa structure ;
• qui peut créer ou supprimer un modèle ;
• qui peut accéder aux styles globaux ;
• quels blocs ou compositions peuvent être verrouillés ;
• quelles modifications nécessitent une validation.

Ce besoin ne figure pas comme une fonctionnalité centrale annoncée pour WordPress 7.1. Il doit donc être considéré comme une attente pour les versions futures, plutôt que comme une promesse de cette release.

Les mécanismes de verrouillage existants constituent une première réponse, mais ils restent souvent techniques ou insuffisamment granulaires pour les besoins d’un projet client. Le prochain stade de maturité du FSE sera moins visuel que organisationnel : il devra intégrer la gouvernance directement dans l’expérience d’édition.

Un bon outil no-code ne donne pas nécessairement accès à tout. Il donne accès aux bonnes actions, au bon moment, aux bonnes personnes.

Une version de consolidation plus que de rupture

WordPress 7.1 contient de nombreuses améliorations utiles : styles responsive, états interactifs comme le survol ou le focus, nouvelles possibilités de dimensionnement, progrès sur les médias et affinage général de l’éditeur. La feuille de route évoque également une meilleure visualisation des styles hérités, un sujet particulièrement important lorsque des réglages globaux, des styles de thème et des personnalisations locales se superposent.

Mais la version ne réparera pas à elle seule toutes les limites révélées par WordPress 7.0.

L’édition collaborative ne sera pas au rendez-vous. La transition des metaboxes reste inconfortable. La gouvernance du Full Site Editing est encore trop limitée. Et la gestion responsive devra être éprouvée dans des situations réelles avant de pouvoir remplacer les solutions développées par les agences et les éditeurs de plugins.

Cela ne signifie pas que WordPress 7.1 manque d’ambition. Au contraire, la version pourrait marquer une évolution importante dans la manière dont le projet hiérarchise ses priorités.

Après plusieurs années consacrées à étendre le champ fonctionnel de Gutenberg, WordPress doit désormais réduire les frictions qui empêchent son adoption complète : réglages difficiles à trouver, comportements différents entre l’éditeur et le front, manque de contrôle selon les rôles et dépendance persistante au code pour des ajustements visuels courants.

La prochaine grande étape de WordPress ne sera peut-être pas une nouvelle fonctionnalité spectaculaire. Ce sera le moment où un utilisateur pourra construire, adapter et administrer un site complet sans craindre de casser sa structure, sans chercher ses réglages et sans solliciter un développeur pour chaque comportement responsive.

WordPress 7.1 peut constituer une étape sérieuse dans cette direction. Mais elle doit être jugée non pas seulement sur ce qu’elle ajoute, mais sur ce qu’elle rend enfin simple.