Test de charge Artillery : l'outil Node.js passé en revue

19 octobre 2026 7 min de lecture

Artillery est un outil de test de charge open source qui tourne sur Node.js et décrit chaque test dans un fichier YAML, TypeScript ou JavaScript. Le test de charge avec Artillery convient aux équipes qui vivent dans l’écosystème JavaScript, qui veulent faire arriver de nouveaux utilisateurs à un rythme fixé ou qui veulent des tests navigateur avec Playwright dans le même outil. Les équipes qui veulent un binaire unique sans runtime seront mieux servies par k6, et celles qui ont besoin de nombreux protocoles prêts à l’emploi par JMeter.

Nous n’avons pas exécuté Artillery pour cette revue. Les faits proviennent de la documentation, du dépôt, du paquet npm et de la page de tarifs d’Artillery, vérifiés le 19 octobre 2026, et les appréciations sont les nôtres.

Sujet	Artillery
Licence	MPL-2.0 ; certains modules Azure sous BSL
Runtime	Node.js, dernière LTS (le paquet exige 22.18.0 ou plus)
Version actuelle	2.0.34 (14 août 2026)
Tests écrits en	YAML, TypeScript ou JavaScript
Modèle de charge	Nouveaux utilisateurs virtuels par seconde, par phases
Moteurs intégrés	HTTP, WebSocket, Socket.IO, Playwright
Contrôles de réussite	Plugin `ensure`, code de sortie non nul
Montée en charge	`run-lambda`, `run-fargate`, `run-aci`
Rapports hébergés	Artillery Cloud, facultatif, avec offre gratuite

Qui développe Artillery, et sous quelle licence ?

Artillery Software Inc. le maintient sur GitHub. L’essentiel du code est sous MPL-2.0, qui autorise l’usage commercial ; certains modules propres à Azure sont sous Business Source License.

Le README du dépôt autorise l’usage d’Artillery sur Azure pour l’évaluation et les preuves de concept, et exige une licence commerciale pour un usage commercial ou en production sur Azure. La dernière version est la 2.0.34, publiée sur npm le 14 août 2026, et ses métadonnées demandent Node.js 22.18.0 ou plus ; le guide d’installation recommande la dernière version LTS (vérifié le 19 octobre 2026).

Comment fonctionne un script de test Artillery ?

Un script a deux parties : config, qui fixe la cible, les phases de charge et les plugins, et scenarios, qui liste ce que fait chaque utilisateur virtuel. Vous pouvez l’écrire en YAML ou exporter config et scenarios depuis un fichier TypeScript ou JavaScript.

Ce test monte de 5 à 50 nouveaux utilisateurs par seconde en deux minutes, tient 50 par seconde pendant dix minutes et échoue si le 99e percentile du temps de réponse atteint 800 ms :

config:
  target: https://staging.example.com
  phases:
    - duration: 120
      arrivalRate: 5
      rampTo: 50
      name: ramp
    - duration: 600
      arrivalRate: 50
      name: sustain
  plugins:
    ensure:
      thresholds:
        - http.response_time.p99: 800
scenarios:
  - name: browse and add to cart
    flow:
      - get:
          url: /products
      - think: 2
      - post:
          url: /cart
          json:
            sku: A-100

D’après la référence des scripts de test, les quatre types de phase sont un taux d’arrivée constant, une rampe linéaire avec rampTo, un arrivalCount fixe réparti sur une période et une pause. Le code personnalisé chargé par config.processor peut être un module TypeScript en local et sur Fargate, pas sur Lambda (vérifié le 19 octobre 2026).

Quel modèle de charge Artillery utilise-t-il ?

Artillery lance de nouveaux utilisateurs virtuels au rythme que vous fixez, que les précédents aient terminé ou non. C’est un modèle de charge ouvert, qui maintient les arrivées même quand le système ralentit.

Chaque nouvel utilisateur choisit un scénario, l’exécute et repart, donc un système lent accumule des utilisateurs comme le ferait un vrai trafic. maxVusers plafonne le nombre d’utilisateurs simultanés d’une phase si vous devez protéger le générateur de charge. Notre article sur le modèle de charge ouvert ou fermé explique la différence, et la loi de Little montre comment le taux d’arrivée et le temps de réponse fixent le nombre d’utilisateurs simultanés.

Quels protocoles et navigateurs peut-il tester ?

HTTP est le moteur par défaut, et WebSocket, Socket.IO et Playwright sont intégrés. gRPC et AWS Kinesis demandent des moteurs installés à part.

La page des moteurs décrit le principe : chaque scénario tourne sur un moteur, et vous pouvez écrire le vôtre. Sur npm, artillery-engine-grpc en est à la 0.0.9 et artillery-engine-kinesis à la 1.1.1, tous deux sous MPL-2.0. Le moteur Playwright exécute votre code Playwright dans de vrais navigateurs headless et publie des Web Vitals comme TTFB, FCP et LCP par page. La documentation prévient qu’un navigateur séparé par utilisateur, au lieu d’un contexte de navigateur, demande beaucoup plus de CPU et de mémoire (vérifié le 19 octobre 2026). Notre panorama des outils de test de charge WebSocket place Artillery à côté d’autres options pour les applications temps réel.

Comment s’intègre-t-il à la CI ?

Le plugin ensure transforme des métriques en contrôles de réussite, et un contrôle en échec fait sortir Artillery avec un code non nul. Cela suffit à n’importe quel système de CI pour faire échouer le build.

La référence d’ensure propose deux types de contrôle : thresholds, où une métrique doit rester sous une valeur, et conditions, qui combinent des métriques dans une expression comme http.response_time.p95 < 250 and http.request_rate > 1000. Une condition marquée strict: false signale sans faire échouer. Le plugin apdex ajoute un score Apdex aux tests HTTP, avec un seuil par défaut de 500 ms (vérifié le 19 octobre 2026) ; notre article sur le score Apdex explique comment le lire. Pour un fichier de workflow, voir notre guide du test de charge dans GitHub Actions.

Comment faire monter un test Artillery en charge ?

Depuis la ligne de commande, sur votre propre compte cloud : run-lambda et run-fargate sur AWS, run-aci sur Azure Container Instances. Artillery crée les ressources nécessaires à l’exécution et supprime ensuite les ressources temporaires.

Le guide Fargate liste les ressources et les permissions IAM en jeu. Le guide Lambda en donne les limites : un test ne peut pas durer plus de 15 minutes, un test lancé ne peut pas être arrêté, et les hooks before et after tournent une fois par worker. Le guide Azure demande Artillery 2.0.19 ou plus et, hors évaluation, un abonnement (vérifié le 19 octobre 2026).

LoadFocus, qui publie ce site, n’exécute pas de scripts Artillery. LoadFocus exécute des plans de test JMeter et des scripts k6 depuis 25 régions cloud : pour Artillery, les commandes ci-dessus restent le moyen de monter en charge.

Combien coûte Artillery Cloud ?

Le tableau de bord est facultatif : les résultats n’y arrivent que si vous lancez avec --record et une clé d’API. Les offres vont d’une formule gratuite à 499 $ par mois.

La page de tarifs indique (vérifié le 19 octobre 2026) :

Free : 30 rapports par mois, 1 mois de conservation, 2 membres, tests distribués jusqu’à 5 workers et 30 minutes.
Team, 199 $ par mois : 1 000 rapports, 6 mois, 8 membres, jusqu’à 25 workers et 2 heures.
Business, 499 $ par mois : 2 500 rapports, 18 mois, sans limite de membres, de workers ni de durée.

Le SSO entreprise, les journaux d’audit et les SLA de support commencent à 1 199 $ par mois, et la facturation annuelle fait économiser 20 %.

Que fait bien Artillery, et où sont ses limites ?

Il excelle sur la charge à taux d’arrivée, les scripts courts et lisibles et les tests navigateur avec Playwright. Il est moins à l’aise quand il faut un binaire unique, de nombreux protocoles sans extension ou Azure sans licence.

En tant qu’outil Node.js, il peut utiliser n’importe quel module npm dans des fonctions personnalisées, au prix d’un runtime de plus sur chaque machine de test. Limites que la documentation énonce elle-même :

Les exécutions Lambda s’arrêtent à 15 minutes et ne peuvent pas être annulées.
Le code personnalisé en TypeScript (config.processor) ne tourne pas sur Lambda.
gRPC et Kinesis sont des moteurs séparés.
L’usage en production sur Azure exige une licence commerciale.

Quand choisir plutôt k6, JMeter ou Locust ?

Choisissez un autre outil quand son runtime, ses protocoles ou son langage conviennent mieux à votre équipe.

Choisissez plutôt k6 si vous voulez un binaire Go sans Node.js à gérer et des seuils dans le script. Notre comparatif k6 vs Artillery met les deux côte à côte. LoadFocus exécute des scripts k6 depuis 25 régions cloud, mais fait tourner les scénarios arrival-rate avec un nombre fixe d’utilisateurs ; pour tenir un taux d’arrivée, lancez-les avec k6 lui-même.

Choisissez plutôt JMeter si vous avez besoin de JDBC, JMS, LDAP ou FTP prêts à l’emploi, ou si vos testeurs construisent leurs tests dans une interface graphique.

Choisissez plutôt Locust si votre équipe écrit en Python ; notre revue de Locust le présente. Le panorama des outils de test de charge open source les met tous côte à côte.

FAQ

Artillery est-il gratuit pour un usage commercial ? La CLI est en majeure partie sous MPL-2.0, qui autorise l’usage commercial. L’exception est Azure : un usage commercial ou en production de ses modules Azure exige une licence commerciale.

Artillery peut-il exécuter des tests navigateur ? Oui. Son moteur Playwright intégré exécute votre code Playwright dans des navigateurs headless et publie des Web Vitals pour chaque page.

LoadFocus peut-il exécuter des scripts Artillery ? Non. LoadFocus exécute des plans de test JMeter et des scripts k6. Pour faire monter un test Artillery en charge, utilisez run-lambda, run-fargate ou run-aci.