WordPress 6.9, en décembre 2025, a posé les bases des abilities avec wp_register_ability(). WordPress 7.0, quelques mois plus tard, comble un point resté aveugle depuis : une fois qu’un agent a le droit d’exécuter une action, comment un administrateur sait-il ce qu’il en a réellement fait, à quelle fréquence, et avec quel résultat ? Cette version répond en apportant une couche d’observabilité native, pensée dès le départ pour s’articuler avec des outils de supervision externes comme Sentry.
Sur un projet qui exploite plusieurs agents connectés via MCP à des abilities WordPress, cette nouveauté a immédiatement changé la façon dont l’équipe technique surveille ce qui se passe réellement en production, là où auparavant chaque projet devait bricoler sa propre journalisation autour des exécutions d’abilities.
Impact fort : un journal d’exécution natif
Chaque appel à une ability enregistrée passe désormais par un journal interne, consultable dans l’administration WordPress, qui trace l’identité de l’appelant (agent, utilisateur, application), les paramètres transmis et le résultat de l’exécution, succès ou échec. Ce journal ne remplace pas un outil de supervision dédié, mais fournit un premier niveau de visibilité directement accessible sans configuration supplémentaire.
Impact fort : le hook wp_ability_executed
Le nouveau hook d’action wp_ability_executed, déclenché après chaque exécution réussie ou échouée d’une ability, permet de brancher n’importe quel outil de supervision externe sans dépendre du journal natif. Voici comment ce hook a été relié à Sentry sur ce projet :
add_action( 'wp_ability_executed', function ( string $ability_name, array $contexte, $resultat ) {
if ( is_wp_error( $resultat ) ) {
\Sentry\captureMessage(
sprintf( 'Échec ability %s : %s', $ability_name, $resultat->get_error_message() ),
\Sentry\Severity::warning()
);
}
// Envoi systématique d'une trace, succès ou échec, pour la corrélation
\Sentry\addBreadcrumb( array(
'category' => 'wp_ability',
'message' => $ability_name,
'data' => $contexte,
) );
}, 10, 3 );
Cette simple intégration donne à l’équipe une visibilité continue sur les abilities exécutées par les agents, directement dans le tableau de bord Sentry déjà utilisé pour le reste du monitoring applicatif du site, sans outil supplémentaire à déployer.
Impact moyen : la corrélation conversation / effets réels
WordPress 7.0 introduit également un identifiant de contexte transmis de bout en bout entre un appel MCP et l’exécution de l’ability correspondante, ce qui permet de relier une conversation d’agent précise à la liste exacte des actions qu’elle a déclenchées sur le site. Auparavant, cette corrélation demandait un travail manuel de recoupement entre les journaux du serveur MCP et ceux de WordPress.
Impact moyen : des seuils d’alerte configurables par ability
Chaque ability peut désormais déclarer un seuil de fréquence d’exécution acceptable, au-delà duquel une alerte native est levée dans l’administration, indépendamment de toute intégration externe comme Sentry. Cette fonctionnalité reste basique par rapport à un outil de supervision dédié, mais elle offre un filet de sécurité minimal pour les sites qui n’ont pas encore mis en place de monitoring externe.
Impact mineur : une interface d’audit simplifiée
Une nouvelle page d’administration liste, de façon lisible pour un administrateur non technique, les abilities les plus exécutées sur les sept derniers jours, avec leur taux d’échec. Utile pour un premier aperçu, elle reste largement en retrait par rapport à un tableau de bord Sentry correctement configuré, qui demeure recommandé pour tout site où plusieurs agents sont actifs en production.
Un agent qui agit sans laisser de trace observable n’est pas un agent en production, c’est une boîte noire qu’on espère bien élevée.
En résumé
WordPress 7.0 ne change rien à la façon dont les agents décident d’agir, mais transforme radicalement la capacité d’un administrateur à savoir ce qu’ils ont réellement fait, grâce au hook wp_ability_executed et au journal natif qui l’accompagne. L’installation initiale de Sentry sur un projet WordPress, elle, reste un sujet distinct qui ne dépend pas de cette version.
