🎺 WordPress 7.0 « Armstrong » : la première major où WordPress assume l'IA
📚 Introduction
WordPress 7.0 « Armstrong » est arrivé le 20 mai 2026, comme toujours nommé d’après un musicien — cette fois Louis Armstrong. Mais derrière le clin d’œil jazz se cache la première major depuis 5.0 qui change vraiment la donne. WordPress 6.x avait été dédié au Full Site Editing et à la consolidation. 7.0 ouvre un nouveau chapitre : l’IA dans le Core.
Je suis loin d’être un fan inconditionnel de WordPress, mais je continue à le côtoyer pour des clients en agence ou en freelance, et pour développeur WordPress à Strasbourg. Cette release mérite qu’on s’y intéresse, même si on n’est pas dans l’écosystème quotidien. Ce que WordPress fait sur l’IA aujourd’hui touchera demain 43 % du web.
🤖 AI Client et Abilities API
Le cœur de 7.0, c’est l’AI Client intégré au Core et son pendant frontend, le Client-Side Abilities package. Concrètement :
- Un hub central de connexions dans le dashboard. Tu y branches Anthropic, OpenAI, ou ton endpoint maison.
- L’Abilities API (PHP) expose ces capacités aux plugins et aux blocs. Un plugin peut déclarer une ability “generate alt text” et le Core sait l’appeler.
- Le Client-Side Abilities (JavaScript) fait la même chose pour le frontend du dashboard, avec une UI et une command palette intégrées.
C’est exactement la même philosophie que celle qu’on voit côté Laravel avec Laravel Boost ou Laravel AI SDK : standardiser l’invocation des modèles plutôt que de laisser chaque plugin réimplémenter son client OpenAI dans son coin. WordPress n’invente pas le pattern, mais l’installe à l’échelle de son écosystème.
Le plugin officiel AI (à installer séparément) propose immédiatement de la génération d’images, de titres, d’extraits, et d’attributs alt. Ce qui m’intéresse plus, ce sont les abilities que des plugins tiers vont commencer à exposer. SEOPress qui suggère une meta description ? WooCommerce qui rédige une fiche produit ? Tout devient possible sans installer 12 plugins concurrents.
🎨 Dashboard et command palette
Le dashboard reçoit son premier vrai relooking depuis longtemps. Nouveau thème admin, transitions fluides entre écrans, et surtout une command palette (⌘K / Ctrl+K) qui te transporte n’importe où en deux frappes. C’est le pattern qu’on retrouve dans Linear, Slack, ou GitHub. Important sur un dashboard qui a 20 ans et 200 écrans.
La nouvelle page de gestion des fonts centralise typographies block, hybride et classique au même endroit. Plus besoin de plugin dédié pour servir une font locale en RGPD-compliant. C’est dans le Core.
Les révisions deviennent scrollables visuellement — tu glisses sur une timeline et tu vois les changements en aperçu. Pour les rédacteurs en équipe, c’est un gros confort.
🧩 Blocs et design tools
Côté éditeur, plusieurs nouveaux blocs :
- Gallery lightbox : enfin une galerie avec lightbox native, sans plugin Lightbox.js de 2014.
- Heading : un bloc Heading dédié avec contrôle markup fin (utile en sémantique HTML).
- Breadcrumbs : navigation breadcrumbs en bloc, fini les
yoast_breadcrumb()à coller dans leheader.php. - Icons : bibliothèque d’icônes intégrée, configurable par taille et couleur.
Les contrôles de responsiveness par viewport permettent de cacher un bloc sur mobile sans CSS custom. Ça paraît trivial, c’est ce que demandent les rédacteurs depuis des années.
Et enfin, le CSS au niveau bloc : tu peux écrire du CSS directement sur un bloc dans le post, sans toucher au theme. Pratique pour un cas isolé, à utiliser avec parcimonie sinon le maintien long terme devient un cauchemar.
🔧 Côté développeur : enregistrement automatique
Le changement qui va le plus me servir : les blocs PHP-only peuvent être auto-enregistrés côté JS via le flag supports.autoRegister dans block.json. Plus besoin de dupliquer la déclaration JS pour des blocs purement serveur. WordPress expose automatiquement le bloc côté éditeur.
Le Site Editor devient extensible : routing, validation de routes, et un nouveau package @wordpress/boot qui permet aux plugins de construire leurs propres pages dans le Site Editor. Pour ceux qui développent des plugins admin, c’est la fin du add_menu_page() qui ne respecte plus l’UI native.
🎯 Pour qui ça vaut la mise à jour
- Sites éditoriaux : la command palette, les révisions visuelles, et la lightbox justifient la mise à jour à eux seuls.
- Agences : l’auto-enregistrement des blocs PHP simplifie sérieusement le code des thèmes custom.
- Plugins métiers : l’Abilities API est ce que tu attendais pour brancher proprement un assistant IA dans ton plugin sans dupliquer la couche LLM.
- E-commerce : WooCommerce devra suivre rapidement pour exposer ses propres abilities. À surveiller dans les semaines qui viennent.
⚠️ Quelques précautions
- Plugins legacy : comme à chaque major, les plugins non maintenus depuis 2 ans risquent de casser sur les hooks deprecated. Backup et tableau de pré-prod obligatoires.
- AI plugin : le plugin AI est séparé du Core. À installer et configurer manuellement. Et oui, ça facture chez le provider que tu connectes.
- Sécurité IA : exposer une ability LLM côté admin ouvre une surface d’attaque par prompt injection. Limite les rôles habilités à invoquer les abilities.
- Block CSS : tu peux désormais écrire du CSS dans le post. Tu vas le faire. Tes successeurs aussi. Prévois une convention.
🎉 Conclusion
WordPress 7.0 n’invente pas l’IA dans un CMS, mais l’installe au cœur d’un écosystème qui anime 43 % du web. Pour les développeurs Symfony et Laravel qui regardent WordPress de loin, c’est un signal : la couche d’abstraction LLM standardisée arrive partout, et les plugins/packages vont rapidement s’aligner.
Pour les utilisateurs : c’est probablement la meilleure release depuis Gutenberg. Mise à jour à planifier dès qu’un point de stabilité .1 sera sorti (souvent quelques semaines après).