Azure Load Testing : le service de Microsoft passé en revue

19 octobre 2026 7 min de lecture

Azure Load Testing est le service managé de Microsoft pour exécuter des tests JMeter et Locust à grande échelle depuis Azure, facturé à l’heure d’utilisateur virtuel. Il convient bien quand le système testé tourne sur Azure, car il peut récupérer les métriques serveur d’Azure Monitor et atteindre des endpoints privés dans un réseau virtuel. Les équipes qui écrivent des scripts k6, qui n’ont pas d’abonnement Azure ou qui testent depuis l’extérieur des régions Azure trouveront d’autres services plus simples.

Nous n’avons pas exécuté Azure Load Testing pour cette revue. Les faits proviennent de la documentation et de la page de tarifs de Microsoft, vérifiées le 19 octobre 2026, et les appréciations sont les nôtres.

Sujet	Azure Load Testing
Type	Service managé du hub Azure App Testing
Frameworks de test	Apache JMeter et Locust uniquement
Option sans code	Test rapide par URL, jusqu’à cinq requêtes HTTP
Échelle par exécution	Jusqu’à 400 instances de moteur
Test le plus long	24 heures
Origine de la charge	Région de la ressource, ou jusqu’à 5 régions
Endpoints privés	Oui, par injection dans un réseau virtuel
Prix	0,15 $ par heure d’utilisateur virtuel, 0,06 $ après 10 000
Conservation	6 mois ; métriques client 365 jours

Qu’est-ce qu’Azure Load Testing ?

C’est un service entièrement managé qui exécute votre test de charge sur les moteurs de test de Microsoft, si bien que vous ne construisez ni ne maintenez jamais de générateurs de charge. Vous créez une ressource de test de charge dans une région Azure, vous y ajoutez des tests et vous lancez les exécutions depuis le portail, l’Azure CLI ou un pipeline.

La page de présentation précise que l’application testée peut se trouver n’importe où : dans Azure, sur site ou dans un autre cloud. Microsoft range désormais le service dans le hub Azure App Testing, à côté de Playwright Workspaces ; le démarrage rapide Locust crée la ressource depuis ce hub (vérifié le 19 octobre 2026).

Quels types de tests et quels outils prend-il en charge ?

Trois entrées : un test rapide par URL, un script JMeter téléversé ou un script Locust téléversé. La documentation indique clairement qu’aucun autre framework de test n’est pris en charge.

Le test rapide accepte jusqu’à cinq requêtes HTTP et un nombre cible d’utilisateurs virtuels ou de requêtes par seconde. Chaque moteur gère jusqu’à 250 utilisateurs virtuels, donc 400 utilisateurs tournent sur deux moteurs de 200 chacun.

Avec JMeter, vous pouvez utiliser des plugins de jmeter-plugins.org ou téléverser les vôtres, et la présentation affirme que tous les protocoles pris en charge par JMeter fonctionnent, comme une connexion à une base de données ou une file de messages. Avec Locust, vous pouvez ajouter des plugins Locust et d’autres bibliothèques Python. La documentation de Locust renvoie elle-même vers le service comme option hébergée, et notre revue de Locust présente l’outil lui-même. Les scripts k6, Gatling et Artillery ne tournent pas ici (vérifié le 19 octobre 2026).

Comment fonctionnent moteurs, utilisateurs virtuels et limites ?

Vous faites monter un test en charge en ajoutant des instances de moteur. Pour JMeter, la charge totale est le nombre d’utilisateurs du plan de test multiplié par le nombre de moteurs ; pour Locust, vous fixez le total d’utilisateurs et choisissez combien de moteurs les génèrent.

La page des concepts donne les deux formules, et la page des limites du service fixe les plafonds par région et par abonnement (vérifié le 19 octobre 2026) :

Instances de moteur par exécution : 1 à 400 par défaut selon l’offre, 400 au maximum.
Instances de moteur simultanées : 5 à 400 par défaut, jusqu’à 1 000 sur demande.
Durée de test : 3 à 24 heures par défaut, 24 heures au maximum.
Critères d’échec : jusqu’à 50 par test.
Conservation : métriques serveur 90 jours, métriques client 365 jours, résultats et journaux 6 mois.

Relever une limite par défaut passe par une demande au support ; rien ne dépasse les maximums indiqués.

Peut-il tester des endpoints privés et générer de la charge depuis plusieurs régions ?

Oui aux deux, avec une réserve : les deux ne se combinent pas. La charge multirégion ne fonctionne que vers des endpoints publics.

Par défaut, les moteurs tournent dans la région de votre ressource de test de charge. Le guide multirégion permet de choisir jusqu’à 5 régions par test et d’y répartir la charge, et il bascule alors le test en trafic public. Pour les services sans endpoint public, l’injection dans un réseau virtuel place les moteurs dans le réseau qui héberge l’application (vérifié le 19 octobre 2026).

Que montrent les résultats et les métriques serveur ?

Le tableau de bord affiche en direct les métriques côté client pendant l’exécution, comme les utilisateurs virtuels, le temps de réponse et les requêtes par seconde. Pour les applications hébergées sur Azure, il ajoute les métriques côté serveur d’Azure Monitor, d’Application Insights et de Container Insights sur la même chronologie.

Ce couplage est le principal atout du service : vous voyez la base de données ou le conteneur qui sature au moment où les temps de réponse montent, sans monter un tableau de bord séparé. Le guide des métriques serveur en décrit les étapes. Les exécutions passées restent comparables côte à côte, et vous pouvez télécharger les résultats pour d’autres outils.

Comment fonctionnent les critères de réussite et la CI ?

Vous définissez des critères d’échec sur des métriques client ou serveur, et l’exécution est marquée en échec dès que l’un d’eux est dépassé. Les pipelines d’Azure DevOps, de GitHub Actions ou de tout outil de CI capable d’appeler l’Azure CLI peuvent lancer un test et faire dépendre la suite de ce résultat.

Selon le guide des critères d’échec, un critère est un agrégat d’une métrique client, comme le temps de réponse moyen ou le pourcentage d’erreurs, comparé à un seuil, soit pour tout le test, soit pour une requête nommée. Les métriques serveur exigent que l’identité managée de la ressource puisse les lire. L’arrêt automatique stoppe une exécution quand le taux d’erreur dépasse une limite, pour qu’une mauvaise URL ne continue pas à coûter. Le guide CI/CD couvre GitHub Actions et Azure Pipelines (vérifié le 19 octobre 2026). Notre guide sur les critères de réussite d’un test de charge explique comment choisir les limites.

Combien coûte Azure Load Testing ?

Vous payez à l’heure d’utilisateur virtuel (VUH) : 0,15 $ par VUH pour les 10 000 premières, puis 0,06 $ par VUH, au même tarif dans toutes les régions de la page de tarifs. Depuis le 1er mars 2026, il existe aussi un minimum facturé par exécution.

La page de tarifs définit une VUH comme le nombre d’utilisateurs virtuels multiplié par les minutes, divisé par 60, compté toutes les 10 secondes ; 1 000 utilisateurs pendant 30 minutes font 500 VUH, soit 75 $ au tarif du premier palier. Le minimum est de 10 utilisateurs virtuels par moteur pendant la durée de l’exécution, avec au moins 10 minutes. Une exécution de 3 heures avec 5 utilisateurs sur un moteur est donc facturée 30 VUH au lieu de 15 (vérifié le 19 octobre 2026).

Quand choisir autre chose ?

Choisissez une autre option quand vos scripts, votre cloud ou votre budget vous orientent ailleurs.

Notre panorama des outils de test de charge open source présente les outils que vous pouvez faire tourner vous-même.

Choisissez plutôt LoadFocus, qui publie ce site, si vous voulez exécuter des plans de test JMeter et des scripts k6 depuis 25 régions cloud sans abonnement Azure. LoadFocus n’exécute pas Locust et fait tourner les scénarios k6 arrival-rate avec un nombre fixe d’utilisateurs.

Choisissez plutôt Grafana Cloud k6 ou le k6-operator si vos tests sont écrits pour k6, qu’Azure Load Testing ne sait pas exécuter (vérifié le 19 octobre 2026).

Choisissez plutôt Locust auto-hébergé si vous disposez déjà de Kubernetes ou de machines libres : son mode distribué est gratuit, et vous ne payez que le matériel.

FAQ

Azure Load Testing prend-il en charge k6 ? Non. Il exécute des tests Apache JMeter et Locust, ainsi que des tests rapides par URL qu’il transforme lui-même en script. Les scripts k6 demandent un autre service ou votre propre infrastructure.

Puis-je utiliser Azure Load Testing pour une application qui n’est pas hébergée sur Azure ? Oui. Les moteurs de test peuvent viser n’importe quel endpoint public. Les métriques serveur ne sont collectées que pour les ressources Azure ; pour un autre hébergement, lisez les métriques serveur dans votre propre monitoring.

Existe-t-il une offre gratuite ? La page de tarifs n’indique pour le test de charge que des prix à l’heure, avec un minimum par exécution. Les nouveaux comptes Azure reçoivent un crédit de 200 $ pour leurs 30 premiers jours, d’après la même page.