🚦 Grafana k6 : les tests de charge écrits comme du code

📚 Introduction

Le test de charge a longtemps été un projet à part : un outil lourd, un plan de test en XML maintenu par une seule personne, une campagne lancée deux fois par an avant une grosse mise en production. Le résultat est prévisible — le test dérive du code réel, personne ne le relit, et la régression de performance se découvre en production.

Grafana k6 prend le problème par l’autre bout. C’est un binaire Go, sans JVM ni interface graphique, qui exécute des scripts JavaScript. Le test est un fichier .js versionné à côté du code, relu en pull request, exécuté en CI. Le projet est publié par Grafana Labs sous licence AGPL-3.0, et il couvre HTTP, WebSockets, gRPC et le navigateur via un module dédié.

Sa version majeure 2.0 est sortie en mai 2026 (la 2.2.0 est la dernière en date au moment où j’écris ces lignes), avec un nettoyage assumé des vieilles API et un virage net vers l’outillage d’extensions. Voyons ce que ça donne concrètement.

🚀 Premier test en cinq minutes

L’installation passe par les canaux habituels — dépôt APT, Homebrew ou image Docker :

# Debian / Ubuntu
curl -fsSL https://dl.k6.io/key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/k6-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list
sudo apt-get update
sudo apt-get install k6
 
# macOS
brew install k6
 
# Docker
docker pull grafana/k6

k6 new génère un script de départ, k6 run l’exécute :

k6 new
k6 run script.js
k6 run --vus 10 --duration 30s script.js

Et sans rien installer du tout, l’image officielle lit le script sur l’entrée standard :

docker run --rm -i grafana/k6 run --vus 10 --duration 30s - <script.js

Un script minimal tient en quelques lignes. La fonction exportée par défaut est le corps de l’itération : chaque VU (virtual user) la rejoue en boucle pendant toute la durée du test.

import http from 'k6/http';
import { check, sleep } from 'k6';
 
export const options = {
	stages: [
		{ duration: '30s', target: 20 },
		{ duration: '1m30s', target: 10 },
		{ duration: '20s', target: 0 }
	]
};
 
export default function () {
	const res = http.get('https://test.k6.io');
	check(res, { 'status was 200': (r) => r.status === 200 });
	sleep(1);
}

🎯 Scénarios et executors : modéliser une vraie charge

vus + duration suffit pour un smoke test, pas pour reproduire un trafic réaliste. Les scenarios permettent de faire tourner plusieurs profils de charge en parallèle, chacun avec son executor. Il y en a six :

La distinction qui compte est celle entre les executors à VUs et ceux à arrival rate. Avec constant-vus, si l’application ralentit, le débit de requêtes baisse mécaniquement : le test s’auto-régule et masque la dégradation. Avec constant-arrival-rate, k6 maintient le débit demandé et alloue des VUs supplémentaires si nécessaire — c’est ce qu’on veut pour valider un SLO exprimé en requêtes par seconde. Dans le doute, c’est le second qu’il faut choisir.

🔎 check, threshold ou expect : lequel utiliser ?

Les trois répondent à des questions différentes, et c’est la source de confusion la plus fréquente chez les gens qui découvrent l’outil.

Un check valide une réponse individuelle. Il n’interrompt rien : un check qui échoue est simplement comptabilisé dans la métrique checks, et le test continue. C’est un indicateur, pas une assertion bloquante.

Un threshold est un critère de réussite du test entier, évalué sur une métrique agrégée. C’est lui qui décide du code de sortie — donc de la couleur du job CI :

export const options = {
	thresholds: {
		http_req_failed: ['rate<0.01'],
		http_req_duration: ['p(95)<200'],
		checks: ['rate>0.99']
	}
};

La forme longue permet en plus d’abandonner le test dès que le seuil est franchi, ce qui évite de laisser tourner vingt minutes de charge sur un service déjà par terre :

export const options = {
	thresholds: {
		http_req_duration: [{ threshold: 'p(99) < 10', abortOnFail: true, delayAbortEval: '10s' }]
	}
};

Enfin, expect vient de la bibliothèque k6-testing, dont l’API s’inspire de celle de Playwright. Elle apporte des assertions qui font vraiment échouer l’itération, avec des matchers familiers et, côté navigateur, des assertions qui réessaient jusqu’au timeout :

import http from 'k6/http';
import { expect } from 'https://jslib.k6.io/k6-testing/0.6.1/index.js';
 
export default function () {
	const res = http.get('https://test-api.k6.io/public/crocodiles/1/');
	const data = res.json();
 
	expect(res.status).toBe(200);
	expect(res.headers['Content-Type']).toContain('application/json');
	expect(data).toHaveProperty('id');
	expect(data.age).toBeGreaterThan(0);
}

En pratique : check pour observer, threshold pour décider, expect quand le script sert autant de test fonctionnel que de test de charge. Si vous venez de Pest 4 et de son browser testing, le troisième vous parlera immédiatement.

🧰 En CI et dans la stack d’observabilité

Deux actions officielles couvrent GitHub Actions — l’une installe le binaire, l’autre lance les tests avec un glob :

jobs:
  perf:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: grafana/setup-k6-action@v1
      - uses: grafana/run-k6-action@v1
        with:
          path: |
            ./tests/api*.js

Le même principe s’applique à un pipeline GitLab CI avec l’image grafana/k6. Le point important n’est pas l’intégration en elle-même mais les thresholds : sans eux, le job est vert quoi qu’il arrive.

Côté résultats, --out envoie les métriques en temps réel vers une destination externe : json, csv, prometheus-rw, opentelemetry, influxdb, datadog, elasticsearch, et d’autres. Les deux premiers de cette liste sont ceux qui m’intéressent le plus : ils branchent le test de charge sur l’observabilité déjà en place, qu’elle repose sur kube-prometheus-stack ou sur SigNoz. On compare alors la charge injectée et ce que le service en a fait, sur les mêmes dashboards — et on vérifie ses SLO au lieu de les supposer.

Pour la charge distribuée, l’opérateur Kubernetes k6 Operator est passé en 1.0 avec la version 2.0 : il répartit un même script sur plusieurs pods, ce qui se teste très bien sur un cluster k3s local avant de viser plus gros.

🧩 Extensions et outillage agents

k6 2.0 a beaucoup travaillé l’extensibilité. Les extensions sont classées en deux niveaux — officielles, maintenues par Grafana Labs (k6/x/faker, k6/x/sql, k6/x/mqtt, k6/x/dns), et communautaires (k6/x/sse, k6/x/kafka) — et une nouvelle catégorie d’extensions ajoute des sous-commandes sous le namespace k6 x. Quatre sont livrées d’office :

k6 x explore              # parcourir le registre d'extensions
k6 x docs                 # la doc et les API, en CLI
k6 x mcp                  # serveur MCP exposant k6 aux agents
k6 x agent init claude-code   # câbler k6 dans son assistant

k6 x agent init dépose les fichiers de skill dans l’emplacement attendu par l’éditeur (.claude/skills/, .cursor/rules/…) et fusionne l’entrée du serveur MCP dans la configuration existante. --all cible tous les éditeurs supportés, --dry-run montre ce qui serait écrit, k6 x agent status vérifie l’état. La démarche est la même que celle de Laravel Boost : donner à l’agent les outils et la doc du projet plutôt que de le laisser inventer une API.

⚠️ Quelques précautions

• La migration vers la 2.0 casse des choses. Les commandes k6 pause, k6 resume, k6 scale, k6 status et k6 login ont disparu, ainsi que l’executor externally-controlled et le module k6/experimental/redis. options.ext.loadimpact est remplacé par options.cloud, et la forme k6 cloud script.js cède la place à k6 cloud run script.js. Le serveur d’API HTTP ne démarre plus tout seul : il faut désormais --address ou K6_ADDRESS. Pour les extensions, le chemin du module Go devient go.k6.io/k6/v2.
• k6 n’est pas un navigateur — sauf quand on utilise explicitement le module k6/browser. Une requête HTTP ne déclenche ni JavaScript, ni chargement d’assets. Un test protocolaire mesure le backend, pas l’expérience utilisateur.
• Le poste de travail est un facteur limitant. Au-delà de quelques milliers de VUs, c’est la machine qui sature avant le service testé. Passez sur plusieurs machines (k6 Operator) ou sur l’offre cloud plutôt que de croire un résultat plafonné par votre laptop.
• Testez ce que vous avez le droit de tester. Un test de charge contre un service tiers, une API SaaS ou un environnement partagé sans accord préalable, c’est un déni de service.

🎉 Conclusion

k6 fait ce que j’attends d’un outil de test de charge en 2026 : un binaire unique, des scripts versionnés, un code de sortie exploitable en CI, et des métriques qui partent vers la stack d’observabilité existante. Rien de magique — la partie difficile reste de définir ce qu’on mesure et à partir de quand on considère que ça ne va pas.

Si vous démarrez : un script, un constant-arrival-rate, deux thresholds, et un job CI qui tourne sur la branche principale. C’est peu, mais c’est déjà une régression de performance détectée avant la mise en production plutôt qu’après.

🔗 Liens utiles

• Site officiel de Grafana k6
• Documentation Grafana k6
• Dépôt GitHub grafana/k6
• Guide de migration vers k6 v2
• Annonce de k6 2.0 sur le blog Grafana
• Référence des executors
• Action GitHub grafana/run-k6-action