Temps de réflexion en test de charge : bien le régler

Le temps de réflexion en test de charge est la pause qu’un utilisateur virtuel marque entre deux actions, qui représente les secondes qu’une vraie personne passe à lire une page ou à remplir un formulaire. Il fixe la pression qu’exerce chaque utilisateur virtuel : plus la pause est longue, moins le même nombre d’utilisateurs envoie de requêtes par seconde. Mesurez-le à partir des données de vrais utilisateurs, faites-le varier au hasard autour de cette valeur et écrivez-le dans le script avec la commande de pause de votre outil.

Ce n’est qu’un calcul, sans test derrière : une requête par boucle, une réponse en 0,5 seconde, et le nombre d’utilisateurs divisé par (temps de réponse + temps de réflexion).

Qu’est-ce que le temps de réflexion en test de charge ?

Le temps de réflexion est l’attente volontaire qu’un script de test insère entre les étapes d’un parcours utilisateur. Il reproduit la part humaine d’une session : lire, comparer, taper.

Dans le script d’une boutique, il se place entre « ouvrir la fiche produit » et « ajouter au panier », en dehors de toute requête. Le guide de LoadFocus sur les délais en test de charge le distingue du délai de montée en charge, qui ajoute les utilisateurs progressivement, et du délai de démarrage entre deux utilisateurs, et note que beaucoup d’outils désignent par le simple mot « delay » le délai de montée en charge. Quand un outil propose un champ « delay », vérifiez lequel des trois il désigne.

Pourquoi le temps de réflexion change-t-il la charge à nombre d’utilisateurs égal ?

Avec un nombre fixe d’utilisateurs virtuels, chacun attend une réponse, fait une pause, et seulement ensuite envoie la requête suivante. Sa boucle dure le temps de réponse plus le temps de réflexion, donc chaque seconde de pause en plus réduit le nombre de requêtes que chaque utilisateur envoie par seconde.

Cent utilisateurs sans pause envoient 200 requêtes par seconde avec une réponse en 0,5 seconde ; avec une pause de 5 secondes, ils en envoient environ 18, si bien que deux tests « à 100 utilisateurs » peuvent être très différents. La documentation de k6 décrit le même effet pour son modèle fermé : l’itération suivante ne démarre que lorsque la précédente est terminée, donc des réponses plus lentes font aussi baisser le rythme (vérifié le 9 octobre 2026).

Réduire le temps de réflexion pour tirer plus de charge de moins d’utilisateurs a un coût : vingt utilisateurs sans pause peuvent atteindre la cadence de requêtes de plusieurs centaines d’utilisateurs qui marquent des pauses, tout en gardant bien moins de sessions et de connexions ouvertes que la production.

Quelle est la différence entre temps de réflexion et pacing ?

Le temps de réflexion est une pause après une étape, donc une boucle s’allonge dès que les réponses ralentissent. Le pacing fixe l’intervalle entre le début d’une boucle et le début de la suivante, et raccourcit l’attente quand le travail a pris plus de temps.

Avec un pacing de 30 secondes, un utilisateur lance une boucle toutes les 30 secondes, que ses requêtes aient pris 2 secondes ou 20, ce qui convient à un test construit à partir de volumes métier comme « 500 commandes par heure ». La documentation de constant_pacing dans Locust précise le cas limite : si la tâche dure plus longtemps que l’intervalle, l’attente tombe à zéro (vérifié le 9 octobre 2026). Beaucoup de scripts combinent les deux, avec du temps de réflexion entre les étapes et un pacing sur la boucle entière.

Le temps de réflexion doit-il être fixe ou aléatoire ?

Aléatoire, autour d’une moyenne mesurée. Une pause fixe maintient synchronisés les utilisateurs partis ensemble, qui arrivent sur la même page au même moment, boucle après boucle.

Ces vagues synchronisées peuvent créer des pics que la production ne connaît pas, et une pause aléatoire disperse les utilisateurs. Gardez la moyenne là où vos données la placent : une pause uniforme entre 2 et 8 secondes fait 5 en moyenne, soit la même charge moyenne qu’une pause fixe de 5 secondes. La loi uniforme est le choix simple par défaut ; une loi normale (gaussienne) regroupe les pauses autour d’une valeur typique, et une loi exponentielle donne beaucoup d’attentes courtes et quelques longues.

Comment choisir les valeurs du temps de réflexion ?

Tirez-les de ce que font les vrais utilisateurs à chaque étape, grâce à vos outils d’analyse web, vos logs d’accès ou un outil de suivi des utilisateurs réels (RUM). Prenez une valeur par étape, car lire une fiche produit prend plus de temps que cliquer sur un bouton.

Le temps passé sur la page dans vos outils d’analyse, ou l’écart entre deux requêtes successives d’une même session dans les logs d’accès, s’approche du temps de réflexion de cette étape. Prenez la médiane comme pause moyenne et la dispersion pour fixer la plage aléatoire, et écartez les temps morts comme un onglet resté ouvert pendant le déjeuner.

Une API appelée par d’autres programmes n’a pas d’humain dans la boucle : modélisez directement sa cadence de requêtes. Sans données, notez les valeurs supposées dans le plan de test pour qu’un test ultérieur les remplace ; le guide pas à pas du test de charge montre où elles s’insèrent.

Comment ajouter du temps de réflexion dans k6, JMeter, Gatling, Locust et Artillery ?

Chaque outil a sa propre commande de pause, et la plupart proposent aussi un pacing ou un réglage de débit.

Les informations du tableau ci-dessus et des notes ci-dessous viennent de la documentation de chaque projet, vérifiées le 9 octobre 2026 ; les cinq outils figurent dans notre tour d’horizon des outils de test de charge open source.

k6. sleep(t) met l’utilisateur virtuel en pause pendant t secondes ; la documentation construit des pauses aléatoires avec Math.random() ou avec randomIntBetween() de k6-utils :

import http from "k6/http";
import { sleep } from "k6";

export default function () {
  http.get("https://example.com/products");
  sleep(2 + Math.random() * 6); // 2 à 8 secondes
  http.get("https://example.com/cart");
}

JMeter. Parmi les timers, le Constant Timer prend un délai en millisecondes, les Uniform et Gaussian Random Timers ajoutent une part aléatoire à un décalage fixe, et le Constant Throughput Timer fait varier ses pauses pour tenir un objectif d’échantillons par minute. Un timer s’exécute avant chaque sampler de sa portée, donc un seul timer au niveau du Thread Group fait une pause avant chaque requête.

Gatling. pause(2, 8) attend un temps aléatoire uniforme, et pace(30) dans une boucle l’exécute au plus une fois toutes les 30 secondes. Au niveau de la simulation, vous pouvez passer toutes les pauses à une loi normale ou exponentielle, ou les couper avec disablePauses().

Locust. wait_time s’applique après chaque tâche, donc une tâche de deux requêtes sous constant_throughput(2) envoie quatre requêtes par seconde et par utilisateur.

Artillery. Une étape think fait une pause d’un nombre de secondes donné, et un réglage think.jitter sous config.http.defaults ajoute une variation aléatoire à chaque étape think. Pour deux de ces outils face à face, voyez k6 vs Artillery.

Le temps de réflexion compte-t-il dans un test à taux d’arrivée ?

Moins, pour ce qui est de la cadence de requêtes. Quand l’outil lance de nouvelles itérations à un rythme fixé, les pauses déterminent combien de temps chaque utilisateur reste, et donc combien sont actifs en même temps.

Les exécuteurs arrival-rate de k6 cadencent les itérations par leur taux, et la documentation déconseille un sleep en fin d’itération ; les phases de charge d’Artillery créent de même un nombre fixe de nouveaux utilisateurs virtuels par seconde (vérifié le 9 octobre 2026 pour les deux). Le temps de réflexion entre les étapes façonne malgré tout chaque session.

Comment les outils de script de LoadFocus fixent-ils le temps de réflexion ?

Ils l’écrivent dans le script k6 ou JMeter comme valeur de départ, à ajuster ensuite.

L’import depuis cURL, HAR, Postman ou OpenAPI transforme une requête capturée en script k6 qui termine chaque itération par sleep(1) ; considérez cette seconde comme une valeur provisoire à remplacer par vos mesures. Le générateur de tests par IA de LoadFocus a pour consigne de donner un temps de réflexion à chaque étape, l’écrit sous forme de sleep() pour k6 ou de Constant Timer pour JMeter, et prévient quand un scénario à plusieurs étapes n’en a aucun.

FAQ

Peut-on lancer un test de charge sans temps de réflexion ? Oui, pour trouver le débit maximal d’un endpoint ou pour un test de stress, à condition de présenter le résultat en requêtes par seconde. Il en dit peu sur le nombre de vrais utilisateurs que le système peut servir.

Le temps de réflexion compte-t-il dans le temps de réponse ? Pas dans les temps des requêtes. Dans k6, http_req_duration couvre l’envoi, l’attente et la réception, tandis que iteration_duration couvre toute la boucle (référence des métriques, vérifié le 9 octobre 2026). Un Transaction Controller de JMeter exclut les timers de son temps, sauf si vous cochez l’option qui les inclut.

À lire aussi

• Modèle de charge ouvert ou fermé : lequel choisir ?
• Loi de Little en test de charge : dimensionner et vérifier
• Comment faire un test de charge : le guide pas à pas
• Théorie des files d’attente : ce qu’elle dit de la latence

Les affirmations techniques de cet article n'ont pas été relues de façon indépendante.