Trois agents Playwright : le planificateur, le générateur et le correcteur pour une application de panier en direct.

La plupart des gens ont vu la démonstration : on sollicite un modèle, on reçoit un script Playwright, on le lance une fois, puis on le voit cesser de fonctionner peu de temps après. Une équipe de QA efficace suit un cycle différent composé d’exploration, de planification, d’automatisation et de maintenance, et l’objectif ici était de conférer à un agent la responsabilité de chacune de ces étapes. Le résultat est un framework Playwright réutilisable, soutenu par trois agents spécialisés :

• Planner explore l’application en temps réel et rédige le plan de test.
• Generator transforme un scénario planifié en une spécification fonctionnelle.
• Healer exécute le jeu de tests, détermine pourquoi ceux-ci échouent et corrige la cause sous-jacente.

Le prototype visé était une petite application de panier avec un flux allant du connexion aux produits, en passant par le panier, la caisse et une page de remerciement. Au final, on a obtenu 22 scénarios automatisés couvrant les parcours normaux, les cas négatifs et les cas limites de validation. Ils s’exécutent en parallèle, en utilisant des objets de page que les agents gèrent eux-mêmes. Le rapport HTML de Playwright indiquait 22 tests réussis, 0 échecs, 0 cas instables, avec l’ensemble des tests terminés en 16,2 secondes.

Prérequis avant l’exécution de tout agent

Il faut d’abord disposer de trois éléments. La plupart des guides les omettent, or ce sont eux qui déterminent si le résultat généré est utilisable ou non.

Le serveur de test MCP de Playwright. Les agents ne doivent pas deviner la structure du DOM, c’est pourquoi ils utilisent un vrai navigateur. Un fichier de configuration les relie entre eux :

{
  "servers": {
    "playwright-test": {
      "type": "stdio",
      "command": "npx",
      "args": ["playwright", "run-test-mcp-server"]
    }
  }
}

Cela fournit à chaque agent des outils tels que browser_navigate, browser_snapshot et browser_click, ainsi que test_run et test_debug pour le Healer.

Un contrat de framework. Un fichier framework.md définit les dossiers et les conventions : les sélecteurs se trouvent dans pages/, les parcours utilisateurs dans flows/, et les adresses ainsi que les identifiants dans .env. Chaque agent le lit avant d’effectuer quoi que ce soit, de sorte que les résultats ressemblent à une seule base de code plutôt qu’à trois styles personnels distincts.

Un test de base. Une petite spécification ouvre la page d’accueil réelle et vérifie l’existence de quelque chose de stable. Chaque test généré part de cet état connu et fiable.

Un agent n’est bon que dans la mesure où il s’appuie sur des fondements solides, et ces trois éléments en constituent les fondations.

Le Planificateur : décider ce qui mérite un test

Le planificateur n’écrit absolument aucun code. Il ouvre l’application, explore comme un testeur curieux et cartographie ce qui existe : formulaires, mécanismes d’authentification, panier d’achat, étapes de paiement, messages de validation et états vides.

Sa routine :

1. Appeler planner_setup_page une seule fois.
2. Explorer à l’aide des outils du navigateur, en consultant des captures DOM plutôt que des captures d’écran.
3. Identifier les parcours principaux et les manières dont chacun peut échouer.
4. Enregistrer un plan au format Markdown à l’emplacement specs/<feature>-plan.md.

Chaque scénario du plan comporte un titre, des étapes numérotées, un résultat attendu, une hypothèse concernant l’état de départ (une session vierge sauf indication contraire) ainsi que le chemin du fichier qui en résultera.

Le plan de paiement s’est révélé comprendre 22 scénarios organisés en sections pour le connexion, le panier, le paiement, ainsi qu’un parcours complet du début à la fin. Cette structure s’avère utile par la suite, car le générateur transforme chaque nom de section en un bloc test.describe, ce qui permet au plan et au code de rester alignés dès la conception.

Pourquoi une étape séparée ? La couverture est un problème de réflexion. Lorsqu’une seule instruction exige à la fois la planification et l’écriture du code, la planification se détériore. Un résultat uniquement basé sur la planification peut être revu et modifié avant même qu’une seule ligne de code de test n’existe.

Le générateur : rendre un scénario réel

Le générateur gère exactement un scénario à la fois, jamais l’ensemble du plan. Pour chacun d’eux, il :

1. Démarre generator_setup_page pour atteindre l’état de départ.
2. Exécute chaque étape en temps réel dans le navigateur, interprétant le texte de l’étape comme une intention.

Réécrit le journal d’exécution à l’aide de generator_read_log, qui contient les identifiants des éléments et indique ceux qui ont réellement fonctionné.

Appelle generator_write_test pour générer un seul fichier de spécifications.

C’est à l’étape trois que provient la valeur. Aucune information provenant des données d’entraînement n’est conservée. Ce qui est enregistré dans le fichier correspond à un rapport d’une session venant de se dérouler sur l’interface réelle.

La sortie respecte automatiquement les règles du framework :

// spec: specs/checkout-e2e-plan.md
// seed: tests/web/seed.spec.js

import { test, expect } from '../../../fixtures';
import { users } from '../../../testdata';test.describe.configure({ mode: 'parallel' });test.describe('E2E checkout journey', () => {
  test('positive: login → add product → checkout → thank you → home', async ({ flow }) => {
    await flow.completeHappyPathPurchase();
  });
});

Il manque notoirement dans le résultat les sélecteurs CSS, un mot de passe littéral ainsi que des chaînes URL. Les sélecteurs sont intégrés dans les objets de page, et les parcours en plusieurs étapes deviennent des méthodes au sein d’une classe de flux :

async completeHappyPathPurchase(user = users.standard, info = checkout.valid) {
  await this.goToCheckoutInformation(user);
  await this.fillValidInformation(info);
  await this.continueToOverview();
  await this.app.checkoutOverview.expectProductVisible(products.first.name);
  await this.finishOrder();
  await this.backHomeToProducts();
}

Chaque test reçoit également son propre contexte de navigateur, son graphe d’objets de page et son instance de flux grâce aux fixtures. En l’absence d’état mutable partagé, la suite est sûre pour être exécutée en parallèle dès le début, et non comme une solution ajoutée ultérieurement. C’est ce qui distingue un script d’un framework.

The Healer : corriger le bon niveau

La génération de tests représente un avantage ponctuel. La maintenance constitue le coût permanent, et c’est là que le troisième agent trouve sa place. Son cycle est le suivant :

1. test_run exécute la suite et collecte les échecs.
2. test_debug s’arrête à chaque échec.
3. Il examine l’aperçu en temps réel, la console, le trafic réseau ainsi que l’assertion qui a échoué.
4. Il diagnostique la cause : un locateur modifié, un décalage de timing, un contrat changé ou un véritable bug du produit.

Il répare la cause racine et non le symptôme, en mettant à jour pages/ lorsque l’interface a été déplacée et api/endpoints/ lorsque un contrat a été modifié.

Il exécute à nouveau ce test puis passe au prochain échec.

Deux mécanismes de contrôle garantissent sa fiabilité. Il ne affaiblit jamais une assertion juste pour obtenir un résultat positif. Si le produit est incorrect mais que le test est correct, il marque le test avec test.fixme() ainsi qu’un commentaire décrivant le comportement réel, afin que l’échec reste visible et ne soit pas occulté. Il évite également les API peu fiables comme networkidle en guise de solution temporaire à un problème de concurrence.

L’avantage réside dans la concentration des modifications. En renommant un bouton, une seule méthode d’objet de page est modifiée, ce qui permet à tous les tests qui l’utilisent de fonctionner à nouveau. Étant donné que 22 tests partagent 325 lignes d’objets de page réparties sur 10 classes, une refonte n’affecte pas l’ensemble du jeu de tests. Dans l’ensemble, chaque composant est responsable d’une partie bien définie du répertoire, et la couche commune des objets de page est ce qui maintient tout le système en place.

L’exécution du début à la fin

Les commandes de configuration :

1. Copy .env.example → .env, set BASE_URL (+ credentials)
2. npm install && npx playwright install

Et l’agent s’exécute, dans l’ordre suivant :

3. Run the Planner
      → specs/checkout-e2e-plan.md   (22 scenarios, reviewed by me)4. Run the Generator, scenario by scenario
      → tests/web/login/login.spec.js
      → tests/web/cart/cart.spec.js
      → tests/web/checkout/checkout.spec.js
      → tests/web/e2e/checkout-journey.spec.js5. npm test        (4 workers, fully parallel)6. Any red? Run the Healer → re-run → green

Le passage à un autre produit n’affecte pas les agents. Définissez BASE_URL sur le nouveau produit, recréez les objets de page et les données de test, puis lancez à nouveau les mêmes trois instructions. Comme les agents lisent framework.md et .env plutôt qu’un nom de produit codé en dur, le pipeline est portable et non sur mesure.

De combien est-ce vraiment plus rapide ?

Une affirmation du type « L’IA a rendu cela dix fois plus rapide » ne devrait pas être acceptée sans une explication détaillée. Rédiger un test bout en bout manuellement ne consiste que rarement à taper du texte. Il s’agit plutôt d’ouvrir les DevTools, de chercher un sélecteur fiable, de trouver le bouton à l’intérieur d’un conteneur inhabituel, de relancer le test pour constater que la vérification se déclenche prématurément, et de tout recommencer. La majeure partie du temps est consacrée à ce cycle de découverte, et le générateur l’absorbe en exécutant les étapes en temps réel et en indiquant ce qui a fonctionné.

Les gains apparaissent à plusieurs étapes :

• Détermination de la couverture. De manière manuelle, cela relève du cas par cas et omet souvent les cas négatifs. Le planificateur énumère à l’avance les scénarios positifs, négatifs et limites.
• Recherche des locateurs. La recherche manuelle dans les outils de développement par élément cède la place à des locateurs extraits d’une session déjà terminée.
• Premier test réussi. Le cycle d’écriture, de exécution, de correction et de répétition se transforme en génération à partir d’un transcript vérifié.
• Maintien de la suite de tests en état de fonctionnement. La recherche systématique dans chaque spécification pour identifier un sélecteur défectueux cède la place à une correction unique sur la page-objet qui résout tous les tests dépendants.

Les économies les plus importantes proviennent du deuxième au vingtième test. Le premier implique des coûts réels de configuration pour les objets de page, les fixtures et les données initiales. À partir de là, un nouveau scénario consiste principalement en l’assemblage de parties existantes, ce qui fait chuter rapidement le coût par test.

La vitesse d’exécution provient d’une autre source complètement différente. Le parallélisme n’est pas une fonctionnalité de l’IA ; c’est une règle de conception que les agents doivent respecter. Chaque test reçoit un contexte frais provenant des fixtures, et aucun ne modifie l’état du module partagé, ce qui permet à la configuration de s’exécuter en parallèle : quatre travailleurs localement, deux dans le CI avec deux tentatives de répétition, les traces et la vidéo étant enregistrés uniquement en cas d’échec du test. Toute suite qui réutilise une seule session de connexion ne peut pas fonctionner de cette manière sans risque. Celle-ci, en revanche, le peut, car la règle selon laquelle un scénario équivaut à un test indépendant devait être respectée par le Générateur dans chaque fichier.

Quatre leçons à retenir

• Réduisez la portée des rôles. Un seul prompt étendu qui planifie, code et débogue produit des résultats flous. Trois rôles ciblés, chacun disposant de ses propres outils, permettent de laisser quelque chose à examiner à chaque étape.

Favoriser l’exécution basée sur la mémoire. Les locateurs confirmés dans un navigateur en cours d’exécution sont plus fiables que ceux déduits à partir des documents.

Construire l’ossature avant les agents. Les objets de page, les fixtures, la gestion de l’environnement et les règles parallèles sont ce qui permet à l’IA de produire un framework plutôt qu’un amas de scripts. Rédiger framework.md a amélioré la qualité plus que n’importe quel ajustement de prompt.

La correction est le véritable résultat attendu. Il est facile de créer un test une seule fois. C’est un agent capable de maintenir 22 tests fonctionnels après un renouvellement de l’interface utilisateur qui justifie l’adoption de cette approche.

Ce qui convient à qui

Les ingénieurs QA qui passent plus de temps à réparer les outils de localisation qu’à concevoir des stratégies de couverture en tireront profit. De même, les équipes qui adoptent Playwright et souhaitent intégrer de l’IA au sein d’une structure disciplinée sans la remplacer, ainsi que quiconque compare les agents Copilot ou Cursor au serveur de tests MCP de Playwright en bénéficieront.

Rien de tout cela ne remplace le travail de QA. Le jugement quant à ce qui est important, ce qui constitue un véritable bug et quelle couverture manque reste entre les mains d’un humain. Les agents s’occupent de l’exploration, des tâches répétitives et des corrections, ce qui permet de suivre le cycle : planifier, générer, exécuter, corriger et réexécuter.