Contact
Rechercher dans les tutoriels Genisoft ESC
Abilities API : ce qu'un agent IA peut lire sur votre WordPress
Actualités

Abilities API : ce qu'un agent IA peut lire sur votre WordPress

WordPress 7.2 bêta 2 poursuit l'Abilities API. Testée sur une install 7.1 : trois capacités par défaut, en lecture seule, filtrées par permission.

Par

WordPress construit depuis la version 6.9 une brique discrète mais structurante : l’Abilities API, le point d’entrée standard par lequel un assistant IA peut lire des informations ou déclencher une action sur votre site. La bêta 2 de WordPress 7.2, publiée le 27 octobre 2026, confirme que ce chantier continue. Nous l’avons ouverte sur une installation réelle pour voir ce qu’elle expose vraiment aujourd’hui, et ce que vous pouvez contrôler.

Ce qui a été annoncé

La bêta 2 de WordPress 7.2 est sortie le 27 octobre 2026 ; la version finale est attendue le 8 décembre 2026. Parmi les chantiers en cours, le billet officiel indique que « le développement continue sur l’Abilities API, notamment la requête de contenu, les capacités requises, et des améliorations de la gestion des schémas et des permissions » (traduction depuis l’anglais).

L’Abilities API n’est pas nouvelle. Elle a été introduite dans WordPress 6.9 puis étendue en 7.1, avec notamment des filtres de validation et une action déclenchée au début de chaque exécution. L’idée : offrir un répertoire normalisé d’« abilities » (capacités), chacune décrite par un schéma JSON d’entrée et de sortie, qu’un plugin peut enrichir et qu’un client IA peut découvrir. C’est la plomberie sur laquelle s’appuient les assistants IA et les serveurs MCP côté WordPress.

Ce que ça change pour un site WordPress

Analyse. Jusqu’ici, quand on parlait d’« IA dans WordPress », chaque plugin inventait sa propre passerelle. L’Abilities API pose une convention commune : une capacité porte un nom (core/get-site-info), un schéma, une fonction d’exécution, des annotations de sûreté, et surtout une fonction de permission. Pour vous, marchand ou éditeur, trois conséquences concrètes.

D’abord, la surface d’exposition devient lisible : on peut lister ce qu’un agent peut demander à votre site, au lieu de le deviner. Ensuite, la permission est attachée à la capacité elle-même : une capacité peut être découverte sans être exécutable. Enfin, les annotations (readonly, destructive) donnent à l’agent — et à vous — une étiquette sur le risque de chaque action. C’est exactement la logique des serveurs MCP, mais intégrée au cœur du CMS.

Notre test

Nous avons travaillé sur un bac à sable local : WordPress 7.1.3, PHP 8.3, sans aucune donnée réelle. Les sorties brutes ont été conservées.

Premier constat, en lisant le code installé (wp-includes/abilities.php) puis en listant à l’exécution : WordPress enregistre trois capacités par défaut, et seulement trois :

core/get-site-info        (catégorie site, readonly, non destructif)
core/get-user-info        (catégorie user, readonly, non destructif)
core/get-environment-info (catégorie site, readonly, non destructif)

Les trois sont en lecture seule. Aucune capacité qui écrit, publie ou supprime n’est livrée par défaut : toute action qui modifie votre site vient d’un plugin qui a enregistré sa propre capacité. Nous l’avons vérifié en ajoutant, via un petit mu-plugin de test, une capacité genisoft/get-store-summary (nombre d’articles et d’utilisateurs). Elle apparaît bien comme 4ᵉ capacité, puis nous l’avons retirée et l’installation est revenue à trois.

Deuxième constat, le plus important : découverte et exécution sont deux choses différentes. La liste des capacités renvoie les mêmes entrées que l’on soit connecté ou non. Mais l’exécution passe par la fonction de permission de chaque capacité. Connectés en administrateur, nous obtenons le résultat ; déconnectés, le même appel renvoie une erreur :

core/get-site-info (admin) → {"name":"WP Veille (tests)","url":"http://localhost/wp-veille",
                              "version":"7.1.3","admin_email":"veille@example.test"}
core/get-site-info (déconnecté) → WP_Error: ability_invalid_permissions

Dans le code, core/get-site-info et core/get-environment-info exigent la capacité WordPress manage_options (administrateur) ; core/get-user-info exige seulement d’être connecté. À noter : core/get-site-info renvoie aussi l’adresse e-mail de l’administrateur à un appelant qui a les droits — un détail à garder en tête quand vous décidez quelle clé ou quel compte vous confiez à un agent.

Troisième constat, côté REST. Les routes existent bien : /wp-abilities/v1/abilities, .../abilities/{nom}/run, .../categories. Un GET de la liste sans authentification renvoie un HTTP 401 rest_forbidden. Autrement dit, même énumérer les capacités à distance demande un compte. Nous n’avons pas testé l’exécution authentifiée par REST (hors périmètre du bac à sable).

Que faire cette semaine

  1. Repérez vos capacités. Si vous êtes en 6.9 ou plus récent, listez ce qui est enregistré (en WP-CLI : wp eval 'foreach(wp_get_abilities() as $a){echo $a->get_name()."\n";}'). Vous saurez quels plugins exposent déjà des actions à l’IA.
  2. Repérez les capacités destructives. Pour chaque capacité ajoutée par un plugin, regardez son annotation destructive et sa fonction de permission. Une capacité qui modifie des commandes ou des réglages doit exiger un rôle fort.
  3. Traitez les comptes d’agent comme des comptes à privilèges. Un agent qui exécute core/get-site-info lit déjà l’e-mail admin. Donnez-lui le rôle minimal, jamais un compte administrateur « au cas où ».
  4. Surveillez la REST. Par défaut, /wp-json/wp-abilities/v1/ exige une authentification (401 sans identifiant dans notre test) ; vérifiez qu’aucun plugin ni réglage ne l’a ouvert sur votre production.
  5. Testez avant d’adopter 7.2. La bêta 2 ne s’installe pas en production ; essayez-la sur une copie si des plugins IA sont en jeu, la sortie finale étant prévue pour le 8 décembre.

Limites et incertitudes

Notre test porte sur WordPress 7.1.3, pas sur la bêta 7.2 : nous décrivons donc l’état stable actuel, pas les changements précis que 7.2 apportera aux schémas et aux permissions. Nous n’avons pas mesuré l’exécution d’une capacité via une requête REST authentifiée, ni le comportement avec un vrai serveur MCP branché. Les noms de capacités d’une proposition de fusion de juillet (core/read-settings, etc.) ne correspondent pas à ceux réellement livrés : nous nous appuyons sur le code installé, pas sur la proposition. Enfin, ceci n’est pas un audit de sécurité : c’est une lecture de ce que le cœur expose par défaut.

Questions fréquentes

L’Abilities API ouvre-t-elle mon site aux IA sans mon accord ? Non. Par défaut, le cœur n’expose que trois capacités en lecture seule, et chacune est protégée par une fonction de permission. L’exécution exige un compte autorisé, et la découverte à distance par REST exige elle aussi une authentification (401 sinon dans notre test).

Dois-je installer WordPress 7.2 maintenant ? Non. La bêta 2 est réservée aux tests. La version finale est prévue pour le 8 décembre 2026. Si vous utilisez des plugins IA ou MCP, essayez la bêta sur une copie pour vérifier leur compatibilité, pas sur votre boutique.

En quoi est-ce lié à WooCommerce et à MCP ? Les capacités sont le vocabulaire commun. Un plugin comme WooCommerce peut enregistrer des capacités « boutique » (lire une commande, par exemple), et un serveur MCP les expose à un assistant. L’Abilities API est la couche de base ; MCP est l’un des canaux qui la consomment.

Comment cet article a été produit. Faits vérifiés dans les sources primaires listées plus bas ; test réalisé le 28 octobre 2026 sur une installation locale WordPress 7.1.3 (sorties conservées). Rédigé avec l’aide de Claude (Anthropic), puis relu et validé par l’équipe Genisoft avant publication.

Sources

Pour aller plus loin :

Agence web PrestaShop & WordPress

Agence web spécialisée PrestaShop et WordPress : création, maintenance, sécurité, performance et référencement. Nos tutoriels sont issus de nos interventions sur de vraies boutiques.

L'agence Genisoft → LinkedIn →