Abilities API et un bloc personnalisé : exposer son rendu à un assistant compatible

« L’Abilities API fournit un registre standardisé pour que les plugins et thèmes puissent déclarer des capacités que les systèmes d’intelligence artificielle peuvent découvrir et invoquer de façon fiable », résume la proposition officielle portée par le projet WordPress. Sur une build de développement de WordPress 6.9, dont la sortie stable est prévue en décembre 2025, il est déjà possible de tester concrètement ce que cela change pour un bloc personnalisé.

Ce tutoriel déclare une capacité Abilities API exposant le rendu d’un bloc evenements/programme-jour à un assistant compatible. Il ne couvre pas le protocole MCP complet ni les autres capacités natives fournies par le cœur de WordPress, qui suivent une logique similaire mais un périmètre différent.

Étape 1 — Préparer l’environnement de test

À ce stade, l’Abilities API est disponible via la build de développement de WordPress 6.9 ou via l’extension de référence maintenue par l’équipe du projet, à installer sur un environnement de recette dédié, jamais en production tant que la version stable n’est pas sortie.

Étape 2 — Déclarer la capacité

La capacité se déclare avec wp_register_ability(), en précisant un identifiant unique préfixé par le nom de l’extension, une description en langage naturel destinée à l’assistant, et des schémas d’entrée et de sortie stricts :

function evenements_declarer_capacite_programme() {
    wp_register_ability( 'evenements/lire-programme-jour', array(
        'label'       => __( 'Lire le programme du jour', 'evenements' ),
        'description' => __( 'Retourne la liste des sessions programmées pour une date donnée.', 'evenements' ),
        'input_schema'  => array(
            'type'       => 'object',
            'properties' => array(
                'date' => array( 'type' => 'string', 'format' => 'date' ),
            ),
            'required' => array( 'date' ),
        ),
        'output_schema' => array(
            'type'  => 'array',
            'items' => array( 'type' => 'string' ),
        ),
        'execute_callback'    => 'evenements_executer_lecture_programme',
        'permission_callback' => 'evenements_verifier_permission_lecture',
    ) );
}
add_action( 'abilities_api_init', 'evenements_declarer_capacite_programme' );

Étape 3 — Écrire la fonction d’exécution

La fonction d’exécution réutilise directement la logique du render_callback du bloc, en la transformant pour retourner des données structurées plutôt que du HTML, plus adapté à une consommation par un modèle de langage :

function evenements_executer_lecture_programme( $entree ) {
    $sessions = get_posts( array(
        'post_type'   => 'session',
        'meta_key'    => 'date_session',
        'meta_value'  => $entree['date'],
        'numberposts' => -1,
    ) );

    return array_map(
        fn( $session ) => $session->post_title . ' — ' . get_post_meta( $session->ID, 'intervenant', true ),
        $sessions
    );
}

Étape 4 — Verrouiller la permission

Le permission_callback n’est pas optionnel : sans lui, la capacité serait exécutable par n’importe quel appelant disposant d’un accès à l’API. Pour ce programme d’événement, la lecture reste publique, mais la déclaration explicite du contrôle d’accès reste une bonne pratique systématique, y compris pour les capacités en lecture seule :

function evenements_verifier_permission_lecture() {
    return true; // Lecture publique assumée et documentée, pas oubliée.
}

• Toujours définir permission_callback explicitement, même pour une capacité publique.
• Réutiliser la logique métier existante du bloc plutôt que de la dupliquer pour l’assistant.
• Retourner des données structurées, pas du HTML, pour une consommation fiable par le modèle.

Ce qui reste à observer avant la sortie stable

Le comportement exact de la découverte des capacités par les clients IA, et la stabilité de la signature de wp_register_ability(), restent susceptibles d’évoluer d’ici la sortie stable de WordPress 6.9 en décembre 2025. Ce test sur build de développement vaut donc comme validation de principe, pas comme déploiement définitif sur un site en production.

Tester une API encore en développement a un intérêt réel : comprendre la logique avant sa stabilisation, à condition de ne jamais la considérer comme acquise avant la sortie officielle.

En résumé

Déclarer une capacité Abilities API pour un bloc personnalisé revient, une fois la logique en place, à réexposer un render_callback existant sous une forme structurée et vérifiée par permission. La nouveauté n’est pas dans la logique métier, déjà écrite pour le bloc, mais dans la façon dont elle devient découvrable et invocable par un assistant compatible, sans passer par un serveur MCP séparé.