Gatling vs k6 : simulations JVM ou un seul binaire Go ?

Gatling et k6 sont deux outils open source qui gardent les tests 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 Gatling si votre équipe travaille en Java, Kotlin ou Scala, ou veut un rapport HTML après chaque exécution sans rien configurer. Choisissez k6 si vous voulez un seul binaire Go sans JVM, le gRPC et les tests navigateur dès l’installation, et des seuils capables d’arrêter tôt une exécution qui échoue.

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

Quelle est la différence entre Gatling et k6 ?

La plus grande différence tient à l’environnement d’exécution. Gatling tourne sur la JVM et vous écrivez les tests avec l’un de ses SDK, alors que k6 est un programme Go compilé unique qui exécute du JavaScript.

Le README de Gatling cite un SDK Java pour Java, Kotlin et Scala, lancé par un plugin Maven, Gradle ou sbt. Son SDK JavaScript et TypeScript s’installe avec npm, et son outil en ligne de commande télécharge GraalVM : même une simulation JavaScript tourne donc sur une JVM.

k6 s’installe sous forme de paquet ou de binaire autonome, sans autre environnement d’exécution. Il exécute aussi directement les fichiers .ts, et sa prise en charge de TypeScript retire les types sans les vérifier (vérifié le 9 octobre 2026).

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

Les deux outils peuvent exprimer le même test en JavaScript. Gatling parle de simulation et décrit la charge par un profil d’injection, k6 parle de script et la décrit par un scénario doté d’un executor.

Voici un test où dix nouveaux utilisateurs arrivent chaque seconde pendant cinq minutes, et qui échoue si le 95e percentile dépasse 500 ms ou si plus de 1 % des requêtes échouent. Avec le SDK JavaScript de Gatling, sur le modèle de son tutoriel de première simulation :

import {
  constantUsersPerSec, global, scenario, simulation,
} from "@gatling.io/core";
import { http } from "@gatling.io/http";

export default simulation((setUp) => {
  const api = http.baseUrl("https://staging.example.com");

  const users = scenario("API users")
    .exec(http("list users").get("/api/users"));

  setUp(users.injectOpen(constantUsersPerSec(10).during(300)))
    .protocols(api)
    .assertions(
      global().responseTime().percentile(95).lt(500),
      global().failedRequests().percent().lt(1),
    );
});

Le même test dans k6, avec l’executor constant-arrival-rate :

import http from "k6/http";

export const options = {
  scenarios: {
    api_users: {
      executor: "constant-arrival-rate",
      rate: 10,
      timeUnit: "1s",
      duration: "5m",
      preAllocatedVUs: 50,
    },
  },
  thresholds: {
    http_req_duration: ["p(95)<500"],
    http_req_failed: ["rate<0.01"],
  },
};

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

Lancez-les avec npx gatling run et k6 run script.js.

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

Les deux prennent en charge les modèles de charge ouvert et fermé. Dans Gatling, le choix passe par la méthode d’injection que vous appelez, dans k6 par l’executor que vous retenez.

Dans Gatling, injectOpen prend des taux d’arrivée comme constantUsersPerSec, et injectClosed des objectifs de concurrence comme constantConcurrentUsers. k6 propose six executors : les deux à taux d’arrivée suivent le modèle ouvert, les quatre autres le modèle fermé, où un utilisateur virtuel ne lance sa prochaine itération qu’une fois la précédente terminée.

Un scénario k6 à taux d’arrivée lance ses itérations depuis un pool d’utilisateurs virtuels préalloués, et quand ce pool est épuisé, k6 saute des itérations et les compte comme itérations abandonnées (vérifié le 9 octobre 2026). Notre guide sur le modèle de charge ouvert ou fermé explique quand choisir l’un ou l’autre.

Comment Gatling et k6 décident-ils si un test a réussi ?

Les deux transforment des objectifs de performance en un verdict, réussite ou échec, qu’un pipeline CI peut exploiter. Gatling vérifie ses objectifs une fois l’exécution terminée, et k6 peut en plus arrêter une exécution dès qu’un objectif est manqué.

Les assertions de Gatling sont évaluées après la simulation, et une seule assertion en échec fait échouer la simulation et le build. Les thresholds de k6 terminent une exécution en échec avec un code de sortie non nul, et un threshold réglé avec abortOnFail arrête le test dès qu’il échoue (vérifié le 9 octobre 2026).

Quels protocoles et quels tests navigateur chaque outil couvre-t-il ?

Les deux gèrent HTTP et WebSockets dès l’installation. Gatling y ajoute Server-Sent Events et JMS, et k6 le gRPC et de vraies sessions de navigateur.

Selon le README de Gatling, gRPC, MQTT et GraphQL sont des composants distincts sous la Gatling Enterprise Component License, limités sans Enterprise à cinq utilisateurs simultanés et à des tests de cinq minutes. k6 cite HTTP/1.1, HTTP/2, WebSockets et gRPC comme protocoles intégrés, et d’autres s’ajoutent via des extensions xk6 comme Kafka et Redis.

Pour les tests navigateur, k6 dispose d’un module navigateur qui pilote un navigateur basé sur Chromium et collecte des métriques côté frontend. La documentation de Gatling ne décrit aucun moteur de navigateur : le Recorder de Gatling transforme une session de navigateur ou un fichier HAR en simulation au niveau HTTP (vérifié le 9 octobre 2026).

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

L’édition open source de Gatling génère la charge depuis une seule machine, et l’exécution distribuée demande Gatling Enterprise. k6 peut répartir un test sur un cluster Kubernetes avec le k6-operator open source, ou le lancer sur Grafana Cloud k6.

Le guide d’installation de Gatling demande un compte Enterprise pour l’exécution distribuée, qui s’appuie sur des générateurs de charge gérés ou sur des emplacements privés dans votre propre compte AWS, Azure, GCP ou Kubernetes. Le k6-operator répartit un test sur plusieurs instances k6 dans un cluster (vérifié le 9 octobre 2026).

Il existe une troisième voie pour les scripts k6. LoadFocus, l’éditeur de ce site, exécute les scripts k6 sur sa propre infrastructure cloud depuis 25 régions, avec le nombre d’utilisateurs et la durée pris dans les réglages du test. Son validateur de script prévient que les scénarios à taux d’arrivée y tournent avec un nombre fixe d’utilisateurs : un script en modèle ouvert comme celui ci-dessus ne tient donc pas son taux d’arrivée sur LoadFocus. LoadFocus n’exécute pas les simulations Gatling : pour Gatling, la voie vers plus de machines reste Gatling Enterprise.

Quels rapports obtenez-vous ?

Gatling écrit un rapport HTML après chaque exécution, sans configuration. k6 affiche un résumé dans le terminal et peut produire un rapport HTML depuis son tableau de bord web intégré.

Le rapport HTML de Gatling trace les percentiles du temps de réponse, les utilisateurs lancés par seconde et les requêtes par seconde au fil du test. k6 affiche un résumé de fin de test, et son tableau de bord web montre des graphiques en direct et exporte un rapport HTML autonome quand vous définissez K6_WEB_DASHBOARD_EXPORT.

Lequel choisir ?

Gatling convient aux équipes qui vivent sur la JVM, et k6 à celles qui veulent un binaire unique et du JavaScript. Les protocoles, les tests navigateur et la montée en charge tranchent la plupart des autres cas.

Choisissez Gatling plutôt que k6 si votre équipe vit sur la JVM et veut des tests en Java, Kotlin ou Scala construits avec Maven, Gradle ou sbt à côté du code de l’application, si vous avez besoin de JMS ou de Server-Sent Events, ou si vous voulez un rapport HTML après chaque exécution sans configuration.

Choisissez k6 plutôt que Gatling si vous voulez un binaire unique en CI sans JVM à installer, si vos tests ont besoin de gRPC ou de vraies sessions de navigateur, si des thresholds doivent arrêter tôt une exécution qui échoue, ou si vous comptez monter en charge sur Kubernetes avec un operator open source.

FAQ

Gatling est-il plus rapide que k6 ? 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.

Gatling peut-il exécuter des scripts k6 ? Pas d’après la documentation de Gatling, qui ne décrit aucun moyen d’exécuter des scripts k6. Les deux SDK ont des API différentes et les convertisseurs de Gatling couvrent JMeter et LoadRunner : un script k6 doit donc être réécrit en simulation Gatling, même avec le SDK JavaScript.

LoadFocus peut-il exécuter des tests Gatling ? Non. LoadFocus exécute des scripts k6 et des plans de test JMeter. Pour répartir une simulation Gatling sur plusieurs machines, utilisez Gatling Enterprise.

À lire aussi

• Test de charge Gatling : l’outil JVM passé en revue
• k6 vs Artillery : quel outil de test de charge choisir ?
• Gatling vs JMeter : du code ou un plan de test graphique ?
• Gatling vs Locust : simulations JVM ou locustfiles Python ?
• Test de charge gRPC : outils, mise en place et mesures

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