Questions d'entretien ingénieur performance Gatling ou k6, code et charge

Avec Gatling ou k6, un test de charge est du code : une simulation en Java, Kotlin, Scala ou JavaScript, relue en merge request et lancée par la pipeline. Le poste demande donc deux savoir-faire qu'on trouve rarement ensemble sur un CV, écrire un code de test propre et construire une charge qui ressemble à la production.

Recevoir la fiche complète

Mis à jour le Par l'équipe Delectus5 min de lecture

La fiche Ingénieur performance as code (Gatling, k6) : technologies, chaîne du poste, une question et la grille d'évaluation

Gatling et k6 apparaissent dans les annonces de tests de performance à côté de JMeter et NeoLoad, et aussi dans des postes de SRE, de DevOps ou de tech lead qui demandent de tester la charge. Les questions d'entretien Gatling ou k6 partent du livrable : un projet versionné, des scénarios qui tiennent un débit cible, des données alimentées proprement, des seuils qui donnent un verdict automatique à la CI, des métriques envoyées dans Grafana.

Deux profils se présentent souvent. Le développeur écrit un script élégant mais fixe 50 utilisateurs virtuels en pensant obtenir 50 requêtes par seconde. Le testeur de performance venu de JMeter ou de LoadRunner connaît la méthode et bute sur la session immuable de Gatling ou sur le moteur de k6, qui n'est pas Node.js. Les questions de modèle de charge et de code doivent donc se poser au même entretien.

La personne lit et corrige un script court, en Java pour Gatling ou en JavaScript pour k6, qui contient un faux débit et un seuil trop large. Le PDF ajoute 30 questions sur six axes, un cas de 20 minutes sur une API de commandes et une grille de 1 à 4.

Gatling, k6 et l'outillage autour

Gatling

Outil de test de charge open source sous licence Apache 2.0, qui tourne sur la JVM. Les simulations s'écrivent en Java, Kotlin ou Scala depuis la version 3.7, ou en JavaScript et TypeScript avec un SDK limité au HTTP. La dernière version est la 3.16, Java 11 au minimum. Le rapport HTML est produit à la fin de chaque tir.

DSL Gatling : scénarios, checks, feeders

Un scénario enchaîne des requêtes, des pauses et des boucles. Les checks valident les réponses et extraient des valeurs dans la Session, qui est immuable. Les feeders alimentent les utilisateurs virtuels en données, avec une stratégie (queue, circular, random, shuffle) qui change le comportement en fin de fichier.

Profils d'injection Gatling

injectOpen fixe un débit d'arrivée d'utilisateurs (constantUsersPerSec, rampUsersPerSec, incrementUsersPerSec), injectClosed fixe un nombre d'utilisateurs simultanés. Les assertions de fin de tir donnent le verdict et font échouer la build Maven ou Gradle.

Grafana k6

Outil open source sous licence AGPL, écrit en Go, dont les scripts sont en JavaScript ou TypeScript. La version 1.0 date de mai 2025, la 2.0 de mai 2026, avec plusieurs ruptures de compatibilité. Le moteur n'est pas Node.js : les modules npm ne s'importent pas directement.

Exécuteurs, scénarios et seuils k6

Six exécuteurs, dont constant-arrival-rate et ramping-arrival-rate pour tenir un débit, et constant-vus pour un nombre d'utilisateurs fixe. Plusieurs scénarios peuvent tourner dans le même test. Les thresholds, posés sur une métrique ou une sous-métrique taguée, font sortir k6 en erreur, ce que la CI exploite.

Gatling Enterprise et Grafana Cloud k6

Les offres payantes des deux éditeurs : injecteurs gérés dans plusieurs régions, tirs distribués, historique, comparaison et critères d'arrêt. Des emplacements privés permettent de tirer sur une application interne. Le candidat doit dire laquelle il a utilisée et ce qu'elle lui a évité de construire.

k6 Operator et injection sur Kubernetes

Le k6 Operator lance un test découpé sur plusieurs pods à partir d'une ressource TestRun. C'est la voie courante pour distribuer k6 sans service cloud. Il faut alors surveiller les ressources des pods et la façon dont les seuils sont évalués.

CI/CD : GitLab CI, Jenkins, GitHub Actions

Les tests partent de la pipeline : smoke test à chaque merge request, tir plus long la nuit ou avant une mise en production. Le verdict vient des seuils k6 ou des assertions Gatling, et la version de l'outil est figée dans l'image ou le wrapper.

Prometheus, Grafana, OpenTelemetry

k6 envoie ses métriques en direct par Prometheus remote write, OpenTelemetry ou InfluxDB, Gatling au format Graphite. Les mettre à côté des métriques de l'application dans Grafana permet de lire la charge et ses effets sur la même courbe.

Le poste s'appelle ingénieur performance, testeur de performance, ou se cache dans une fiche SRE ou DevOps qui cite k6 parmi d'autres outils. Gatling se rencontre davantage dans les équipes Java et Kotlin, k6 dans celles qui travaillent en JavaScript ou qui ont déjà la pile Grafana. Le périmètre varie : certains postes demandent seulement d'écrire et de maintenir les scripts, d'autres attendent l'infrastructure de tir sur Kubernetes, l'intégration en CI et le diagnostic avec l'APM. Aucun des deux éditeurs ne délivre de certification de référence pour l'outil. La certification ISTQB Performance Testing couvre la méthode.

Ce qu'un ingénieur performance as code doit savoir faire

  • Écriture de simulations Gatling
  • Scripts k6 et choix des exécuteurs
  • Modèle de charge à débit d'arrivée
  • Données de test et feeders
  • Seuils, assertions et verdict en CI
  • Tirs distribués et observabilité

Cinq questions de code et de charge sur Gatling et k6

Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.

  1. Question 1 · confirmé

    Vous devez tenir 50 commandes par seconde avec k6, quel que soit le temps de réponse. Quel exécuteur prenez-vous, et comment le réglez-vous ?

    Une bonne réponseUn exécuteur constant-arrival-rate, avec rate à 50 et timeUnit à 1s, une durée, des preAllocatedVUs et un maxVUs suffisants. Le débit d'arrivée ne dépend plus du temps de réponse. Avec constant-vus, le débit baisse dès que le serveur ralentit. Pour des paliers, le candidat cite ramping-arrival-rate.

    Signal d'alerte« Je mets 50 VUs et un sleep(1) », comme si chaque utilisateur virtuel faisait une requête par seconde quel que soit le serveur.

  2. Question 2 · confirmé

    Dans une simulation Gatling en Java, une fonction appelle session.set("panierId", id), et la requête suivante ne trouve pas la variable. Pourquoi ?

    Une bonne réponseLa Session de Gatling est immuable : set renvoie une nouvelle session, qu'il faut retourner depuis la fonction, du type exec(session -> session.set("panierId", id)). Ignorer la valeur renvoyée revient à perdre la modification. Le candidat rappelle que, pour une valeur issue d'une réponse, un check avec saveAs fait le travail sans code. La version 3.16 ajoute aussi une étape setInSession.

    Signal d'alerteUne variable statique partagée pour contourner le problème, ou « c'est un bug de Gatling ».

  3. Question 3 · confirmé

    Votre fichier CSV contient 10 000 comptes. Comment le chargez-vous dans k6 sans saturer la mémoire, et comment donnez-vous un compte différent à chaque itération ?

    Une bonne réponseUne SharedArray du module k6/data, qui lit le fichier une fois et le partage en lecture seule entre les VUs, avec papaparse pour le CSV. Sans elle, chaque VU garde sa propre copie. Pour l'unicité, un index tiré de k6/execution : exec.scenario.iterationInTest pour un compte par itération, exec.vu.idInTest pour un compte par VU. Le candidat prévoit ce qui se passe quand l'index dépasse la taille du fichier.

    Signal d'alerteUn open() suivi d'un JSON.parse dans chaque VU, ou un Math.random() qui donne le même compte à deux utilisateurs en même temps.

  4. Question 4 · confirmé

    Un seuil k6 p(95)<500 sur http_req_duration passe, alors que l'étape de paiement est lente. Comment est-ce possible, et que changez-vous ?

    Une bonne réponseLe seuil porte sur toutes les requêtes du test. Des centaines d'appels rapides au catalogue noient les quelques appels lents du paiement. Le candidat nomme les requêtes par un tag, puis pose un seuil sur la sous-métrique, du type 'http_req_duration{name:paiement}': ['p(95)<800']. Il ajoute un seuil sur http_req_failed. Dans Gatling, la même idée passe par une assertion sur details("Paiement") plutôt que sur global().

    Signal d'alerte« Le seuil passe, donc tout va bien. » Ou aucune idée de la façon de cibler une requête précise.

  5. Question 5 · confirmé

    Comment envoyez-vous les métriques d'un tir k6 ou Gatling dans Grafana, à côté de celles de l'application ?

    Une bonne réponsePour k6, une sortie temps réel : Prometheus remote write, OpenTelemetry, que k6 recommande désormais plutôt qu'InfluxDB, ou InfluxDB configuré par variables d'environnement. Pour Gatling, l'écriture au format Graphite vers InfluxDB ou Graphite, ou les tableaux de bord de Gatling Enterprise. Le candidat ajoute un identifiant de tir en tag pour filtrer, et place sur le même tableau de bord les métriques de l'application et du tir, sur une même horloge.

    Signal d'alerteLe seul résumé de fin de k6 ou le rapport HTML de Gatling, sans vue dans le temps ni lien avec les serveurs.

Recevez la fiche d'entretien complète en PDF

La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.

  • 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
  • Le niveau visé pour chaque question
  • Une mise en situation de 20 minutes et ce qu'on attend du candidat
  • La grille d'évaluation de 1 à 4, axe par axe

Gatling ou k6, les questions fréquentes

Un profil k6 peut-il reprendre des simulations Gatling, et l'inverse ?

La méthode se transpose : modèle ouvert ou fermé, débit d'arrivée, seuils, données. Le code demande un temps d'adaptation. Gatling suppose d'être à l'aise sur la JVM, avec Maven ou Gradle et une Session immuable. k6 suppose du JavaScript moderne et la connaissance des limites de son moteur. Une ou deux questions sur l'outil en place suffisent. Des réponses solides sur la charge et hésitantes sur la syntaxe annoncent une adaptation de quelques semaines.

Faut-il un développeur ou un testeur de performance pour écrire les tests en code ?

Les deux peuvent convenir, à condition de vérifier ce qui manque à chacun. Un développeur écrit vite un script propre, mais il faut contrôler qu'il sait construire une charge réaliste et lire des percentiles. Un testeur de performance maîtrise la méthode, mais il doit montrer qu'il sait maintenir du code dans un dépôt partagé, avec revue et CI. L'entretien doit couvrir les deux côtés, quelle que soit l'origine du candidat.

Quel exercice de code est donné en entretien ?

Un script court préparé à l'avance, d'une trentaine de lignes, avec un exécuteur ou un profil d'injection qui ne tient pas le débit demandé, un seuil global qui masque une requête lente et une donnée partagée entre utilisateurs virtuels. Le candidat le corrige en partageant son écran et en expliquant ses choix. Ce test technique tient en vingt minutes et montre à la fois le niveau de code et la compréhension de la charge.

Gatling et k6 sont-ils gratuits ?

Les deux outils existent en version open source : Gatling sous licence Apache 2.0, k6 sous licence AGPL. Les offres payantes, Gatling Enterprise et Grafana Cloud k6, ajoutent des injecteurs gérés, la distribution des tirs, l'historique et les comparaisons. Une équipe peut tout faire en open source, à condition de construire elle-même l'infrastructure de tir et le stockage des résultats. Le CV doit dire lequel des deux modes le candidat a pratiqué.

Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.

Les fiches voisines

Toutes les fiches →

Voyez Delectus sur vos propres offres.

Commencez gratuitement. Passez à l'échelle quand vous êtes prêt.

Demander une démo

Votre ATS, connecté à Delectus

  • Workable
  • Teamtailor
  • iCIMS
  • Lever
  • SmartRecruiters
  • Jobvite
  • Greenhouse
  • Pinpoint