Critères de réussite d'un test de charge : comment les fixer

9 octobre 2026 8 min de lecture

Les critères de réussite d’un test de charge sont les quelques seuils qu’une exécution doit tenir pour être déclarée réussie : un percentile de latence pour les requêtes que les utilisateurs attendent, un taux d’erreur et un taux de requêtes minimal, le tout à une charge donnée. Tirez ces seuils d’un objectif de niveau de service (SLO), placez à l’intérieur des seuils de régression issus d’exécutions précédentes, et laissez le code de sortie de l’outil faire échouer l’exécution sur ces seuils stricts uniquement. Tout le reste est un avertissement qu’une personne lit.

Les informations sur les outils ont été vérifiées le 9 octobre 2026 dans la documentation de chaque projet, et chaque seuil présenté est un exemple.

Critère	Seuil d’exemple	Origine du chiffre	En cas d’écart
p95 de latence, paiement	Moins de 400 ms	SLO de latence moins une marge	Échec
p99 de latence, paiement	Moins de 1 200 ms	Exécutions précédentes de ce test	Avertissement
Taux d’erreur	Moins de 0,5 %	SLO de disponibilité	Échec
Requêtes par seconde	Au moins 95 % du plan	La charge prévue	Échec
CPU du générateur de charge	Moins de 80 %	Outil ou plateforme	Exécution invalide

Qu’est-ce qui fait réussir ou échouer un test de charge ?

Une exécution réussit quand chaque seuil strict tient à la charge prévue, et échoue dès qu’un seuil est manqué. Elle est invalide quand le test lui-même n’a pas fait son travail, quels que soient les chiffres.

Un générateur de charge saturé, une charge qui n’a jamais atteint sa cible ou un script en erreur produisent des chiffres sur le dispositif de test. LoadFocus, par exemple, affiche un avertissement de saturation du générateur de charge quand un moteur a atteint ou dépassé 80 % de CPU en pointe. Les codes de sortie de k6 séparent les cas pour la CI : 99 signale des seuils non tenus, 107 une exception dans le script (vérifié le 9 octobre 2026).

Comment transformer un SLO en critères de test de charge ?

Reformulez chaque SLO que la charge peut mettre en défaut, en général la latence et la disponibilité, en seuil sur ce que le test mesure, et rendez ce seuil plus strict que le SLO pour qu’une réussite laisse de la marge.

Le livre SRE de Google définit un SLO comme une valeur cible ou une plage de valeurs pour un niveau de service mesuré par un indicateur (SLI), avec des exemples comme : 99 % des appels Get se terminent en moins de 100 ms. Il demande qu’un SLO précise comment il est mesuré et dans quelles conditions il s’applique, et recommande une marge de sécurité : un objectif interne plus strict que celui annoncé aux utilisateurs.

Pour un test de charge, ces conditions sont la charge et le mélange de requêtes. « 95 % des appels de paiement en moins de 500 ms » pourrait ainsi devenir, à titre d’exemple, « p95 du paiement sous 400 ms à 300 requêtes par seconde pendant 15 minutes ». Sans SLO, convenez d’un objectif provisoire avec le responsable produit.

Quelles métriques les critères doivent-ils couvrir ?

La latence des requêtes que les utilisateurs attendent, un taux d’erreur, le taux de requêtes atteint et, surtout sous forme d’avertissements, les ressources des serveurs.

La latence par type de requête. Un percentile global mélange un health check rapide et une recherche lente. Dans k6, les requêtes étiquetées créent des sous-métriques avec leurs propres seuils ; dans Gatling, details() cible une requête ou un groupe. Un test qui a freiné sa propre charge affiche des percentiles flatteurs (coordinated omission).
Les erreurs, au sens large. Un 200 rapide qui renvoie une page d’erreur reste un échec : vérifiez le contenu. Une Response Assertion JMeter en échec marque son échantillon comme non réussi ; les checks k6 n’agissent sur le code de sortie qu’à travers un seuil.
Un plancher de taux de requêtes. Dans un modèle de charge fermé, un système lent reçoit moins de requêtes, et une exécution peut tenir ses seuils de latence avec une fraction de la charge prévue (modèle de charge ouvert ou fermé).
Les ressources des serveurs. CPU, mémoire et occupation des pools viennent de votre supervision. Traitez-les comme des avertissements, sauf si un plan de capacité fixe un plafond strict.

Comment choisir les chiffres ?

Le plafond vient du SLO, le seuil de régression des exécutions précédentes du même test. Le SLO dit ce que les utilisateurs tolèrent ; les exécutions précédentes disent ce que ce build fait d’habitude.

Le livre SRE déconseille de fixer un SLO à partir des performances actuelles. Un seuil de régression sert à repérer un changement, et les performances actuelles sont justement sa matière première. Lancez plusieurs fois le build inchangé avec le même environnement et la même charge, notez de combien chaque métrique varie, et placez le seuil au-dessus de la pire exécution avec un peu de marge, tout en restant sous le plafond tiré du SLO quand il y en a un.

Si les exécutions d’un même build varient davantage que la régression que vous voulez détecter, le test est trop bruité pour bloquer un build : allongez d’abord la phase stable ou isolez l’environnement. Enregistrez de nouvelles exécutions de référence après tout changement volontaire.

Quels critères doivent faire échouer le build, et lesquels seulement avertir ?

Faites échouer le build sur les seuils issus d’un SLO ou qui vérifient l’exactitude des réponses. Avertissez sur les percentiles de queue, l’usage des ressources et les dérives lentes, qui demandent du jugement ; une barrière qui échoue sur du bruit finit vite désactivée.

Le plugin ensure d’Artillery a un niveau d’avertissement : une condition avec strict: false est facultative, et un échec ne change donc pas le code de sortie (vérifié le 9 octobre 2026). Dans k6, un check sans seuil ne fait jamais échouer l’exécution. Ailleurs, gardez les avertissements hors des assertions.

config:
  plugins:
    ensure:
      thresholds:
        - "http.response_time.p95": 400
      conditions:
        - expression: "http.response_time.p99 < 1200"
          strict: false

Quand un test de charge doit-il s’arrêter plus tôt ?

Quand continuer ne peut que nuire ou ne prouve plus rien : des erreurs bien au-delà du seuil, un système déjà tombé ou un générateur qui ne suit plus. Donnez à la règle un délai de grâce pour que le bruit du démarrage ne la déclenche pas.

Rendez les règles d’arrêt plus lâches que les seuils de réussite : elles protègent un environnement partagé. Dans k6, abortOnFail arrête le test dès qu’un seuil échoue, après un delayAbortEval facultatif. La documentation de Locust sur les extensions montre un greenlet en arrière-plan qui arrête l’exécution quand le taux d’échec dépasse un seuil. Dans Gatling, crashLoadGeneratorIf arrête le générateur avec un code d’échec quand une condition est vraie dans la session d’un utilisateur virtuel. Un Thread Group JMeter peut arrêter le test sur une erreur de sampler, ce qui convient à un contrôle d’exactitude (tout vérifié le 9 octobre 2026).

Comment chaque outil encode-t-il les critères ?

k6 et Artillery transforment un seuil strict manqué en code de sortie non nul, Locust le fait pour toute requête en échec ou pour les seuils que vous codez vous-même, et les assertions de Gatling font échouer le build. JMeter laisse le verdict à une étape qui suit l’exécution.

k6 : les seuils se placent dans les options du script. Cet exemple échoue sur le p95 des requêtes étiquetées name: checkout ou sur 0,5 % d’erreurs, et s’arrête au bout d’une minute si les erreurs dépassent 5 % :

export const options = {
  thresholds: {
    "http_req_duration{name:checkout}": ["p(95)<400"],
    http_req_failed: [
      "rate<0.005",
      { threshold: "rate<0.05", abortOnFail: true,
        delayAbortEval: "1m" },
    ],
  },
};

Gatling : les assertions associent une portée (global, forAll, details), une statistique comme un percentile ou requestsPerSec, et une condition. Elles sont évaluées après l’exécution, et une seule assertion en échec fait échouer la simulation.

Locust se termine avec le code 1 si au moins une requête a échoué, et --exit-code-on-error change ce code. Pour un ratio ou un percentile, définissez environment.process_exit_code dans un listener quitting ; le code source de Locust donne la priorité à cette valeur.

JMeter juge chaque échantillon avec ses assertions, et ses options en ligne de commande ne prévoient aucun seuil pour l’exécution entière. C’est la CI qui tranche : un court script sur le fichier de résultats, comme dans notre guide GitHub Actions, ou le jmeter-maven-plugin, un plugin tiers dont le goal results fait échouer le build si un seul échantillon a échoué, sauf si errorRateThresholdInPercent fixe un taux (vérifié le 9 octobre 2026).

LoadFocus juge les exécutions selon des seuils de réussite ou d’échec enregistrés sur le test : temps de réponse p95 et p99 maximaux, taux d’erreur maximal et taux de requêtes minimal, chacun facultatif. Chaque exécution reçoit un badge PASS ou FAIL avec les valeurs mesurées et les cibles, et une API transmet le verdict à un pipeline. LoadFocus exécute les scénarios k6 à taux d’arrivée avec un nombre fixe d’utilisateurs : là, un plancher de taux vérifie donc ce que ces utilisateurs ont atteint.

FAQ

Le temps de réponse moyen doit-il être un critère de réussite ? Rarement. Le livre SRE préfère les percentiles : une moyenne masque la longue traîne et peut rester stable pendant que les requêtes les plus lentes ralentissent nettement.

Combien de critères de réussite un test de charge doit-il avoir ? Une poignée de seuils stricts, plus des avertissements. Le livre SRE conseille d’avoir le moins de SLO possible et estime qu’un SLO qu’on ne peut jamais invoquer pour gagner une discussion sur les priorités ne vaut probablement pas la peine d’être gardé. Appliquez la même règle à chaque seuil d’un test de charge.

Un test de charge peut-il réussir avec quelques requêtes en échec ? Oui, si le taux d’erreur reste sous son seuil. Vérifiez le comportement par défaut de votre outil : Locust fait échouer l’exécution à la moindre requête en échec.