WordPress 7.1, nom de code « Mary Lou » en hommage à la pianiste et compositrice de jazz Mary Lou Williams, est disponible depuis le 19 août 2026. L’annonce officielle de sortie recense plus de 800 contributeurs, dont plus de 170 pour leur toute première contribution à WordPress, et plus de 1 500 correctifs et améliorations au total — en complément du décompte du Field Guide : plus de 310 tickets Core Trac, plus de 100 améliorations, et plus de 180 corrections de bugs, auxquels s’ajoutent près de 600 améliorations et plus de 630 corrections de bugs fusionnées depuis Gutenberg. La plupart des relais qui nous sont parvenus cette semaine s’arrêtent à deux petits réglages de bloc, nichés dans l’éditeur. La version elle-même va bien plus loin : un chantier d’architecture désormais achevé dans l’éditeur, deux nouveaux blocs, une API pour développeurs qui continue de grandir, et des fonctionnalités longtemps annoncées qui ne sont toujours pas livrées. Allons voir tout cela ensemble !
Qu’est-ce qui change vraiment dans l’éditeur de blocs ?
Le changement le plus structurel prolonge ce que WordPress 7.0 avait amorcé en mai dernier. Nous en parlions déjà dans notre article sur les nouveautés de la 7.0. WordPress migre depuis plusieurs versions l’éditeur d’articles vers une architecture basée sur iframe : la 7.1 achève cette migration. Chaque article se charge désormais dans l’éditeur en iframe, y compris sur les sites qui enregistrent encore des meta boxes héritées, un groupe que le déploiement précédent avait laissé de côté. D’après le Field Guide officiel de WordPress 7.1, le cycle qui a mené à cette version a touché 1 480 fichiers, avec 88 163 lignes ajoutées et 18 601 supprimées entre la 7.0.2 et la bêta 4 de la 7.1. Ce n’est pas l’empreinte d’une mise à jour cosmétique.
Dans votre édition au quotidien, cela ne ressemblera à rien de nouveau. C’est en grande partie le but recherché. La migration vers l’iframe n’est pas une fonctionnalité sur laquelle on clique, c’est la plomberie qui fait que les blocs personnalisés et les meta boxes héritées se comportent enfin de façon cohérente entre eux. Si vous maintenez des blocs personnalisés, c’est le point à tester en priorité.
Deux petits réglages de bloc qui règlent un vrai casse-tête de mise en page
Les deux réglages qui ont fait le tour des digests sont bien réels, seulement mal expliqués. Le premier est le support du dégradé d’arrière-plan (background.gradient) : le panneau Arrière-plan d’un bloc peut désormais combiner un dégradé et une image d’arrière-plan en même temps. Jusqu’ici, les deux réglages s’excluaient mutuellement, ce qui forçait à choisir entre une photo et un traitement colorimétrique plutôt que de superposer les deux.
Le second est le support de la largeur minimale de bloc (minWidth), sur le même modèle que le contrôle de hauteur minimale déjà existant. En pratique, il évite qu’un bloc rétrécisse en dessous d’une taille utilisable sur les petits viewports, sans que vous ayez à sortir du CSS personnalisé pour tenir la ligne.
Aucun des deux réglages ne réinvente la façon de concevoir une page. Les deux suppriment un petit désagrément récurrent que la plupart des créateurs de thèmes rafistolaient jusque-là avec du CSS sur mesure, exactement le genre de correctif sans éclat qui fait gagner du temps une fois qu’on l’a repéré.
Deux nouveaux blocs : Playlist et Onglets
WordPress 7.1 introduit aussi deux blocs entièrement nouveaux. Le bloc Playlist joue plusieurs pistes audio à la suite depuis un seul bloc, avec une visualisation en forme d’onde pour chaque piste, au lieu d’assembler des blocs Audio séparés à la main. Le bloc Onglets organise nativement du contenu en panneaux à onglets, un motif de mise en page qui nécessitait jusqu’ici une extension tierce. Ni l’un ni l’autre n’est révolutionnaire pris isolément, mais tous deux comblent des manques que les constructeurs de pages rafistolaient depuis des années.
Téléversement des médias et accessibilité : moins de friction au quotidien
Côté médias, le traitement des images se fait désormais côté client avant même le début du téléversement. La médiathèque défile à l’infini par défaut au lieu de paginer, et l’API REST valide les dimensions des images avec une qualité d’encodage ajustée à leur taille. Rien de tout cela ne se présente comme un réglage à activer consciemment : vous remarquerez simplement que les téléversements paraissent un peu moins pénibles, en particulier sur une médiathèque de plusieurs milliers d’éléments.
L’accessibilité a aussi capté une attention réelle sur ce cycle : un mécanisme partagé standardise désormais les noms accessibles et les infobulles dans l’administration, la hiérarchie des tableaux d’administration est plus claire pour les lecteurs d’écran, et le contraste comme la navigation au clavier gagnent encore en finesse. D’après le Field Guide, l’accessibilité a concentré 46 tickets sur ce cycle, la plus élevée des trois zones d’effort citées par le Field Guide, devant l’interface (40) et les écrans d’administration (28). C’est une part inhabituellement large de l’effort d’une version consacrée à quelque chose que la plupart des utilisateurs ressentiront sans jamais le voir affiché en une.
L’édition collaborative en temps réel est-elle enfin là ?
Pas encore. L’édition collaborative en temps réel est en développement actif depuis plusieurs cycles, et elle avait déjà été retenue une première fois lorsque la 7.0 était sortie sans elle. Le Field Guide est explicite : elle a de nouveau reçu des tests et des retours approfondis tout au long du cycle de la 7.1, mais elle n’est pas activée dans cette version finale non plus. La migration prévue de l’éditeur vers React 19 est elle aussi mise en pause pour la 7.1, mais pour une raison distincte : après l’avoir brièvement activée dans le plugin Gutenberg, des incompatibilités sont apparues entre anciennes et nouvelles versions de React dans la façon dont les extensions l’utilisent, forçant un retour en arrière — la migration continue comme expérimentation dans le plugin plutôt que d’intégrer le cœur.
Si vous attendiez de pouvoir coéditer un article avec un collègue comme dans un document partagé, l’attente continue. La feuille de route du projet mentionne encore des questions ouvertes sur le mécanisme de stockage à retenir et sur la part de la fonctionnalité à livrer d’un coup, ce qui laisse penser à un choix délibéré plutôt qu’à un simple retard.
Ce qui change pour les développeurs : l’API Abilities continue de grandir
WordPress 7.1 continue d’investir dans l’API Abilities, cette brique d’infrastructure que nous avions déjà présentée quand l’AI Client avait fait son entrée dans la 7.0 (nous ne répétons pas cet article ici, juste le fil de continuité). Ce cycle ajoute un filtrage amélioré via wp_get_abilities(), des hooks de cycle de vie d’exécution permettant aux extensions de réagir pendant qu’une ability s’exécute, un indicateur d’exposition public unifié, et une préparation de schéma JSON visant l’interopérabilité côté client. Vingt nouveaux hooks sont livrés au total, dix-neuf filtres et une action.
Deux ajouts plus modestes complètent le volet développeur. Une nouvelle API SVG Icon offre aux extensions et aux thèmes une manière standardisée d’enregistrer et de restituer des icônes personnalisées, plutôt que de laisser chacun bricoler sa propre gestion de SVG inline. Et une première fondation de design tokens, bâtie sur des styles partagés, vise à rendre les interfaces tierces plus cohérentes avec le cœur au fil du temps, même si le bénéfice visible prendra encore quelques cycles pour se concrétiser.
Styles globaux et barre d’admin persistante : les petits conforts qui comptent
Les Styles globaux gagnent des variations de style responsives et des viewports configurables : un choix de style peut désormais s’adapter selon le point de rupture au lieu de s’appliquer identiquement partout. S’y ajoute un support natif de l’ombre portée sur le texte pour les blocs qui le souhaitent. La barre d’admin, de son côté, reste visible et persistante lorsque vous naviguez entre les écrans de l’éditeur et le site public, au lieu de disparaître puis de réapparaître selon l’endroit où vous vous trouvez.
Rien de tout cela ne fera à soi seul un communiqué de presse. Ensemble, ce sont pourtant le genre de détails qui rendent WordPress un peu plus prévisible à utiliser au quotidien, ce qui vaut mieux que ce que cela laisse paraître.
Notre avis
Au-delà des deux réglages qui ont circulé cette semaine, WordPress 7.1 se lit comme une version de consolidation : elle achève un chantier ouvert par la 7.0 (l’éditeur en iframe), fait grandir une infrastructure introduite par la 7.0 (l’API Abilities), et tient sa position sur une fonctionnalité que beaucoup espéraient voir arriver (l’édition collaborative en temps réel, toujours absente). C’est une histoire cohérente, même si elle ne tient pas en deux lignes de résumé.
Si votre site tourne surtout sur des blocs natifs avec des extensions bien entretenues, la 7.1 s’intègre sans effort à votre rythme de mise à jour habituel : testez en préproduction, vérifiez que vos extensions clés ont confirmé leur compatibilité avec la 7.1, puis mettez à jour la production. Si vous maintenez des blocs personnalisés ou quoi que ce soit qui enregistre encore des meta boxes héritées, accordez une attention particulière à la migration iframe pendant ce passage en préproduction avant de basculer, car c’est le point de cette version le plus susceptible de révéler un cas limite. LA façon la plus sûre d’adopter WordPress 7.1 reste la plus ennuyeuse : la préproduction d’abord, la production ensuite, jamais l’inverse. Pour la checklist complète de mise à jour, ce qu’il faut tester et quand patienter, consultez notre guide prudent pour migrer WordPress. Bonne découverte de WordPress 7.1 !
