WordPress 7.1 : nouveautés et faut-il mettre à jour ?

WordPress 7.1 : ce qu’elle apporte et faut-il l’installer ?

WordPress 7.1 sort le 19 août 2026, calée sur WordCamp US. Elle apporte un système de Notes enrichi (mentions, suggestions, réactions), le style responsive et les états hover/focus natifs sans CSS, deux blocs Playlist et Tabs, et retire le bloc Classic de l’inserteur. Ne l’installez pas le jour J sans sauvegarde ni préproduction : attendez de valider vos extensions.

Le fait : une version orientée productivité, pas révolution

Selon la roadmap officielle, WordPress 7.1 est la deuxième version majeure de 2026, après 7.0 « Armstrong » sortie le 20 mai. Elle prolonge l’axe collaboration éditoriale, mais sans livrer la fonctionnalité phare tant attendue : la collaboration en temps réel est reportée pour la deuxième fois consécutive, faute de décisions d’architecture finalisées.

Ce qui arrive réellement, ce sont des améliorations de confort. Le système de Notes gagne les @mentions avec liste de collaborateurs recherchable, le formatage de texte, les fils de discussion multiples et la possibilité d’annoter une sélection précise plutôt qu’un bloc entier, détaille WPBeginner. Côté design, la Beta 1 confirme un pas important vers le responsive intégré : vous pouvez enfin styler pour tablette et mobile, et gérer les états hover/focus/active, sans écrire une ligne de CSS. Deux blocs s’ajoutent (Playlist, Tabs), la gestion des médias passe au traitement d’image côté navigateur (HEIC, AVIF, UltraHDR, WebP) et l’API Icons devient publique pour les développeurs de thèmes et d’extensions.

Pourquoi c’est important pour une PME

Le vrai signal de 7.1 n’est pas une fonctionnalité vitrine, c’est un changement de plancher éditorial : le bloc Classic (core/freeform) disparaît de l’inserteur de blocs par défaut, comme l’annonce Raidboxes. Concrètement, les sites qui produisaient encore leur contenu à l’ancienne, ou dont certaines extensions reposent sur cet éditeur, sont poussés vers Gutenberg complet. Si votre équipe rédige toujours dans l’éditeur classique, ce n’est pas anodin : la bascule se prépare, elle ne s’improvise pas le jour de la mise à jour.

Deuxième point de vigilance, hérité de 7.0 : le socle technique s’est durci. WordPress 7.0 exige désormais PHP 7.4 minimum, avec PHP 8.3 ou supérieur recommandé. Les sites restés sous PHP 7.2 ou 7.3 ne reçoivent tout simplement pas la mise à jour. Avant de viser 7.1, vérifiez donc votre version de PHP côté hébergeur, et rappelez-vous que 7.0 a connu une faille critique « WP2Shell » corrigée en urgence par la 7.0.2 le 17 juillet 2026. Une version majeure fraîche n’est jamais exempte de correctifs de sécurité rapides.

L’angle Peechy : ni le jour J, ni jamais

La bonne posture tient en une phrase de pixel-info : repousser indéfiniment une mise à jour majeure n’est pas une stratégie de sécurité, mais l’installer le jour même sans sauvegarde ni recette n’est pas une stratégie de maintenance. Aucune version majeure ne peut garantir la compatibilité de chaque extension tierce. Le risque réel ne vient presque jamais du cœur de WordPress : il vient d’un plugin ou d’un thème mal maintenu qui casse au contact du nouveau code.

Pour un site vitrine simple, avec un thème à jour et peu d’extensions, la mise à jour quelques jours après la sortie stable est raisonnable. Pour un site e-commerce, un site à forte personnalisation, ou tout site reposant sur des extensions premium critiques, la préproduction n’est pas optionnelle. C’est exactement le type de galère que nous évitons en amont : nous avons déjà documenté comment mettre à jour WordPress sans rien casser et la checklist à dérouler avant une mise à jour majeure.

Le calendrier conseillé est simple : tester dès les Release Candidates sur un environnement proche de la production, sauvegarder de façon restaurable, ouvrir une fenêtre de maintenance courte le jour J, puis surveiller les erreurs et les performances pendant plusieurs jours. Un plan de rollback doit être prêt avant de cliquer : restauration des fichiers et de la base, désactivation ciblée du composant fautif, puis analyse des journaux. Si une mise à jour tourne mal, notre guide pour réparer un site cassé après une mise à jour détaille la marche à suivre, et celui sur les plugins qui cassent après MAJ couvre le rollback propre.

Que faire maintenant

• Vérifiez votre version de PHP : sous 7.4, vous n’aurez pas 7.1. Visez PHP 8.3+ auprès de votre hébergeur.
• Assurez-vous d’être en 7.0.2 minimum aujourd’hui, pour ne pas rester exposé à la faille WP2Shell.
• Listez vos extensions critiques et vérifiez leur compatibilité annoncée avec 7.1, surtout celles liées à l’éditeur.
• Repérez tout contenu encore en bloc Classic : c’est le point de friction spécifique à 7.1.
• Sauvegardez de façon restaurable (fichiers + base) et testez la restauration, pas seulement la sauvegarde.
• Testez sur une préproduction dès une Release Candidate si votre site est complexe ou e-commerce.
• Attendez quelques jours après le 19 août avant la production : laissez remonter les premiers correctifs.

Une version majeure n’est jamais un simple bouton « Mettre à jour ». Sur 7.1, le vrai chantier n’est pas dans les nouveautés, il est dans PHP, vos extensions et votre bloc Classic.