Le scénario est déroutant pour qui le vit. La mise à jour s'installe sans erreur, le site public s'affiche normalement, les pages se chargent, le formulaire de contact fonctionne. Puis quelqu'un ouvre une page pour corriger un horaire, et le constructeur visuel refuse de déplier son panneau de réglages. Ou un bloc affiche un message d'erreur là où se trouvait un tableau de tarifs. Le site est intact, c'est la capacité à le modifier qui ne répond plus.
WordPress 7.1, publiée le 19 août 2026 sous le nom de code Mary Lou, produit exactement ce symptôme. Ce n'est pas une version spectaculaire : plus de trois cents tickets traités, sans fonctionnalité vedette. Mais elle achève un changement d'architecture de l'éditeur annoncé depuis longtemps, qui met en défaut les extensions n'ayant pas fait le travail.
Ce qui change réellement dans l'éditeur
Depuis cette version, l'éditeur de contenu est systématiquement affiché dans un cadre isolé, ce que le vocabulaire technique appelle un iframe : une page autonome chargée à l'intérieur de la page d'administration. Cette isolation existait déjà pour l'éditeur de site, et elle devient la règle pour l'éditeur d'articles et de pages, quel que soit votre thème, quelle que soit la génération des blocs installés, y compris sur les sites qui déclarent des encarts d'administration à l'ancienne.
L'intention est saine. Jusqu'ici, votre contenu était mis en forme dans le même document que l'interface d'administration, et les styles de celle-ci se mélangeaient aux vôtres. Une largeur exprimée en pourcentage de l'écran ne signifiait pas la même chose dans l'éditeur et sur le site, et une règle d'affichage conditionnée à la taille de l'écran mesurait la fenêtre du navigateur au lieu de mesurer la zone d'édition. Résultat classique : une mise en page qui paraissait correcte à la rédaction et se décalait en ligne. Avec l'isolation, ces unités désignent enfin la zone d'édition elle-même, et l'aperçu devient fidèle.
Le prix de cette fidélité est une frontière. Un script d'extension qui lisait le document de la page d'administration pour aller manipuler le contenu ne trouve plus ce qu'il cherche, parce que le contenu vit maintenant dans un document distinct. Les éditeurs sérieux ont publié des versions compatibles avant le 19 août. Les extensions abandonnées, elles, ne le feront jamais.
Pourquoi la panne se voit si tard
Ce mode de défaillance mérite d'être compris, parce qu'il contredit l'intuition.
Une mise à jour qui casse le site public se remarque en quelques minutes : un visiteur appelle, ou le dirigeant voit sa page d'accueil blanche. Ici, rien de tel. Le rendu public ne dépend pas de l'éditeur mais du thème et du contenu déjà enregistré en base, et votre vitrine continue donc de fonctionner.
La panne ne se révèle qu'au moment où quelqu'un veut publier. Sur un site modifié une fois par mois, cela peut prendre trois semaines. Entre-temps, d'autres mises à jour se sont installées et personne ne fait plus le lien avec celle qui a provoqué le problème. C'est le mécanisme décrit dans notre article sur les failles WordPress et la maintenance : le délai entre la cause et le symptôme est ce qui rend le diagnostic coûteux.
L'ordre des opérations, qui n'est pas celui qu'on croit
Face à ce genre de version, le réflexe consistant à mettre à jour le cœur puis à voir ce qui casse est le mauvais ordre.
La bonne séquence commence par les extensions et le thème, puis le cœur. Les éditeurs ayant anticipé l'isolation, leurs versions récentes savent fonctionner dans les deux configurations, avant et après. En les installant d'abord, vous partez d'une base compatible et le passage en 7.1 devient un non-événement. Dans l'ordre inverse, vous fabriquez vous-même la fenêtre de casse.
Tout cela se fait sur une copie de recette, c'est-à-dire un duplicata complet du site sur une adresse non publique, où l'on installe les mises à jour avant de les appliquer en production. C'est le sujet de notre article sur l'environnement de test WordPress, et le seul moyen de découvrir un constructeur défaillant sans qu'un client soit en train de regarder.
Si un constructeur se comporte mal après la bascule, la réponse est presque toujours une mise à jour de l'extension, pas un retour arrière du cœur : revenir en arrière vous replace sur un cœur privé de correctifs de sécurité, ce qui échange un problème gênant contre un problème sérieux. Et si votre thème a été modifié directement dans ses fichiers plutôt que dans un thème enfant, prévoyez du temps supplémentaire, pour les raisons expliquées dans notre article sur le thème enfant.
Les apports qui valent vraiment la mise à jour
Il serait injuste de réduire cette version à un risque de compatibilité, car plusieurs nouveautés servent directement une entreprise qui gère son site elle-même.
Le traitement des images se fait désormais dans le navigateur. La compression, le redimensionnement et la fabrication des vignettes ne sollicitent plus le serveur, ce qui fait disparaître deux erreurs très fréquentes sur les hébergements mutualisés : le dépassement de mémoire et l'expiration du délai d'envoi quand on charge une photo issue d'un téléphone récent. Les formats AVIF et HEIC sont reconnus nativement, ce qui complète ce que nous expliquions sur les images et la vitesse d'un site.
Les réglages d'affichage selon la taille de l'écran deviennent accessibles depuis les styles globaux et depuis chaque bloc, sans écrire de feuille de style, avec aperçu aux différentes largeurs et seuils de bascule paramétrables. Masquer une image uniquement sur téléphone demandait jusqu'ici du code ou un réglage propre au constructeur.
Un véritable éditeur de média remplace enfin l'ancien recadrage sommaire, avec rotation, retournement et métadonnées au même endroit. Et les notes de révision acceptent la mise en forme et la mention d'un collaborateur, sur un passage précis plutôt que sur le document entier, ce qui sert quand un texte est relu à plusieurs avant publication.
Deux annonces qui n'ont pas eu lieu
Il circule deux informations inexactes sur cette version, et il vaut la peine de les corriger.
La première concerne le bloc classique, celui qui permet de conserver un contenu rédigé à l'ancienne. Une proposition visait à le masquer pour les nouveaux contenus. Après discussion et tests, elle a été abandonnée : le bloc classique reste disponible en 7.1. Si un prestataire vous annonce une refonte urgente au motif de sa disparition, la justification ne tient pas.
La seconde concerne l'édition simultanée à plusieurs, souvent présentée comme la grande nouveauté du cycle. Elle n'est pas dans cette version et continue d'être travaillée. Les notes de révision progressent, l'écriture à quatre mains en temps réel, non.
Sur la partie serveur, la recommandation officielle pour une nouvelle installation passe à PHP 8.4 ou 8.5. Le minimum reste très bas par rétrocompatibilité, ce qui n'en fait pas une bonne idée : voir notre article sur la fin de vie de PHP 8.2.
Ce que couvre le contrat de maintenance
Notre méthode tient en quatre temps : inventaire des extensions et du thème, recherche des versions compatibles publiées, installation de la séquence complète sur la copie de recette, puis ouverture de l'éditeur pour vérifier que les gabarits réellement utilisés se modifient encore. Ce dernier point est le seul qui compte, car un site peut afficher zéro erreur et avoir un modèle de page inutilisable. Vient ensuite la production, avec sauvegarde préalable et contrôle des pages sensibles.
Ce périmètre correspond à la maintenance WordPress à 500 HT / an, qui comprend la supervision, les sauvegardes, les mises à jour et un rapport mensuel. Nous intervenons à distance, partout en France et en Suisse. Le détail figure dans l'annonce officielle de WordPress 7.1.
À retenir
WordPress 7.1 ne menace pas votre vitrine, elle menace votre éditeur, et c'est une panne qui se découvre des semaines plus tard, le jour où vous voulez publier. Mettez à jour les extensions et le thème avant le cœur, faites-le sur une copie de recette, et ouvrez réellement l'éditeur sur vos gabarits pour valider. Les apports sur le traitement des images et sur l'affichage selon la taille de l'écran justifient de ne pas rester en arrière.
Si votre site est en 7.1 et que quelque chose se comporte mal côté administration, ou si vous n'osez pas lancer la mise à jour, dites-le nous. Nous testons sur une copie avant de toucher à votre site.