Qu'est-ce que le load testing ?

Qu'est-ce que le load testing ?

Le load testing est la pratique de simuler du trafic utilisateur réaliste contre un site, une API ou un service, et de mesurer comment le système se comporte sous cette charge. L'objectif est la vérification : vous avez une prévision de trafic (peak du Black Friday, campagne de launch day, surge quotidien de 9h) et vous voulez savoir si votre infrastructure peut le gérer avant que de vrais utilisateurs ne le fassent.

Un load test rampe typiquement les utilisateurs virtuels (VUs) jusqu'à une concurrence cible, les maintient à ce niveau pendant une période soutenue, et enregistre les métriques qui comptent : temps de réponse, throughput, error rate. Si ces métriques restent dans votre performance budget (vos service-level objectives, ou SLOs), le test passe.

Pourquoi le load testing compte

Sans load testing, chaque release est un pari. La première fois que vous découvrez que votre checkout flow ne tient pas 5 000 acheteurs concurrents, c'est le moment où vos clients ne peuvent pas finaliser leur achat. Le load testing convertit ce pari en preuves.

Concrètement, un load test répond à :

• Mon système atteindra-t-il mes SLOs au trafic peak attendu ? Si votre SLO est "p95 latency sous 1 seconde" et que le load test montre p95 grimper à 3 secondes au peak, vous avez une décision corriger-ou-reporter avant le launch, pas pendant.
• Où la latence commence-t-elle à se dégrader ? Le response time scale habituellement linéairement avec la concurrence jusqu'à un point, puis grimpe abruptement. Connaître ce coude vous dit votre vrai plafond de capacité.
• Quel est l'error rate à la charge cible ? Un p95 qui a l'air parfait ne signifie rien si 10% des requêtes timeoutent. L'error rate gate la conformité SLO autant que la latence.

Load testing vs stress testing vs performance testing

Ces termes se chevauchent et sont souvent utilisés de manière interchangeable, mais répondent à des questions différentes.

• Performance testing est le terme parapluie pour tout test mesurant le comportement non-fonctionnel du système : vitesse, fiabilité, scalabilité sous charge.
• Load testing est un sous-ensemble qui se concentre spécifiquement sur les niveaux de trafic attendus. C'est de la vérification.
• Stress testing est l'opposé du load testing : au lieu de courir à la charge attendue, vous poussez au-delà pour trouver le breaking point. C'est de la découverte.

Une équipe d'ingénierie typique exécute des load tests avant chaque release majeure (CI/CD-friendly, rapide) et des stress tests moins fréquemment (trimestriellement ou après des changements d'architecture).

Métriques clés en load testing

Cinq métriques comptent le plus à la lecture d'un rapport de load test :

1. Percentiles de response time (p50, p95, p99). La moyenne trompe parce que les outliers la tirent. p95 signifie "95% des requêtes étaient plus rapides que cela", ce qui est un bien meilleur proxy d'expérience utilisateur.
2. Throughput (requêtes par seconde). Combien de travail le système accomplit réellement. Surveillez le moment où le throughput cesse de scaler linéairement avec la charge ajoutée.
3. Error rate. Pourcentage de requêtes échouées (HTTP 5xx, timeouts, assertion failures). Au-delà de ~0,5% sous charge attendue, c'est généralement un fail.
4. Utilisateurs virtuels actifs. La concurrence que le test génère réellement. Important de vérifier contre votre cible, car beaucoup d'outils plafonnent silencieusement la création de threads quand les ressources locales s'épuisent.
5. Utilisation de ressources sur le système sous test. CPU, mémoire, connexions base de données, réseau. Le load test montre le symptôme (réponses lentes), mais l'utilisation vous dit la cause.

Quand exécuter un load test

• Avant chaque release majeure. Câblez le load testing dans CI/CD pour que chaque build soit gated contre vos SLOs.
• Avant un peak connu. Pre-Black-Friday, pre-lancement de produit, pre-campagne marketing.
• Après des changements d'infrastructure. Nouvelle base de données, nouvelle couche de cache, nouvelle région. Re-exécutez le load test pour confirmer que les SLOs tiennent encore.
• Après des changements de code significatifs. Refactorings majeurs, upgrades de framework ou changements de dépendances peuvent déplacer les caractéristiques de performance subtilement.

Comment le load testing s'inscrit avec stress, spike et soak testing

Le load testing est une des plusieurs "formes" de testing non-fonctionnel :

• Load testing : soutenu au peak attendu.
• Stress testing : rampé au-delà du peak attendu pour trouver le breaking point.
• Spike testing : saut instantané de normal à peak (ou au-delà) pour tester elastic scaling et comportement warm-up.
• Soak / endurance testing : soutenu à charge modérée pendant de nombreuses heures pour faire émerger memory leaks et dégradation lente.

Les mêmes scripts exécutent les quatre. Seul le profil de charge (réglages thread group / scenario) change.

Outils pour le load testing

Les deux standards open source sont :

• JMeter : projet Apache, basé Java, GUI-driven. Forte couverture de protocoles (HTTP, JDBC, JMS, MQTT, gRPC), des milliers de plugins de la communauté, le standard historique en QA enterprise.
• k6 : moderne, code-first (JavaScript), construit en Go. Footprint mémoire moindre par VU, DX developer-friendly, s'intègre proprement à CI/CD.

Les deux tournent en local pour les petits tests. Pour une charge réaliste (milliers d'utilisateurs concurrents depuis plusieurs régions géographiques), il vous faut un cloud runner. LoadFocus exécute JMeter et k6 depuis 25+ régions cloud avec une analyse IA des résultats.

Si vous préférez ne pas écrire les scripts vous-même, LoadFocus propose des load testing services où des ingénieurs écrivent les scripts pour vos scénarios, les exécutent à grande échelle et livrent le rapport.