Réserver

WordPress 7 : ce qui a vraiment changé avec les versions 7.0 et 7.1

par Francis Rozange | Oct 2, 2026 | WordPress

A glass timeline with glowing crystal milestones, one of them left dim

WordPress 7.0 devait sortir le 9 avril 2026. Il est sorti le 20 mai, avec six semaines de retard. Et la fonction que son annonce de version bêta mettait en tête, la collaboration en temps réel sur un même article, n’y figurait pas. Elle n’est pas non plus dans la version 7.1, et elle ne figure pas au programme de la 7.2.

Ce décalage entre l’annonce et la livraison est la meilleure raison d’écrire ce guide. Une annonce de version bêta ne dit pas ce qui sera réellement livré. Or, pour décider d’une mise à jour ou d’un développement, seule compte la version finale.

Nous avons donc tout vérifié sur les sources officielles : les annonces de version sur wordpress.org, les guides de terrain et les notes de développement publiés sur le blog des contributeurs. Ce qui n’y figure pas n’est pas dans cet inventaire. À la date où nous écrivons, la version en cours est la 7.1.2, publiée le 22 septembre 2026.

Le calendrier : de la 7.0 à la 7.1.2 en quatre mois

WordPress 7.0, baptisée « Armstrong » en hommage à Louis Armstrong, est sortie le 20 mai 2026. La date prévue, le 9 avril, a été abandonnée fin mars, pour finaliser des choix d’architecture liés à la collaboration en temps réel. Nous y revenons dans le cas réel.

Suivent quatre versions de maintenance et de sécurité de la branche 7.0 en juillet et août, dont une mise à jour de sécurité forcée le 17 juillet. WordPress 7.1, « Mary Lou » en hommage à la pianiste Mary Lou Williams, sort à l’heure le 19 août 2026.

Les versions 7.1.1 et 7.1.2 suivent les 17 et 22 septembre, la seconde pour une seule faille critique ; les mêmes jours, la branche 7.0 reçoit ces correctifs avec les versions 7.0.5 et 7.0.6. La 7.2 est annoncée pour début décembre 2026.

Au 1er octobre 2026, selon les statistiques de wordpress.org, la 7.1 équipe environ six sites sur dix parmi ceux qui transmettent leur version. Les sites restés sous PHP 7.2 ou 7.3 sont bloqués sur la branche 6.9, qui reçoit encore les correctifs de sécurité à titre de courtoisie, comme toutes les branches jusqu’à la 4.7 : seule la dernière version est officiellement maintenue.

Ce que WordPress 7.0 a changé

Une nouvelle apparence pour l’administration

L’administration adopte un nouveau jeu de couleurs par défaut, baptisé Modern dans les notes de version et affiché « Par défaut » dans le profil ; l’ancien reste proposé sous le nom « Fresh ». Les utilisateurs qui avaient gardé les couleurs par défaut ont été basculés automatiquement lors de la mise à jour, mais chacun peut revenir à l’ancien jeu depuis son profil.

Les changements d’écran s’accompagnent de transitions animées, désactivées quand le système demande de réduire les animations. La palette de commandes dispose d’un raccourci dans la barre d’administration. Une page dédiée à la bibliothèque de polices apparaît, valable pour tous les types de thèmes, et la comparaison des révisions devient visuelle, avec un curseur dans l’éditeur.

Un changement de sécurité discret mérite d’être connu : les rôles Administrateur et Éditeur ne peuvent plus être choisis comme rôle par défaut des nouveaux inscrits, dans Réglages, puis Général. Si l’un d’eux était déjà sélectionné, la Santé du site vous alerte. Notre guide des rôles utilisateurs WordPress explique pourquoi c’était dangereux.

L’éditeur et la mise en page

WordPress 7.0 permet de masquer un bloc selon l’appareil, mobile, tablette ou ordinateur. Attention : le bloc masqué reste présent dans la page, simplement caché par CSS. Les menus mobiles peuvent désormais être construits avec des blocs et des compositions, et chaque bloc peut recevoir son propre CSS personnalisé.

Deux nouveaux blocs arrivent, Fil d’Ariane et Icône. La galerie gagne un diaporama en visionneuse, le bloc Bannière accepte désormais une vidéo intégrée (embed) en arrière-plan, et le paragraphe peut se répartir en colonnes. Les compositions non synchronisées se modifient désormais comme un tout, en ne laissant éditables que les contenus : un changement qui peut surprendre les thèmes qui comptaient sur une édition libre.

Côté développeurs, un bloc peut désormais être déclaré entièrement en PHP, sans JavaScript, avec une fonction de rendu. Notre comparatif des plugins de blocs Gutenberg montre ce que ces nouveautés retirent aux bibliothèques de blocs.

Les fondations de l’IA, sans le battage

L’annonce de la 7.0 présente cette version comme le début d’une nouvelle ère, posant les fondations de l’IA dans WordPress. Concrètement, le cœur reçoit surtout de la tuyauterie et un écran de réglages, mais aucune fonction de génération. Un client d’IA, accessible aux développeurs par la fonction wp_ai_client_prompt(), envoie des requêtes à un fournisseur sans dépendre de l’un d’eux en particulier.

Un nouvel écran de réglages, dédié aux connecteurs, permet d’y brancher Anthropic, Google ou OpenAI. Mais WordPress n’embarque aucun fournisseur : il faut installer le plugin du fournisseur et saisir une clé d’API. Les clés enregistrées en base de données ne sont pas chiffrées, seulement masquées à l’écran ; mieux vaut les définir par une constante ou une variable d’environnement.

Les fonctions de génération de titres, d’extraits, d’images ou de textes alternatifs viennent d’un plugin séparé, nommé simplement AI. Installer WordPress 7.0 ne fait donc rien écrire à votre place. Notre guide sur l’IA, l’Abilities API et MCP détaille ces briques.

Ces plugins ont trouvé leur public : en octobre 2026, le plugin AI dépasse les 50 000 installations actives, comme chacun des plugins de fournisseurs officiels pour Anthropic, Google et OpenAI.

La brique la plus structurante reste pourtant l’Abilities API, apparue en PHP dans WordPress 6.9 : elle permet à un plugin de déclarer ce qu’il sait faire, avec ses paramètres et ses droits. La 7.0 lui ajoute un pendant en JavaScript, et la 7.1 un drapeau unique pour exposer une capacité publiquement, en rappelant qu’exposer n’est pas autoriser : les vérifications de droits restent indispensables.

PHP 7.4 devient le minimum

WordPress 7.0 abandonne PHP 7.2 et 7.3 : la version minimale est désormais PHP 7.4, et la version recommandée PHP 8.3 ou plus. Un site sous PHP 7.2 ou 7.3 ne reçoit pas la mise à jour vers la 7.0 et reste sur la branche 6.9. Depuis mai 2026, WordPress indique aussi prendre pleinement en charge PHP 8.5, sans l’ancienne mention « bêta ».

Vérifiez la version de PHP de votre hébergement avant toute chose ; notre guide sur la version de PHP pour WordPress explique comment la changer sans casse.

Un cadre de verre imbriqué dans un autre, traversé par la lumière

Ce que WordPress 7.1 a changé

Des styles adaptés à chaque écran

La 7.1 ajoute des états Tablette et Mobile dans les styles globaux et sur chaque bloc : une marge, une taille de police ou une couleur peuvent varier selon l’écran, sans CSS. Les points de rupture par défaut sont 480 et 782 pixels, et un thème peut les redéfinir dans son fichier theme.json. Les styles de survol, de focus et d’activation deviennent aussi réglables, notamment pour le bloc Bouton.

L’éditeur toujours dans une iframe

Changement majeur pour les développeurs : l’éditeur d’articles s’affiche désormais toujours dans une iframe, comme l’éditeur de site, quels que soient le thème et les blocs utilisés, y compris avec d’anciennes boîtes méta. En 7.0, ce n’était le cas que sous conditions. Un script qui manipule directement le document de la page pour agir sur l’éditeur ne trouvera plus rien : il doit cibler le document de l’iframe.

Les images traitées dans le navigateur

La compression, le redimensionnement et la création des miniatures peuvent se faire dans le navigateur, grâce à une version WebAssembly de la bibliothèque libvips. Ce mode, actif par défaut, ne fonctionne que dans Chrome et Edge récents, en HTTPS, sur un appareil assez puissant ; Firefox et Safari repassent par le serveur. Une politique de sécurité du contenu trop stricte peut le bloquer. Un filtre permet de le désactiver.

add_filter( 'wp_client_side_media_processing_enabled', '__return_false' );

Notes, barre d’administration et petites choses

Les notes, apparues en 6.9 pour commenter un bloc dans l’éditeur, gagnent le texte enrichi, les mentions avec notifications et les notes sur une sélection de texte. Deux nouveaux blocs arrivent, Onglets et Liste de lecture. La barre d’administration reste visible dans tous les éditeurs, et la médiathèque passe au défilement infini par défaut, désactivable dans chaque profil.

Pour les développeurs, une API d’icônes SVG devient publique, des fonctions d’infobulles accessibles apparaissent, et jQuery UI passe en version 1.14.2, avec quelques fonctions anciennes supprimées.

Le chargement spéculatif, introduit en 6.8 pour précharger la page suivante probable, peut désormais être réglé par des constantes ou des variables d’environnement, ce qui facilite la tâche des hébergeurs. Sur un multisite, depuis la 7.0, marquer un compte comme indésirable ne marque plus automatiquement ses sites comme indésirables.

Le cas réel : la fonction qui n’est jamais arrivée

La collaboration en temps réel devait être la vitrine de WordPress 7.0 : plusieurs personnes modifiant le même article en même temps, comme dans un traitement de texte en ligne. Son retrait est documenté pas à pas sur les blogs officiels des contributeurs. C’est l’histoire la plus instructive du cycle 7.

La promesse

En décembre 2025, la planification de la 7.0 place la collaboration en temps réel en tête, en prévenant qu’elle dépend davantage que d’habitude des serveurs. Des clients de WordPress VIP la testent depuis octobre 2025, et 45 participants à la bêta font des retours encourageants sur les sites construits en blocs.

Le 20 février 2026, la version bêta 1 de WordPress 7.0 la présente en premier, activable sur option pendant la phase de test. La synchronisation repose par défaut sur des requêtes régulières au serveur, à défaut de connexions permanentes que tous les hébergeurs ne proposent pas. Une note de développement précise qu’elle se désactive en présence d’anciennes boîtes méta, pour éviter les pertes de données.

Les fissures

Le 19 mars, la première version candidate est repoussée de cinq jours, notamment à cause des performances de la collaboration. Le 31 mars, Matias Ventura, responsable de la version, annonce un report de quelques semaines pour finaliser des choix d’architecture. La question centrale est le stockage des modifications : des métadonnées d’article, une table dédiée, des données temporaires.

Le 2 avril, Jonathan Desrosiers décrit une situation qu’il qualifie de sans précédent : revenir en phase bêta après une version candidate. Les commits destinés à la 7.1 sont suspendus. Le 29 avril, un appel urgent demande aux hébergeurs de tester la collaboration sur leurs configurations réelles, y compris les hébergements mutualisés sans cache d’objets.

La décision

Le 8 mai 2026, Anne McCarthy annonce que la collaboration ne sera pas livrée avec la 7.0. Matt Mullenweg ne juge pas l’approche assez robuste, en citant la surface de code, les conflits d’accès simultanés, la charge des serveurs, la mémoire et des bugs récurrents révélés par des tests à données aléatoires (fuzzing). Le même jour, les résultats des tests de huit environnements d’hébergement sont publiés.

Ces tests montrent qu’une table dédiée associée à des données temporaires aurait été en moyenne environ 52 % plus rapide que la solution de départ. Mais la décision est prise : la 7.0 sort le 20 mai sans collaboration, et son annonce n’en dit pas un mot. La fonction reste disponible dans le plugin Gutenberg, sur option.

La suite

En juin, lors de la réunion des committers du cœur à WordCamp Europe, la très grande majorité des présents approuve le retrait ; certains regrettent que l’histoire de la fonction ait été mal racontée. Le guide de la 7.1 confirme qu’elle n’est pas activée dans la version finale. Le 18 septembre 2026, un article de Chris Zarate annonce un changement de cap : la collaboration doit être pilotée par le serveur.

L’argument est concret. Un auteur insère un script dans un bloc, un administrateur corrige une faute et enregistre : le script est sauvegardé avec les droits de l’administrateur. Un script automatisé qui lit à 9 heures et écrit à 9 h 03 efface le travail de deux rédacteurs. Le même jour, la feuille de route de la 7.2 écarte délibérément la collaboration, plutôt que de l’annoncer pour la retirer ensuite.

Ce que l’histoire enseigne

Une fonction annoncée en version bêta n’est pas une fonction livrée : vérifiez toujours l’annonce finale et le guide de terrain. Les anciennes boîtes méta freinent les fonctions modernes de l’éditeur : les plugins qui en dépendent sont le premier risque à auditer. Enfin, l’hébergement compte : une fonction qui écrit souvent en base profite nettement d’un cache d’objets persistant.

Les autres annonces qui ne sont pas arrivées

La collaboration n’est pas la seule fonction annoncée puis reportée. Le masquage du bloc Classique dans l’outil d’insertion, annoncé en juin 2026 pour la 7.1, a été annulé début juillet, et le plugin prévu pour le réactiver a été fermé. Le passage à React 19 a été repoussé au-delà de la 7.1.

Le mode suggestion et les réactions dans les notes sont devenus l’objectif de la 7.2. Les « Guidelines », des règles éditoriales destinées à l’IA, n’ont pas été intégrées à la 7.1. Inversement, le bloc Liste de lecture, retiré du guide de la 7.0, est arrivé en 7.1, comme l’iframe obligatoire de l’éditeur et le traitement des images dans le navigateur, pourtant présenté dans l’annonce de la bêta 1 de la 7.0.

La sécurité du cycle 7 : cinq alertes en trois mois

Le cycle 7 a compté de nombreux correctifs de sécurité, chacun annoncé et documenté sur wordpress.org. Le 17 juillet 2026, la version 7.0.2 a corrigé une chaîne de deux failles, une confusion dans les requêtes groupées de l’API REST et une injection SQL, qui permettait l’exécution de code à distance. La 6.9 a reçu les deux correctifs avec la version 6.9.5 ; la 6.8, touchée seulement par l’injection SQL, a reçu ce seul correctif avec la 6.8.6. La mise à jour a été forcée.

Le 6 août, la 7.0.3 a corrigé douze failles, dont une injection de script sur l’écran de connexion exploitable sans compte et une élévation de privilèges sur les multisites, avec des correctifs reportés jusqu’à la version 4.7. Le 12 août, la 7.0.4 a fermé une exécution de code possible pour un auteur, par l’envoi d’un fichier PostScript piégé, sur les serveurs qui utilisent Imagick et Ghostscript.

Le 17 septembre, la 7.1.1 a apporté onze correctifs de sécurité, et le 22 septembre, la 7.1.2 a corrigé une seule faille critique : sous certaines conditions, la résolution des modèles de page pouvait inclure un fichier PHP situé hors des thèmes et mener à l’exécution de code. La leçon est simple : chaque version mineure compte, et c’est précisément le rôle des mises à jour automatiques.

Ce que les développeurs doivent vérifier

Les changements qui cassent

  • L’iframe de l’éditeur : tout script qui cible le document global depuis l’éditeur doit passer par le document de l’iframe.
  • jQuery UI 1.14.2 : quelques fonctions internes anciennes ont été supprimées.
  • Les listes d’articles : l’en-tête de ligne est passé de la case à cocher à la colonne du titre, ce qui peut casser des sélecteurs CSS ou JavaScript.
  • Les compositions : les attributs de blocs doivent être déclarés comme contenu pour rester modifiables dans les compositions verrouillées.
  • Les médias : avec le traitement dans le navigateur, le hook de génération des métadonnées d’image peut s’exécuter deux fois ; un plugin doit le supporter.
  • La politique de sécurité du contenu : elle doit autoriser les workers en blob: pour le traitement des images.

Les régressions corrigées depuis

La 7.1.1 a corrigé plusieurs régressions de la 7.1, dont une qui pouvait supprimer le contenu d’un utilisateur effacé sur un multisite sans proposer de le réattribuer, et une autre qui servait le plan du site natif en erreur 404 sur les sites sans article publié. Si vous êtes encore en 7.1.0, la mise à jour n’est pas facultative.

Comment mettre à jour vers la 7.1.2 sans risque

Sauvegarder et vérifier la sauvegarde

La documentation officielle le dit sans détour : sauvegardez la base de données régulièrement, et toujours avant une mise à jour, puis vérifiez que la sauvegarde existe et qu’elle est utilisable. Une sauvegarde jamais restaurée n’est qu’une hypothèse, comme le rappelle notre comparatif des plugins de sauvegarde WordPress.

Tester sur une copie

Avant la production, mettez à jour une copie du site : vérifiez la version de PHP, la mention « testé jusqu’à » de vos plugins, l’éditeur avec vos plugins à boîtes méta, l’envoi d’une image et votre politique de sécurité du contenu. Pour tester les prochaines versions avant leur sortie, le plugin officiel WordPress Beta Tester s’installe sur une copie, jamais en production.

Garder les mises à jour mineures automatiques

La mise à jour 7.0.2 du 17 juillet, qui corrigeait une chaîne de failles classée critique, a été forcée par wordpress.org sur les sites concernés. Désactiver les mises à jour mineures, c’est renoncer à ce filet de sécurité. Notre checklist de maintenance WordPress organise ce suivi.

Régler les mises à jour automatiques en connaissance de cause

La documentation officielle décrit les réglages possibles. La constante WP_AUTO_UPDATE_CORE accepte true pour toutes les versions, 'minor' pour les seules versions mineures, ou false. Désactiver entièrement le système de mise à jour est possible, mais fortement déconseillé par la documentation elle-même.

Les filtres plus fins, pour les plugins, les thèmes ou les versions majeures, se placent dans une extension indispensable, au sens de WordPress : un fichier du dossier mu-plugins, chargé en permanence, et jamais directement dans wp-config.php. Depuis la version 5.6, une installation neuve reçoit aussi les mises à jour majeures automatiquement : sur un site sensible, préférez les mineures seules et planifiez les majeures après un test.

Vérifier les fichiers après une installation en ligne de commande

Deux jours après la sortie de la 7.0, un utilisateur a signalé que la commande wp core download de la version stable de WP-CLI produisait une installation cassée : certains chemins de fichiers trop longs, apparus avec le client d’IA, étaient tronqués à l’extraction, sans message d’erreur. Le correctif n’existe qu’en version de développement de WP-CLI. Après toute installation, lancez cette vérification, présentée dans notre sélection de commandes WP-CLI :

wp core verify-checksums

Tableau récapitulatif

Fonction Version Statut À faire
PHP 7.4 minimum 7.0 Livré Vérifier PHP, viser 8.3
Client d’IA et connecteurs 7.0 Livré, sans fournisseur Clés par constante plutôt qu’en base
Nouvelle administration 7.0 Livré Prévenir les utilisateurs
Visibilité des blocs par appareil 7.0 Livré Ne pas compter dessus pour alléger
Styles par écran 7.1 Livré Revoir les CSS spécifiques
Éditeur toujours en iframe 7.1 Livré Tester les plugins à boîtes méta
Images traitées dans le navigateur 7.1 Livré, Chromium seulement Vérifier la politique de sécurité
Collaboration en temps réel Annoncée en 7.0 Retirée, absente de la 7.2 Ne pas l’attendre
Masquage du bloc Classique Annoncé en 7.1 Annulé Rien
React 19 Annoncé en 7.1 Repoussé après la 7.1, peu probable en 7.2 Tester avec Gutenberg

Questions fréquentes

La collaboration en temps réel est-elle dans WordPress 7 ?

Non. Elle a été retirée de la 7.0 le 8 mai 2026, n’est pas activée dans la 7.1 et ne figure pas au programme de la 7.2. Elle n’existe que dans le plugin Gutenberg, sur option.

Faut-il PHP 8 pour WordPress 7 ?

Non. Le minimum est PHP 7.4, la recommandation PHP 8.3 ou plus. Un site sous PHP 7.2 ou 7.3 reste sur la branche 6.9.

WordPress 7 écrit-il du contenu avec l’IA ?

Pas tout seul. Le cœur fournit la tuyauterie ; les fonctions de génération viennent d’un plugin séparé, avec un plugin de fournisseur et une clé d’API de ce fournisseur.

Faut-il attendre avant de passer en 7.1 ?

Non, en passant directement à la 7.1.2, qui corrige les régressions et les failles connues. Testez d’abord sur une copie si vous utilisez des plugins anciens ou une politique de sécurité du contenu stricte.

Pourquoi mes envois d’images diffèrent-ils dans Firefox ?

Parce que le traitement des images dans le navigateur ne fonctionne que dans Chrome et Edge récents. Dans Firefox et Safari, WordPress traite les images sur le serveur, comme avant.

Peut-on garder les anciennes couleurs de l’administration ?

Oui. L’ancien jeu de couleurs reste disponible sous le nom « Fresh », dans le profil de chaque utilisateur.

Conclusion

WordPress 7 n’est pas la révolution que ses annonces laissaient attendre, mais une série de changements solides : une administration rafraîchie, un éditeur plus cohérent, des styles par écran, des images traitées dans le navigateur, et les fondations d’une IA qui reste à brancher. PHP 7.4 devient le minimum, et l’éditeur en iframe oblige les plugins anciens à se mettre à niveau.

L’histoire de la collaboration en temps réel rappelle la règle d’or : seule la version finale compte. Passez à la 7.1.2 après une sauvegarde vérifiée et un test sur une copie, gardez les mises à jour mineures automatiques, et ne bâtissez rien sur une fonction qui n’est qu’annoncée.

Sources

LaFactory conçoit, développe et maintient des sites WordPress et WooCommerce, et développe ses propres plugins. Parlons de votre projet WordPress.

Francis Rozange

Ancien chef de rubrique à Libération, il dirige LaFactory, agence web internationale depuis 1996.

Panier