k6 vs Locust : scripts JavaScript ou utilisateurs Python ?

k6 et Locust sont deux outils open source qui gardent un test de charge sous forme de code dans votre dépôt, et l’un comme l’autre testera correctement une API HTTP sous charge. Choisissez Locust si votre équipe écrit du Python et veut de la logique de test en Python pur. Choisissez k6 si vous écrivez du JavaScript, voulez des seuils de réussite intégrés, ou avez besoin d’un test qui tient un taux d’arrivée.

Les informations de ce comparatif k6 vs Locust viennent de la documentation et du dépôt de chaque projet, vérifiées le 13 octobre 2026.

Quelle est la différence entre k6 et Locust ?

La différence principale est le langage dans lequel vous écrivez les tests. k6 exécute du JavaScript dans un programme Go compilé, tandis que Locust exécute votre code Python et s’appuie sur gevent pour gérer de nombreux utilisateurs simultanés.

k6 s’installe comme paquet ou binaire autonome, sans autre environnement d’exécution. Il exécute aussi des fichiers .ts, mais son support de TypeScript retire les types sans les vérifier. Locust s’installe avec pip install locust, et sa page What is Locust indique que les tests sont du Python ordinaire, versionné comme n’importe quel autre code (vérifié le 13 octobre 2026).

Comment écrire le même test dans chaque outil ?

Les deux expriment le test sous forme de petit programme. Voici un test avec 50 utilisateurs pendant cinq minutes, qui échoue si le 95e percentile dépasse 500 ms ou si plus de 1 % des requêtes échouent.

Dans k6, les objectifs font partie du script, sous forme de seuils :

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

export const options = {
  vus: 50,
  duration: "5m",
  thresholds: {
    http_req_duration: ["p(95)<500"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  http.get("https://staging.example.com/api/users");
  sleep(1);
}

Dans Locust, l’utilisateur est une classe, et les mêmes objectifs vont dans un listener, d’après le modèle de la documentation du mode headless :

import logging
from locust import HttpUser, between, events, task


class ApiUser(HttpUser):
    wait_time = between(1, 2)

    @task
    def list_users(self):
        self.client.get("/api/users")


@events.quitting.add_listener
def _(environment, **kw):
    stats = environment.stats.total
    if stats.fail_ratio > 0.01:
        environment.process_exit_code = 1
    elif stats.get_response_time_percentile(0.95) > 500:
        environment.process_exit_code = 1

On les lance avec k6 run script.js et locust -f locustfile.py --headless -u 50 -r 10 -t 5m --host https://staging.example.com (vérifié le 13 octobre 2026).

Comment k6 et Locust modélisent-ils la charge ?

k6 prend en charge les deux modèles de charge, alors que Locust décrit la charge comme un nombre fixe d’utilisateurs. Dans k6 vous choisissez le modèle par l’exécuteur, dans Locust par le nombre d’utilisateurs et le délai d’attente.

k6 propose six exécuteurs. Quatre sont fermés : un utilisateur virtuel ne démarre son itération suivante que lorsque la précédente est terminée. Les deux exécuteurs arrival-rate suivent le modèle ouvert, où les itérations démarrent indépendamment de la durée des précédentes. Le guide du locustfile précise que le délai d’attente peut seulement limiter le débit et ne peut pas lancer de nouveaux utilisateurs pour atteindre une cadence cible (vérifié le 13 octobre 2026).

Si votre objectif est « 300 requêtes arrivent chaque seconde, quel que soit le temps de réponse », k6 sait l’exprimer directement. Notre guide sur le modèle de charge ouvert et fermé explique quand utiliser chacun.

Comment k6 et Locust décident-ils si un test est réussi ?

k6 fait des critères de réussite une fonction centrale, et Locust laisse l’essentiel à votre code. Un seuil k6 non respecté termine l’exécution avec un code de sortie non nul, et abortOnFail arrête le test dès qu’il échoue.

Locust se termine avec le code 1 si une requête a échoué. Pour des limites sur le taux d’échec, la moyenne ou le 95e percentile, sa documentation montre un listener comme celui ci-dessus, qui fixe lui-même le code de sortie (vérifié le 13 octobre 2026). Notre guide sur les critères de réussite d’un test de charge aide à choisir les limites.

Quels protocoles chaque outil couvre-t-il ?

k6 livre quatre protocoles et un module navigateur, Locust livre HTTP et HTTPS et vous laisse envelopper n’importe quel client Python pour le reste.

k6 liste HTTP/1.1, HTTP/2, WebSockets et gRPC comme protocoles intégrés, avec d’autres via des extensions xk6, ainsi qu’un module navigateur qui pilote un navigateur basé sur Chromium. La page de Locust sur les autres systèmes dit qu’il n’a de support intégré que pour HTTP/HTTPS mais qu’on peut l’étendre pour tester presque n’importe quel système, en enveloppant une bibliothèque de protocole et en signalant chaque appel comme une requête. La bibliothèque doit coopérer avec gevent (vérifié le 13 octobre 2026).

Comment lancer un test plus gros que ce qu’une machine peut générer ?

Locust monte en charge avec un master et des workers, k6 avec un opérateur Kubernetes ou un service hébergé. Les deux peuvent répartir un test sur de nombreuses machines.

La documentation du mode distribué de Locust indique qu’un processus peut faire plus de mille requêtes par seconde pour un plan de test simple ; les tests plus gros utilisent donc un worker par cœur de processeur, sur autant de machines que nécessaire. Le k6-operator répartit un test sur plusieurs instances k6 dans un cluster Kubernetes, et Grafana Cloud k6 est la voie hébergée (vérifié le 13 octobre 2026).

Il existe une troisième voie pour les scripts k6. LoadFocus, qui publie ce site, exécute des scripts k6 depuis 25 régions cloud, avec les utilisateurs et la durée tirés des réglages du test. Son validateur de scripts avertit que les scénarios arrival-rate y tournent avec un nombre fixe d’utilisateurs : un script en modèle ouvert ne tient donc pas son taux d’arrivée sur LoadFocus. LoadFocus n’exécute pas Locust : il exécute uniquement des scripts k6 et des plans de test JMeter.

Quels rapports obtient-on ?

k6 affiche un récapitulatif en fin de test et peut exporter un rapport HTML depuis son tableau de bord web. Locust montre des graphiques en direct dans son interface web et écrit des fichiers à la demande.

Le récapitulatif de fin de test de k6 s’affiche dans le terminal, et son tableau de bord web exporte un rapport HTML autonome quand vous définissez K6_WEB_DASHBOARD_EXPORT. Locust sert une interface web sur le port 8089 avec des graphiques en direct, et sa référence de configuration liste les sorties --csv, --html et --json (vérifié le 13 octobre 2026).

Lequel choisir ?

Locust convient aux équipes Python, et k6 à celles qui veulent des seuils intégrés et un modèle de charge ouvert. Les protocoles et la montée en charge tranchent la plupart des autres cas.

Choisissez Locust plutôt que k6 si votre équipe écrit du Python et veut des boucles, des branchements, des données générées et son propre client d’API en Python pur, si vous voulez réutiliser des bibliothèques Python pour un protocole, ou si vous voulez une interface web avec des graphiques en direct pour explorer un système. Choisissez k6 plutôt que Locust si votre équipe écrit du JavaScript ou du TypeScript, si des seuils doivent faire échouer un build CI et arrêter tôt une mauvaise exécution, si vous avez besoin d’un taux d’arrivée constant, ou si vous voulez gRPC et les tests navigateur dans le même outil.

Pour une vue plus large, lisez notre revue du test de charge avec Locust.

FAQ

Locust est-il plus rapide que k6 ? Nous ne l’avons pas mesuré nous-mêmes, donc nous ne désignons pas de gagnant. Le test équitable est le même scénario avec les deux outils sur votre propre matériel.

Locust peut-il exécuter des scripts k6 ? Pas d’après la documentation de Locust, qui décrit des tests écrits en Python dans un locustfile. Un script k6 est du JavaScript, il faut donc le réécrire en classe d’utilisateur Python, et les seuils deviennent un listener.

LoadFocus peut-il exécuter des tests Locust ? Non. LoadFocus exécute des scripts k6 et des plans de test JMeter. Pour faire monter en charge un test Locust, utilisez son mode master et workers, l’opérateur Kubernetes ou Azure Load Testing.

À lire aussi

• Test de charge Locust : l’outil Python passé en revue
• Locust vs JMeter : scripts Python ou plans de test JMeter ?
• Gatling vs k6 : simulations JVM ou binaire Go ?
• k6 vs Artillery : quel outil de test de charge choisir ?
• Modèle de charge ouvert ou fermé : lequel utiliser ?
• Azure Load Testing : le service de Microsoft passé en revue

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