# Les Abilities API de WordPress 6.9 appliquées à un catalogue WooCommerce > WordPress 6.9 formalise une nouvelle façon de déclarer ce qu'un site sait faire. Voici ce que change cette API pour un catalogue WooCommerce, en dehors de tout contexte MCP. - Auteur : Clément Hadrot - Publié le : 2026-02-09 - Mis à jour le : 2026-02-09 - Catégorie : E-commerce - URL : https://wpmoderne.dev.wordpress-developpement.fr/ecommerce/abilities-api-wordpress-6-9-catalogue-woocommerce/ ## L’essentiel - Une capacité déclarée est distincte d'une capacité WordPress classique (rôle) - L'API sépare la découverte de la capacité de son exécution - Elle sert de socle à d'autres protocoles, sans en dépendre elle-même WordPress 6.9, sorti en décembre 2025, a intégré au cœur du logiciel une nouvelle notion : l'*ability* (capacité), à ne pas confondre avec les capacités de rôles utilisateurs qui existent depuis les débuts de WordPress. Cette nouvelle API répond à un besoin distinct : permettre à un site de déclarer, de façon structurée et découvrable par programme, ce qu'il sait faire — indépendamment de qui a le droit de le faire. Cet article se concentre volontairement sur l'API elle-même et son application à un catalogue WooCommerce, sans entrer dans le fonctionnement du Model Context Protocol, qui s'appuie sur cette même API mais mérite un traitement séparé. ## Ce qu'est une ability, précisément Une *ability* est un enregistrement structuré, composé d'un identifiant unique, d'une description en langage naturel, d'un schéma d'entrée, d'un schéma de sortie, et d'une fonction d'exécution. Elle se déclare via une fonction dédiée du cœur, sur le modèle des enregistrements déjà familiers de blocs ou de types de contenu personnalisés. ``` wp_register_ability( 'mon-agence/produits-stock-bas', array( 'label' => 'Produits sous le seuil de stock', 'description' => 'Retourne les produits WooCommerce dont le stock est inférieur au seuil défini.', 'input_schema' => array( 'type' => 'object', 'properties' => array( 'seuil' => array( 'type' => 'integer', 'default' => 5 ), ), ), 'output_schema' => array( 'type' => 'array', 'items' => array( 'type' => 'object' ), ), 'execute_callback' => 'mon_agence_lister_produits_stock_bas', 'permission_callback' => function() { return current_user_can( 'manage_woocommerce' ); }, ) ); ``` ## Découverte et exécution : deux étapes distinctes La conception de l'API sépare volontairement deux moments qui, dans une API REST classique, sont souvent confondus : la découverte de ce qui est possible, et l'exécution proprement dite. Un client (un plugin d'administration, un futur agent connecté) peut interroger la liste des *abilities* enregistrées sans exécuter quoi que ce soit, ce qui permet de construire dynamiquement une interface ou un menu d'actions disponibles sans coupler ce code à l'implémentation de chaque capacité. > L'essentiel à retenir : Une capacité déclarée est distincte d'une capacité WordPress classique (rôle) ; L'API sépare la découverte de la capacité de son exécution ; Elle sert de socle à d'autres protocoles, sans en dépendre elle-même ## Application concrète à un catalogue Sur un catalogue WooCommerce, les *abilities* trouvent un usage naturel pour tout ce qui relève d'une action métier bien définie, réutilisable dans plusieurs contextes : mise à jour groupée de prix, génération d'un rapport de rupture de stock, recalcul des variations après une modification d'attribut. Plutôt que d'écrire cette logique une fois pour l'interface d'administration classique et une autre fois pour une intégration externe, l'*ability* devient le point d'entrée unique, appelable depuis plusieurs contextes sans duplication. ``` function mon_agence_lister_produits_stock_bas( $input ) { $seuil = $input['seuil'] ?? 5; $produits = wc_get_products( array( 'stock_status' => 'instock', 'limit' => -1, ) ); return array_values( array_filter( array_map( function( $produit ) use ( $seuil ) { $stock = $produit->get_stock_quantity(); if ( null !== $stock && $stock < $seuil ) { return array( 'id' => $produit->get_id(), 'nom' => $produit->get_name(), 'stock' => $stock, ); } return null; }, $produits ) ) ); } ``` ## Ce que l'API ne fait pas à elle seule - Elle ne remplace pas le système de rôles et capacités WordPress classique : le `permission_callback` continue de s'appuyer dessus, il ne le contourne pas. - Elle n'implémente pas, à elle seule, un protocole de communication avec un agent externe : c'est un registre interne à WordPress, que d'autres couches (dont un futur serveur MCP) peuvent exposer vers l'extérieur. - Elle ne dispense pas de valider les entrées : le schéma déclaré documente la forme attendue, mais la fonction d'exécution reste responsable de sa propre validation défensive. ### Pourquoi ce découplage compte En séparant la déclaration d'une capacité de son mode d'exposition, WordPress 6.9 pose une base réutilisable par plusieurs protocoles futurs sans lier le cœur du logiciel à l'un d'entre eux en particulier. Une *ability* enregistrée aujourd'hui pour un usage d'administration interne pourrait, demain, être exposée sans modification à un serveur MCP ou à tout autre mécanisme de découverte, simplement parce que sa structure (entrée typée, sortie typée, contrôle de permission) est déjà pensée pour être consommée par un système tiers, humain ou automatisé. > Le vrai apport de cette API n'est pas de rendre WordPress compatible avec l'IA, c'est de rendre explicite ce qui restait implicite : ce qu'un site sait faire, indépendamment de l'interface utilisée pour le déclencher. ## En résumé Les Abilities API de WordPress 6.9 introduisent une couche de déclaration structurée des capacités d'un site, distincte du système de rôles existant et distincte de tout protocole de communication avec un agent. Pour un catalogue WooCommerce, elles offrent un moyen propre de centraliser des actions métier réutilisables, avec un schéma d'entrée et de sortie explicite — un socle solide, que ce soit pour une interface d'administration classique ou pour des usages encore à inventer.