# Un pipeline de tests de régression automatisés pour les abilities d’un site

> Mise en place d'une suite qui rejoue des scénarios d'agent contre les abilities d'un site à chaque déploiement, pour repérer une régression avant un agent réel.

- Auteur : Clément Hadrot
- Publié le : 2026-08-29
- Mis à jour le : 2026-08-29
- Catégorie : IA & MCP
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/pipeline-tests-regression-abilities/

## L’essentiel

- Chaque ability a ses propres scénarios de test rejoués automatiquement
- Le pipeline s'exécute à chaque déploiement, pas seulement en recette
- Une régression détectée bloque le déploiement avant qu'un agent la rencontre

Une agence gérant l'intégration continue d'un site exposant une vingtaine d'abilities à plusieurs agents internes a connu, à deux reprises en quelques mois, le même type d'incident : une mise à jour de code touchant une fonction métier existante modifiait involontairement le comportement d'une ability qui s'appuyait dessus, sans que personne ne le remarque avant qu'un agent en production ne rencontre l'anomalie. Ce texte ne traite pas l'évaluation d'un agent sur des tâches ponctuelles, sujet distinct déjà abordé ailleurs : il porte sur un pipeline de tests de régression appliqué directement aux abilities elles-mêmes.

L'idée centrale du pipeline mis en place : traiter chaque ability comme une interface publique au même titre qu'une fonction d'API, avec des tests automatisés qui vérifient qu'elle continue de se comporter comme attendu à chaque changement de code, indépendamment de l'agent qui l'utilisera plus tard.

## La structure d'un scénario de test

Chaque ability du site dispose d'au moins deux scénarios de test : un cas nominal, avec des paramètres valides et un résultat attendu précis, et un cas limite, avec des paramètres invalides ou en bordure du domaine accepté. Ces scénarios sont écrits une fois, lors de l'enregistrement de l'ability, et rejoués automatiquement à chaque déploiement.

> L'essentiel à retenir : Chaque ability a ses propres scénarios de test rejoués automatiquement ; Le pipeline s'exécute à chaque déploiement, pas seulement en recette ; Une régression détectée bloque le déploiement avant qu'un agent la rencontre

```
class Test_Ability_Consulter_Stock extends WP_UnitTestCase {

    public function test_cas_nominal_produit_existant() {
        $produit_id = $this->creer_produit_test( array( 'stock' => 12 ) );

        $resultat = wp_execute_ability( 'agence/consulter-stock', array(
            'product_id' => $produit_id,
        ) );

        $this->assertSame( 12, $resultat['quantite'] );
        $this->assertArrayHasKey( 'derniere_maj', $resultat );
    }

    public function test_cas_limite_produit_inexistant() {
        $resultat = wp_execute_ability( 'agence/consulter-stock', array(
            'product_id' => 999999,
        ) );

        $this->assertWPError( $resultat );
        $this->assertSame( 'produit_introuvable', $resultat->get_error_code() );
    }
}
```

## L'exécution à chaque déploiement

Le pipeline d'intégration continue exécute l'ensemble des 42 scénarios de test à chaque poussée de code vers la branche principale, avant tout déploiement en production. Un échec sur un seul scénario bloque le déploiement entier, avec un rapport précisant exactement quelle ability et quel scénario ont échoué.

```
$ vendor/bin/phpunit --testsuite abilities-regression

Exécution de 42 scénarios sur 21 abilities...

FAIL: Test_Ability_Ajuster_Stock::test_cas_nominal_quantite_positive
  Attendu : quantite = 45
  Obtenu  : quantite = null

1 échec sur 42 scénarios. Déploiement bloqué.
```

## Un exemple de régression réellement détectée

Trois semaines après la mise en place du pipeline, une modification apportée à la fonction de calcul de stock pour prendre en compte un nouvel entrepôt secondaire a introduit une régression sur l'ability `ajuster_stock` : le champ de retour `quantite` se retrouvait vide dans certains cas, la fonction modifiée renvoyant désormais un tableau détaillé par entrepôt plutôt qu'un total unique, sans que ce changement de format ait été répercuté dans la couche d'adaptation de l'ability. Le pipeline a bloqué le déploiement avant toute mise en production, avec un message précis désignant le scénario en échec.

| Sans pipeline de régression | Avec pipeline de régression |
| --- | --- |
| Régression découverte par un agent en production | Régression bloquée avant déploiement |
| Diagnostic après coup, sans contexte du changement en cause | Message d'échec pointant directement le scénario concerné |

## Maintenir les scénarios à jour

Le pipeline n'a de valeur que si les scénarios eux-mêmes restent à jour avec les besoins réels des agents. Chaque nouvelle capacité utilisée par un agent en production, non couverte par un scénario existant, déclenche l'écriture d'un nouveau test avant la prochaine évolution de l'ability concernée, plutôt que d'attendre un futur incident pour le constater.

> Un scénario de test qui ne couvre pas un usage réel de l'agent ne protège que d'une régression théorique. La vraie protection vient des scénarios écrits à partir de ce que les agents font effectivement, pas de ce qu'on imagine qu'ils pourraient faire.

## En résumé

Traiter chaque ability comme une interface publique testée en continu, avec des scénarios rejoués à chaque déploiement, permet de repérer une régression avant qu'un agent en production ne la rencontre, plutôt qu'après. Le coût d'écriture initial de ces scénarios reste modeste comparé au temps de diagnostic économisé le jour où une modification de code, apparemment sans rapport, casse silencieusement le comportement d'une ability existante.