WordPress 6.9 « Gene » est sorti le 2 décembre 2025, et WordPress 7.0 « Armstrong » a suivi le 20 mai 2026. Entre ces deux versions, le projet a discrètement ajouté les pièces qui permettent à un agent IA de lire un site WordPress et d’agir dessus. La plupart des articles les ont réunies sous un seul titre, « WordPress devient agentique », comme si l’on avait actionné un interrupteur. Il n’y a pas d’interrupteur unique. Il y a trois briques distinctes, chacune avec son rôle, et l’une d’elles n’est même pas dans le cœur. Allons les découvrir ensemble, une brique à la fois.
Qu’est-ce qui rend un site WordPress « agentique » ?
Pour qu’un agent IA pilote un site web, trois conditions doivent être réunies. Le site doit déclarer ce qu’il sait faire dans un format lisible par une machine. Quelque chose doit permettre au code du site de parler à un fournisseur d’IA. Et quelque chose doit permettre à un agent extérieur de découvrir ces capacités et de les appeler sans danger. WordPress dispose désormais d’une pièce pour chacune : l’Abilities API, l’AI Client et le MCP Adapter. WordPress devient agentique non pas grâce à une fonction unique, mais grâce à trois couches qui font chacune un travail : déclarer, parler et piloter. Toutes sont nées du même effort, l’initiative AI Building Blocks for WordPress, ce qui explique qu’elles s’emboîtent aussi proprement.
Brique un : l’Abilities API, ou ce que votre site sait faire
La première brique est la plus ancienne. L’Abilities API a été intégrée au cœur de WordPress en 6.9, sortie le 2 décembre 2025. Selon la note de développement qui l’a présentée, c’est « un nouveau système fondamental qui permet aux extensions, aux thèmes et au cœur de WordPress de déclarer et d’exposer leurs capacités dans un format normalisé et lisible par une machine ». Chaque capacité s’appelle une ability, définie comme une unité de fonctionnalité autonome dotée d’entrées, de sorties, de permissions et d’une logique d’exécution déterminées.
Voyez-la comme un catalogue que le site publie sur lui-même. « Créer un brouillon d’article », « récupérer les dix dernières commandes », « lancer un diagnostic » : chacune est enregistrée avec un schéma typé et une règle de permission. L’Abilities API n’appelle aucune IA ; elle se contente de décrire, de façon prévisible, ce que le site a le droit de faire. Cette description est le socle sur lequel tout le reste repose, car un agent ne peut pas agir sur ce qu’il ne peut pas lire.
Brique deux : l’AI Client, ou comment votre site parle aux fournisseurs d’IA
La deuxième brique est arrivée avec la 7.0. L’AI Client est, selon sa propre note de développement, « une API PHP agnostique du fournisseur qui permet aux extensions d’envoyer des requêtes à des modèles d’IA et d’en recevoir les résultats via une interface cohérente ». Une extension y accède par un point d’entrée unique, la fonction wp_ai_client_prompt(), et WordPress achemine la requête vers le fournisseur que le propriétaire du site a configuré.
Le mot important est « agnostique ». Le même code d’extension peut atteindre OpenAI, Anthropic ou Google sans être réécrit pour chacun, parce que c’est l’AI Client qui gère l’acheminement. Le cœur de WordPress n’appelle aucun modèle et n’écrit aucun contenu de lui-même ; l’AI Client offre seulement une manière standard d’interroger un modèle, quand le code décide de le faire. Nous détaillons ce recadrage, et pourquoi passer à la 7.0 ne transforme pas votre site en rédacteur IA, dans notre article sur ce que l’AI Client change vraiment.
Brique trois : le MCP Adapter, ou laisser un agent piloter
La troisième brique est celle qui transforme les deux premières en quelque chose qu’un agent extérieur peut utiliser, et c’est aussi celle sur laquelle il faut être précis. Le MCP Adapter n’est pas dans le cœur. C’est un paquet officiel de l’initiative AI Building Blocks for WordPress, installé comme une extension à part depuis la page des releases de son dépôt GitHub, et il exige WordPress 6.9 ou une version ultérieure, car il dépend de l’Abilities API.
Son rôle, énoncé clairement dans la note qui l’a présenté, est « d’adapter les Abilities enregistrées par l’Abilities API aux primitives du Model Context Protocol (MCP), afin que des outils d’IA comme Claude Desktop, Claude Code, Cursor et VS Code découvrent et appellent directement les Abilities de WordPress ». Un agent installé dans votre éditeur peut donc lister ce que le site propose et invoquer l’une de ces capacités via un protocole standard. Le MCP Adapter est le pont qui laisse un agent IA extérieur découvrir vos capacités déclarées et les appeler, et il reste pour l’instant une extension plutôt qu’un composant du cœur.
Pourquoi l’adaptateur officiel n’est pas une extension « exécuter n’importe quel code »
Voilà la distinction à retenir, car le vocabulaire autour de MCP et de WordPress confond deux choses très différentes. Plusieurs extensions MCP tierces exposent des points d’entrée larges, certaines allant jusqu’à un point d’exécution PHP ou WP-CLI brut, ce qui revient à confier à un agent de quoi lancer à peu près n’importe quoi. LE MCP Adapter officiel, lui, fait l’inverse. Il n’expose que les Abilities enregistrées via l’Abilities API, chacune avec son schéma typé et son contrôle de permission, et rien d’autre.
L’adaptateur officiel donne accès à des capacités déclarées et bornées que vous maîtrisez, pas à l’exécution de code arbitraire, et cette limite est toute la raison d’être de son ancrage sur l’Abilities API. Si vous n’avez jamais vu MCP qu’à travers une extension qui lance des commandes shell, la voie du cœur est un choix volontairement plus étroit et plus sûr. L’agent peut faire ce que vous avez déclaré, avec les permissions que vous avez fixées, et rien de plus.
Notre avis
L’histoire agentique est réelle, mais c’est une architecture, pas une fonction magique que l’on active. Ce qui compte pour un praticien, c’est que les briques sont délibérément superposées et, sur la voie officielle, délibérément bornées. Deux des trois briques sont aujourd’hui dans le cœur, la troisième est une extension optionnelle, et aucune ne fait quoi que ce soit tant que vous n’avez pas enregistré une ability ni décidé qui peut l’appeler. C’est rassurant plus que spectaculaire, et c’est ainsi que nous aimons nos infrastructures.
Voici donc une manière posée d’aborder le sujet. Si vous êtes seulement curieux, lisez ces briques comme une carte et patientez : rien n’est exposé par défaut. Si vous voulez expérimenter, installez le MCP Adapter sur un site de préproduction, enregistrez une seule ability bien délimitée, et vérifiez exactement quel agent et quel utilisateur peuvent l’appeler avant d’aller plus loin. Et si vous gérez des sites clients, auditez toute extension MCP tierce à la recherche d’un point d’exécution de code brut, et préférez la voie officielle bornée. Quel que soit votre cas, commencez toujours en préproduction ; et si vous n’avez pas encore franchi le pas, notre checklist prudente pour passer à WordPress 7.0 couvre le reste. Les briques sont en place ; ce que vous laissez un agent en faire reste votre décision.
