WordPress 7.0 est sorti le 20 mai 2026 sous le nom de version Armstrong, six semaines après la date du calendrier 2026 initial, et c’est la version majeure la plus lourde de conséquences pour les agences depuis le block editor. Le titre : le core sait désormais parler aux modèles d’IA générative. Le détail qui compte davantage, c’est que le core définit aussi comment un plugin est censé leur parler, ce qui change discrètement ce que chaque plugin du site peut supposer de son territoire.

Pour un rédacteur, les changements visibles restent modestes : une Command Palette, un tableau de bord plus net, un écran de gestion des polices, de meilleures révisions. Pour qui entretient des sites professionnellement, l’essentiel se joue sous l’administration : un magasin d’identifiants dans la table des options, un registre de ce que le site sait faire, et une surface REST qui l’énumère. Rien n’est optionnel, puisque cela arrive avec le core et non avec un plugin choisi.

Voici la lecture du praticien. Ce qui a réellement atterri, ce qui a été retiré douze jours avant la sortie et pourquoi, ce que la mise à jour casse ou non, et quoi dire à un client qui vient de lire un titre sur l’IA dans WordPress.

Faut-il mettre à jour ? Oui, mais allez jusqu’à 7.1 plutôt que de vous arrêter à 7.0. WordPress 7.1 est sorti le 19 août 2026 et 7.0 compte quatre versions de maintenance. Les fonctions d’IA restent inertes tant qu’un administrateur n’a pas enregistré une clé de fournisseur dans Réglages, puis Connectors, donc la mise à jour seule n’envoie aucun contenu nulle part. Le vrai risque tient à la compatibilité ordinaire des plugins et des thèmes, pas à l’IA.

Ce que WordPress 7.0 a réellement livré

La version porte le nom de Louis Armstrong, suivant la convention du projet qui baptise les versions majeures d’après des musiciens de jazz. L’annonce de sortie crédite plus de 875 contributeurs et plus de 420 améliorations et corrections.

La liste de ce qui a atterri est assez courte pour être utile. Le core a gagné un AI Client, une interface PHP indépendante du fournisseur pour envoyer des prompts à des modèles génératifs. Il a gagné un écran Connectors dans les Réglages, où un administrateur enregistre les identifiants du fournisseur. Il a gagné la moitié JavaScript de l’Abilities API, dont la moitié PHP était déjà arrivée en 6.9.

Côté rédaction, il y a une Command Palette sur Ctrl+K ou Cmd+K, un tableau de bord modernisé, une page dédiée à la gestion des polices, un défilement visuel dans les révisions, et de nouveaux blocs Heading, Breadcrumbs et Icons, ainsi qu’un diaporama en lightbox pour les galeries.

Ce qui n’a pas atterri, c’est la fonctionnalité autour de laquelle toute la version avait été construite. L’édition collaborative en temps réel a été retirée douze jours avant le lancement. Cette absence, et sa raison, en disent plus sur l’état actuel du core que la liste des nouveautés.

Pourquoi la date a bougé

La sortie était initialement prévue le 9 avril 2026. Elle a glissé au 20 mai parce que l’édition collaborative n’était pas prête et que le projet refusait de la livrer en l’état. Le billet sur la voie à suivre dit explicitement que le report visait à laisser plus de temps pour traiter les retours de tests sur l’implémentation de la collaboration en temps réel, et le cycle est retourné en bêta tout en conservant des numéros de version de release candidate pour des raisons techniques.

C’est inhabituel. Une version majeure qui repasse en bêta après avoir atteint la RC est un signal fort, et c’était la bonne décision.

L’AI Client : le core livre l’abstraction, pas le modèle

Le fait architectural le plus important de WordPress 7.0, c’est que le core n’embarque ni modèle d’IA, ni clé d’API, ni relation avec un quelconque fournisseur. La note de développement sur l’AI Client énonce clairement que le core de WordPress ne fournit directement aucun fournisseur d’IA.

Ce que le core livre, c’est une interface PHP cohérente. Un plugin appelle wp_ai_client_prompt(), qui renvoie un objet WP_AI_Client_Prompt_Builder, enchaîne la configuration comme using_temperature() ou using_model_preference(), et termine par generate_text() ou generate_image(). Les erreurs reviennent sous forme de WP_Error, les requêtes passent par le transport HTTP de WordPress, et l’ensemble est branché sur le système de hooks.

L’effet pratique, c’est qu’un auteur de plugin n’écrit plus un client HTTP, une boucle de réessai, un écran de stockage de clé et une page de réglages pour chaque fournisseur de modèles. Il décrit ce qu’il veut et le core achemine.

C’est une vraie réduction de code dupliqué. C’est aussi une centralisation de la confiance, et c’est la partie qui mérite réflexion avant d’activer quoi que ce soit.

Ce qu’est un connector

Un connector est la relation enregistrée entre votre site et un service externe. En 7.0, le seul type de connector concerne les fournisseurs d’IA, et il existe trois plugins de référence couvrant Anthropic, Google et OpenAI, installés séparément.

La note de développement sur l’API Connectors décrit la résolution des identifiants. Une clé peut venir d’une variable d’environnement, d’une constante PHP ou d’un réglage en base, vérifiés dans cet ordre, avec des noms d’option suivant le motif connectors_ai_{$id}_api_key.

Un détail mérite l’attention de toute personne responsable d’un site. La note précise que les clés d’API stockées en base ne sont pas chiffrées mais seulement masquées dans l’interface, le chiffrement étant renvoyé à des travaux ultérieurs. Si vous saisissez une clé depuis l’écran d’administration, elle se retrouve en clair dans wp_options, et chaque sauvegarde de cette base contient désormais un identifiant facturable.

Ce que cela signifie si vous ne codez pas

Pour un propriétaire de site, le changement est plus simple qu’il n’y paraît. Rien ne génère, ne résume ni ne réécrit quoi que ce soit tant que deux conditions ne sont pas réunies : un plugin de fournisseur est installé, et quelqu’un a collé une clé fonctionnelle dans Réglages, puis Connectors.

Jusque-là, l’AI Client est une bibliothèque dormante. Passer à WordPress 7.0 n’envoie pas vos articles à un modèle, ne crée de compte nulle part et ne déclenche aucune facture.

Ce que cela fait, en revanche, c’est abaisser la barrière pour le prochain plugin que vous installerez. Un plugin qui devait auparavant vous demander une clé peut désormais en trouver une déjà configurée sur le site et s’en servir. C’est pratique, et c’est exactement le genre de chose sur laquelle écrire une politique avant qu’elle n’arrive par accident.

L’Abilities API et pourquoi la conception des plugins change

L’Abilities API est la pièce qui comptera encore dans trois ans, et elle n’a rien à voir en soi avec l’IA. C’est un registre. Un plugin enregistre une unité de fonctionnalité nommée avec wp_register_ability(), sous la forme namespace/ability-name, avec une description lisible, un JSON Schema pour ses entrées et sorties, un callback d’exécution et un callback de permission facultatif.

La documentation officielle montre le callback de permission comme un contrôle de capacité ordinaire, renvoyant par exemple current_user_can( 'manage_options' ). C’est tout le modèle de sécurité, et il ne vaut que le jugement de l’auteur du plugin.

Une fois les abilities déclarées, d’autres logiciels peuvent les énumérer. On peut remettre à un modèle la liste de ce que ce site précis sait faire, sous forme de schéma, et il peut en appeler une. Une Command Palette côté client aussi, ce qui explique que la moitié JavaScript de l’API soit arrivée dans la même version que la palette.

La conséquence de conception pour les auteurs de plugins est réelle. Une fonctionnalité qui n’était accessible que par votre écran d’administration, avec votre nonce et votre formulaire, devient quelque chose que l’on peut attendre de vous sous forme d’ability, avec un contrat lisible par machine. C’est une autre surface d’exposition et une autre charge de documentation.

Ce qui a changé en 7.1

WordPress 7.1 a resserré le registre plutôt que de l’élargir. La note de développement sur les abilities en 7.1 ajoute les filtres de validation wp_ability_validate_input et wp_ability_validate_output, une action wp_ability_invoked déclenchée au début de l’exécution, et un indicateur de métadonnées public qui contrôle la découvrabilité d’une ability via REST sur /wp-json/wp-abilities/v1/abilities.

Cette note porte aussi la phrase que tout auteur de plugin de journalisation devrait lire. Le hook d’invocation reçoit des entrées brutes, non normalisées, et les développeurs devraient éviter de journaliser ces entrées sans discernement, car elles peuvent contenir des identifiants, des données personnelles ou d’autres informations sensibles.

La collaboration en temps réel et la table qu’il lui fallait

L’édition collaborative repose sur Yjs, un type de données répliqué sans conflit, avec une abstraction de fournisseur de synchronisation. Le core livre par défaut un fournisseur en polling HTTP, choisi plutôt que les WebSockets parce qu’il fonctionne chez n’importe quel hébergeur, et les plugins peuvent remplacer le transport via un filtre.

Le problème n’a jamais été l’algorithme de fusion. C’était l’endroit où vivaient les données de synchronisation. L’implémentation initiale les conservait dans les post meta, choix évident dans WordPress et mauvais choix pour des données qui changent plusieurs fois par seconde.

Les écritures de post meta déclenchent l’invalidation du cache. Éditeur ouvert, les données de synchronisation s’écrivaient en continu, donc chaque écriture vidait les requêtes en cache pour cet article. En pratique, une seule personne éditant une page pouvait maintenir le cache objet persistant du site en vidage permanent pendant toute la session.

C’est une bonne leçon générale sur les post meta. C’est un magasin clé-valeur attaché au cycle de vie du cache du contenu auquel il se rattache, et il convient aux attributs qui changent quand l’article change. Ce n’est pas un brouillon pour de l’état à haute fréquence.

La correction mesurée, et la décision

Les contributeurs ont testé des stratégies de stockage sur huit environnements d’hébergement. L’analyse de performance conclut qu’une table dédiée adossée aux transients était environ 52% plus rapide que l’implémentation existante, et une table dédiée simple environ 37% plus rapide. Avec un cache objet persistant en place, les deux stratégies à transients tombaient à une seule requête en base par envoi.

La table dédiée avec transients a été retenue. Puis, le même jour, la fonctionnalité a été retirée.

L’avis de retrait cite des inquiétudes sur la surface d’exposition, les situations de compétition, la charge serveur, l’efficacité mémoire et les bugs récurrents trouvés par fuzzing, et indique que la décision a été prise pour livrer aux utilisateurs un WordPress 7.0 stable et fiable.

Où en est-on aujourd’hui

Ce n’est pas non plus sorti en 7.1. Le guide de terrain de 7.1 indique que l’édition collaborative en temps réel a reçu des tests et des retours nourris pendant le cycle de WordPress 7.1, mais qu’elle n’est pas activée dans la version finale.

Notes, la fonctionnalité voisine mais distincte qui permet de commenter au niveau du bloc, est bien sortie et a été améliorée en 7.1 avec du texte enrichi et des mentions avec @. Si un client demande une coédition à la manière de Google Docs dans WordPress, la réponse honnête aujourd’hui est que Notes couvre le flux de relecture et que la saisie simultanée n’est toujours pas dans le core.

Les changements d’administration et les tickets qu’ils génèrent

Deux changements vont produire des demandes de support, et aucun des deux n’est un bug.

La Command Palette sur Ctrl+K ou Cmd+K est vraiment rapide une fois apprise, mais Ctrl+K est le raccourci d’insertion de lien dans beaucoup d’éditeurs, et certains utilisateurs signaleront que l’insertion de lien est cassée. Elle ne l’est pas ; c’est le contexte du focus qui décide quel gestionnaire l’emporte.

Le tableau de bord modernisé est le plus gros morceau. Tout client dont le personnel a été formé sur des captures d’écran dispose désormais d’un support de formation périmé, et tout plugin qui injectait du balisage dans les écrans d’administration en supposant des classes ou une structure DOM particulières peut s’afficher de travers. C’est cosmétique plutôt que fonctionnel, mais cela arrive le jour de la mise à jour, sur chaque site, pour chaque utilisateur, ce qui en fait la partie la plus visible de la version pour ceux qui ne développent pas.

Prévoyez une heure par client pour une courte note écrite avec de nouvelles captures avant toute mise à jour. C’est moins cher que la même explication donnée quinze fois par e-mail.

La vraie question de compatibilité

La numérotation suggère une version qui casse. Les prérequis PHP disent le contraire. Comme l’expose la clarification sur le support de PHP, la version minimale de PHP prise en charge est 7.4 depuis WordPress 7.0, et la version minimale recommandée reste 8.3. Le support de PHP 7.2 et 7.3 a été abandonné dans cette version.

La clarification retire aussi l’ancienne étiquette bêta appliquée aux versions récentes de PHP, et acte le support complet de PHP 8.5 dans WordPress 6.9 et 7.0.

L’écart entre supporté et raisonnable est tout l’enjeu. PHP 7.4 est arrivé en fin de vie en novembre 2022, donc un site qui franchit tout juste le minimum tourne sur un interpréteur sans correctif de sécurité depuis près de quatre ans. Si votre hébergement est encore en 7.4 en 2026, la version de WordPress n’est pas votre problème le plus urgent.

Les casses suivent en pratique un schéma prévisible. Les plugins abandonnés lâchent en premier, en particulier tout ce qui manipule le DOM d’administration ou l’iframe de l’éditeur. Les thèmes sur mesure au style d’administration codé en dur s’affichent mal. Les page builders qui embarquent leurs propres bundles React sont la source habituelle des pages blanches dans l’éditeur, et ce sont aussi les plus rapides à corriger.

Une procédure de mise à jour concrète

Faites une préproduction. Clonez la production, base comprise, vers un environnement non indexable et qui n’envoie pas d’e-mails. Rien de ce qui suit ne mérite d’être fait sur un site en ligne.

Notez l’état de départ. Relevez la version de PHP, la liste des plugins et thèmes avec leurs versions, et la version actuelle de WordPress. Prenez des captures des deux ou trois écrans d’administration que le client utilise chaque jour.

Mettez d’abord à jour WordPress seul. Laissez les plugins et thèmes intacts, puis parcourez le front, l’éditeur d’articles, l’éditeur de site, le tunnel WooCommerce s’il existe, et tous les écrans d’administration sur mesure. Une panne ici appartient au core ou à une extension incompatible, et séparer cela d’une mise à jour de plugin est toute la raison de procéder dans cet ordre.

Mettez ensuite à jour les plugins par petits lots, en retestant entre les lots, pour qu’une régression ait une courte liste de suspects.

Consultez les journaux d’erreurs plutôt que de regarder les pages. Les notices PHP issues d’un appel déprécié ne s’affichent pas toujours et remplissent un journal en silence pendant des mois.

Laissez l’écran Connectors vide. Livrez la mise à jour sans fournisseur d’IA configuré, et traitez son activation comme un changement séparé et délibéré, avec sa propre validation. Notre checklist de renforcement WordPress couvre les contrôles autour, et le guide d’audit de performance couvre ce qu’il faut mesurer ensuite.

Gouvernance : ce qu’un connector a le droit de faire

Voici la question que crée la couche des abilities et qu’aucun auteur de plugin ne peut trancher à votre place. Un plugin tiers peut enregistrer une ability qui lit des fiches clients, exporte des utilisateurs ou modifie du contenu publié, et un modèle ayant accès au registre peut l’appeler. Le callback de permission est un contrôle de capacité, donc le modèle agit avec les droits de la personne connectée.

Si cette personne est administrateur, le modèle peut faire des choses d’administrateur. Ce n’est pas un défaut de conception, c’est la conception qui fonctionne comme documenté. Cela veut dire que le choix des connectors présents sur un site est une décision de protection des données, pas une préférence informatique.

Le contenu d’un CMS est rarement de la simple prose marketing. Commentaires, envois de formulaires, commandes et profils utilisateurs sont des données personnelles, et les envoyer à un modèle externe est un traitement que vous devez pouvoir justifier. Les recommandations de l’ICO sur l’IA et la protection des données posent les attentes de responsabilité et de transparence, dont la protection des données dès la conception.

Le minimum pratique pour un site client est une courte politique écrite : quels connectors sont autorisés, qui peut en ajouter, quelles abilities sont exposées publiquement via REST, et quelle est la position de conservation chez le fournisseur. Écrivez-la avant que quelqu’un ne colle une clé, car après, ce sera un rapport d’incident et non une politique.

Ce qui arrive ensuite

WordPress 7.1 est arrivé le 19 août 2026 avec des contrôles de style responsives dans les Global Styles, une barre d’administration persistante dans les éditeurs, une vraie modale d’édition des médias, des blocs Playlist et Tabs, et les améliorations de Notes déjà citées. Il a aussi achevé le passage à un éditeur d’articles en iframe, y compris pour les sites déclarant d’anciennes meta boxes, et c’est le changement le plus susceptible d’exposer un vieux plugin.

WordPress 7.2 est prévu comme dernière version majeure de 2026. La page de la version 7.2 place la sortie finale dans la fenêtre du 8 au 10 décembre 2026, avec des bêtas à partir de fin octobre. Ce calendrier est prévu et non livré, et ce projet a déjà déplacé une date de version majeure cette année.

L’édition collaborative reste le candidat évident pour une future version, mais elle en a maintenant manqué deux, et personne ne devrait promettre une date à un client.

Ce que cela change commercialement

Trois conversations client changent, et une seule porte sur l’IA.

La première est celle de la mise à jour. WordPress 7.0 et 7.1 méritent d’être facturés comme une mise à jour pilotée avec passage en préproduction, parce que l’éditeur en iframe et la refonte de l’administration exposent réellement les vieilles extensions. Vendre cela en forfait, avec un plan de test écrit, est plus honnête et plus rentable que de l’absorber dans un contrat de maintenance et de découvrir un page builder cassé à 18h.

La deuxième est la gouvernance. La politique des connectors, la revue des abilities et la gestion des identifiants sont du conseil facturable qui n’existait pas avant mai 2026, et cela convient bien mieux à une agence qu’à une équipe marketing interne.

La troisième est la réalisation. L’AI Client supprime la moitié ennuyeuse de la construction d’une fonction d’IA dans un site, ce qui abaisse le prix de la plomberie et élève la valeur de savoir quoi construire. Si vous pesez cela face à un développement sur mesure, notre comparaison entre WordPress et le développement sur mesure montre où passe la ligne, et nos notes sur les tarifs des développeurs WordPress montrent ce que le travail devrait coûter.

Mecanik prend en charge les montées de version du core, la gouvernance des connectors et le travail sur les fonctions d’IA dans le cadre de nos services de développement WordPress et d’intégration d’IA. Le schéma que nous voyons est constant : la mise à jour elle-même est une routine, et les surprises coûteuses viennent d’extensions que personne n’avait relues depuis trois ans.

Questions fréquentes

Quand WordPress 7.0 est-il sorti et pourquoi a-t-il été retardé ? WordPress 7.0, nom de version Armstrong, est sorti le 20 mai 2026, six semaines après la date du 9 avril prévue au calendrier initial. Le report visait à traiter les retours de tests sur l’implémentation de l’édition collaborative en temps réel, et le cycle est repassé en bêta après avoir atteint la release candidate. L’édition collaborative a finalement été retirée de la version le 8 mai 2026.

WordPress 7.0 envoie-t-il mes contenus à un fournisseur d’IA ? Non. Le core livre un AI Client mais n’embarque aucun fournisseur d’IA, aucun modèle et aucune clé d’API. Rien n’est envoyé nulle part tant qu’un administrateur n’a pas installé un plugin de fournisseur et enregistré un identifiant fonctionnel dans Réglages, puis Connectors. Jusque-là, l’AI Client est une bibliothèque dormante qui ne coûte rien et ne transmet rien.

À quoi sert l’Abilities API ? C’est un registre qui permet à un plugin de déclarer une unité de fonctionnalité nommée, avec des entrées et sorties en JSON Schema, un callback de permission et un callback d’exécution. D’autres logiciels, dont les modèles d’IA et la Command Palette, peuvent alors énumérer ce qu’un site sait faire et l’appeler. La moitié PHP est arrivée dans WordPress 6.9 et la moitié JavaScript dans 7.0.

Quelle version de PHP WordPress 7.0 exige-t-il ? La version minimale prise en charge est PHP 7.4 depuis WordPress 7.0, qui a abandonné le support de PHP 7.2 et 7.3. La version minimale recommandée reste PHP 8.3. Comme PHP 7.4 est arrivé en fin de vie en novembre 2022, se contenter du minimum revient à faire tourner un interpréteur non maintenu, alors traitez 8.3 ou plus comme la vraie exigence.

L’édition collaborative en temps réel est-elle disponible ? Pas dans le core. Elle a été retirée de WordPress 7.0 douze jours avant la sortie, pour des inquiétudes sur les situations de compétition, la charge serveur et l’efficacité mémoire, et elle n’est pas non plus activée dans WordPress 7.1. La fonctionnalité distincte Notes, qui permet des commentaires au niveau du bloc avec des mentions, est bien sortie et couvre la relecture, pas la saisie simultanée.