Avec WordPress 7.0, l’écosystème IA du CMS ne se limite plus au backend PHP. À l’issue de l’AI Client, de la Connectors API et des Abilities API server-side introduites en 6.9, une nouvelle brique vient compléter le dispositif : la version client-side de l’Abilities API. Cette extension JavaScript permet aux agents IA, aux extensions navigateur et à WebMCP d’interagir directement avec l’interface d’administration WordPress.
Cette évolution est peut-être la plus stratégique de toutes celles introduites dans le cycle 7.0, car elle transforme WordPress en une plateforme programmable non seulement côté serveur, mais aussi côté client.
Le contexte : pourquoi une API d’abilities côté client ?
Pour comprendre l’intérêt de cette API, il faut revenir sur ce que l’Abilities API server-side (WordPress 6.9) a apporté. Elle a créé une interface commune permettant aux plugins, aux outils d’automatisation et aux agents IA d’exécuter des actions dans WordPress via PHP. Permettant de créer un article, modifier un réglage, interroger des données… C’est un contrat standardisé qui décrit ce que WordPress sait faire, avec des schémas d’entrée et de sortie validés.
Mais cette API PHP ne couvre qu’une partie du spectre. De nombreuses actions dans WordPress se produisent côté client, comme la navigation vers un écran d’administration, l’insertion d’un bloc dans l’éditeur Gutenberg, l’interaction avec une interface React. Un agent IA qui tourne dans le navigateur (via une extension Chrome, par exemple) ou un protocole comme WebMCP n’a pas accès au runtime PHP. Il lui faut un équivalent JavaScript.
C’est exactement ce que WordPress 7.0 apporte comme un miroir client-side de l’Abilities API, conçu pour exposer les capacités du CMS au JavaScript, avec le même niveau de rigueur dans la validation et les permissions.
Deux packages, deux niveaux d’abstraction
L’architecture choisie par l’équipe WordPress core est élégante dans sa séparation des responsabilités. La Client-Side Abilities API est distribuée sous forme de deux packages npm distincts.
- `@wordpress/abilities´, est un package de state management pur. Il ne dépend d’aucune infrastructure WordPress. Il fournit le store, les fonctions d’enregistrement (`registerAbility´, `registerAbilityCategory´), de requêtage (`getAbilities´, `getAbility´) et d’exécution (`executeAbility´). Ce package peut être utilisé dans n’importe quel projet JavaScript, y compris en dehors de WordPress. Ce choix de conception découple la logique d’abilities de WordPress et rend cette abstraction réutilisable dans des contextes plus larges.
- `@wordpress/core-abilities´, est la couche d’intégration WordPress. Lorsqu’il est chargé, il récupère automatiquement toutes les abilities et catégories enregistrées côté serveur via la REST API (`/wp-abilities/v1/´) et les inscrit dans le store `@wordpress/abilities´ avec les callbacks appropriés. C’est le pont entre le monde PHP et le monde JavaScript.
Cette séparation en deux packages n’est pas un détail d’implémentation. Cette décision d’architecture détermine la portabilité et la testabilité de l’ensemble. Chez WexIT, nous appliquons le même principe sur nos projets React/Next.js. C’est un gage de maintenabilité à long terme.
Le modèle d’enregistrement : catégories, schémas et permissions
L’enregistrement d’une ability côté client suit un modèle structuré qui impose de la rigueur aux développeurs de plugins. Chaque ability appartient à une catégorie, qui doit être enregistrée au préalable. Les slugs de catégorie suivent une convention stricte, à savoir en alphanumériques, en minuscules et avec des tirets uniquement.
Ce qui distingue cette API d’un simple système d’événements ou de hooks, c’est le contrat de données qu’elle impose. Chaque ability peut définir un `input_schema´ et un `output_schema´ au format JSON Schema (draft-04). L’input est validé avant l’exécution du callback, l’output est validé après. Si la validation échoue, une erreur typée est levée : `ability_invalid_input´ ou `ability_invalid_output´.
Ce niveau de validation est fondamental pour la fiabilité des interactions avec des agents IA. Un agent qui appelle une ability doit pouvoir compter sur un contrat clair :
- Quels paramètres l’API attend-elle ?
- Quels formats de retour l’API garantit-elle ?
Sans cette rigueur, l’intégration IA serait fragile et imprévisible. Avec elle, WordPress définit un protocole d’interaction stable que n’importe quel agent peut consommer avec confiance. Le système de permissions ajoute une couche de sécurité essentielle. Chaque ability peut déclarer un `permissionCallback´ qui est vérifié avant l’exécution. Si le callback retourne `false´, une erreur `ability_permission_denied´ est levée. C’est le même pattern que les `permission_callback´ de la REST API WordPress, appliqué cette fois au contexte JavaScript.
Les annotations : décrire le comportement, pas seulement la fonction
Un aspect de l’API qui mérite une attention particulière est le système d’annotations. Chaque ability peut déclarer des métadonnées qui décrivent son comportement : `readonly´ (lecture seule, ne modifie pas l’état), `destructive´ (opération destructrice) et `idempotent´ (peut être appelée plusieurs fois avec le même résultat).
Ces annotations ne sont pas de la documentation passive. Elles ont un impact direct sur le comportement du système. Pour les abilities server-side exécutées via la REST API, les annotations déterminent la méthode HTTP utilisée : GET pour les abilities `readonly´, DELETE pour les abilities `destructive´ + `idempotent´, et POST pour tous les autres cas.
D’un point de vue architectural, ces annotations sont précieuses pour les agents IA. Un agent qui analyse le catalogue d’abilities disponibles peut s’appuyer sur ces métadonnées pour prendre des décisions : exécuter une ability `readonly´ sans confirmation utilisateur, demander une validation avant une ability `destructive´, optimiser les appels en regroupant les abilities `idempotent´. C’est le type d’information sémantique qui transforme un simple catalogue de fonctions en un véritable protocole d’interaction.
Cela fait écho à un sujet que nous abordons régulièrement chez WexIT dans nos projets d’architecture API en réalisant la différence entre exposer des endpoints et concevoir un contrat d’interaction. Les annotations de l’Abilities API relèvent de cette seconde catégorie. Elles ne décrivent pas seulement ce qu’une ability fait, mais comment elle se comporte. On évoque également ce point dans l’article « OWASP Top 10 LLM : les 10 failles de sécurité des apps IA, expliquées avec des exemples concrets« .
L’intégration React et @wordpress/data : la réactivité native
Le store des abilities s’intègre nativement avec `@wordpress/data´, le système de state management de l’écosystème Gutenberg. Cela signifie que les composants React peuvent consommer les abilities de manière réactive via `useSelect´.
C’est un choix qui simplifie considérablement le développement de plugins d’administration. Un composant peut afficher dynamiquement les abilities disponibles, filtrer par catégorie, et réagir en temps réel à l’enregistrement ou au désenregistrement d’abilities. Le tout sans aucune logique d’abonnement manuelle.
Pour les équipes qui développent des interfaces d’administration complexes, cette intégration réactive ouvre des possibilités intéressantes. C’est un cas fréquent dans nos projets WexIT, notamment sur les back-offices e-commerce B2B. Imaginez un dashboard d’administration qui affiche dynamiquement les actions disponibles en fonction des plugins actifs, des permissions de l’utilisateur, et du contexte courant. L’Abilities API rend cela possible nativement.
Le pont server/client : synchronisation automatique via REST API
L’un des aspects les plus réussis de cette architecture est la transparence de la synchronisation entre les abilities server-side et client-side. Les abilities enregistrées côté PHP via `wp_register_ability()´ sont automatiquement disponibles côté JavaScript lorsque `@wordpress/core-abilities´ est chargé.
Le mécanisme est simple : `@wordpress/core-abilities´ interroge la REST API `/wp-abilities/v1/´ au chargement, il récupère toutes les abilities et catégories server-side, et les inscrit dans le store client avec des callbacks qui exécutent les requêtes REST appropriées. Aucune configuration supplémentaire n’est nécessaire côté plugin.
WordPress core charge automatiquement `@wordpress/core-abilities´ sur toutes les pages d’administration, ce qui signifie que toutes les abilities server-side sont disponibles par défaut dans l’admin. C’est une décision de design qui favorise la découvrabilité. Un agent IA ou un outil de workflow peut interroger le store côté client et obtenir la liste complète de tout ce que le site sait faire, côté serveur comme côté client.
WebMCP et les agents de navigateur : la vraie cible
La dev note de WordPress mentionne explicitement que cette API est fondamentale pour l’intégration avec les browser agents/extensions et le protocole WebMCP. C’est là que réside l’enjeu stratégique le plus important.
Le protocole MCP (Model Context Protocol) définit un standard d’interaction entre les agents IA et les outils qu’ils manipulent. WebMCP est son extension pour les interactions via navigateur. Avec la Client-Side Abilities API, WordPress devient un environnement natif pour ces agents. Ils peuvent interroger le catalogue d’abilities disponibles, comprendre les schémas d’entrée/sortie, vérifier les permissions, et exécuter des actions, le tout via une API JavaScript standardisée.
C’est un changement de paradigme pour WordPress. Le CMS ne se contente plus d’exposer des API REST pour des clients programmatiques classiques. Il expose désormais un catalogue sémantique d’actions, avec des métadonnées de comportement, accessible directement dans le contexte d’exécution du navigateur. C’est exactement ce dont les agents IA ont besoin pour opérer de manière autonome et sûre dans un environnement web.
Chez WexIT, nous suivons de près l’évolution du protocole MCP et de ses applications dans l’écosystème web. Nous avons déjà exploré les possibilités offertes par le MCP Figma dans le contexte de l’automatisation des design systems. L’arrivée d’une Abilities API client-side dans WordPress ouvre la voie à des scénarios similaires. Dès demain, un agent IA pourrait piloter la création de contenu, la configuration d’un site, ou la gestion d’un catalogue e-commerce directement depuis le navigateur, en s’appuyant sur un contrat d’interaction standardisé.
Un point de vigilance : la validation des schémas
La communauté WordPress a également signalé un point de vigilance. Un contributeur a relevé un problème potentiel dans la validation des `input_schem´, lié à la propriété `sanitize_callback´ utilisée notamment par le plugin IA officiel. Ce type de friction entre la validation stricte des schémas et les besoins de sanitization des données est classique dans les API qui traitent des inputs provenant d’agents IA.
C’est un rappel que la standardisation des interactions IA est encore en construction. Les schémas JSON sont un bon point de départ, mais les cas limites (callbacks de sanitization, types complexes, validations conditionnelles) exigeront des itérations. C’est normal dans une API de cette ambition, et le fait que la communauté WordPress l’identifie tôt est plutôt bon signe.
L’avis de WexIT : WordPress devient une plateforme prête pour les agents IA
En prenant du recul sur l’ensemble des briques IA introduites dans le cycle WordPress 6.9/7.0 (Abilities API PHP, AI Client, Connectors API, et maintenant la Client-Side Abilities API), le tableau qui se dessine est celui d’un CMS qui se transforme méthodiquement en plateforme agent-ready.
Chaque brique joue un rôle précis dans cette transformation.
- L’AI Client fournit l’interface d’interaction avec les modèles.
- La Connectors API gère la gouvernance des connexions aux services externes.
- L’Abilities API server-side expose les capacités PHP.
- La Client-Side Abilities API étend ces capacités au navigateur, là où opèrent les agents IA de nouvelle génération.
Ce qui est remarquable, c’est la cohérence architecturale de l’ensemble. Les mêmes patterns se retrouvent partout : des registries centralisés, des schémas de validation, des systèmes de permissions, des hooks d’extension. C’est une plateforme conçue pour être programmable à tous les niveaux, pas un assemblage de fonctionnalités IA ajoutées en urgence.
Pour les agences web comme WexIT, cette évolution change la donne à moyen terme. Les projets WordPress de demain ne seront plus uniquement des projets de développement de thèmes et de plugins. Ils incluront la conception d’abilities, la configuration de connectors et l’intégration d’agents IA. C’est un élargissement significatif du périmètre de ce que signifie « développer avec WordPress ».
Le mot de la fin !
Ma recommandation pour les équipes techniques : commencez à expérimenter avec l’Abilities API dès maintenant. Identifiez les actions récurrentes dans vos projets WordPress, comme la création de contenu, la configuration de réglages ou la gestion de catalogue. Encapsulez-les sous forme d’abilities avec des schémas typés afin de poser les bases d’une intégration IA propre lorsque le besoin se présentera.
L’architecture, ce n’est pas seulement résoudre les problèmes d’aujourd’hui, c’est préparer les fondations pour les usages de demain.
