Le WordPress d'aujourd'hui, décodé pour les développeurs

Tips

Un badge « compatible MCP Adapter » sur la fiche d’une extension interne

Aider une équipe à repérer d'un coup d'œil quelles extensions maison sont prêtes pour l'écosystème MCP de WordPress 7.0.

Par Clément Hadrot • 11 avril 2026 • 4 min de lecture • Aucun commentaire
Un badge « compatible MCP Adapter » sur la fiche d'une extension interne

Décembre 2025 a marqué l’arrivée de l’Abilities API dans le cœur de WordPress avec la version 6.9, suivie de près par le MCP Adapter permettant d’exposer ces capacités à des agents externes via le Model Context Protocol. Quelques mois plus tard, avec l’approche de WordPress 7.0, la question devient très concrète pour une agence disposant d’un parc d’extensions maison : lesquelles ont déjà été adaptées, et lesquelles restent à auditer ?

Plutôt que de tenir cette information dans un tableur externe, vite désynchronisé du code réel, il est plus fiable de la déclarer directement dans l’en-tête de chaque extension et de l’afficher sous forme de badge sur l’écran natif des extensions.

Déclarer la compatibilité dans l’en-tête de l’extension

WordPress permet d’ajouter des champs personnalisés dans le commentaire d’en-tête d’un plugin, au même titre que Plugin Name ou Version. On y ajoute un champ MCP Adapter qui prend la valeur compatible, partiel ou non-teste :

/**
 * Plugin Name: Gestion des rendez-vous internes
 * Description: Extension maison de gestion de créneaux.
 * Version: 2.4.0
 * MCP Adapter: compatible
 */

Lire cette information et l’afficher en badge

L'essentiel à retenir : Un attribut de compatibilité déclaré par extension ; Un badge visible sur l'écran des extensions ; Une liste filtrable pour l'équipe technique

La fonction get_plugin_data ne remonte pas nativement les en-têtes personnalisés : il faut les lire soi-même via get_file_data, puis injecter le badge sur la ligne correspondante de l’écran des extensions grâce au hook plugin_row_meta :

add_filter( 'plugin_row_meta', 'ajouter_badge_mcp_adapter', 10, 2 );
function ajouter_badge_mcp_adapter( $meta, $plugin_file ) {
    $chemin_complet = WP_PLUGIN_DIR . '/' . $plugin_file;
    $donnees = get_file_data( $chemin_complet, array( 'mcp' => 'MCP Adapter' ) );

    $statuts = array(
        'compatible'  => '<span style="color:green;">✓ Compatible MCP Adapter</span>',
        'partiel'     => '<span style="color:orange;">⚠ Compatibilité partielle</span>',
        'non-teste'   => '<span style="color:gray;">— Non testé</span>',
    );

    if ( ! empty( $donnees['mcp'] ) && isset( $statuts[ $donnees['mcp'] ] ) ) {
        $meta[] = $statuts[ $donnees['mcp'] ];
    }

    return $meta;
}

Pourquoi trois niveaux plutôt qu’un simple oui/non

Une extension peut exposer certaines capacités via l’Abilities API sans que l’ensemble de ses fonctionnalités soit couvert. Le niveau « partiel » évite de donner une fausse impression de complétude à une équipe qui déciderait de connecter un agent externe en se fiant uniquement à un badge binaire.

Construire une liste filtrable pour l’équipe technique

Sur un parc de trente extensions, parcourir l’écran natif reste praticable, mais une page d’administration dédiée, listant chaque extension avec son statut et sa date de dernier audit, facilite le suivi dans le temps :

  • Extensions compatibles : aucune action requise
  • Extensions partielles : ticket d’audit à planifier
  • Extensions non testées : priorité selon leur usage réel en production

Ne pas confondre ce badge avec la déclaration de l’ability elle-même

Ce dispositif se limite à un indicateur de suivi côté gouvernance ; il ne remplace pas le travail d’implémentation consistant à enregistrer réellement les capacités de l’extension via wp_register_ability, sujet qui relève d’un tout autre chantier technique, propre à chaque extension.

Un badge de compatibilité n’a de valeur que s’il est mis à jour à chaque changement de version de l’extension concernée ; sinon, il devient plus trompeur qu’utile.

Automatiser la vérification lors des mises à jour

Un contrôle automatisé, exécuté dans le pipeline de déploiement interne, peut vérifier que le champ MCP Adapter est bien présent dans l’en-tête avant d’autoriser la publication d’une nouvelle version de l’extension sur le dépôt privé de l’agence, évitant qu’un badge obsolète subsiste après une refonte majeure.

En résumé

Un simple champ d’en-tête et un filtre sur plugin_row_meta suffisent à rendre visible, en quelques minutes de développement, un état de compatibilité qui autrement resterait dispersé entre mémoires individuelles et documents externes. Sur un parc d’extensions conséquent, ce badge devient rapidement un outil de pilotage aussi utile que le numéro de version affiché à côté.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi