« Vous pouvez me montrer ce que ça donne concrètement ? » C’est la question qu’un client a posée après avoir lu un billet sur make.wordpress.org évoquant l’Abilities API, cette couche qui permettra de déclarer explicitement les capacités qu’une extension expose aux clients externes comme les assistants IA. Le projet est réel, documenté, activement développé, mais WordPress 6.9 — la version qui doit l’intégrer au cœur — n’est pas encore sortie. Impossible donc de faire une démonstration sur un site de production existant sans installer un plugin expérimental sur un environnement sensible.
La solution retenue a été WordPress Playground : un environnement WordPress complet exécuté dans le navigateur, sans serveur, sans installation, et surtout sans aucun risque pour les sites clients réels. Ce texte détaille comment nous avons construit cette démonstration reproductible, ce qu’elle montre et ce qu’elle ne prétend pas montrer avant la sortie officielle de la fonctionnalité.
Pourquoi Playground plutôt qu’un environnement de staging classique
Un environnement de staging traditionnel implique un serveur, une base de données, et surtout une durée de vie qui dépasse largement celle d’une démonstration. Playground, lui, démarre un WordPress complet directement dans l’onglet du navigateur du client grâce à WebAssembly, sans toucher à aucune infrastructure existante. La démonstration peut être partagée par un simple lien, testée depuis n’importe quel poste, et abandonnée sans laisser de trace une fois la réunion terminée.
C’est aussi la garantie qu’aucune fonctionnalité expérimentale ne se retrouve, même temporairement, sur un site de production accessible publiquement.
Reproduire l’Abilities API avant son intégration au cœur
L’Abilities API n’étant pas encore fusionnée dans le cœur de WordPress au moment de cette démonstration, nous nous sommes appuyés sur le plugin de référence développé par l’équipe du projet, installé directement dans l’environnement Playground via un fichier de « blueprint » — un fichier JSON qui décrit l’état initial souhaité de l’instance : plugins à activer, contenus à créer, options à définir.
{
"landingPage": "/wp-admin/admin.php?page=abilities-demo",
"steps": [
{ "step": "login", "username": "admin", "password": "password" },
{
"step": "installPlugin",
"pluginData": { "resource": "wordpress.org/plugins", "slug": "abilities-api" }
},
{ "step": "activatePlugin", "pluginName": "Abilities API" }
]
}Ce blueprint, une fois hébergé et référencé dans une URL Playground, ouvre directement une instance déjà configurée : plugin installé, activé, et quelques capacités de démonstration déjà déclarées pour illustrer le principe sans que le client ait à taper la moindre commande.
Ce que la démonstration montre vraiment
La démonstration présentée au client couvrait trois éléments concrets :
- La déclaration d’une capacité via la fonction d’enregistrement fournie par le plugin, avec un nom, une description et un schéma d’entrée
- La liste des capacités disponibles, consultable depuis l’administration comme un inventaire lisible
- Un appel simulé depuis un client externe illustrant comment un assistant pourrait invoquer cette capacité une fois le MCP Adapter du cœur disponible
À chaque étape, nous avons rappelé explicitement que ce plugin est une préfiguration, pas la version finale : les noms de fonctions et la structure exacte peuvent évoluer avant la fusion dans WordPress 6.9, prévue en décembre 2025.
Les limites qu’il ne faut jamais cacher au client
Présenter une fonctionnalité avant sa sortie officielle comporte un risque : que le client comprenne qu’elle est déjà disponible en production. Nous avons pris le parti d’afficher, en introduction de la démonstration elle-même, un rappel explicite du statut expérimental et de la date de disponibilité prévue, plutôt que de le mentionner seulement à l’oral pendant la réunion.
Une démonstration honnête dit ce qu’elle ne fait pas encore, avant de montrer ce qu’elle fait déjà.
Pourquoi un lien vaut mieux qu’un rendez-vous en visioconférence
Le lien Playground, contrairement à une capture d’écran ou à un partage d’écran en visioconférence, reste manipulable par le client après la réunion. Il peut cliquer, tester, revenir en arrière, sans dépendre de la disponibilité de l’équipe technique. Sur ce projet, le client a rouvert le lien à deux reprises dans la semaine suivante pour montrer la démonstration en interne à son propre comité de direction, ce qu’une capture figée n’aurait jamais permis.
En résumé
Démontrer une fonctionnalité qui n’existe pas encore dans le cœur de WordPress est possible sans risque, à condition de bien choisir l’outil et de ne jamais laisser planer le doute sur son statut expérimental. Playground, combiné à un blueprint précis et au plugin de référence du projet, permet une démonstration fidèle, reproductible et partageable, en attendant la sortie de WordPress 6.9.
