Gatling vs JMeter : du code ou un plan de test graphique ?

9 octobre 2026 8 min de lecture

Gatling et Apache JMeter sont deux outils de test de charge gratuits et open source qui tournent sur la JVM, et le choix dépend surtout de la façon dont votre équipe veut construire ses tests. Choisissez Gatling si vous voulez des tests sous forme de code en Java, Kotlin, Scala, JavaScript ou TypeScript, des profils d’injection ouverts et un rapport HTML après chaque exécution. Choisissez JMeter si vous avez besoin de protocoles comme JDBC, LDAP, FTP ou le mail sans rien ajouter, si vous préférez construire vos tests dans une interface graphique, ou si vous avez déjà des plans de test .jmx.

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

	Gatling	Apache JMeter
Licence	Apache 2.0 ; gRPC, MQTT et GraphQL sous une licence de composant distincte (dépôt)	Apache 2.0 (dépôt)
Environnement d’exécution	JVM, OpenJDK LTS 11 à 25 (version 3.16.0)	JVM, Java 8 ou plus récent (version 5.6.3)
Tests écrits en	Code Java, Kotlin, Scala, JavaScript ou TypeScript	Plans de test construits dans une interface graphique, enregistrés en XML (`.jmx`)
Protocoles intégrés	HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events, JMS	HTTP(S), SOAP/REST, FTP, JDBC, LDAP, JMS, mail, TCP, commandes shell, objets Java
Enregistreur	Proxy HTTP ou convertisseur de fichiers HAR	HTTP(S) Test Script Recorder (proxy)
Modèle de charge	Profils d’injection ouverts ou fermés	Thread Groups ; un Open Model Thread Group expérimental
Mise à l’échelle	Une seule machine ; l’exécution distribuée demande Gatling Enterprise	Mode distant intégré, un client qui pilote plusieurs serveurs
CI et exécution sans interface	Plugins Maven, Gradle, sbt et npm ; une assertion en échec fait échouer l’exécution	Mode CLI (`jmeter -n`) ; plugins tiers pour Maven, Gradle et Jenkins
Rapports	Rapport HTML après chaque exécution	Tableau de bord HTML ; résultats en direct via un Backend Listener

Quelle est la différence entre Gatling et JMeter ?

Dans Gatling, un test est un programme dans un projet de build. Dans JMeter, un test est un arbre d’éléments que vous assemblez dans une interface graphique de bureau puis enregistrez dans un fichier XML, et la plupart des autres différences en découlent.

Le README de Gatling appelle les tests des simulations et les range dans votre dépôt comme du code applicatif, exécutés via un plugin Maven, Gradle, sbt ou npm. Le SDK JavaScript et TypeScript s’installe avec npm et télécharge son propre environnement GraalVM.

Un plan JMeter contient 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). Sous le capot, JMeter exécute chaque utilisateur virtuel dans un thread Java, tandis que le README de Gatling décrit les utilisateurs virtuels comme des messages légers sur un moteur non bloquant construit sur Netty.

Comment écrit-on un test avec chaque outil ?

Dans Gatling, vous écrivez une classe de simulation qui définit un scénario, un profil d’injection et des assertions. 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.

Une simulation Java inspirée du tutoriel de première simulation de Gatling : les nouveaux utilisateurs arrivent d’abord à un par seconde, passent à dix par seconde en une minute, puis restent à ce rythme pendant cinq minutes. L’exécution échoue si le 95e percentile dépasse 500 ms ou si plus de 1 % des requêtes échouent :

import static io.gatling.javaapi.core.CoreDsl.*;
import static io.gatling.javaapi.http.HttpDsl.*;

import io.gatling.javaapi.core.*;
import io.gatling.javaapi.http.*;

public class ApiSimulation extends Simulation {

  HttpProtocolBuilder httpProtocol =
      http.baseUrl("https://staging.example.com");

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

  {
    setUp(users.injectOpen(
            rampUsersPerSec(1).to(10).during(60),
            constantUsersPerSec(10).during(300)))
        .protocols(httpProtocol)
        .assertions(
            global().responseTime().percentile(95.0).lt(500),
            global().failedRequests().percent().lt(1.0));
  }
}

Lancez-la avec ./mvnw gatling:test ; une simulation JavaScript ou TypeScript se lance avec npx gatling run.

Dans JMeter, le même test est un Thread Group qui contient un sampler HTTP Request, et une Duration Assertion peut marquer en échec chaque réponse trop lente. Le guide de démarrage construit le plan en mode GUI et l’exécute en mode CLI, et -e -o ajoute le rapport HTML :

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

Les deux outils peuvent enregistrer un premier jet depuis un navigateur. Le Recorder de Gatling fonctionne comme un proxy HTTP ou convertit un fichier HAR en simulation, et le HTTP(S) Test Script Recorder de JMeter capture le trafic du navigateur dans un plan (vérifié le 9 octobre 2026). La documentation de Gatling qualifie désormais ce Recorder de legacy, et le plus récent Gatling Studio exige un compte Enterprise pour se connecter (vérifié le 10 octobre 2026).

Quels protocoles chaque outil peut-il tester ?

JMeter couvre davantage de protocoles en standard. Gatling fournit les principaux protocoles web plus JMS, et confie l’essentiel du reste à des composants séparés ou à des plugins communautaires.

Le README de JMeter liste tous les protocoles du tableau ci-dessus, mail compris. JDBC et JMS demandent les fichiers JAR du pilote fournis par votre base de données ou votre fournisseur JMS, et le Plugins Manager installe des plugins communautaires depuis l’interface graphique.

D’après le README de Gatling, gRPC, MQTT et GraphQL sont des composants séparés sous la Gatling Enterprise Component License, limités sans Enterprise à cinq utilisateurs simultanés et à des tests de cinq minutes. Kafka, AMQP, SFTP, FTP et JDBC passent par des plugins tiers pour Gatling 3.13 que Gatling ne maintient pas (vérifié le 9 octobre 2026).

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

Gatling vous fait choisir entre un modèle ouvert et un modèle fermé dans le script lui-même. Le Thread Group classique de JMeter est un pool fermé d’utilisateurs, et une charge fondée sur les arrivées demande le plus récent Open Model Thread Group.

Dans Gatling, injectOpen accepte des taux d’arrivée comme constantUsersPerSec et rampUsersPerSec, et injectClosed des cibles de concurrence comme constantConcurrentUsers. JMeter 5.5 a ajouté l’Open Model Thread Group, que la référence marque toujours comme expérimental (vérifié le 9 octobre 2026). Notre guide sur le modèle de charge ouvert ou fermé explique pourquoi ce choix compte.

Comment répartir un test sur plusieurs machines ?

JMeter intègre un mode distribué. L’édition open source de Gatling génère la charge depuis une seule machine, et sa documentation indique qu’il faut un compte Gatling Enterprise pour l’exécution distribuée.

Le mode de test distant de JMeter permet à un client de piloter autant de serveurs que nécessaire. Chaque serveur exécute le plan entier : 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 serveur distant à configurer. LoadFocus n’exécute pas de simulations Gatling.

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

Les deux tournent sans interface. Les assertions de Gatling peuvent faire échouer le build directement, alors que celles de JMeter signalent des échantillons isolés et que l’intégration CI passe par des bibliothèques tierces.

Les assertions de Gatling sont vérifiées après l’exécution, et une seule assertion en échec fait échouer la simulation et la tâche de build. Le rapport HTML montre les percentiles du temps de réponse, les utilisateurs démarrés par seconde, les utilisateurs simultanés et les requêtes par seconde au fil du temps.

Le mode CLI de JMeter n’offre aucun critère de réussite : un objectif manqué ne fait échouer le build qu’à travers les bibliothèques pour Maven, Gradle et Jenkins que cite son README, ou une vérification de votre part. Le tableau de bord de JMeter ajoute une table APDEX, une table de statistiques avec trois percentiles configurables et des synthèses d’erreurs, et un Backend Listener envoie les résultats en direct vers InfluxDB ou Graphite.

Lequel choisir ?

Choisissez Gatling si votre équipe écrit du Java, du Kotlin, du Scala ou du TypeScript 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à du web, si vos testeurs préfèrent une interface graphique, ou si vous avez déjà des plans .jmx.

Gatling convient aux équipes qui décrivent le trafic en taux d’arrivée et veulent des règles de réussite ou d’échec à côté du scénario, avec un rapport lisible sans configuration supplémentaire.

JMeter est le meilleur choix pour tester JDBC, LDAP, FTP ou le mail, pour les testeurs qui affinent visuellement un parcours enregistré, et pour l’exécution distribuée sur vos propres serveurs sans licence commerciale. Une entreprise qui utilise déjà JMeter conserve aussi ses plans, ses plugins et son savoir-faire.

FAQ

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

Gatling peut-il exécuter des fichiers .jmx de JMeter ? Pas directement. Gatling exécute des simulations écrites avec ses SDK, donc un plan JMeter doit être réécrit. Le README de Gatling mentionne des extensions d’IA qui convertissent les plans de test JMeter, et elles demandent un jeton d’API Gatling Enterprise.

LoadFocus peut-il exécuter des tests Gatling ? 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.