Load Test dans le développement mobile — ce que c’est, scénarios et comment il est effectué

Qu’est-ce que le Load Test?

Load Test est un processus de vérification du comportement d’un système sous un nombre attendu de requêtes ou d’utilisateurs simultanés. Dans le contexte du développement mobile, le Load Test est appliqué à la fois au backend (API, base de données, cache) et au client (traitement des notifications push, synchronisation des données). La principale différence avec les tests de stress est que le Load Test simule une charge réelle, pas extrême. Selon l’AWS Well-Architected Framework (2024), les tests de charge doivent être effectués en utilisant des profils de charge basés sur des analyses d’utilisation réelles.

Le Load Test peut être effectué au niveau des requêtes HTTP vers l’API, des connexions WebSocket ou des transactions de base de données. L’objectif est de garantir que le temps de réponse de chaque requête ne dépasse pas un seuil spécifié (généralement 500–1000 ms pour l’API) et que le débit (RPS — requêtes par seconde) réponde aux exigences. Google Cloud Armor (2024) définit des valeurs seuils basées sur des percentiles: le temps de réponse p95 ne doit pas dépasser 2 secondes pour les endpoints critiques.

Le test de charge d’un backend mobile comprend la simulation de scénarios typiques: inscription, authentification, chargement du fil d’actualité, soumission de formulaire. Les scénarios sont enregistrés sous forme de fichiers HAR (HTTP Archive) et rejoués par l’outil de test de charge. Selon la documentation k6 (2025), la conversion HAR peut réduire le temps de préparation du Load Test de 60%.

Objectifs du test de charge

Le premier objectif du Load Test est de confirmer le débit du système. Si la spécification exige le traitement de 1000 RPS, le test de charge doit le confirmer avec une marge de 20%. Selon le Netflix Tech Blog (2024), les tests de charge chez Netflix sont effectués avec une marge de 2x par rapport à la charge de pointe: si 10000 RPS sont attendus, le test vérifie 20000 RPS. Cette approche garantit la stabilité lors des pics soudains de trafic.

Le deuxième objectif est d’identifier les goulots d’étranglement (bottlenecks) dans l’architecture. Les goulots d’étranglement typiques dans les backends mobiles sont la base de données (requêtes lentes), le cache (stratégie d’invalidation incorrecte) et les API externes (services tiers lents). Le tracing distribué (Jaeger, Zipkin) aide à localiser le problème au niveau d’un service ou d’une requête spécifique.

Le troisième objectif est de déterminer le point de saturation (saturation point). C’est le moment où l’ajout de nouveaux utilisateurs n’augmente plus le débit. Dans les applications mobiles, le point de saturation survient souvent à 70–80% de charge CPU sur les serveurs de base de données. L’auto-scaling doit déclencher avant d’atteindre ce point.

Scénarios de test de charge

Test de pic (Spike Test) — simule une augmentation soudaine d’activité, comme une campagne de notifications push matinale ou le lancement d’une campagne publicitaire. Selon Grafana k6 (2025), le Spike Test simule une croissance de charge de 100 à 10000 RPS en 30 secondes. Le système doit gérer cela sans perdre de requêtes et sans dépasser le temps de réponse de plus de 50%.

Test d’endurance (Endurance Test) — vérifie la stabilité du système lors d’un fonctionnement prolongé sous charge. La durée typique est de 1 à 4 heures. L’Endurance Test révèle les fuites mémoire dans les applications serveur, les problèmes de pool de connexions à la base de données et la dégradation des performances du cache. Le pool de connexions PostgreSQL sous charge prolongée sans configuration adéquate peut épuiser les connexions disponibles en 2–3 heures de fonctionnement.

Test de charge progressif (Step Load Test) — augmentation graduelle de la charge par paliers de 10–20% toutes les 2–5 minutes. Ce scénario aide à trouver la limite exacte après laquelle le système se dégrade. InfluxDB et Prometheus collectent des métriques à chaque étape pour construire un graphique du temps de réponse en fonction du RPS.

Métriques de Load Test

Temps de réponse

Temps de réponse est la métrique principale du Load Test. Mesuré en millisecondes et analysé par percentiles: p50 (médiane), p95 et p99. Google SRE (2024) recommande un seuil p95 ne dépassant pas 1000 ms pour l’API REST et pas plus de 200 ms pour gRPC. Les percentiles sont plus importants que les moyennes car ils montrent le comportement des pires requêtes, que les utilisateurs remarquent en premier. Apdex (Indice de performance d’application) est une métrique composite qui prend en compte la proportion d’utilisateurs satisfaits, tolérants et frustrés.

Débit

Débit (Throughput) — le nombre de requêtes réussies par unité de temps. Mesuré en RPS (requêtes par seconde) ou TPS (transactions par seconde). Le graphique du débit dans les coordonnées « temps — RPS » doit être linéaire jusqu’au point de saturation. Une chute brutale du débit avec l’augmentation de la charge est un signe d’atteinte de la limite du système. Apache Bench et wrk sont des outils CLI simples pour des vérifications rapides du débit pendant le développement.

Taux d’erreur

Taux d’erreur (Error Rate) — la proportion de réponses avec un statut HTTP 4xx ou 5xx par rapport au nombre total de requêtes. Le seuil acceptable est inférieur à 1%. Les erreurs 429 (Trop de requêtes) et 503 (Service indisponible) sous charge élevée indiquent la nécessité de configurer la limitation de débit et l’auto-scaling. Un limiteur de débit côté API Gateway protège le backend contre le dépassement de la charge autorisée. La politique de réessai avec backoff exponentiel aide les clients à gérer correctement les erreurs temporaires.

Outils pour le Load Test

k6 (Grafana)

k6 — l’outil Open Source leader de test de charge de Grafana. Les scripts sont écrits en JavaScript, avec prise en charge de scénarios modulaires, de seuils (thresholds) et d’intégration avec Prometheus et InfluxDB. k6 peut s’exécuter à la fois en CLI et dans le cloud Grafana Cloud k6. Grafana Cloud construit automatiquement des tableaux de bord à partir des résultats du Load Test et les compare aux données historiques. k6 prend en charge Protocol Buffers et gRPC via le module séparé k6/net/grpc.

Apache JMeter

Apache JMeter — un outil classique de Load Test avec interface graphique. Il prend en charge un large éventail de protocoles: HTTP, JDBC, JMS, FTP et TCP. JMeter est mieux adapté aux scénarios complexes avec de nombreux types de requêtes différents mais nécessite plus de configuration manuelle par rapport à k6. Les plugins JMeter étendent les fonctionnalités pour les tests WebSocket et gRPC. Pour l’exécution distribuée, JMeter utilise une architecture maître-esclave avec un contrôleur.

Locust

Locust — un outil basé sur Python qui permet de décrire des scénarios de charge en code. Locust est pratique pour les équipes qui utilisent Python comme langage d’automatisation principal. Contrairement à k6 et JMeter, Locust prend en charge l’exécution distribuée natif: un nœud maître coordonne plusieurs nœuds workers. L’exécution distribuée permet de générer une charge allant jusqu’à 100000 RPS depuis plusieurs machines. Locust prend également en charge les tests WebSocket via des extensions personnalisées.

import http from 'k6/http'
import check from 'k6'
import sleep from 'k6'

export const options = {
    stages: [
        { duration: '2m', target: 100 },
        { duration: '5m', target: 100 },
        { duration: '2m', target: 200 },
    ],
    thresholds: {
        http_req_duration: ['p(95)<500'],
        http_req_failed: ['rate<0.01'],
    }
}

export default function() {
    const res = http.get('https://api.example.com/users')
    check(res, {
        'status is 200': (r) => r.status === 200,
    })
    sleep(1)
}

Exemple d’écriture d’un Load Test en k6

Le script k6 ci-dessus illustre une structure typique de test de charge. Options définit le profil de charge: montée en charge (ramp-up) pendant 2 minutes jusqu’à 100 utilisateurs, puis 5 minutes de charge constante et une nouvelle montée jusqu’à 200 utilisateurs. Les seuils définissent les critères de réussite du test: temps de requête p95 ne dépassant pas 500 ms, taux d’erreur inférieur à 1%. Si les seuils sont dépassés, k6 se termine avec un code non nul — cela permet d’intégrer le Load Test dans CI/CD.

Dans le développement mobile, le Load Test du backend est particulièrement important lors du lancement de nouvelles fonctionnalités qui créent une charge supplémentaire: likes, commentaires, streaming. Recommandation — effectuez un Load Test sur chaque staging avant de déployer en production. La création d’un profil de charge de base pendant la phase de conception de l’API permet d’éviter des problèmes architecturaux dans les phases ultérieures.