Des minutes au lieu de jours, sur le papier
Gatling décrit une chaîne qui part d'une navigation dans un navigateur Playwright et aboutit à un projet Gatling Java/Maven corrélé, écrit par un agent de code. L'éditeur chiffre l'écart sans détour : un premier test qui marche demande des jours à la main, des heures avec un enregistreur, des minutes avec cette méthode.
L'outil accélère la capture et la corrélation. Il ne conçoit pas le test à votre place, et les sources le reconnaissent dans leur section sur les limites, de loin la plus utile pour un praticien. Le reste se joue dans l'ordre : préparer le poste, tenir la capture, relire le Java, et seulement ensuite parler de charge.
Avant la capture : poste, périmètre, compte
La source liste ce qu'il faut sur le poste :
- un OpenJDK LTS 64 bits, de la version 11 à 25 ;
- Node.js 24 ou plus récent, pour playwright-cli ;
- un agent de code qui gère les serveurs MCP et les skills (Claude Code, Cursor, Codex, Windsurf et Antigravity sont cités) ;
- le plugin Gatling AI extensions ;
- un jeton d'API Gatling Enterprise avec au moins le rôle Configure, placé dans
GATLING_ENTERPRISE_API_TOKEN.
Maven est facultatif, le projet embarque le Maven Wrapper. L'installation de playwright-cli tient en deux commandes :
npm install -g @playwright/cli@latest
playwright-cli install --skills --globalLa seconde installe la skill pour Claude Code ; pour d'autres agents, la source indique --skills agents.
Un point se tranche avant de lancer quoi que ce soit : seuls les appels vers l'URL de base d'API déclarée dans le prompt entrent dans le test. Si votre front appelle plusieurs API, listez-les toutes. Un oubli donne un script qui rejoue proprement une partie seulement du trafic réel, et le smoke test passera quand même.
Reste le compte. Le dossier discovery/ contient de vraies données de session, cookies, jetons et identifiants saisis compris. Gatling demande d'enregistrer sur un environnement de test ou de recette, avec un compte de test, puis de relire le dossier ou de l'ajouter au .gitignore avant de committer. Nous réglerions la question du .gitignore dès la création du workspace : après coup, c'est souvent trop tard.
Pendant la capture : la discipline des marqueurs
Le découpage en étapes repose sur des marqueurs starting: postés dans la conversation avec l'agent. Chaque marqueur clôt l'étape en cours, dont les requêtes partent dans discovery/. Tout ce qui précède le premier marqueur devient une étape « initial load ».
L'ordre compte. Postez le marqueur, attendez la confirmation de l'agent, puis cliquez : le trafic émis avant un marqueur appartient à l'étape précédente.
La vraie chausse-trappe est ailleurs. playwright-cli ne liste que les requêtes de la page courante ; un rechargement complet au milieu d'une étape fait perdre les requêtes précédentes, et l'agent ne peut pas le détecter. L'erreur est donc silencieuse. Les changements de route d'une application monopage ne posent pas ce problème, mais sur une application à rechargements fréquents, découpez finement, une page complète par étape.
Les noms d'étapes, enfin, ne sont pas décoratifs. Les vérifications en découlent : une étape appelée « unauthenticated checkout » reçoit un 401 attendu, que Gatling compte alors comme OK. Un nom ambigu peut produire une assertion fausse.
Après la capture : relire ce que l'agent a écrit
Une fois done tapé, l'agent ferme le navigateur et ne travaille plus qu'à partir de discovery/. Il associe chaque appel à une étape et en fait un bloc du scénario ; dans la démonstration, 8 appels d'API se répartissent sur 6 étapes. Identifiants et jetons sont extraits des réponses et réutilisés, pas codés en dur.
Le résultat est du Java lisible, et l'agent vous interroge quand une requête ne s'attribue pas clairement à une étape ou qu'une étape semble incomplète. Répondez sérieusement à ces questions, puis passez le code au crible. Nous regarderions d'abord ceci :
| Point de contrôle | Pourquoi |
|---|---|
| Chaque étape contient-elle des appels ? | Une étape vide peut trahir un rechargement de page ou un marqueur tardif |
| Les statuts attendus sont-ils justes ? | Ils découlent des noms d'étapes |
| Toutes les API du front sont-elles présentes ? | Seule l'URL de base déclarée est retenue |
L'agent ajoute aussi une assertion qui fait échouer le tir si une requête échoue. C'est une vérification de fonctionnement, pas un critère de performance.
Le smoke test n'est pas un test de charge
Le premier lancement local tourne avec un seul utilisateur virtuel :
./mvnw gatling:testSous Windows, la commande est mvnw.cmd gatling:test. Dans la démonstration, ce tir renvoie 8 requêtes, 8 OK, 0 KO. Le parcours se rejoue, rien de plus.
Pour ajouter de la charge, il faut modifier le profil d'injection dans le setUp de la simulation. Pour une application web publique, Gatling conseille un modèle ouvert fondé sur un débit d'arrivée, par exemple rampUsersPerSec, afin qu'un ralentissement apparaisse au lieu d'être masqué. Le conseil est bon, et c'est là que commence le travail qu'aucun agent ne fait pour vous.
Le passage sur Gatling Enterprise se fait ensuite par un prompt ; l'agent pose quelques questions, dont l'emplacement du générateur et les critères d'arrêt. Ces critères et les objectifs de débit, c'est à vous de les fixer : les sources ne disent rien d'une aide à leur conception.
Ce que la méthode ne mesure pas
Le test rejoue le trafic d'API, pas le navigateur, et le temps de rendu côté front n'est pas mesuré. En contrepartie, Gatling annonce jusqu'à 60 000 utilisateurs virtuels simultanés par générateur, avec une réserve qu'il pose lui-même sur la complexité du protocole et l'architecture. Nous lisons ce chiffre comme un ordre de grandeur, pas comme une capacité garantie.
Si votre question porte sur la performance perçue, page comprise, la source rappelle que Playwright sert aussi à charger avec de vrais navigateurs sans tête, au prix d'une consommation CPU et mémoire qui croît avec chaque utilisateur.
L'agent peut aussi parcourir le site seul à partir d'une description. Gatling garde pourtant la navigation manuelle par défaut, pour des raisons concrètes : l'agent choisit son propre chemin, peut bloquer sur une connexion, un CAPTCHA ou une détection de robot, et la capture porte l'User-Agent d'un navigateur sans tête, avec des pauses estimées au lieu de vos temps de réflexion. Comme l'éditeur le suggère, ce mode convient aux parcours publics simples, pas davantage.
Ce qu'on ignore encore
Traitez le script généré comme un brouillon corrélé, à relire avant tout tir. Une question reste ouverte, et les sources n'y répondent pas : la démonstration porte sur un parcours e-commerce à 6 étapes. Comment la capture tient-elle sur un parcours long, avec des dizaines d'étapes et plusieurs API ? Nous ne le savons pas encore.
Publié par Philippe Naveau