Test de Stress dans le développement mobile : définition, objectifs et mise en œuvre

Qu’est-ce que le Stress Test ?

Le Stress Test (test de stress) est un processus d’évaluation de la capacité d’un système à fonctionner dans des conditions dépassant les valeurs calculées. Pour une application mobile, cela peut signifier 10000 notifications push simultanées pour une norme de 1000, pour le backend — 50000 RPS pour 5000 attendus. La principale différence entre le Stress Test et le Load Test est que l’objectif n’est pas de confirmer la performance, mais d’étudier le comportement du système au-delà de sa capacité nominale. Netflix Engineering (2024) définit le Stress Test comme « la vérification de l’hypothèse selon laquelle le système tombera en panne de manière prévisible ».

Le test de stress comprend deux étapes obligatoires : la charge jusqu’à la panne et l’observation de la récupération. La récupération (recovery) est la capacité du système à revenir à un fonctionnement normal après la suppression de la surcharge. Un système qui ne récupère pas sans redémarrage est considéré comme fragile, même s’il supporte une surcharge de courte durée. Selon l’AWS Well-Architected Framework (2024), le temps de récupération après un Stress Test ne doit pas dépasser 5 minutes.

Pour les clients mobiles, le Stress Test inclut la vérification du fonctionnement en cas d’arrêt forcé des processus, de déconnexion du réseau et d’épuisement de la RAM. L’Android Low Memory Killer peut terminer un processus en arrière-plan en cas de manque de RAM — le test de stress doit vérifier que l’application restaure correctement son état après une telle terminaison. Apple UIKit (2024) recommande de tester les scénarios d’avertissement de mémoire sur chaque écran de l’application.

Objectifs du test de stress

Détermination du point de défaillance

Le premier objectif du Stress Test est la détermination du point de défaillance (breaking point). C’est le moment où l’un des indicateurs clés de performance franchit un seuil critique : le temps de réponse p95 dépasse 10 secondes, le pourcentage d’erreurs HTTP 5XX dépasse 5%, ou le débit chute en dessous de 50% de la référence. La fixation du point de défaillance permet à l’équipe de connaître à l’avance la limite de passage à l’échelle du système. La planification de capacité s’appuie précisément sur les données du Stress Test, et non du Load Test, car le Load Test ne vérifie pas les conditions limites.

Vérification des mécanismes de récupération

Le deuxième objectif est la vérification des mécanismes de récupération. Une fois la charge réduite à un niveau normal, le système doit revenir à ses indicateurs standards. Si le pool de connexions à la base de données n’est pas libéré ou si le cache n’est pas invalidé, le Stress Test identifiera ce problème. Le circuit breaker (Hystrix, Resilience4j) doit se déclencher en cas de surcharge et rétablir automatiquement la connexion après stabilisation. Les points de terminaison Health check aident à surveiller l’état de chaque service pendant le test.

Validation de l’auto-scaling

Le troisième objectif est la validation de l’auto-scaling. Si l’infrastructure utilise Kubernetes ou AWS Auto Scaling, le Stress Test vérifie que les nouveaux pods ou instances sont créés suffisamment rapidement. Selon Google Kubernetes Engine (2024), le temps de déploiement d’un nouveau pod ne doit pas dépasser 30 secondes à partir du déclenchement de la métrique HPA (Horizontal Pod Autoscaler). Le HPA doit passer à l’échelle en fonction du CPU, de la mémoire et de métriques personnalisées. Le Cluster Autoscaler ajoute de nouveaux nœuds si les nœuds actuels ne peuvent pas accueillir les pods.

Méthodologie du Stress Test

L’augmentation progressive de la charge (Ramp-up Stress Test) est le scénario le plus courant. La charge initiale est fixée à 50% de la charge attendue, puis augmentée de 10% toutes les 2 minutes jusqu’à ce que le système tombe en panne. Ce scénario permet de trouver la limite exacte de la résilience. Grafana Cloud k6 (2025) recommande un pas d’augmentation ne dépassant pas 10% pour obtenir un graphique lisse du temps de réponse.

Le pic soudain de charge (Spike Stress Test) — la charge passe de 10% à 500% en 10–30 secondes. Ce scénario modélise des situations comme la propagation virale de contenu ou une attaque DDoS. Le Spike Stress Test vérifie moins la performance que la survivabilité du système : sa capacité à ne pas tomber complètement et à reprendre son fonctionnement après stabilisation. La passerelle API doit configurer une limitation de débit pour protéger le backend des pics soudains.

Le maintien prolongé de la surcharge (Sustained Stress Test) — le système est maintenu en état de surcharge pendant 30–60 minutes. Ce scénario révèle des fuites de ressources qui n’apparaissent pas lors de tests de courte durée. Les fuites de mémoire dans les applications Java/Kotlin s’accumulent pendant 20–40 minutes de fonctionnement intensif, et seul le Sustained Stress Test les détecte.

Analyse du point de défaillance et de la récupération

Le point de défaillance est déterminé selon trois critères : le temps de réponse, le pourcentage d’erreurs et le débit. Le seuil de temps de réponse est généralement le premier à être dépassé — les requêtes commencent à prendre plus de temps que la limite établie. Ensuite, le pourcentage d’erreurs augmente : le serveur ne parvient pas à traiter les requêtes et renvoie 503. Enfin, le débit chute — le système cesse de gérer même la charge minimale. La métrique du point de défaillance est enregistrée dans le profil de charge pour la planification des capacités.

L’analyse de la récupération comprend trois phases : la réaction immédiate (les 30 premières secondes après la suppression de la charge), la stabilisation (1–5 minutes) et la récupération complète (5–30 minutes). Dans la phase de réaction immédiate, le temps de réponse doit tomber en dessous de la référence — le système se libère des files d’attente. Si cela ne se produit pas, le problème ne vient pas de la charge mais de l’état accumulé. La dégradation gracieuse — capacité du système à conserver une fonctionnalité partielle en cas de surcharge — est un indicateur clé de la maturité de l’architecture.

Le Chaos Engineering complète le Stress Test par l’introduction intentionnelle de pannes : arrêt du serveur de base de données, latence réseau, arrêt d’un microservice. Chaos Monkey de Netflix (2024) termine aléatoirement des processus en production, vérifiant la résilience du système. Pour les applications mobiles, le Chaos Engineering signifie tester des scénarios : absence de réseau, indisponibilité de l’API, réponse vide du serveur.

Outils pour le Stress Test

k6 avec ramping-arrival-rate

k6 prend en charge le Stress Test via le module `execution` avec la configuration ramping-arrival-rate. Ce mode augmente le nombre de requêtes par seconde indépendamment du temps d’exécution de chaque requête. Par rapport au Load Test, le Stress Test dans k6 nécessite la configuration de seuils plus agressifs et la désactivation de gracefull-stop pour simuler une panne soudaine. Grafana Cloud détecte automatiquement le point de défaillance par la cassure de la courbe du temps de réponse. k6-operator pour Kubernetes permet d’exécuter des tests de stress distribués depuis le cluster.

JMeter avec Ultimate Thread Group

JMeter permet de configurer le Stress Test via Ultimate Thread Group — un plugin qui définit le profil de charge sous forme de tableau : nombre de threads, temps de montée en charge, temps de maintien, temps de descente. Ultimate Thread Group est pratique pour les scénarios multiphases complexes. JMeter Backend Listener envoie des métriques à InfluxDB pour construire des graphiques du point de défaillance. Pour le Stress Test, il est recommandé de désactiver les timeouts de connexion dans JMeter afin de mesurer plus précisément le comportement en surcharge.

Gremlin pour le Chaos Engineering

Gremlin est une plateforme de Chaos Engineering pour le Stress Test de l’infrastructure. Gremlin permet de désactiver le réseau, de charger le CPU, de remplir le disque et de terminer des processus au niveau de pods Kubernetes individuels. Les équipes SRE utilisent Gremlin avec k6 pour un Stress Test complet : k6 génère la charge, Gremlin introduit les pannes. Le Game Day — sessions régulières de Stress Test utilisant Gremlin, documentées dans un « chaos report » pour analyser la résilience du système.

Exemple de Stress Test sur k6

Le script k6 ci-dessous illustre un Stress Test avec augmentation progressive de la charge jusqu’à la panne. Ramping-arrival-rate augmente le nombre de requêtes par seconde indépendamment du temps d’exécution. Les seuils sont configurés pour une détection agressive de la dégradation : p95 ne dépassant pas 2000 ms, taux d’erreur ne dépassant pas 5%. En cas de dépassement des seuils, k6 termine le test avec un code d’erreur, ce qui permet d’intégrer le Stress Test dans un pipeline CI/CD.

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

export const options = {
    scenarios: {
        stress: {
            executor: 'ramping-arrival-rate',
            startRate: 50,
            timeUnit: '1s',
            stages: [
                { duration: '2m', target: 200 },
                { duration: '5m', target: 500 },
                { duration: '2m', target: 1000 },
            ],
            preAllocatedVUs: 50,
            maxVUs: 200,
        },
    },
    thresholds: {
        http_req_duration: ['p(95)<2000'],
        http_req_failed: ['rate<0.05'],
    },
}

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

Bonnes pratiques du test de stress

Commencez le Stress Test sur l’environnement de staging — le test de stress en production nécessite une surveillance avancée et un plan de retour arrière. Google SRE (2024) recommande d’effectuer le Stress Test dans un environnement 100% isolé qui reproduit la production en termes d’architecture et de capacités. Après un test réussi sur staging, on peut passer en production sous la supervision de la SRE. Le feature flag pour désactiver des fonctionnalités en cas de surcharge est un élément obligatoire.

Automatisez le Stress Test dans le CI/CD pour l’analyse régressive du point de défaillance. Si une nouvelle version de l’application a un point de défaillance 20% inférieur à la précédente, il s’agit d’une régression à corriger avant la sortie. Le point de rupture de référence est stocké dans les métriques et automatiquement comparé au résultat de chaque Stress Test. Une alerte se déclenche en cas de baisse de 10% du point de défaillance.

Documentez chaque Stress Test : profil de charge, point de défaillance, comportement de récupération et liste des problèmes découverts. Netflix Engineering (2024) organise des « Game Days » — sessions régulières de Stress Test dont les résultats sont documentés dans un « chaos report ». Le rapport de test de stress doit contenir un graphique « RPS — temps de réponse » avec le point de défaillance marqué.