Avec la sortie de WordPress 6.9 en décembre 2025, l’Abilities API a rejoint le cœur du logiciel après avoir circulé plus d’un an sous forme de plugin de fonctionnalité porté par l’équipe travaillant sur l’intégration entre WordPress et les agents d’intelligence artificielle. Plusieurs clients nous ont demandé, dans la foulée, si leurs extensions maison devaient être réécrites pour « être compatibles » avec cette nouveauté. La réponse courte est non, mais elle mérite d’être détaillée pour éviter deux excès inverses : ignorer complètement le sujet, ou se précipiter sur une réécriture non justifiée.
Ce billet ne couvre pas la construction d’une ability à proprement parler, sujet plus technique traité dans notre catégorie consacrée à l’intelligence artificielle et au protocole MCP. Il se concentre sur ce qu’un mainteneur d’extension doit vérifier ou envisager d’adapter, sans réécrire son architecture existante pour autant.
Ce que l’Abilities API introduit concrètement
À sa base, l’Abilities API fournit un registre central où une extension ou un thème peut déclarer des « abilities », des actions ou des capacités d’information nommées, décrites de façon structurée, avec un schéma d’entrée et de sortie explicite. Cette déclaration passe par une fonction dédiée, wp_register_ability(), appelée typiquement sur le hook abilities_api_init, hook prévu spécifiquement pour ce moment d’enregistrement, de la même façon que rest_api_init sert à enregistrer des routes REST.
add_action( 'abilities_api_init', function() {
wp_register_ability( 'mon-extension/lister-commandes-en-retard', array(
'label' => __( 'Lister les commandes en retard', 'mon-extension' ),
'description' => __( 'Retourne les commandes dont la livraison dépasse le délai prévu.', 'mon-extension' ),
'input_schema' => array( 'type' => 'object', 'properties' => array() ),
'output_schema' => array( 'type' => 'array' ),
'execute_callback' => 'mon_extension_lister_commandes_en_retard',
'permission_callback' => function() {
return current_user_can( 'manage_woocommerce' );
},
) );
} );L’objectif de ce registre est de permettre à des agents logiciels, notamment via un adaptateur exposant ces abilities au protocole MCP, de découvrir dynamiquement ce qu’un site WordPress est capable de faire, plutôt que de deviner ou de coder en dur des intégrations propres à chaque extension.
Ce qui ne change pas pour une extension existante
Le point le plus rassurant à retenir : aucune extension existante ne cesse de fonctionner du fait de l’arrivée de cette API dans le cœur. Il ne s’agit pas d’un remplacement des hooks, des routes REST ou des capacités classiques, mais d’une couche additionnelle, purement optionnelle, que rien n’oblige à adopter. Une extension qui n’enregistre aucune ability continue de fonctionner exactement comme avant 6.9.
Ce qu’un mainteneur devrait vérifier malgré tout
La confusion avec les capacités WordPress classiques
Le terme « ability » prête à confusion avec les capacités WordPress traditionnelles, gérées via current_user_can() et le système de rôles. Il ne s’agit pas de la même chose : une ability décrit une action métier de haut niveau exposable à un agent, tandis qu’une capacité reste le mécanisme de permission sous-jacent qui continue, d’ailleurs, à être vérifié dans le permission_callback de chaque ability enregistrée. Un mainteneur doit éviter de mélanger les deux concepts dans sa documentation interne, sous peine de confusion pour les développeurs qui reprendront le code plus tard.
Le risque d’une action destructrice mal encadrée
Toute extension qui déclarerait une ability exécutant une action irréversible, comme la suppression d’un contenu ou l’envoi d’un paiement, doit s’assurer que son permission_callback reste au moins aussi strict que celui qu’elle appliquerait à l’équivalent humain de cette action dans l’interface d’administration. Le fait qu’un agent logiciel appelle cette action plutôt qu’un humain ne justifie aucun assouplissement des vérifications de permission.
La cohérence des schémas déclarés
- Vérifier que le
input_schemaet leoutput_schemadéclarés reflètent fidèlement ce que la fonction de rappel accepte et retourne réellement, un agent s’appuyant entièrement sur cette description pour construire ses appels. - Éviter de dupliquer une route REST existante sous forme d’ability sans réfléchir à la granularité attendue : une ability trop large, mélangeant plusieurs responsabilités, devient difficile à décrire précisément dans son schéma.
- Ne pas exposer par réflexe toutes les fonctionnalités d’une extension sous forme d’abilities : seules celles qui ont un sens pour un agent externe, en dehors du contexte d’un écran d’administration, méritent cette déclaration.
Une adoption qui reste, pour l’instant, à la carte
Sur les projets clients suivis depuis la sortie de WordPress 6.9, aucun n’a jugé urgent de déclarer des abilities pour ses extensions existantes, faute de cas d’usage concret impliquant un agent IA côté client à ce stade. La situation évoluera probablement à mesure que des outils tiers s’appuieront davantage sur ce registre, mais la prudence reste de mise avant d’investir du temps de développement sur une exposition d’abilities qui ne répond encore à aucune demande réelle.
Un repère que nous donnons à nos clients sur ce sujet précis : l’Abilities API mérite d’être suivie de près, pas nécessairement adoptée immédiatement. Rien dans son arrivée en 6.9 n’impose de délai ni d’obligation à une extension déjà stable.
En résumé
L’arrivée de l’Abilities API dans WordPress 6.9 n’oblige aucune extension existante à évoluer dans l’urgence. Elle introduit un vocabulaire commun pour décrire des actions exposables à des agents logiciels, distinct des capacités classiques de permission, et son adoption reste pour l’instant une décision à prendre au cas par cas, en fonction de besoins réels plutôt que par anticipation d’un usage encore hypothétique.
