Gatling publie un tutoriel pour obtenir un premier test de charge sans écrire le script à la main. Vous parcourez votre application dans un navigateur Playwright, en annonçant chaque étape à l'agent de code (le tutoriel utilise Claude Code). L'agent enregistre les appels d'API de chaque étape, puis écrit un projet Gatling en Java et Maven où les identifiants et les jetons sont extraits des réponses plutôt que figés. Il lance ensuite le test une fois avec un utilisateur, et une seconde consigne le déploie sur Gatling Enterprise.
Le texte annonce lui-même ses limites. Le test rejoue le trafic d'API : l'affichage côté navigateur n'est pas mesuré. Le dossier d'enregistrement contient cookies, jetons et identifiants saisis, d'où la consigne d'utiliser un compte de test. Les 60 000 utilisateurs virtuels concurrents par injecteur (selon la complexité du protocole) et le premier test « en minutes » sont des chiffres de l'éditeur, non mesurés ici.
Ce que ça change pour un testeur de performance
À notre avis, le gain porte sur la première version du script, la plus pénible : corrélations et enchaînement d'étapes. C'est un brouillon à relire, pas un test prêt pour la charge. Un essai à un utilisateur ne prouve ni la bonne paramétrisation des données ni des temps de réflexion réalistes ; le tutoriel reconnaît d'ailleurs, quand l'agent parcourt lui-même le site, des pauses estimées plutôt que les vôtres.
Reste le profil d'injection. Pour une application publique, le texte recommande un modèle ouvert (un taux d'arrivée, par exemple rampUsersPerSec), afin qu'un ralentissement apparaisse au lieu d'être masqué. Bonne consigne, à appliquer vous-même : le premier test n'a qu'un utilisateur. Flux non rejoué ici.
Rédigé avec l’aide d’une IA, relu et validé par Philippe Naveau.