Quand Gutenberg devient la grammaire des agents IA dans WordPress

Dans une interview publiée le 3 septembre par The Repository, Andy Peatling revient sur la construction de Miles, son agent de design pour WordPress. L’entretien arrive à un moment intéressant : Miles est ouvert à tous depuis le 17 août, après plusieurs mois de bêta et de nombreuses itérations depuis mars.

Miles conçoit des directions graphiques, transforme un design validé en thème blocs éditable et peut intervenir sur un site existant avec des blocs WordPress natifs. C’est déjà une rupture avec une grande partie des générateurs de sites IA : la sortie n’est pas seulement une maquette ou une couche propriétaire, elle revient dans le système de blocs.

Mais l’angle le plus intéressant est probablement plus large. Avec la maturité acquise par Gutenberg et le Full Site Editing, l’Abilities API, l’AI Client et les briques MCP développées autour de WordPress, le CMS commence à disposer d’une architecture où un agent peut faire autre chose que produire du texte ou du HTML. Il peut potentiellement travailler à l’intérieur d’une grammaire éditoriale et visuelle déjà définie.

Gutenberg a créé une grammaire avant que les agents en aient besoin

Depuis l’arrivée des block themes, le Site Editor ne se limite plus au contenu d’un article. Headers, footers, templates, navigation, Query Loops, styles globaux et compositions peuvent être représentés avec des blocs.

Les patterns ajoutent une autre couche essentielle : ils permettent de définir des compositions réutilisables. Un site peut ainsi disposer de ses propres sections héro, encarts, grilles, appels à l’action, blocs de témoignages ou mises en page éditoriales. Certaines sont libres, d’autres synchronisées, d’autres encore intégrées au thème.

Pour un humain, cet ensemble forme une interface visuelle. Pour un agent, il peut devenir une grammaire de composition.

C’est une différence importante avec l’approche qui consiste à demander à un modèle : « crée-moi une landing page ». Dans ce second cas, le modèle doit inventer à la fois le contenu, la structure et souvent le système de design. Dans WordPress, une grande partie de ces choix peut déjà être contrainte par le site lui-même.

L’agent n’a alors plus besoin d’inventer une interface. Il peut choisir parmi des éléments autorisés et les assembler.

De la conversation au contenu riche, pas au simple texte

C’est probablement là que se trouve le cas d’usage le plus immédiatement accessible.

Aujourd’hui, une conversation avec une IA débouche encore souvent sur du Markdown, du HTML ou un texte qu’il faut ensuite reporter dans le CMS. Même lorsqu’une API permet de créer directement l’article, le résultat reste généralement centré sur le corps éditorial.

Avec un WordPress exposant proprement ses capacités, le même échange pourrait produire un document beaucoup plus structuré.

Une demande comme « prépare un comparatif de trois solutions, ajoute une FAQ, une section points forts/faiblesses, deux visuels à produire et un CTA final » pourrait devenir une suite d’actions contrôlées : création du brouillon, choix du bon modèle d’article, insertion d’un pattern de comparaison, ajout d’un bloc FAQ fourni par le site, création de blocs image avec leurs emplacements et leurs métadonnées à renseigner, insertion du CTA autorisé par la charte, puis passage du contenu dans le workflow de validation.

Même chose pour des onglets, des accordéons, des tableaux enrichis ou des composants métier : s’ils existent sous forme de blocs ou de capacités exposées par le site, l’agent peut les utiliser sans avoir à réinventer leur markup ou leur comportement.

Le résultat n’est plus « un texte généré par une IA ». C’est une page WordPress native, composée avec les briques du site.

MCP rend ce scénario beaucoup moins théorique

Cette logique se rapproche déjà de ce que permettent les workflows MCP actuels.

L’Abilities API, introduite côté serveur avec WordPress 6.9, fournit un registre standardisé de capacités avec des entrées, des sorties et des permissions définies. Un plugin peut déclarer une action de manière découvrable au lieu de laisser un agent deviner comment appeler une API interne.

Avec WordPress 7.0, la Client-Side Abilities API ajoute le pendant JavaScript de ce registre. La documentation cite précisément des actions comme la navigation ou l’insertion de blocs, et présente cette couche comme un socle pour les agents opérant dans le navigateur. WordPress 7.1 ajoute de son côté des hooks permettant notamment d’étendre la validation des entrées et des sorties d’une Ability.

Le MCP Adapter peut ensuite exposer ces Abilities à un client compatible MCP. Mais la nuance est importante : le MCP Adapter n’est pas intégré au core de WordPress. C’est un package officiel de l’initiative AI Building Blocks, à installer comme plugin ou à intégrer comme dépendance Composer. Pour une agence ou une équipe technique, cette couche agentique suppose donc encore une brique à déployer et à configurer sur le site.

WordPress.com propose de son côté un accès MCP permettant à des assistants externes d’interagir avec les sites, les articles, les commentaires ou certains réglages.

Dans l’autre sens, WordPress 7.0 a intégré un AI Client indépendant du fournisseur. L’écosystème dispose donc progressivement des deux directions : appeler un modèle depuis WordPress, ou laisser un agent externe appeler des capacités WordPress.

La documentation développeur va déjà jusqu’à montrer comment combiner Abilities API, AI Client et MCP Adapter dans un même plugin.

Ce qui manque n’est donc plus uniquement une connexion technique entre WordPress et les modèles. Le vrai chantier devient la définition des capacités utiles et des garde-fousRègles et filtres (policy, classifiers, allowlists) qui limitent les sorties ou actions dangereuses d’un système IA. qui les entourent.

Le design system devient un garde-fou pour l’IA

C’est ici que Gutenberg peut devenir paradoxalement plus important à l’ère des interfaces conversationnelles.

On pourrait imaginer que le chat remplace l’éditeur. Le scénario le plus solide est probablement l’inverse : le chat pilote, mais l’éditeur contraint.

Le thème définit les styles. Les patterns définissent les compositions réutilisables. Les blocs disponibles définissent le vocabulaire. Les rôles et permissions définissent ce que l’agent peut modifier. Les règles éditoriales définissent les champs obligatoires, les statuts et les étapes de validation.

Dans cette configuration, l’IA ne remplace pas le design system : elle s’appuie dessus.

C’est particulièrement intéressant pour des équipes éditoriales ou des agences. Un agent n’aurait pas besoin de connaître abstraitement « la bonne façon » de construire une page. Il devrait connaître la façon dont ce site précis construit ses pages.

On peut imaginer une bibliothèque de capacités comme : « insérer le pattern FAQ », « ajouter un comparatif », « créer une image à valider », « utiliser le CTA newsletter », « préparer la fiche produit », « appliquer le modèle dossier », « vérifier les champs SEOSearch Engine Optimization : ensemble de pratiques pour améliorer la visibilité organique dans les moteurs de recherche. », ou « soumettre en review ».

Autrement dit, ce que l’on encode aujourd’hui dans une documentation interne, une checklist ou l’expérience d’un intégrateur peut progressivement devenir un arsenal de fonctions accessibles à un agent.

Générer tout le site est possible, mais les usages sont déjà plus fragmentés

Miles va plus loin et montre qu’un agent peut également créer un thème blocs, explorer des directions graphiques et bâtir une structure de site complète. Techniquement, cette direction devient donc de plus en plus crédible.

Mais l’usage réel semble déjà moins linéaire que la promesse « du brief au site terminé ». Dans son entretien avec The Repository, Peatling explique avoir conçu Miles comme une expérience de bout en bout, tout en observant que les utilisateurs s’en servent souvent de manière plus fragmentée : certains s’arrêtent à l’idéation, tandis que d’autres l’utilisent surtout pour modifier ou redessiner des sites existants.

Ce constat résonne particulièrement avec une lecture plus « agence » de WordPress.org.

Sur WordPress.com, la génération d’un site complet à partir d’une conversation répond à un problème clair : réduire au maximum le chemin entre une intention et un site fonctionnel pour un utilisateur qui ne veut pas nécessairement comprendre les thèmes, les patterns ou l’architecture du CMS.

Sur WordPress.org, le contexte est souvent plus hétérogène. Le site existe déjà. Il possède un thème, des plugins, des contenus, des conventions, parfois un design system sur mesure et un workflow éditorial spécifique. Une agence ou une équipe technique ne cherche pas forcément un agent qui recommence tout. Elle peut tirer davantage de valeur d’un agent capable de comprendre l’existant et d’opérer proprement à l’intérieur.

C’est aussi là que les difficultés augmentent : compatibilité entre extensions, accessibilitéAccessibilité numérique : rendre les interfaces utilisables par le plus grand nombre (WCAG, sémantique, clavier)., performance, permissions, actions destructrices, migrations, cohérence entre templates ou rollback. Plus l’agent intervient sur la structure globale du site, plus les mécanismes de prévisualisation, d’approbation et de restauration deviennent importants. Miles lui-même met en avant des environnements sandbox privés et des restore points automatiques pour les modifications prises en charge.

WordPress pourrait devenir un CMS particulièrement adapté aux agents

Pendant plusieurs années, Gutenberg a parfois été perçu comme une complexification de l’expérience WordPress. À l’ère des agents, cette complexité structurée peut devenir un avantage.

Un document composé de blocs typés, de patterns identifiables, de templates, de styles partagés et de capacités déclarées est beaucoup plus exploitable par une machine qu’une page libre dont l’architecture dépend d’un empilement de shortcodes ou d’un builder fermé.

La combinaison commence à être lisible :

• Gutenberg fournit la grammaire de contenu et d’interface ;
• le FSE étend cette grammaire à l’ensemble du site ;
• les patterns fournissent des compositions réutilisables ;
• l’Abilities API décrit ce que WordPress et ses extensions savent faire, côté serveur depuis 6.9 et côté client depuis 7.0 ;
• le MCP Adapter officiel, lorsqu’il est installé, ouvre ces capacités aux agents externes ;
• l’AI Client permet aux extensions WordPress d’appeler elles-mêmes des modèles.

Il reste beaucoup à normaliser avant qu’un agent puisse entrer sur n’importe quel WordPress et comprendre instantanément tous les blocs et toutes les conventions d’un site. Et sur le self-hosted, une partie de cette architecture reste volontairement à assembler. Mais le socle est désormais suffisamment concret pour déplacer la discussion.

La question n’est plus seulement : « comment ajouter de l’IA dans WordPress ? »

Elle devient : « quelles capacités de notre WordPress voulons-nous rendre compréhensibles et actionnables par un agent ? »

Et à court terme, la réponse la plus utile n’est peut-être pas « construire le site à notre place ». C’est permettre à l’agent de transformer une intention éditoriale en une page riche, native et conforme au système déjà en place.