Locust vs JMeter : scripts Python ou plans de test JMeter ?

9 octobre 2026 8 min de lecture

Locust et Apache JMeter sont deux outils de test de charge gratuits et open source, et le bon choix dépend surtout de la façon dont votre équipe veut construire ses tests. Choisissez Locust si votre équipe écrit du Python et veut une logique de test sous forme de code ordinaire, exécutée par des utilisateurs légers et événementiels. Choisissez JMeter si vous avez besoin de protocoles au-delà de HTTP comme JDBC, JMS ou LDAP, si vous préférez construire vos tests dans une interface graphique, ou si vous avez déjà une bibliothèque de plans de test .jmx.

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

	Locust	Apache JMeter
Licence	MIT (dépôt)	Apache 2.0 (dépôt)
Environnement d’exécution	Python 3.11 ou plus récent	Java 8 ou plus récent (version 5.6.3)
Tests écrits en	Code Python dans un locustfile	Plans de test construits dans une interface graphique, enregistrés en XML (`.jmx`)
Interface graphique	Interface web pour lancer, ajuster et suivre un test en cours	IDE de bureau pour enregistrer, construire et déboguer des plans de test
Protocoles intégrés	HTTP et HTTPS ; les autres via un client Python	HTTP(S), SOAP/REST, FTP, JDBC, LDAP, JMS, mail, TCP, commandes shell, objets Java
Utilisateurs virtuels	Un greenlet par utilisateur sur gevent (événementiel)	Un thread Java par utilisateur
Mode distribué	Un master et autant de workers que nécessaire	Un client qui pilote des serveurs JMeter distants
CI et exécution sans interface	`--headless`, code de sortie 1 si des requêtes échouent	Mode CLI (`jmeter -n`)
Rapports	Graphiques en direct dans l’interface web, fichiers CSV, rapport HTML	Tableau de bord HTML, résultats en direct via un Backend Listener

Quelle est la différence entre Locust et JMeter ?

Dans Locust, un test est un programme Python. Dans JMeter, un test est un plan que vous assemblez dans une interface graphique de bureau puis enregistrez dans un fichier, et la plupart des autres différences en découlent.

Le README de Locust décrit des tests écrits avec des boucles, des conditions et des bibliothèques Python ordinaires. Locust s’installe avec pip install locust et demande Python 3.11 ou plus récent, d’après ses métadonnées de paquet.

Un test JMeter est un arbre d’éléments : un Thread Group pour les utilisateurs, des samplers pour les requêtes, des assertions et des listeners pour les résultats. JMeter 5.6.3, la version actuelle sur la page de téléchargement, demande Java 8 ou plus récent. Le README de la branche de développement de JMeter exige déjà Java 17 (vérifié le 10 octobre 2026). Quand une étape a besoin d’une vraie logique, un sampler JSR223 exécute un script Groovy à l’intérieur du plan.

Comment écrit-on un test avec chaque outil ?

Dans Locust, vous écrivez une classe Python pour chaque type d’utilisateur, avec des méthodes marquées comme tâches. Dans JMeter, vous ajoutez un Thread Group et des samplers dans l’interface graphique, vous enregistrez le plan puis vous le lancez en ligne de commande.

Un utilisateur Locust qui attend une à trois secondes entre deux tâches et consulte la liste des utilisateurs trois fois plus souvent qu’une fiche individuelle :

from locust import HttpUser, task, between


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

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

    @task
    def view_user(self):
        self.client.get("/api/users/42", name="/api/users/[id]")

Lancement sans interface avec 50 utilisateurs, cinq nouveaux par seconde, pendant cinq minutes :

locust -f locustfile.py --headless -u 50 -r 5 \
  --run-time 5m --host https://staging.example.com

Dans JMeter, le même test est un Thread Group de 50 threads avec une durée de montée en charge, qui contient deux samplers HTTP Request. Le guide de démarrage lance un plan enregistré en mode CLI, et -e -o ajoute le rapport HTML à la fin :

jmeter -n -t api-users.jmx -l results.jtl -e -o report/

Le fichier .jmx est du XML, comme le montrent les exemples livrés avec JMeter, et il se relit moins facilement en pull request que du Python. JMeter sait aussi enregistrer un plan depuis un navigateur ; l’équivalent côté Locust est har2locust, un convertisseur d’enregistrements HAR en locustfile encore en bêta (vérifié le 9 octobre 2026).

Quels protocoles chaque outil peut-il tester ?

JMeter couvre beaucoup plus de protocoles d’origine. Locust fournit HTTP et HTTPS et vous laisse apporter un client Python pour tout le reste.

Le README de JMeter cite HTTP et HTTPS, SOAP et REST, FTP, les bases de données via JDBC, LDAP, la messagerie JMS, le mail en SMTP, POP3 et IMAP, TCP, les commandes natives et les objets Java. JDBC et JMS demandent les fichiers JAR du pilote, fournis par l’éditeur de votre base de données ou de votre solution JMS.

La page sur les autres protocoles de la documentation Locust montre comment encapsuler une bibliothèque de protocole, avec des exemples pour gRPC, XML-RPC et MQTT, et renvoie à locust-plugins pour Kafka, Selenium et Playwright (vérifié le 9 octobre 2026). La bibliothèque doit être compatible avec gevent, car des entrées-sorties faites en code C compilé bloquent tout le processus ; la documentation cite le pilote PostgreSQL psycopg2, qui a besoin d’un paquet supplémentaire. Pour tester une base de données sous charge, le sampler JDBC de JMeter est le chemin le plus court.

Comment fonctionnent les utilisateurs virtuels dans Locust et JMeter ?

JMeter exécute chaque utilisateur virtuel dans un thread Java. Locust exécute chaque utilisateur dans un greenlet sur la boucle d’événements de gevent, ce qui réduit le coût de chaque utilisateur.

Chaque thread d’un Thread Group JMeter exécute tout le plan de façon indépendante. JMeter démarre par défaut avec un tas (heap) de 1 Go, ce qui, selon son guide, peut ne pas suffire pour des plans plus lourds et de nombreux threads.

D’après son README, un seul processus Locust peut gérer plusieurs milliers d’utilisateurs simultanés. La documentation sur la charge distribuée précise qu’un processus Python ne peut pas exploiter pleinement plus d’un cœur de processeur : on lance donc un worker par cœur, ce que --processes fait pour vous sur une seule machine.

Comment répartir un test sur plusieurs machines ?

Les deux outils ont un mode distribué intégré. Dans Locust, un master pilote des workers qui exécutent les utilisateurs, et dans JMeter, le client lance le plan de test complet sur chaque serveur distant.

Dans Locust, un processus lancé avec --master fait tourner l’interface web et indique aux processus --worker quand démarrer et arrêter des utilisateurs. La documentation de Locust présente aussi un opérateur Kubernetes et Azure Load Testing, un service Microsoft qui exécute des tests Locust dans le cloud (vérifié le 9 octobre 2026).

Le mode de test distant de JMeter permet à un client de piloter autant de serveurs que nécessaire via RMI. Chaque serveur exécute tout le plan : 1 000 threads sur six serveurs donnent donc 6 000 threads. Tous les nœuds devraient utiliser la même version de JMeter et de Java, RMI a besoin d’un keystore sauf si SSL est désactivé, et les fichiers de données doivent être copiés sur chaque serveur.

Il existe une troisième voie pour les plans de test JMeter. LoadFocus, l’éditeur de ce site, exécute vos plans de test JMeter existants sans modification depuis 25 régions cloud, sans serveurs distants à configurer. LoadFocus n’exécute pas les tests Locust : pour Locust, les options ci-dessus restent les moyens de monter en charge.

Comment s’intègrent-ils à la CI, et quels rapports obtient-on ?

Les deux s’exécutent sans interface, en ligne de commande. Locust se termine en plus avec le code de sortie 1 quand des requêtes échouent, et JMeter produit le rapport HTML le plus complet.

La documentation du mode headless de Locust montre un court écouteur d’événement qui fixe le code de sortie selon le taux d’échec, le temps de réponse moyen ou le 95e percentile, ainsi qu’un exemple pour GitHub Actions. Les options --csv et --html enregistrent les résultats et un rapport après l’exécution.

La documentation de JMeter est claire : les tests de charge se lancent en mode CLI, et l’interface graphique sert à construire et à déboguer. Son README renvoie à des bibliothèques tierces pour Maven, Gradle et Jenkins. Le tableau de bord JMeter comprend une table APDEX, un tableau de statistiques avec trois percentiles configurables, des synthèses d’erreurs et des graphiques de temps de réponse.

Quel outil choisir ?

Choisissez Locust si votre équipe écrit du Python et veut relire ses tests de charge comme le reste de son code. Choisissez plutôt JMeter si vous avez besoin de protocoles au-delà de HTTP, si vos testeurs préfèrent une interface graphique ou si vous avez déjà des plans .jmx.

Locust convient aux scénarios avec des boucles, des branchements et des données générées, aux tests qui réutilisent un client Python interne pour votre API, et à une forte concurrence d’utilisateurs qui passent la plupart de leur temps à attendre.

JMeter est le meilleur choix pour tester JDBC, JMS, LDAP, FTP ou le mail, là où Locust demanderait un client à maintenir vous-même, ainsi que pour les testeurs qui enregistrent un parcours dans le navigateur et l’affinent visuellement. Une entreprise qui utilise déjà JMeter conserve en outre ses plans et son savoir-faire.

FAQ

Locust est-il plus rapide que JMeter ? Nous ne l’avons pas mesuré nous-mêmes, donc nous ne désignerons pas de gagnant. La comparaison honnête consiste à lancer le même scénario avec les deux outils sur votre propre matériel.

Locust peut-il exécuter des fichiers .jmx de JMeter ? Pas d’après sa documentation, qui décrit les tests uniquement comme des locustfiles Python. Passer un plan de test JMeter à Locust revient à le réécrire en Python.

LoadFocus peut-il exécuter des tests Locust ? Non. LoadFocus exécute des scripts JMeter et k6. Pour étendre un test Locust au-delà d’une machine, utilisez le mode master et workers de Locust, son opérateur Kubernetes ou Azure Load Testing.