Comment faire un test de charge : le guide pas à pas

Pour faire un test de charge, décidez à quoi ressemble un bon résultat, scriptez un parcours utilisateur réaliste, vérifiez ce script avec un seul utilisateur, puis augmentez la charge par paliers en surveillant les temps de réponse et les erreurs. Comparez ce que vous avez mesuré avec l’objectif fixé au départ, et ne changez qu’une chose à la fois avant le test suivant.

Que faut-il décider avant de lancer un test de charge ?

Décidez quelle charge vous testez et quel résultat compte comme une réussite. Sans les deux, un test de charge produit des chiffres, mais pas de réponse.

Partez du trafic réel si vous en avez. Vos outils d’analyse ou vos logs d’accès indiquent l’heure la plus chargée, le nombre de requêtes par seconde et les pages ou endpoints qui en reçoivent le plus. Placez la cible au-dessus de ce pic, puisque le but est de savoir que vous avez de la marge. Écrivez ensuite les critères sous forme de chiffres, par exemple : le 95e percentile du temps de réponse reste sous 500 ms et moins de 1 % des requêtes échouent, à 200 utilisateurs virtuels.

Deux décisions pratiques se prennent aussi à ce moment. Choisissez un environnement proche de la production en taille et en configuration, car un serveur de préproduction avec un quart de la capacité en dit peu sur la production. Et assurez-vous d’avoir le droit de le tester : tester un système qui ne vous appartient pas, ou partagé avec d’autres équipes, sans prévenir ressemble exactement à une attaque.

Comment scripter un parcours utilisateur réaliste ?

Scriptez le parcours qui compte le plus pour l’activité, étape par étape, avec des pauses là où une vraie personne lirait ou taperait. Un script qui appelle une seule URL aussi vite que possible mesure quelque chose, mais rarement ce qui vous intéresse.

Pour une boutique, cela peut être : ouvrir l’accueil, chercher, ouvrir un produit, l’ajouter au panier. Pour une API : se connecter, lister des éléments, en récupérer un. Ajoutez une courte pause entre les étapes (temps de réflexion), utilisez des données de test variées pour que les caches se comportent comme en conditions réelles, et vérifiez chaque réponse pour qu’une page d’erreur ne passe pas pour une réponse rapide.

Voici le script utilisé pour l’exemple de ce guide, écrit pour k6. Il monte à 10 utilisateurs virtuels, maintient la charge puis redescend, avec deux critères de réussite intégrés :

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

export const options = {
  stages: [
    { duration: "10s", target: 10 },
    { duration: "20s", target: 10 },
    { duration: "5s", target: 0 },
  ],
  thresholds: {
    http_req_duration: ["p(95)<500"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  const res = http.get("http://127.0.0.1:8765/");
  check(res, { "status is 200": (r) => r.status === 200 });
  sleep(1);
}

Un vrai parcours comporte plusieurs requêtes et de vraies URL. Celui-ci reste minuscule exprès, pour que les étapes soient faciles à suivre.

Pourquoi lancer d’abord un test de fumée à un seul utilisateur ?

Un test de fumée avec un utilisateur virtuel prouve que le script fonctionne avant de mettre une vraie charge sur quoi que ce soit. C’est le moyen le moins cher de repérer une mauvaise URL, un jeton de connexion manquant ou une vérification qui échoue toujours.

Avec k6, vous pouvez remplacer la charge depuis la ligne de commande, si bien que le même script s’exécute une fois avec un seul utilisateur :

k6 run --vus 1 --iterations 1 script.js

Lors de notre essai, l’unique vérification est passée : le script était prêt pour la charge. Si une vérification échoue à ce stade, corrigez le script avant d’aller plus loin : une erreur à un utilisateur devient du bruit à cent.

Comment augmenter la charge ?

Augmentez la charge par paliers et tenez chaque palier assez longtemps pour qu’il se stabilise, au lieu de sauter directement à la cible. Une montée par paliers montre à partir de quel niveau les choses se dégradent.

Une forme courante consiste à monter à un premier palier, le tenir quelques minutes, monter au suivant, le tenir à nouveau, et ainsi de suite jusqu’à la cible, puis redescendre. En regardant chaque palier séparément, vous voyez si les temps de réponse augmentent régulièrement avec la charge ou restent stables puis décrochent. Ce décrochage, le point où chaque utilisateur supplémentaire ralentit chaque requête, est ce qu’un test de charge peut trouver de plus utile. Notre exemple ne monte qu’à 10 utilisateurs et tient 20 secondes, assez pour montrer les paliers mais bien trop court pour un vrai test.

Que faut-il surveiller pendant le test ?

Surveillez les percentiles du temps de réponse, le taux d’erreur et le débit côté générateur de charge, ainsi que le CPU, la mémoire et la charge de la base de données côté système testé. Les trois premiers indiquent ce que ressentiraient les utilisateurs, les trois derniers expliquent pourquoi.

Fixez des conditions d’arrêt avant de commencer, par exemple : arrêter si le taux d’erreur dépasse 5 % ou si les temps de réponse atteignent plusieurs secondes. Insister sur un système déjà tombé n’apprend rien, et sur un environnement partagé cela gêne le travail des autres.

Surveillez aussi le générateur de charge. S’il tourne à 100 % de CPU, les réponses lentes peuvent venir de votre propre ordinateur plutôt que du serveur.

Comment lire les résultats d’un test de charge ?

Lisez les percentiles et le taux d’erreur au regard des critères notés au départ. Le temps de réponse moyen est le chiffre le moins utile du rapport.

Voici ce qu’a rapporté notre exemple (35 secondes, jusqu’à 10 utilisateurs virtuels, une petite page statique servie sur un portable, le 8 octobre 2026) :

Les chiffres sont minuscules parce que la cible était un fichier statique sur la même machine : ce n’est pas un benchmark. La leçon est dans la forme : la moyenne est ressortie au-dessus du 90e percentile, parce qu’une poignée de requêtes lentes l’a tirée vers le haut. Les percentiles décrivent ce qu’a vécu la plupart des requêtes, et le 99e percentile et la requête la plus lente montrent la traîne que subissent quelques utilisateurs. Jugez le test sur le percentile de vos critères, et servez-vous de la traîne pour décider si quelque chose mérite d’être examiné de plus près.

Si un test manque son objectif, changez une seule chose (une requête, un réglage de cache, une taille d’instance) et relancez le même test, pour savoir ce qui a fait la différence.

Quand faut-il lancer le test depuis le cloud ?

Déplacez le générateur de charge dans le cloud quand une seule machine ne peut pas produire la charge nécessaire, ou quand la localisation de vos utilisateurs compte. Un portable sur le Wi-Fi du bureau mesure votre connexion autant que votre serveur.

Le même script k6 peut tourner sur une infrastructure que vous gérez, sur le service hébergé de Grafana, ou sur LoadFocus, qui exécute les scripts k6 depuis 25 régions cloud. Ses rapports détaillent les résultats par localisation et tracent le temps de réponse en fonction du nombre d’utilisateurs virtuels, là où le décrochage décrit plus haut devient visible (lire les résultats dans LoadFocus).

FAQ

Combien de temps doit durer un test de charge ? Assez longtemps pour tenir la charge cible plusieurs minutes après la montée, afin que de brefs pics ne décident pas du résultat. Tenir au moins 10 minutes est un bon point de départ, et bien plus longtemps si vous cherchez des fuites mémoire ou une dégradation lente.

De combien d’utilisateurs virtuels ai-je besoin ? Déduisez-le du trafic réel. Prenez les requêtes par seconde de l’heure la plus chargée, estimez combien de requêtes fait un parcours et combien de temps il dure, et dimensionnez les utilisateurs virtuels pour que le test produise ce débit avec une marge en plus.

Peut-on tester la production sans risque ? C’est possible, avec prudence : tester à une heure calme, prévenir les personnes qui exploitent le système, fixer des conditions d’arrêt et démarrer bien en dessous du pic attendu. Beaucoup d’équipes préfèrent un environnement de préproduction de la taille de la production, pour qu’un test raté ne touche aucun client.

À lire aussi

• Critères de réussite d’un test de charge : comment les fixer
• Test de charge dans GitHub Actions : guide pratique

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