# Tester une ability WordPress 6.9 appelée par un agent IA via MCP

> Une ability bien déclarée ne garantit pas qu'un agent IA obtienne la bonne réponse. Ce qu'il faut tester côté MCP, une fois l'ability elle-même déjà en place.

- Auteur : Clément Hadrot
- Publié le : 2025-10-08
- Mis à jour le : 2025-10-08
- Catégorie : Tests
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/tester-ability-wp-6-9-agent-ia-mcp/

## L’essentiel

- Un agent IA n'envoie pas toujours l'appel attendu, même avec un schéma clair
- Le refus hors permissions doit être aussi propre que la réponse valide
- Le format de réponse compte autant que son contenu pour un agent

« Est-ce que l'agent obtient vraiment ce qu'il demande, ou juste quelque chose qui ressemble à une réponse ? » C'est la question qui a guidé la conception de cette suite de tests. Déclarer une ability avec `wp_register_ability()` est une chose ; vérifier qu'un agent connecté via le Model Context Protocol reçoit exactement la réponse attendue, ou un refus propre quand il sort du périmètre autorisé, en est une autre. Ce billet ne traite pas la déclaration de l'ability elle-même — schéma, callback, enregistrement — déjà couverte séparément, mais uniquement la couche d'appel côté MCP.

Le contexte : une ability `librairie/rechercher-document` exposée à un agent IA chargé d'assister les bibliothécaires d'un réseau de médiathèques. L'ability existe, son schéma est valide, ses tests unitaires passent. Restait à vérifier ce qui se passe réellement une fois qu'un agent MCP l'appelle dans des conditions réalistes, pas seulement dans le cas idéal.

## Simuler un appel MCP en test

Un agent MCP envoie une requête structurée qui, une fois traduite côté WordPress, aboutit à un appel de l'ability via le registre. Pour tester cette chaîne sans dépendre d'un vrai agent IA (non déterministe par nature), nous simulons directement la charge utile MCP telle qu'elle arriverait :

```
public function test_agent_recoit_les_documents_correspondants(): void
{
    $reponse = $this->appelerAbilityViaMcp('librairie/rechercher-document', [
        'requete' => 'histoire de France',
        'limite' => 5,
    ]);

    $this->assertSame(200, $reponse['status']);
    $this->assertIsArray($reponse['result']['documents']);
    $this->assertLessThanOrEqual(5, count($reponse['result']['documents']));
}
```

## Vérifier le refus propre hors permissions

Le point le plus critique n'est pas le chemin heureux, c'est le refus. Un agent IA mal encadré qui obtient une erreur PHP brute ou une réponse ambiguë peut interpréter cela de façon imprévisible — parfois en réessayant en boucle, parfois en construisant une réponse erronée pour l'utilisateur final. Nos tests vérifient que chaque cas de refus produit une structure prévisible :

> L'essentiel à retenir : Un agent IA n'envoie pas toujours l'appel attendu, même avec un schéma clair ; Le refus hors permissions doit être aussi propre que la réponse valide ; Le format de réponse compte autant que son contenu pour un agent

- Un utilisateur sans la capacité requise qui tente d'appeler l'ability reçoit un refus explicite, pas une erreur 500
- Une ability appelée avec un paramètre hors des valeurs permises par le schéma est rejetée avant exécution du callback
- Une ability désactivée temporairement (par exemple pendant une maintenance) renvoie un statut cohérent, distinct d'un refus de permission
- Un agent qui dépasse une limite de débit définie par l'hébergeur reçoit une réponse structurée indiquant le délai avant nouvelle tentative

### Un format de refus qui reste exploitable par l'agent

Nous avons standardisé la structure des refus sur le modèle utilisé par l'API REST de WordPress (`code`, `message`, `data.status`), pour que l'agent puisse distinguer un refus de permission d'une erreur de validation sans avoir à analyser un message en langage naturel.

## Ce que teste réellement ce type de suite

Contrairement aux tests unitaires classiques d'une ability, ces tests ne portent pas sur la justesse du résultat métier, mais sur la robustesse du canal : forme de la réponse, cohérence des codes de statut, absence de fuite d'information dans les messages d'erreur (un message trop précis peut révéler l'existence de données que l'agent n'aurait pas dû pouvoir deviner).

> Un agent IA ne lit pas entre les lignes d'un message d'erreur ambigu — il agit sur ce qu'il reçoit, littéralement.

## Notre verdict

Tester une ability isolément ne suffit pas dès qu'elle est destinée à être appelée par un agent autonome plutôt que par un humain qui peut interpréter une erreur imparfaite. La couche MCP mérite sa propre suite, centrée sur la forme des réponses et la propreté des refus, distincte des tests unitaires du cœur métier de l'ability.