Gatling vs Locust : simulations JVM ou locustfiles Python ?

13 octobre 2026 7 min de lecture

Gatling et Locust sont deux outils open source gratuits qui gardent les tests de charge sous forme de code dans votre dépôt. Choisissez Gatling si votre équipe travaille sur la JVM ou si vous voulez des profils d’injection ouverts et fermés, des assertions et un rapport HTML dans un seul paquet. Choisissez Locust si votre équipe écrit du Python, apprécie une interface web pour lancer et suivre une exécution, et a besoin du mode distribué sans édition commerciale.

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

	Gatling	Locust
Licence	Apache 2.0 ; gRPC, MQTT et GraphQL sous une licence de composant distincte (dépôt)	MIT (dépôt)
Exécution	JVM, OpenJDK LTS 11 à 25 (version 3.16.0)	Python 3.11 ou plus récent (version 2.46.7)
Code de test	Java, Kotlin, Scala, JavaScript ou TypeScript	Python
Protocoles intégrés	HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events, JMS	HTTP et HTTPS ; les autres via un client Python
Modèle de charge	Profils d’injection ouverts ou fermés	Un pool d’utilisateurs, donc un modèle fermé
Critères de réussite	Assertions, évaluées après l’exécution	Code de sortie 1 si des requêtes échouent, ou votre propre listener
Rapports	Rapport HTML après chaque exécution	Graphiques en direct dans l’interface web, fichiers CSV, rapport HTML
Montée en charge	Gatling Enterprise	Mode master et workers intégré, opérateur Kubernetes

Quelle est la différence entre Gatling et Locust ?

Gatling exécute des simulations sur la JVM, et Locust exécute de simples programmes Python. Gatling fournit d’emblée un modèle de charge et un rapport, tandis qu’avec Locust vous écrivez vous-même la logique du test.

Le README de Gatling décrit un moteur non bloquant construit sur Netty et un SDK en cinq langages : Java, Kotlin et Scala passent par Maven, Gradle ou sbt, JavaScript et TypeScript par un SDK à part. Sa page d’installation demande un OpenJDK LTS 64 bits de 11 à 25, et Node.js 24 ou plus récent pour le SDK JavaScript.

Le README de Locust le présente comme un moyen d’écrire des tests de charge évolutifs en Python pur, et ses métadonnées de paquet exigent Python 3.11 ou plus récent. La page What is Locust précise qu’il repose sur des événements avec gevent, si bien qu’un seul processus peut gérer plusieurs milliers d’utilisateurs simultanés (vérifié le 13 octobre 2026).

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

Dans Gatling, vous enchaînez des requêtes dans un scénario et lui donnez un profil d’injection. Dans Locust, vous écrivez une classe d’utilisateur avec des tâches et un temps d’attente entre elles.

Cinquante utilisateurs simultanés qui listent les utilisateurs puis attendent une à trois secondes, pendant cinq minutes. Avec le SDK Java de Gatling (imports omis) :

public class ApiSimulation extends Simulation {
  HttpProtocolBuilder api =
      http.baseUrl("https://staging.example.com");

  ScenarioBuilder users = scenario("API users")
      .exec(http("list users").get("/api/users"))
      .pause(1, 3);

  {
    setUp(users.injectClosed(
        constantConcurrentUsers(50).during(300)))
      .protocols(api);
  }
}

Le même test dans Locust :

from locust import HttpUser, task, between


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

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

La référence d’injection de Gatling range constantConcurrentUsers parmi les étapes du modèle fermé. Locust reçoit le nombre d’utilisateurs et la durée sous forme d’options (vérifié le 13 octobre 2026) :

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

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

Gatling propose les modèles ouvert et fermé, selon la méthode que vous appelez. Locust fait tourner un pool d’utilisateurs, ce qui correspond à un modèle fermé.

La page sur les modèles de charge de Gatling définit les systèmes fermés comme ceux qui plafonnent le nombre d’utilisateurs simultanés, et les systèmes ouverts comme ceux où les utilisateurs continuent d’arriver même quand l’application répond lentement. Elle ajoute que la plupart des sites web sont ouverts. injectOpen prend des taux d’arrivée et injectClosed des cibles de concurrence.

Le guide du locustfile indique que le temps d’attente ne peut que limiter le débit et ne lance pas de nouveaux utilisateurs pour atteindre un taux cible. Si une boucle dure plus longtemps que l’attente ne le permet, le taux passe sous la cible (vérifié le 13 octobre 2026). Notre guide sur le modèle de charge ouvert ou fermé explique pourquoi cela compte.

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

Locust intègre le mode distribué. L’édition open source de Gatling génère la charge depuis une seule machine, et les exécutions distribuées demandent Gatling Enterprise.

Locust démarre un processus avec --master et autant de processus --worker que nécessaire. Selon les docs sur la charge distribuée, un processus Python n’utilise pas plus d’un cœur, donc on lance un worker par cœur, et --processes en démarre plusieurs sur une machine. Un opérateur Kubernetes gère les exécutions distribuées dans un cluster.

La FAQ de Gatling dit que la Community Edition ne prend pas en charge les tests distribués, et le README décrit Enterprise comme exécuté sur des générateurs de charge gérés ou sur une infrastructure privée (vérifié le 13 octobre 2026).

Il existe une échappatoire pour les deux. LoadFocus, l’éditeur de ce site, n’exécute ni les simulations Gatling ni les tests Locust. Si vous préférez ne faire tourner aucun des deux à grande échelle, il exécute des scripts k6 et des plans de test JMeter depuis 25 régions cloud. Son validateur k6 avertit que les scénarios à taux d’arrivée y tournent avec un nombre fixe d’utilisateurs et ne tiennent donc pas une cadence de requêtes. Passer de l’un ou l’autre outil à ceux-là oblige à réécrire le test.

Comment décident-ils si un test a réussi, et quels rapports obtient-on ?

Gatling évalue les assertions après l’exécution et écrit un rapport HTML à chaque fois. Locust se termine avec le code 1 si une requête a échoué, et vous ajoutez d’autres contrôles sous forme de listener.

Les assertions de Gatling sont évaluées après la simulation, et une seule assertion en échec fait échouer la simulation. Son rapport HTML trace les percentiles du temps de réponse, les utilisateurs démarrés par seconde, les utilisateurs simultanés et les requêtes par seconde.

D’après les docs headless de Locust, l’exécution se termine avec le code 1 si un échantillon a échoué, et un exemple de listener fait échouer l’exécution sur le taux d’échec, le temps de réponse moyen ou le 95e percentile. La référence de configuration cite --csv pour les fichiers de statistiques et --html pour un rapport (vérifié le 13 octobre 2026).

Quels protocoles chaque outil peut-il tester ?

Gatling en fournit davantage, avec des limites sur les plus récents. Locust fournit HTTP et HTTPS et attend un client Python pour le reste.

Le README de Gatling liste HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events et JMS sous Apache 2.0 sans limite. gRPC, MQTT et GraphQL relèvent de la Gatling Enterprise Component License, et les tests qui les utilisent sont plafonnés à 5 utilisateurs simultanés et 5 minutes dans la Community Edition.

La page sur les autres systèmes de Locust montre comment envelopper une bibliothèque de protocole et signaler chaque appel, avec des exemples gRPC et MQTT. La bibliothèque doit fonctionner avec gevent, qui ne peut pas patcher les E/S faites en code C compilé, et locust-plugins ajoute des utilisateurs pour Kafka, Selenium et Playwright (vérifié le 13 octobre 2026).

Lequel choisir ?

Choisissez selon le langage et la façon dont vous chargez le système. Gatling convient aux équipes JVM et aux tests en modèle ouvert, Locust aux équipes Python et aux tests à logique sur mesure.

Choisissez Gatling plutôt que Locust si votre équipe vit sur la JVM et veut des tests Java, Kotlin ou Scala construits avec Maven, Gradle ou sbt, si vous avez besoin d’un modèle ouvert comme un taux d’arrivée fixe, si vous avez besoin de JMS ou de Server-Sent Events, ou si vous voulez des assertions et un rapport sans code supplémentaire.

Choisissez Locust plutôt que Gatling si votre équipe écrit du Python et veut que les tests réutilisent un client Python interne, si vous voulez une interface web pour lancer une exécution et modifier la charge en cours de route, si vous avez besoin du mode distribué dans l’outil gratuit, ou si le système reçoit surtout des utilisateurs qui attendent et que votre protocole a une bibliothèque Python compatible gevent.

Pour un constructeur de tests graphique, regardez JMeter, et pour un seul binaire sans JVM ni Python, regardez k6.

FAQ

Gatling est-il plus rapide que Locust ? Nous ne l’avons pas mesuré nous-mêmes, donc nous ne désignons pas de gagnant. La seule 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 simulations Gatling ? Pas d’après la documentation de Locust, qui ne décrit les tests que comme du code Python. Une simulation Gatling doit être réécrite en locustfile, et l’inverse vaut aussi.

LoadFocus peut-il exécuter des tests Gatling ou Locust ? Non. LoadFocus exécute des plans de test JMeter et des scripts k6. Pour répartir une simulation Gatling sur plusieurs machines, utilisez Gatling Enterprise, et pour Locust son mode master et workers ou son opérateur Kubernetes.