« wp_register_ability() » : cette fonction, introduite avec l’Abilities API de WordPress 6.9 en décembre 2025, permet à une extension de déclarer une capacité que des agents logiciels peuvent découvrir et exécuter, chacune assortie d’un schéma d’entrée, d’un schéma de sortie et d’une fonction de vérification des permissions. Le principe intéresse directement l’accessibilité : si une capacité déclare à l’avance ce qu’elle va modifier sur un site, rien n’empêche d’y accrocher un contrôle avant exécution.
Ce premier passage en revue porte sur trois catégories de capacités exposées par un site WordPress équipé de l’Adaptateur MCP publié pendant l’été 2025 : publication de contenu, modification de menu de navigation, et changement de paramètres visuels globaux. L’objectif : classer par impact ce que le contrôle préalable permet réellement de vérifier avant qu’un agent ne déclenche une action.
Impact élevé : la publication de contenu structuré
La capacité de publication d’un article, une fois déclarée via wp_register_ability(), expose un schéma d’entrée qui décrit précisément la structure attendue du contenu. C’est là que le gain est le plus net : un contrôle préalable peut inspecter ce contenu avant publication et vérifier des points simples mais décisifs, comme la présence d’un texte alternatif sur chaque image ou l’absence de saut de niveau de titre.
wp_register_ability( 'mon-theme/publier-article', array(
'label' => 'Publier un article',
'input_schema' => array( /* ... */ ),
'permission_callback' => 'verifier_droits_redaction',
'execute_callback' => 'verifier_accessibilite_puis_publier',
) );
La fonction verifier_accessibilite_puis_publier peut alors refuser l’exécution ou simplement journaliser un avertissement si le contenu proposé par l’agent contient une anomalie détectable automatiquement, avant même que l’article n’atteigne la base de données.
Impact moyen : la modification de menu de navigation
La capacité de modification d’un menu déclare en entrée la liste des éléments à ajouter, déplacer ou retirer. Le contrôle préalable peut ici vérifier des points plus limités : cohérence de l’ordre logique du menu, absence de lien vide, présence d’un intitulé de lien explicite plutôt qu’un simple « cliquez ici ». La vérification reste utile mais ne couvre pas ce qui se passe réellement au rendu final, notamment la gestion du focus clavier sur un sous-menu, qui dépend du thème et non de la donnée transmise à l’agent.
Impact faible : le changement de paramètres visuels globaux
La capacité de modification des styles globaux, par exemple une variable de couleur définie dans theme.json, se prête beaucoup moins bien à un contrôle automatique avant exécution. Un contrôle de contraste nécessite de connaître la combinaison réelle de couleurs de texte et de fond utilisée à l’écran, information rarement disponible dans le seul schéma d’entrée de la capacité. Un contrôle préalable peut au mieux vérifier qu’une nouvelle couleur respecte un contraste minimal contre un fond de référence connu à l’avance, ce qui couvre une partie seulement des cas réels.
Ce que ce premier classement suggère
Plus une capacité porte sur un contenu structuré et prévisible (texte, images, hiérarchie), plus le contrôle d’accessibilité avant exécution est fiable. Plus elle porte sur un rendu visuel dépendant du contexte global du site, moins ce contrôle isolé suffit à garantir un résultat conforme. La déclaration de capacité reste donc un progrès réel, mais elle ne dispense pas d’un contrôle après publication sur le rendu final, en particulier pour tout ce qui touche à l’apparence.
Conseil maison : commencez par accrocher vos vérifications d’accessibilité aux capacités de publication de contenu, c’est là que le rapport entre l’effort de mise en place et la fiabilité du contrôle est le meilleur.
En résumé
L’Abilities API ouvre une possibilité concrète de vérification avant exécution qui n’existait pas quand un agent modifiait un site uniquement via des appels directs à l’API REST classique, sans schéma déclaré à l’avance. Le gain reste toutefois inégal selon le type d’action, plus net sur le contenu structuré que sur les paramètres visuels globaux, ce qui invite à prioriser les premiers contrôles sur les capacités les plus fréquemment sollicitées par les agents en usage réel.
