Pour préparer les questions d'entretien d'un ingénieur tests de performance, partez de ce qu'il livre. Il écrit des scénarios avec JMeter, Gatling, k6, NeoLoad ou LoadRunner, les rend rejouables par la corrélation et les jeux de données, puis définit avec le projet une charge réaliste. Viennent ensuite les tirs de charge, de stress, d'endurance ou de pic, la lecture des résultats dans un APM comme Dynatrace, Datadog ou AppDynamics, et un rapport qui dit ce qui casse, à quel niveau et pourquoi.
Le premier écueil est un profil qui sait enregistrer un script et lancer un tir, sans vérifier que la charge simulée ressemble à la production. Le second tient aux chiffres. Une moyenne cache les utilisateurs lents, et un injecteur saturé fausse un tir entier. Les candidats expérimentés parlent de percentiles, de débit cible, de temps de réflexion et de l'état des injecteurs avant de parler des serveurs.
Demandez le récit d'un tir réel : la charge visée, l'outil, le premier goulet trouvé et la correction qui a suivi. Une réponse qui s'arrête au rapport de l'outil, sans passer par les métriques serveur ni la base de données, signale un profil d'exécution plus que d'analyse. Le cas pratique du PDF prépare l'ouverture des ventes d'une billetterie en ligne.
Outils de tir et de mesure d'un ingénieur tests de performance
Apache JMeter
L'outil open source le plus cité dans les annonces. Les plans de test se construisent dans une interface graphique et s'enregistrent en XML, puis les tirs se lancent en ligne de commande. Il couvre HTTP, JDBC, JMS et d'autres protocoles. Vérifiez que la personne sait corréler un script et ne lance pas ses tirs depuis l'interface.
Gatling
Outil de tir où les scénarios s'écrivent en code : Java, Kotlin, Scala, et aussi JavaScript ou TypeScript. Les scripts se versionnent et se relisent comme le reste de l'application. Il distingue clairement injection ouverte (taux d'arrivée) et fermée (nombre d'utilisateurs). Une version Enterprise ajoute l'injection distribuée et le suivi des tirs.
k6
Outil de Grafana Labs, scripté en JavaScript, apprécié des équipes qui veulent des tirs dans leur CI. Les seuils (thresholds) font échouer un tir quand un percentile dépasse l'objectif. Les exécuteurs arrival-rate produisent une charge au taux d'arrivée fixe, plus proche d'un site public qu'un nombre fixe d'utilisateurs.
NeoLoad
Outil commercial de Tricentis, fréquent dans les grands projets. Il enregistre les parcours, propose une corrélation assistée et un pilotage centralisé des tirs. Un profil NeoLoad doit savoir expliquer ce que l'outil corrèle à sa place, et le reprendre à la main quand la corrélation automatique se trompe.
LoadRunner
La référence historique des tests de performance, passée chez OpenText avec le rachat de Micro Focus. La version poste de travail s'appelle désormais OpenText Professional Performance Engineering, mais les CV parlent encore de LoadRunner et de VuGen, son éditeur de scripts. On la croise sur des applications anciennes ou des protocoles peu courants comme SAP GUI ou Citrix.
APM : Dynatrace, Datadog, AppDynamics
Les outils de supervision applicative qui suivent chaque transaction à travers les couches : code, base de données, appels externes. C'est là que l'ingénieur trouve la cause d'un ralentissement. Un profil senior lit une trace distribuée sans aide et sait relier un pic de temps de réponse à une ressource saturée.
Grafana, InfluxDB, Prometheus
Le stockage et l'affichage des métriques pendant le tir. Les résultats de JMeter ou de k6 y sont envoyés en direct, à côté des métriques des serveurs, ce qui permet de lire les courbes du tir et celles des machines sur la même base de temps.
JVM et base de données
Une bonne partie des goulets se trouve dans le ramasse-miettes Java, les pools de threads et de connexions ou une requête SQL mal indexée. L'ingénieur lit les journaux du GC, fait une capture de la mémoire et regarde les vues d'attente de la base (AWR sur Oracle, pg_stat_activity sur PostgreSQL).
Le poste se rattache à une équipe qualité, à une cellule performance transverse ou aux équipes de production qui valident les grandes livraisons. Le travail avance par campagnes : cadrage de la charge avec le projet, scripts, tirs, analyse, nouveaux tirs après correction. Dans les équipes qui livrent souvent, on attend aussi des tirs courts dans la CI avec des seuils qui bloquent le pipeline. Le niveau se voit dans l'analyse : un expert remonte jusqu'à la requête SQL, au réglage d'un pool de connexions ou au ramasse-miettes de la JVM, quand un profil plus junior s'arrête au constat. Les annonces consultées citent surtout JMeter, NeoLoad, Dynatrace, AppDynamics et Grafana.
Ce qu'un ingénieur tests de performance doit maîtriser
- Modélisation de la charge
- Scénarisation et corrélation
- Types de tirs et critères de réussite
- Percentiles, débit et saturation
- Diagnostic des goulets (APM, JVM, base)
- Tests de performance en CI
Questions techniques pour un ingénieur tests de performance
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.
Question 1 · confirmé
Le projet vous annonce « 2 000 utilisateurs simultanés ». Comment transformez-vous ce chiffre en scénario de charge ?
Une bonne réponseIl demande d'abord des volumes mesurés : transactions par heure à l'heure de pointe, répartition entre les parcours, durée moyenne d'une session, tirés des journaux ou de l'outil d'analytics. Il en déduit un débit cible par parcours et un temps de réflexion réaliste, puis vérifie la cohérence avec la loi de Little (utilisateurs actifs = débit × durée passée dans le système). Pour un site public, il préfère fixer un taux d'arrivée plutôt qu'un nombre d'utilisateurs virtuels.
Signal d'alerteLancer 2 000 utilisateurs virtuels sans temps de réflexion sur un seul parcours, ce qui produit une charge sans rapport avec la production.
Question 2 · junior à confirmé
Votre script JMeter rejoue la connexion, mais les pages suivantes renvoient une erreur ou l'écran de login. Que s'est-il passé ?
Une bonne réponseDes valeurs dynamiques n'ont pas été corrélées : jeton de session, jeton CSRF, identifiant de transaction, ViewState. Il faut les extraire de la réponse qui les fournit (extracteur JSON, expression régulière ou Boundary Extractor) et les réinjecter dans les requêtes suivantes, avec un gestionnaire de cookies actif. Il ajoute des assertions sur le contenu des pages, car l'écran de login revient souvent avec un code HTTP 200.
Signal d'alerte« Je réenregistre le script », ou un tir validé sur les seuls codes 200 alors que toutes les pages affichent le formulaire de connexion.
Question 3 · confirmé
Le temps de réponse moyen est de 800 ms et l'objectif était d'une seconde. Le tir est-il réussi ?
Une bonne réponseLa moyenne ne permet pas de conclure. Il regarde le 95e et le 99e percentile par transaction, le taux d'erreur, le débit réellement atteint face au débit visé et la stabilité des temps sur la durée du palier. Des erreurs rapides font baisser la moyenne, et quelques transactions très lentes peuvent rester cachées derrière un bon chiffre global.
Signal d'alerte« Oui, on est sous la seconde », sans regarder les percentiles, les erreurs ni le débit.
Question 4 · senior
Pendant le tir, le débit plafonne alors que vous ajoutez des utilisateurs, et les temps de réponse montent. Comment cherchez-vous le goulet ?
Une bonne réponseIl vérifie d'abord les injecteurs : CPU, mémoire, réseau, erreurs côté outil. Puis il remonte les couches avec les mêmes horodatages : CPU et threads des serveurs d'application, attente sur le pool de connexions, requêtes lentes et verrous en base, appels à des services externes. Une trace d'APM sur une transaction lente montre où le temps passe. Il cherche la première ressource saturée, pas la plus visible.
Signal d'alerte« On ajoute des serveurs », sans diagnostic, ou une analyse qui s'arrête au rapport de l'outil de tir.
Question 5 · junior à confirmé
Charge, stress, endurance, pic : que vérifie chacun de ces tirs, et lesquels lancez-vous avant une mise en production ?
Une bonne réponseLa charge vérifie le comportement au volume attendu. Le stress pousse au-delà pour trouver le point de rupture et observer le retour à la normale. L'endurance maintient une charge plusieurs heures pour révéler fuites mémoire, connexions non rendues et journaux qui remplissent le disque. Le pic envoie une montée brutale pour tester l'élasticité et les files d'attente. Le choix dépend du risque : charge nominale presque toujours, pic si un événement est prévu, endurance pour un service qui tourne en continu.
Signal d'alerteDes définitions confondues, ou un seul tir de dix minutes présenté comme suffisant pour tout valider.
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
Tests de performance : ce que demandent les recruteurs
JMeter, NeoLoad ou Gatling : faut-il exiger l'outil déjà en place ?
Pas forcément. Corrélation, données de test, modèle de charge et lecture des résultats se transposent d'un outil à l'autre. Une personne solide sur JMeter prend en main Gatling ou NeoLoad en quelques semaines. Exigez l'outil quand la mission démarre vite sur un existant important, par exemple une centaine de scripts NeoLoad à maintenir dès le premier jour. Sinon, jugez la méthode et demandez comment elle reprendrait un script dans votre outil.
Un ingénieur tests de performance doit-il savoir coder ?
Oui, à un niveau qui dépend de l'outil. Gatling et k6 demandent d'écrire du code en Java, Kotlin, Scala ou JavaScript. JMeter et NeoLoad se pilotent surtout par interface, mais la corrélation demande des expressions régulières ou des scripts Groovy ou JavaScript. Pour l'analyse, lire une trace d'appels Java, un plan d'exécution SQL ou une configuration de pool de connexions fait la différence entre un constat et un diagnostic.
Quelle mise en situation pour juger un ingénieur tests de performance ?
Deux exercices courts suffisent. Le premier part d'un besoin flou, par exemple « le site doit tenir le jour du lancement », et demande d'en tirer un modèle de charge chiffré. Le second montre les courbes d'un tir où le débit plafonne et demande où chercher. Ce test technique d'une demi-heure montre la méthode mieux qu'un script à écrire chez soi, et vous pouvez suivre le raisonnement à voix haute.
Les tests de performance peuvent-ils être confiés aux développeurs ?
Pour les tirs courts dans la CI et le suivi des régressions, oui, surtout avec k6 ou Gatling qui s'écrivent comme du code. La modélisation d'une charge réaliste, les campagnes avant une grande mise en production et le diagnostic croisé entre application, base et infrastructure demandent un profil qui en a fait son métier. Beaucoup d'équipes combinent les deux : les développeurs maintiennent les tirs de CI, un spécialiste prépare les campagnes.
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.
