WordPress 7.1, baptisé « Mary Lou », est disponible depuis le 19 août 2026. La version améliore nettement l’édition, les médias et plusieurs API, mais elle modifie aussi des comportements susceptibles d’affecter les extensions, les blocs et les interfaces d’administration personnalisées. Voici la méthode à suivre pour mettre à jour sans transformer une nouveauté fonctionnelle en incident de production.
1. Ce que contient réellement WordPress 7.1
WordPress 7.1 n’est pas une simple version de maintenance. La publication officielle met en avant une barre d’administration persistante dans les interfaces d’édition, de nouveaux réglages responsive dans l’éditeur de site, une refonte de l’édition des médias, des notes collaboratives enrichies et de nouveaux blocs comme les onglets et les listes de lecture.
Le guide technique de la version mentionne également plus de 180 corrections dans le cœur, plus de 630 corrections issues de Gutenberg, une centaine d’améliorations et plusieurs évolutions d’API. Cette densité justifie une recette structurée, même lorsque le site utilise peu l’éditeur de blocs en façade.
Certaines fonctions attendues n’ont en revanche pas été intégrées à la version finale. React 19 et la collaboration en temps réel ont notamment été différés. Il est donc important de travailler à partir des notes de version définitives, et non d’articles publiés pendant le cycle bêta.
2. Des améliorations éditoriales immédiatement visibles
Les équipes de contenu verront rapidement plusieurs changements utiles. Les styles responsive peuvent être ajustés depuis l’éditeur de site, sans ajouter systématiquement du CSS spécifique. La fonctionnalité Notes gagne le texte enrichi et les mentions, tandis que les blocs Playlist et Tabs offrent de nouvelles possibilités de structuration.
Ces fonctions réduisent potentiellement le nombre de composants sur mesure. Elles ne doivent toutefois pas être activées sans vérifier leur comportement avec le thème, les gabarits et les règles éditoriales existantes. Un bloc natif plus récent n’est pas automatiquement préférable à un composant déjà industrialisé, traduit et testé.
Pour un site administré par plusieurs profils, il faut aussi contrôler les droits. Une nouvelle capacité visible pour un administrateur ne doit pas nécessairement être ouverte à un contributeur ou à un client. La recette doit donc être réalisée avec les rôles réellement utilisés, pas uniquement avec un compte administrateur.
3. Un nouveau traitement des images côté navigateur
L’un des changements les plus intéressants concerne les médias. WordPress 7.1 peut effectuer dans le navigateur une partie de la compression, du redimensionnement et de la génération de miniature avant l’envoi au serveur. L’objectif est de réduire la charge PHP et d’éviter certains échecs liés à la mémoire ou aux délais d’upload.
Le bénéfice peut être important pour les hébergements limités ou les contributeurs qui importent directement des photos très lourdes. Il faut néanmoins vérifier trois points : la qualité visuelle obtenue, la conservation des métadonnées utiles et la compatibilité avec les extensions d’optimisation déjà installées.
Une chaîne média qui redimensionne une image dans le navigateur, puis à nouveau dans WordPress et enfin dans un CDN peut produire une dégradation inutile. La mise à jour est donc l’occasion de documenter le pipeline complet : fichier source, transformation locale, tailles WordPress, conversion WebP ou AVIF, mise en cache et diffusion.
4. Les changements techniques à surveiller
WordPress 7.1 exécute désormais systématiquement le canevas de l’éditeur de contenus dans une iframe, pour tous les thèmes. Les extensions qui manipulent directement le document parent, injectent des styles au mauvais niveau ou supposent que le canevas partage le même contexte DOM peuvent rencontrer des régressions.
La version met aussi à jour jQuery UI et fait évoluer plusieurs briques de l’éditeur, notamment DataViews, DataForm, les styles globaux et l’API publique d’enregistrement d’icônes. Cette dernière est utile pour harmoniser les extensions, mais elle applique une liste prudente d’attributs SVG autorisés. Une icône personnalisée utilisant des propriétés non admises peut donc être altérée.
Les tests doivent couvrir les erreurs JavaScript de la console, les écrans d’administration personnalisés, les champs avancés, les blocs maison, les prévisualisations et l’enregistrement des contenus. Une page qui « semble fonctionner » peut cacher une erreur qui ne se manifeste qu’après plusieurs modifications.
5. Les points de vigilance pour YOOtheme et les constructeurs de pages
Sur un site YOOtheme, Elementor, Divi ou équivalent, il serait tentant de considérer les nouveautés Gutenberg comme secondaires. C’est une erreur : le cœur WordPress, la bibliothèque média, les rôles, les API et de nombreuses extensions restent communs à l’ensemble du site.
Pour YOOtheme, il faut au minimum tester l’ouverture et l’enregistrement d’une page, les champs dynamiques, les modèles d’articles, les images responsives, la médiathèque, les shortcodes éventuels et les interactions avec ACF. Il faut également vérifier qu’un article modifié depuis l’éditeur natif ne perd aucun paramètre utilisé par le constructeur.
Les sites multilingues nécessitent une recette supplémentaire : duplication ou traduction d’un contenu, synchronisation des médias, liens entre langues, prévisualisation et mise à jour des métadonnées SEO.
6. La checklist de recette avant production
Une mise à jour sérieuse commence par un clone récent de la production, avec les mêmes versions de PHP, de base de données, de cache et d’extensions. La recette doit ensuite couvrir les parcours suivants :
- connexion, réinitialisation de mot de passe et gestion des rôles ;
- création, modification, prévisualisation et publication d’une page et d’un article ;
- import, recadrage, remplacement et suppression d’une image ;
- édition d’un contenu long contenant blocs, tableaux, boutons et médias ;
- fonctionnement des formulaires, recherches, filtres, espaces privés et appels API ;
- rendu des gabarits sur mobile, tablette et desktop ;
- absence d’erreurs PHP, JavaScript, tâches planifiées ou requêtes anormalement lentes ;
- contrôle des pages stratégiques avec un outil de comparaison visuelle.
Il faut aussi exécuter les tests de non-régression disponibles et vérifier les extensions abandonnées ou non déclarées compatibles. L’absence de message d’alerte n’est pas une preuve de compatibilité.
7. Le plan de déploiement recommandé
Le déploiement doit être réalisé dans une fenêtre contrôlée. Avant l’intervention, sauvegardez les fichiers, la base de données, la configuration du cache et, si possible, un instantané complet de l’environnement. Testez la restauration avant d’en avoir besoin.
Appliquez ensuite la mise à jour en préproduction, corrigez les incompatibilités, puis rejouez la recette avec un échantillon de contenus réels. En production, activez un mode de maintenance court, déployez les mêmes versions validées, videz les caches et effectuez un contrôle immédiat des parcours critiques.
Les premières heures doivent être surveillées : taux d’erreur, journaux PHP, temps de réponse, files de tâches, envois d’e-mails et retours des équipes éditoriales. Le plan de retour arrière doit préciser qui décide, quel seuil déclenche la restauration et comment sont traités les contenus saisis entre-temps.
8. Faut-il mettre à jour immédiatement ?
Une version majeure apporte des améliorations utiles et des correctifs qu’il ne faut pas ignorer. Elle n’impose pourtant pas une mise en production le jour de sa sortie. Pour un site vitrine simple, quelques jours de validation peuvent suffire. Pour un extranet, un commerce en ligne ou une plateforme fortement personnalisée, une campagne de recette dédiée est préférable.
Le bon indicateur n’est pas le nombre de jours écoulés depuis la publication, mais le niveau de maîtrise de votre chaîne de mise à jour. Un site disposant d’une préproduction fidèle, de tests et d’un retour arrière peut adopter rapidement WordPress 7.1. Un site sans sauvegarde testée ni inventaire des extensions doit d’abord sécuriser son exploitation.
Cette approche rejoint notre méthode de reprise de maintenance d’une application métier : observer, reproduire, tester et seulement ensuite modifier la production.
Conclusion
WordPress 7.1 améliore concrètement l’expérience éditoriale et le traitement des médias. Sa valeur dépend toutefois de la qualité du déploiement. Une recette ciblée sur l’éditeur, les images, les extensions et les rôles permet de profiter des nouveautés sans fragiliser les parcours existants.
Partitech accompagne les entreprises dans l’audit, la mise à niveau et la maintenance de sites WordPress et YOOtheme, avec préproduction, tests de non-régression, optimisation des performances et plan de retour arrière.