Tests agentiques ou Playwright : que garder dans sa CI

Un agent IA sait aujourd'hui parcourir une application web. Reste à savoir à quel endroit du pipeline il apporte quelque chose qu'un script Playwright n'apporte pas, et combien coûte chaque exécution. Une suite Playwright tourne gratuitement sur chaque commit. Un service agentique comme TesterArmy facture le run, mais n'a besoin d'aucun sélecteur et peut lire une pull request pour décider quoi tester.

Cette page ne refait pas la méthode d'écriture d'un test agentique, que le guide tests E2E agentiques couvre déjà. Elle répond à une question d'architecture : quelle couche placer à quel moment de la CI. Les informations viennent des documentations et tarifs officiels consultés le 30 octobre 2026.

Réponse courte

Gardez Playwright pour tout ce qui doit tourner à chaque push et échouer pour une raison précise : contrats d'API, calculs, permissions, réponses réseau simulées, tests de composants. TesterArmy lui-même conseille de laisser les tests de composants et les tests d'API dans Playwright [8]. Ajoutez une couche agentique là où l'écriture et la maintenance de scripts coûtent cher : parcours complets sur un déploiement de prévisualisation, authentification par code reçu par e-mail ou SMS, applications mobiles natives, surveillance planifiée de la production.

Si votre équipe a déjà une suite Playwright stable et peu de parcours qui cassent, la couche agentique n'est pas indispensable. Les agents intégrés à Playwright peuvent même vous aider à écrire et réparer les tests existants sans changer d'outil [4].

Deux modèles d'exécution

Playwright Test est un framework de tests de bout en bout qui regroupe le lanceur, les assertions, l'isolation et la parallélisation. Il pilote Chromium, WebKit et Firefox sous Windows, Linux et macOS, en local ou en CI [1]. Le projet est publié sous licence Apache-2.0 [10]. Les tests sont du code dans votre dépôt, versionné et relu comme le reste.

TesterArmy repose sur des agents qui utilisent la vision pour parcourir l'application comme un utilisateur [6]. Vous écrivez des étapes en langage naturel (« se connecter », « créer un projet ») et l'agent trouve comment les accomplir. Le service gère l'authentification par Google, par mot de passe et par code à usage unique reçu par e-mail ou SMS, l'envoi de fichiers et la résolution de captchas [6]. Les tests vivent dans le service, pas dans le dépôt.

Cette différence a une conséquence directe en CI. Un test Playwright échoue sur une assertion précise, avec un message qui dit ce qui était attendu et ce qui a été reçu [2]. Un run TesterArmy rend un verdict parmi trois : réussi, échoué, ou bloqué. Ce dernier est réservé aux cas où l'environnement ou une limite de l'automatisation empêche de conclure sur le produit [12]. Cette troisième valeur est utile : un environnement en panne ne passe pas pour une régression. Elle oblige aussi à traiter ce cas dans la logique du pipeline.

Ce que Playwright garde mieux

Les assertions de Playwright sont explicites et se réessaient automatiquement jusqu'à ce que la condition soit remplie ou que le délai expire, 5 secondes par défaut [3]. Vous pouvez vérifier un texte exact, un attribut, une URL ou le contenu d'une réponse. Ce niveau de précision est ce qu'il faut pour un montant de facture, un droit d'accès ou un en-tête de sécurité.

La simulation du réseau est l'autre point fort. Un test Playwright peut intercepter une requête et renvoyer une réponse préparée. La documentation de migration de TesterArmy le dit sans détour : ce cas ne se transpose pas, parce que ses tests tournent contre un environnement réel [8]. Si votre suite repose sur des réponses d'API simulées pour tester des cas d'erreur, elle reste dans Playwright.

Le coût marginal compte aussi. Un test Playwright ne coûte que les minutes de votre CI. La commande d'initialisation propose d'ailleurs d'ajouter directement un workflow GitHub Actions qui lance la suite à chaque push et pull request vers la branche principale [2]. Le guide GitHub Actions pour un SaaS montre comment l'intégrer au reste du pipeline.

Playwright vient aussi avec trois agents : un planificateur qui explore l'application et écrit un plan de test en Markdown, un générateur qui transforme ce plan en fichiers de test, et un réparateur qui rejoue un test en échec et propose un correctif, par exemple un sélecteur mis à jour [4]. Le résultat reste du code Playwright dans votre dépôt. Le guide générer des tests avec Claude Code suit la même logique avec un assistant de code.

Ce que la couche agentique apporte

Le premier apport est la tolérance aux changements d'interface. TesterArmy met en avant que les scripts à sélecteurs doivent être modifiés à chaque évolution de l'interface, alors que ses agents se repèrent visuellement [6]. C'est un argument de l'éditeur, à vérifier sur vos propres écrans, mais il touche un vrai coût de maintenance.

Le deuxième est le test des pull requests sans script préalable. TesterArmy peut lancer deux types de tests sur chaque prévisualisation : des groupes de régression enregistrés, qui rejouent toujours les mêmes étapes, et un agent d'exploration [5]. Celui-ci lit le titre, la description et les fichiers modifiés de la PR, écrit un plan adapté au changement, puis l'exécute dans un navigateur ou un simulateur mobile. Un filtre examine d'abord le diff : une PR qui ne touche que la documentation ou la configuration est marquée comme ignorée, avec un statut neutre plutôt qu'un succès ou un échec [9]. Les résultats remontent dans les checks GitHub et en commentaire de la PR [5].

Le troisième est le mobile natif et l'authentification difficile. Playwright émule Chrome sur Android et Safari mobile [1], mais ne pilote pas une application iOS ou Android native. TesterArmy teste des builds sur simulateurs iOS et émulateurs Android [6]. Les codes reçus par e-mail ou par SMS, qu'un script doit souvent contourner avec un code fixe en préproduction, sont gérés par le service [6].

Enfin, la surveillance planifiée. Un groupe de tests peut tourner toutes les heures, chaque nuit ou selon une expression cron, contre la production ou un environnement de recette [13].

Brancher TesterArmy dans un pipeline existant

Pour une CI qui n'est pas reliée à Vercel, Netlify ou Coolify, la documentation décrit un webhook signé par groupe de tests. Après le déploiement, le pipeline envoie l'identifiant du commit et l'URL déployée. TesterArmy met en file tous les tests du groupe et renvoie les identifiants des runs [7]. Deux détails changent la façon de l'utiliser. L'URL cible doit être joignable depuis internet : il n'existe pas d'exécuteur privé pour un environnement interne. Et une réponse positive du webhook signifie que les runs sont acceptés, pas qu'ils ont réussi [7]. Le secret fait partie de l'URL du webhook ; stockez-la comme une variable masquée de la CI, avec les précautions décrites dans gérer les secrets API proprement.

Pour rassembler les résultats au même endroit que ceux de Playwright, TesterArmy exporte un run ou un groupe de runs au format JUnit XML, lisible par les rapporteurs de GitHub, GitLab, Jenkins ou CircleCI [11]. Un run bloqué y apparaît comme une erreur, et non comme un échec [11].

Ce que coûte un run

Playwright ne facture rien. TesterArmy facture le run, et la règle de comptage décide du budget.

Palier TesterArmy	Prix	Runs par mois	Runs simultanés	Projets
Free	0 $	5	1	2
Hobby	99 $ par mois ou 1 000 $ par an	250	3	2
Startup	299 $ par mois ou 3 000 $ par an	1 000	10	5

Tarifs relevés sur la page de prix et la documentation de facturation [14][15]. Un run correspond à l'exécution d'un test et peut durer jusqu'à 20 minutes. Il compte qu'il réussisse ou qu'il échoue, et lancer un groupe de 12 tests consomme 12 runs [15]. Il n'y a pas de dépassement facturé : à la limite, les nouveaux runs sont bloqués jusqu'au 1er du mois suivant, et l'API, la CLI et les webhooks renvoient une erreur HTTP 429 [15].

Faites le calcul avant de brancher la couche agentique sur chaque PR. Un groupe de 10 tests sur 25 pull requests par mois, avec une relance en moyenne sur chacune, représente 500 runs. C'est au-delà du palier Hobby. L'agent d'exploration seul, qui écrit un plan par PR, consomme moins qu'une grande suite rejouée à chaque fois. Gardez aussi en tête qu'un pipeline bloqué par une erreur 429 en fin de mois ne doit pas empêcher une fusion urgente.

Une répartition qui tient

Sur chaque push, lancez la suite Playwright : tests d'API, de composants et de bout en bout sur les parcours sensibles, avec réseau simulé si besoin. Elle doit être rapide et bloquante.

Sur chaque prévisualisation de PR, ajoutez l'agent d'exploration ou un petit groupe de régression agentique, d'abord en mode non bloquant. Comparez ses alertes aux défauts réellement confirmés pendant quelques semaines avant de le rendre obligatoire.

Chaque nuit ou toutes les quelques heures, faites tourner un groupe agentique court sur la production : connexion, parcours principal, paiement en mode test si votre service le permet.

Quand un parcours agentique échoue souvent pour la même raison précise, c'est le signe qu'il doit devenir un test Playwright. À l'inverse, un test Playwright qu'il faut réparer à chaque refonte d'écran est un candidat à la couche agentique.

TesterArmy, pour qui

TesterArmy convient à une équipe qui livre souvent, utilise des déploiements de prévisualisation et passe trop de temps à réparer des sélecteurs. C'est aussi le cas d'une équipe qui doit tester une application mobile native ou des parcours avec code par SMS sans monter sa propre infrastructure. L'offre gratuite à 5 runs suffit pour voir un premier verdict, pas pour juger de la stabilité d'une suite.

Découvrir TesterArmy

Lien affilié : Vibarche peut recevoir une commission si vous souscrivez, sans surcoût pour vous.

Pour aller plus loin

Sources

Pages consultées le 30 octobre 2026.