# Évaluer un agent IA sur un site de test : tâches, scores et régressions

> Construire un banc d'essai reproductible pour comparer agents et prompts sur des tâches WordPress réelles, avec un environnement Playground jetable et des métriques stables.

- Auteur : Clément Hadrot
- Publié le : 2026-05-15
- Mis à jour le : 2026-05-15
- Catégorie : IA & MCP
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/evaluer-agent-ia-site-test/

## L’essentiel

- Un environnement jetable évite la contamination entre deux tests
- Les tâches doivent avoir un critère de réussite vérifiable automatiquement
- Rejouer les mêmes tâches après un changement de modèle révèle les régressions

Choisir un agent IA ou ajuster un prompt à l'intuition, sans mesure reproductible, mène tôt ou tard à une régression silencieuse : un changement qui améliore une tâche en dégrade une autre sans que personne ne s'en aperçoive avant une réclamation client. Nous avons construit un banc d'essai interne, appuyé sur WordPress Playground pour disposer d'un environnement jetable et identique à chaque exécution. Cet article ne traite pas de l'évaluation de prompts isolés hors contexte agentique, un exercice plus simple traité ailleurs : ici, il s'agit de tâches complètes impliquant plusieurs actions successives.

## Pourquoi un environnement jetable est indispensable

Tester un agent sur un site de développement classique pose un problème de fond : chaque test modifie l'état du site, rendant le test suivant non comparable au précédent. WordPress Playground, qui démarre une instance WordPress complète dans un environnement isolé et reproductible, résout ce problème : chaque tâche démarre depuis un état initial identique, chargé à partir d'un export de référence contenant un jeu de contenus et de configurations fixe.

## Construire des tâches à critère vérifiable

Une tâche mal conçue pour un banc d'essai est une tâche dont le succès s'apprécie « à l'œil ». Nous formulons chaque tâche avec un critère de réussite vérifiable par un script, pas par une relecture humaine subjective : par exemple, non pas « améliore le référencement de cette page » mais « la balise `meta description` de la page doit contenir entre 120 et 160 caractères et le mot-clé fourni ».

> L'essentiel à retenir : Un environnement jetable évite la contamination entre deux tests ; Les tâches doivent avoir un critère de réussite vérifiable automatiquement ; Rejouer les mêmes tâches après un changement de modèle révèle les régressions

## Le format d'une tâche du banc d'essai

```
{
  "id": "tache-08",
  "consigne": "Crée une page de contact avec un formulaire à trois champs (nom, email, message) et publie-la.",
  "etat_initial": "export-reference-v3.zip",
  "verification": {
    "type": "script",
    "commande": "wp eval-file verifications/verif-page-contact.php"
  },
  "delai_maximal_minutes": 5
}
```

Le script de vérification interroge directement la base de données de l'instance Playground une fois la tâche terminée, vérifie la présence de la page, la structure du formulaire dans le contenu publié, et le statut réellement publié plutôt que brouillon. Un script de vérification mal écrit fausse tout le banc d'essai autant qu'une tâche mal formulée, nous les relisons donc avec la même rigueur.

## Les métriques suivies au-delà du simple succès binaire

Au-delà de la réussite ou de l'échec, nous suivons trois métriques par tâche : le nombre d'actions effectuées avant d'atteindre le résultat, le temps total d'exécution, et le nombre de tokens consommés. Un agent qui réussit une tâche en dix actions inutiles avant de trouver la bonne approche n'est pas équivalent à un agent qui réussit directement, même si le score de succès final est identique dans les deux cas.

### Détecter une régression après un changement

Le vrai intérêt du banc d'essai apparaît lors d'un changement de modèle ou de version d'un outil : rejouer les douze tâches permet de comparer objectivement les résultats avant et après, plutôt que de se fier à une impression générale d'amélioration ou de dégradation. Sur un changement de version d'un outil agentique testé récemment, deux tâches sur douze ont vu leur nombre d'actions augmenter significativement, révélant un changement de comportement que nous n'aurions probablement pas remarqué sans cette mesure systématique.

- Un environnement jetable identique à chaque test, via un export de référence fixe
- Un critère de réussite vérifiable par script, jamais par appréciation subjective
- Un suivi du nombre d'actions et de tokens, pas seulement du succès final
- Une réexécution systématique du banc complet après tout changement de modèle ou d'outil

> Sans mesure reproductible, une amélioration perçue n'est qu'une impression. Le banc d'essai transforme l'impression en donnée comparable.

## En résumé

Ce banc d'essai de douze tâches nous sert désormais de référence avant tout changement d'outil ou de modèle sur nos projets d'automatisation WordPress. Il ne prédit pas tout, en particulier sur des tâches inhabituelles jamais couvertes par le jeu de tests, mais il évite les régressions silencieuses sur les scénarios que nous avons choisi de surveiller en continu.