« Une ability se déclare, se décrit, et s’exécute : rien de plus, rien de moins » — c’est à peu près ainsi que la proposition d’Abilities API se résume dans les discussions de développement autour du futur noyau de WordPress. L’idée : donner aux extensions un moyen standardisé de déclarer des capacités consultables et actionnables par un assistant externe, plutôt que de bricoler chacune son propre point d’entrée REST.
Cette API n’est pas encore intégrée au cœur de WordPress : elle est encore en discussion pour une intégration ultérieure, prévue autour de la version 6.9. En attendant, un plugin de développement disponible sur le dépôt GitHub du projet permet d’expérimenter dès maintenant la mécanique de déclaration, sur un environnement de recette isolé, sans rien exposer en production.
Ce qu’est une capacité (ability) dans cette proposition
Une capacité regroupe un identifiant unique, un libellé lisible, une description destinée à un assistant automatisé, un schéma d’entrée, et une fonction de rappel PHP qui exécute réellement l’action. Le principe rappelle volontairement celui d’un point de terminaison REST, mais avec un niveau de description supplémentaire pensé pour qu’un assistant IA comprenne, sans documentation externe, ce que fait la capacité et quels paramètres elle attend.
Déclarer une capacité de lecture sur les templates
Le test mené ici se limite volontairement à une action de lecture : lister les templates du thème actif, sans aucune possibilité de modification. Avec le plugin expérimental installé, la déclaration ressemble à ceci :
add_action( 'abilities_api_init', function () {
wp_register_ability( 'monclient/lister-templates', array(
'label' => 'Lister les templates du thème actif',
'description' => 'Retourne la liste des templates du thème actif du Site Editor, avec leur slug et leur zone de contenu.',
'input_schema' => array(
'type' => 'object',
'properties' => array(),
),
'execute_callback' => 'monclient_lister_templates',
'permission_callback' => function () {
return current_user_can( 'edit_theme_options' );
},
) );
} );
function monclient_lister_templates() {
$templates = get_block_templates();
$resultat = array();
foreach ( $templates as $template ) {
$resultat[] = array(
'slug' => $template->slug,
'titre' => $template->title,
);
}
return $resultat;
}Le paramètre permission_callback reprend un mécanisme déjà familier de l’API REST de WordPress : aucune capacité n’est exécutable sans vérification explicite des droits de l’utilisateur ou du contexte d’appel, ce qui évite qu’un assistant mal configuré ne puisse agir au-delà de ce qui est autorisé.
Ce que le test a permis de vérifier
Une fois la capacité déclarée, le plugin de développement expose une liste consultable des capacités enregistrées, et permet de simuler leur exécution directement depuis l’administration, sans passer par un assistant réel. Ce test manuel confirme que la fonction monclient_lister_templates() retourne bien la liste attendue, avec les bons slugs de templates.
Une action volontairement limitée
Aucune capacité d’écriture (modification ou suppression de template) n’a été testée à ce stade. La proposition elle-même insiste sur l’importance de circonscrire précisément le périmètre de chaque capacité, plutôt que d’exposer une action générique trop puissante qu’un assistant pourrait mal interpréter.
Limites de cette expérimentation
Comme cette API n’est pas encore stabilisée dans le cœur, la syntaxe exacte des fonctions de déclaration est susceptible d’évoluer avant toute intégration officielle. Ce test ne doit donc pas être considéré comme une base de production, mais comme une manière de comprendre le principe avant sa disponibilité réelle.
Sur ce genre de proposition encore en discussion, l’intérêt n’est pas de livrer du code définitif, mais de comprendre la logique sous-jacente suffisamment tôt pour anticiper l’architecture des extensions à venir.
Pour aller plus loin
Cette expérimentation ne couvre ni le protocole MCP dans son ensemble, ni les autres capacités natives qui pourraient accompagner une future intégration au cœur de WordPress. Le suivi de cette proposition passe par les discussions publiques sur make.wordpress.org, où les décisions d’architecture sont débattues avant toute stabilisation.
