WordPress 7.0 est presque toujours résumé en deux mots : « version IA ». Le raccourci est commode, mais il rate l’essentiel. Le vrai changement n’est pas que le CMS sache appeler un modèle de langage : brancher une API OpenAI, Anthropic ou Gemini dans un plugin est déjà un geste banal. Ce qui bascule, c’est que WordPress commence à décrire ce qu’un site sait faire de façon structurée, vérifiable et exploitable par des outils externes. Le tableau de bord n’est plus le seul point d’entrée. Le site devient une plateforme pilotable par des interfaces, des scripts, des assistants et, demain, des agents autonomes. C’est cette mutation que l’Abilities API rend concrète.

Ce que WordPress 7.0 change vraiment

WordPress 7.0 « Armstrong » est sorti le 20 mai 2026 et prolonge la phase collaboration de Gutenberg. La version embarque plus de 419 tickets Core, des dizaines d’améliorations pour l’éditeur, un gros travail côté wp-admin et une consolidation des APIs modernes. La collaboration temps réel complète n’a finalement pas été intégrée à cette mouture, mais des briques plus prudentes ont été livrées : notes, révisions visuelles, meilleure expérience d’édition et fondations pour des workflows plus connectés. On reste dans une logique d’incréments solides plutôt que de grande rupture annoncée.

Dans ce paysage, l’Abilities API est la pièce que les développeurs doivent regarder de près. Son rôle tient en une phrase : déclarer les capacités disponibles sur un site, avec un nom, une description, des paramètres attendus, une logique d’exécution et des règles de permissions. Un plugin peut ainsi exposer proprement une action précise — créer une fiche produit, planifier un article, lancer une purge de cache, générer un résumé SEO ou vérifier l’état d’une commande WooCommerce. L’intérêt n’est pas la nouveauté de l’action en elle-même, mais le fait qu’elle devienne déclarée au lieu d’être enfouie dans du code maison difficile à inventorier.

Pourquoi standardiser les « capacités » d’un site

Jusqu’ici, automatiser WordPress revenait à improviser. On colle des webhooks, on détourne des endpoints REST, on confie trop de droits à une clé applicative, ou on réécrit un connecteur sur mesure pour chaque besoin. Le résultat fonctionne, mais il est fragile, opaque et impossible à auditer sereinement. Personne ne dispose d’une vue unifiée de « tout ce que ce site peut faire de l’extérieur ». Chaque intégration vit dans son coin, avec ses propres conventions et ses propres angles morts de sécurité. Cette dispersion est devenue le vrai frein dès qu’on veut industrialiser l’automatisation à l’échelle d’un parc de sites.

Standardiser les capacités inverse cette logique. Chaque action devient déclarative, typée et gouvernée par un même cadre. Pour une agence, le bénéfice est immédiat et concret : au lieu d’ouvrir à un assistant un accès général à l’administration, on dessine un périmètre net. L’agent a le droit de proposer une méta-description mais pas de publier ; il peut créer un brouillon mais pas toucher une page légale ; il peut lire le catalogue WooCommerce mais pas exporter la base clients. C’est exactement la séparation qui manque aujourd’hui dès qu’on mélange automatisation, contenu éditorial et données sensibles. La capacité devient l’unité de contrôle, pas la clé d’API.

L’ère des agents IA et le protocole MCP

Ce mouvement ne se comprend qu’à la lumière de l’écosystème des agents IA. Un agent moderne n’attend pas une documentation rédigée pour des humains : il a besoin de découvrir, par lui-même, quelles actions sont disponibles, quels paramètres elles réclament et ce qu’elles renvoient. C’est précisément ce que cherchent à formaliser les protocoles d’interopérabilité comme le Model Context Protocol (MCP), pensé pour exposer outils et contextes à des modèles de façon normalisée. Décrire ses capacités dans un format structuré rend un système « lisible » par ces agents sans que chaque éditeur réinvente sa propre passerelle à chaque fois.

L’Abilities API s’inscrit naturellement dans cette dynamique. En conceptualisant chaque action comme une capacité nommée, paramétrée et contrôlée, WordPress se dote du vocabulaire dont un agent a besoin pour raisonner : que puis-je faire ici, ai-je le droit de le faire, et quel sera le résultat ? Cela ne signifie pas que WordPress impose un agent ni un fournisseur de modèle particulier. Cela signifie qu’il prépare le terrain pour que des assistants découvrent et déclenchent des actions du site de façon contrôlée. La différence est de taille : on passe d’intégrations bricolées à une surface d’automatisation pensée dès la conception pour être interrogée par des machines.

Abilities API contre API REST : une différence d’intention

La question revient vite : pourquoi ne pas simplement utiliser l’API REST, qui existe depuis des années et couvre déjà énormément d’opérations ? La réponse tient à l’intention. L’API REST expose des ressources — des articles, des pages, des médias, des utilisateurs — que l’on manipule via des verbes HTTP. Elle est excellente pour lire et écrire des données, mais elle ne dit rien, en soi, de la logique métier ni du périmètre d’autorisation attaché à une intention précise. Pour qu’un agent « planifie un article après vérification SEO », il faut composer plusieurs appels et porter soi-même toute la logique de garde-fous.

L’Abilities API raisonne, elle, en termes d’actions métier autodescriptives. Une capacité encapsule un nom, un schéma d’entrée, un contrôle de permission et une sortie prévisible. Le consommateur n’a pas à connaître la plomberie interne : il découvre une action, vérifie qu’il a le droit de l’appeler, l’invoque, et reçoit un résultat typé. Les deux APIs ne s’opposent pas, elles se complètent. La REST reste la fondation pour l’accès aux données ; l’Abilities API ajoute une couche d’intention, plus proche de la manière dont un agent — ou un humain qui automatise — pense réellement son travail. C’est un déplacement du « comment accéder » vers le « que faire ».

Un exemple illustratif de capacité déclarée

Pour fixer les idées, voici une esquisse côté plugin. Elle ne se substitue pas à la documentation officielle et ne prétend pas reproduire la signature exacte de l’API : considérez-la comme illustrative. Concrètement, le principe ressemble à ceci — on décrit l’action, on valide les entrées avec un schéma, et l’on contrôle systématiquement les permissions avant toute exécution. L’important n’est pas le nom précis des fonctions, mais le réflexe qu’il faut adopter : une action bien bornée vaut mieux qu’une porte grande ouverte.

// Illustratif — le principe, pas la signature officielle exacte.
add_action('init', function () {
    if (! function_exists('wp_register_ability')) {
        return;
    }

    wp_register_ability('wpadminlab/seo-draft-summary', array(
        'label'       => 'Générer un résumé SEO de brouillon',
        'description' => 'Retourne un résumé court pour un article en brouillon.',
        'input_schema' => array(
            'type'       => 'object',
            'properties' => array(
                'post_id' => array('type' => 'integer'),
            ),
            'required' => array('post_id'),
        ),
        'permission_callback' => function ($input) {
            // La permission est vérifiée AVANT toute action.
            return current_user_can('edit_post', (int) $input['post_id']);
        },
        'execute_callback' => function ($input) {
            $post = get_post((int) $input['post_id']);
            if (! $post || 'draft' !== $post->post_status) {
                return new WP_Error('invalid_post', 'Brouillon introuvable.');
            }
            return array(
                'title'   => get_the_title($post),
                'excerpt' => wp_trim_words(wp_strip_all_tags($post->post_content), 28),
            );
        },
    ));
});

Ce squelette concentre toute la philosophie de l’approche. La capacité est minuscule, elle ne fait qu’une chose, son entrée est typée par un schéma, sa permission est adossée à un rôle WordPress existant via current_user_can, et sa sortie est prévisible. Un agent qui découvre cette ability sait exactement ce qu’il peut demander et ce qu’il obtiendra. Surtout, il ne peut rien faire que la fonction de permission n’autorise pas : la garde n’est pas optionnelle, elle est intégrée à la déclaration elle-même.

Le point critique : permissions et gouvernance

Le risque principal n’est pas technique, il est organisationnel. Si les plugins exposent des capacités trop larges, les agents IA deviendront des super-utilisateurs opaques, capables d’agir sans que personne ne sache précisément sur quel périmètre. C’est exactement ce qu’il faut éviter. Une capacité saine est petite, testable, documentée et liée aux rôles WordPress existants. Le bon modèle se résume à quatre exigences tenues ensemble : une action métier clairement délimitée, une permission explicite, un journal d’exécution, et une sortie prévisible. Dès qu’une de ces quatre conditions saute, la capacité redevient un trou de sécurité.

Il faut aussi tenir fermement la frontière entre suggestion et publication. Sur un site média, un agent peut préparer cinq titres, repérer des liens cassés, proposer des balises alt et créer un brouillon ; la publication finale, elle, reste soumise au workflow éditorial humain. Sur une boutique WooCommerce, un agent peut signaler des anomalies de stock ou rédiger une description produit, mais une modification massive de prix doit exiger une validation humaine. Cette discipline n’est pas un frein à l’automatisation : c’est ce qui la rend déployable en production sans transformer chaque assistant en risque incontrôlé pour l’activité.

Ce que les développeurs de plugins doivent surveiller

Pour les auteurs d’extensions, l’enjeu est de prendre le pli tôt, avant que de mauvaises habitudes ne s’installent. La première chose à surveiller est la granularité : exposer dix capacités précises vaut mieux qu’une seule capacité fourre-tout qui ferait office de passe-partout. Chaque ability doit déclarer un schéma d’entrée strict, refuser proprement les données invalides et renvoyer des erreurs explicites plutôt que d’échouer en silence. La fonction de permission ne doit jamais être un détail coché à la fin : elle est le cœur du contrat de confiance entre le plugin et tout ce qui l’appellera, agent ou humain.

Vient ensuite la traçabilité. Un plugin sérieux journalise qui a déclenché quelle capacité, avec quels paramètres et quel résultat. C’est indispensable pour diagnostiquer un comportement inattendu et pour rendre des comptes en cas d’incident. Il faut enfin penser aux scénarios d’échec : que se passe-t-il si l’entrée est partielle, si l’utilisateur n’a pas les droits, si une dépendance externe tombe ? Les développeurs qui traiteront ces cas dès la conception livreront des extensions plus propres, plus sûres et nettement mieux compatibles avec les workflows automatisés qui se généralisent en 2026.

L’impact sur l’écosystème WordPress

Pour les agences, cette évolution ouvre un terrain de valeur inédit : l’audit des capacités. Demain, maintenir un site ne se limitera plus à vérifier les mises à jour de plugins. Il faudra cartographier les actions exposées, contrôler les permissions associées, documenter les connecteurs IA, examiner les logs et tester les scénarios d’échec. C’est un véritable métier qui se dessine, à la croisée de la sécurité, de l’éditorial et de l’automatisation. Les structures qui sauront formaliser cette discipline auront un argument concret à faire valoir auprès de clients de plus en plus exposés aux risques de l’IA opérationnelle.

La bonne approche reste de commencer petit. Choisissez un workflow répétitif et à faible risque — générer un résumé SEO, proposer des tags, préparer une réponse de support, classer des brouillons, détecter les images sans texte alternatif — puis montez progressivement vers des opérations plus sensibles. La promesse de l’IA dans WordPress n’a jamais été de remplacer l’administrateur. Elle est d’enlever la friction autour des tâches répétitives tout en gardant la main sur le système. WordPress 7.0 n’est donc pas seulement une version dotée d’une couche IA : c’est le début d’un WordPress plus lisible par les machines, plus automatisable et, s’il est bien gouverné, mieux maîtrisé qu’avant.

Sources

W
WP Admin Lab

Architecte web full-stack. WordPress, performance, data et sécurité. Notes de terrain, tests reproductibles et retours d'expérience.