Test de charge Gatling : l'outil JVM passé en revue

9 octobre 2026 8 min de lecture

Gatling est un outil de test de charge gratuit sous licence Apache 2.0, dans lequel chaque test est une simulation écrite en code, exécutée sur la JVM et suivie d’un rapport HTML. Un test de charge Gatling convient aux équipes de développement qui veulent leurs tests dans le dépôt, des modèles de charge ouverts ou fermés et des assertions qui font échouer le build. Les équipes qui veulent un éditeur de tests graphique ou beaucoup de protocoles seront mieux servies par JMeter, et celles qui veulent un seul binaire sans JVM par k6.

Nous n’avons pas exécuté Gatling pour cette revue. Les faits viennent de la documentation, du dépôt et des pages de version de Gatling, vérifiés le 9 octobre 2026, et les jugements sont les nôtres.

Sujet	Gatling
Licence	Apache 2.0, sauf les plugins gRPC, MQTT et GraphQL
Environnement	JVM, OpenJDK LTS 64 bits de 11 à 25
Version actuelle	3.16.0 (29 septembre 2026)
Langages des tests	Java, Kotlin, Scala, JavaScript, TypeScript
Protocoles intégrés	HTTP/1.1, HTTP/2, WebSocket, SSE, JMS
Résultats	Rapport HTML statique par exécution
Build et CI	Plugins Maven, Gradle, sbt et npm
Montée en échelle	Gatling Enterprise (commercial)

Qui développe Gatling, et le projet est-il toujours maintenu ?

Gatling Corp, une entreprise française, développe Gatling et en détient les droits d’auteur. Le projet est activement maintenu, avec trois versions JVM publiées depuis le début de 2026.

La page des licences attribue les droits d’auteur à Gatling Corp. Maven Central liste la 3.15.0 en février, la 3.15.1 en mai et la 3.16.0 le 29 septembre 2026, et le SDK JavaScript est passé en 3.16.1 le 6 octobre. Les notes de version 3.16 ajoutent GraphQL et des files partagées entre utilisateurs virtuels. Le README présente le dépôt comme la Community Edition, libre d’utilisation, y compris commerciale (vérifié le 9 octobre 2026).

De quoi avez-vous besoin pour exécuter Gatling ?

D’une JVM 64 bits pour Java, Kotlin ou Scala, ou de Node.js pour JavaScript et TypeScript. Dans les deux cas, la simulation elle-même tourne sur une JVM.

La page d’installation prend en charge les versions LTS d’OpenJDK de 11 à 25 et exclut les JVM 32 bits et OpenJ9. La CLI JavaScript demande Node.js 24 ou plus récent et télécharge un bundle d’exécution Gatling, ainsi que GraalVM selon le README de gatling-js (vérifié le 9 octobre 2026).

Comment une simulation Gatling est-elle structurée ?

Une simulation définit des scénarios, donne à chacun un profil d’injection et y attache une configuration de protocole, le tout enregistré par un seul appel à setUp.

Dans la référence des simulations, un scénario enchaîne des requêtes avec des pauses, des boucles et des conditions. Cette simulation Java enregistre l’identifiant d’un produit trouvé par une recherche, marque une pause d’une à trois secondes et ouvre la fiche produit, tandis que les arrivées montent à 20 utilisateurs par seconde puis s’y maintiennent dix minutes :

public class ShopSimulation extends Simulation {

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

  ScenarioBuilder shoppers = scenario("Shoppers")
      .exec(http("search").get("/api/products?q=lamp")
          .check(jsonPath("$[0].id").saveAs("id")))
      .pause(1, 3)
      .exec(http("product").get("/api/products/#{id}"));

  {
    setUp(shoppers.injectOpen(
        rampUsersPerSec(1).to(20).during(120),
        constantUsersPerSec(20).during(600)))
      .protocols(api)
      .assertions(
          global().responseTime().percentile(95.0).lt(800));
  }
}

Les imports sont omis, et #{id} lit la valeur enregistrée grâce à l’Expression Language de Gatling. Gatling vs k6 montre une simulation en JavaScript.

Faut-il injecter les utilisateurs en modèle ouvert ou fermé ?

En modèle ouvert pour la plupart des sites web et des API, où de nouveaux utilisateurs continuent d’arriver même quand le système ralentit. Le modèle fermé convient aux systèmes qui plafonnent la concurrence, comme une file d’attente de billetterie.

La référence de l’injection sépare l’API : injectOpen prend des taux d’arrivée comme rampUsersPerSec, et injectClosed des cibles de concurrence comme constantConcurrentUsers. La page sur les modèles de charge indique que la plupart des sites web se comportent comme des systèmes ouverts et qu’un profil ne peut pas mélanger les deux (vérifié le 9 octobre 2026). Notre guide sur le modèle de charge ouvert ou fermé explique comment choisir.

Comment fonctionnent les checks, les assertions et le rapport ?

Les checks vérifient chaque réponse et peuvent en extraire des valeurs, tandis que les assertions jugent l’exécution entière une fois terminée. Chaque exécution produit ensuite un rapport HTML.

Sans check de statut explicite, Gatling vérifie que chaque réponse HTTP est en 2XX ou 304. Les assertions portent sur les temps de réponse, le nombre de requêtes ou les requêtes par seconde, globalement ou par requête, et une seule assertion en échec fait échouer la simulation. Le rapport HTML présente les tranches de temps de réponse et les percentiles, les utilisateurs démarrés par seconde, les utilisateurs simultanés et les requêtes par seconde ; ses percentiles dans le temps ne comptent que les requêtes réussies (vérifié le 9 octobre 2026).

Comment Gatling s’intègre-t-il au build et à la CI ?

Par son plugin Maven, Gradle, sbt ou npm, qui tourne dans n’importe quel système de CI. Une assertion en échec fait échouer le build.

Le plugin Maven rattache gatling:test à la phase integration-test, si bien que mvn verify le lance, et avec CI=true il ne demande plus quelle simulation exécuter (l’exécution échoue alors si le projet contient plus d’une simulation et qu’aucune n’est désignée). Le plugin Gradle utilise gatlingRun, et le plugin sbt n’accepte que des simulations en Scala. Les intégrations CI toutes prêtes de Gatling, comme son action GitHub, lancent des exécutions Gatling Enterprise (vérifié le 9 octobre 2026). Notre guide GitHub Actions traite le côté workflow.

Quels protocoles Gatling prend-il en charge ?

HTTP/1.1, HTTP/2, WebSocket, Server-Sent Events et JMS sont fournis sans limite. gRPC, MQTT et GraphQL sont des plugins séparés, plafonnés à 5 utilisateurs et 5 minutes hors de Gatling Enterprise.

Le README place les cinq premiers sous Apache 2.0. Les pages d’installation de gRPC, MQTT et GraphQL placent chaque plugin sous la Gatling Enterprise Component License : sans limite sur Gatling Enterprise, tandis qu’un test avec la Community Edition s’arrête à 5 utilisateurs ou 5 minutes. Cette licence accorde un usage gratuit pendant un an au plus, uniquement pour tester en interne vos propres applications web ; elle prend fin dès qu’une limite est atteinte, et Gatling peut modifier ces limites. GraphQL exige la 3.16.0 ou plus récente. Ses notes de version et le README indiquent que le SDK JavaScript ne le prend pas encore en charge, même si la page d’installation cite déjà un paquet npm : vérifiez ce point avant de prévoir un test GraphQL en JavaScript (vérifié le 9 octobre 2026). Notre guide pour tester la charge d’une API GraphQL contourne ce plafond avec de simples requêtes HTTP.

Qu’apporte Gatling Enterprise ?

Gatling Enterprise est l’édition commerciale, sur le même moteur. Elle génère la charge depuis une infrastructure gérée ou privée, ce que l’édition gratuite ne fait pas.

D’après le README, Enterprise exécute les tests sur des générateurs de charge gérés ou dans vos propres comptes AWS, Azure, GCP ou Kubernetes, et ajoute des tableaux de bord en direct, des tendances, des équipes avec SSO et des intégrations CI/CD. La FAQ précise que la Community Edition ne prend pas en charge les tests distribués et que les simulations passent sur Enterprise sans modification (vérifié le 9 octobre 2026).

LoadFocus, l’éditeur de ce site, n’exécute pas de simulations Gatling. Il exécute des plans de test JMeter et des scripts k6 depuis 25 régions cloud ; pour Gatling, la voie vers davantage de machines reste donc Gatling Enterprise.

Quels sont les points forts de Gatling, et ses limites ?

Gatling brille par ses tests sous forme de code relisible, ses modèles de charge et ses rapports sans configuration. Il est plus faible sur les protocoles au-delà du web et de la messagerie, et pour monter gratuitement au-delà d’une machine.

Le README met en avant son moteur : non bloquant, construit sur Netty, où chaque utilisateur virtuel est un message léger. Les limites que la documentation énonce elle-même (vérifié le 9 octobre 2026) :

Gatling n’est pas un navigateur : selon la page du protocole HTTP, il n’exécute pas de JavaScript.
Le SDK JavaScript n’a pas de JMS et ne peut pas utiliser de bibliothèques npm qui exigent des binaires natifs ou des API propres à Node.js.
Le cache HTTP est activé par défaut, ce qui peut réduire le nombre de requêtes.
Le format de simulation.log n’est pas documenté et peut changer à tout moment.

Quand choisir plutôt k6, JMeter ou Locust ?

Choisissez un autre outil quand son langage, ses protocoles ou sa voie gratuite vers la montée en échelle conviennent mieux à votre équipe.

Notre panorama des outils de test de charge open source place Gatling à côté de cinq autres.

Choisissez plutôt k6 si vous voulez en CI un seul binaire sans JVM, des thresholds capables d’arrêter tôt une exécution en échec, ou gRPC parmi ses protocoles intégrés (vérifié le 9 octobre 2026). Gatling vs k6 compare les deux.

Choisissez plutôt JMeter si vos testeurs construisent leurs tests dans une interface graphique, ou si vous avez besoin de JDBC, LDAP ou FTP dans son cœur (vérifié le 9 octobre 2026). LoadFocus exécute vos plans de test JMeter existants depuis 25 régions cloud, et Gatling vs JMeter va plus loin.

Choisissez plutôt Locust si votre équipe écrit en Python et veut un mode distribué dans l’outil gratuit (vérifié le 9 octobre 2026). Notre revue de Locust le présente.

FAQ

Gatling est-il gratuit pour un usage commercial ? Oui. La Community Edition est sous Apache 2.0. Les plugins gRPC, MQTT et GraphQL ont leur propre licence et s’arrêtent à 5 utilisateurs et 5 minutes hors de Gatling Enterprise.

Faut-il Java pour utiliser Gatling ? Pour Java, Kotlin ou Scala, oui : un OpenJDK LTS 64 bits de 11 à 25. Le SDK JavaScript demande Node.js 24 ou plus récent, et sa CLI télécharge elle-même l’environnement JVM.

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.