Si un lancement, des soldes ou une campagne approchent, vous vous demandez peut-être si votre application tiendra quand tout le monde arrivera en même temps. Le test de charge vous permet de le vérifier avant le grand jour : il envoie une foule d’utilisateurs simulés vers votre application ou votre site et mesure la vitesse de réponse de votre produit, la fréquence des requêtes en échec et la charge de travail de vos serveurs.
En tant que l’une des formes de test de performance, le test de charge répond à la question que se posent la plupart des équipes quand le trafic est sur le point de bondir : allons-nous tenir ? Si le système ne suit pas, les clients sont généralement les premiers à le découvrir. Lorsque les précommandes de la Nintendo Switch 2 ont ouvert en avril 2025, les acheteurs de Target, Walmart et Best Buy ont signalé des erreurs de paiement, des échecs de vérification d’adresse et des problèmes de transaction. Un mois plus tôt, OpenAI avait imposé des limites temporaires à son nouvel outil d’images ChatGPT parce que la demande dépassait sa puissance de calcul. Les deux pannes avaient la même cause : plus de visiteurs au même instant que ce pour quoi les systèmes avaient été conçus.
Vous trouverez ci-dessous les trois mesures que surveille tout test de charge, la frontière entre test de charge et test de stress, et comment savoir si votre produit en a besoin. Notre exemple concret est un jeu mobile dont le serveur a commencé à rejeter des requêtes quand 1 000 joueurs se sont connectés en 10 secondes.
Que mesure le test de charge ?
Le test de charge reproduit ce que font les visiteurs réels, mais à une bien plus grande échelle. Un outil crée des centaines ou des milliers de clients fictifs qui se connectent, naviguent et achètent en même temps. Les testeurs les appellent utilisateurs simultanés, c’est-à-dire des personnes présentes sur le système au même moment.
Pendant que cette foule est active, le test suit trois éléments :
- Temps de réponse : combien de temps chaque personne attend que l’application réagisse après une touche ou un clic. Un bon test examine aussi les réponses les plus lentes, car une moyenne saine peut masquer les visiteurs restés devant un écran de chargement.
- Taux d’erreur : la part des requêtes qui échouent. Une requête est chaque message que votre application envoie au serveur, par exemple pour charger une page ou enregistrer une commande. Sous une pression trop forte, certaines reviennent sous forme d’erreurs plutôt que de résultats.
- Utilisation des ressources : l’effort fourni par vos serveurs, mesuré par la puissance de calcul (processeur) et la mémoire vive (RAM). Dès que le processeur ou la mémoire approche de la saturation, tout le reste ralentit.
Ces mesures ne deviennent utiles qu’une fois comparées à un objectif. Avant le test, l’équipe s’accorde sur des limites telles que « aucune requête ne dépasse 3 secondes avec 5 000 utilisateurs connectés ». Le test montre alors si le système atteint l’objectif et, sinon, le point où la performance commence à se dégrader.
Sur une application, les ralentissements peuvent naître sur le téléphone lui-même ou sur le serveur qui se trouve derrière. Quand nous réalisons des tests d’applications mobiles, nous examinons les deux à la recherche de points faibles qui touchent l’utilisation de la mémoire, la stabilité et la résistance à la charge, autrement dit la capacité de l’ensemble à tenir quand le trafic grimpe.
Test de charge et test de stress : quelle différence ?
On confond souvent test de charge et test de stress, car les deux utilisent les mêmes outils. Chaque type de test répond pourtant à une question différente. Le test de charge vérifie que tout fonctionne bien au niveau de trafic que vous attendez, jusqu’à votre pic habituel. Le test de stress continue d’ajouter des utilisateurs au-delà de ce point jusqu’à ce que le système cède, afin que vous sachiez où se situe la limite et ce qui lâche en premier.
Les deux définitions correspondent au guide de test de performance de l’International Software Testing Qualifications Board (ISTQB), qui certifie les testeurs dans le monde entier. L’ISTQB décrit également deux types de tests connexes : le test de pics et le test d’endurance, que de nombreuses équipes appellent test de saturation.
Charge
Tenons-nous notre journée normale la plus chargée ?
Monte jusqu’au pic attendu et s’y maintient
Pages lentes et requêtes en échec au pic de trafic normal
Stress
Où se situe notre point de rupture ?
Continue de monter au-delà de ce pic
La limite réelle, et si le système cède en douceur ou s’effondre
Pics
Que se passe-t-il quand une foule arrive d’un coup ?
Bondit soudainement, puis retombe
Récupération lente et systèmes incapables d’ajouter de la puissance assez vite
Saturation
Restons-nous en bonne santé sur de longues heures ?
Se maintient longtemps à un niveau stable
Mémoire qui se remplit peu à peu et connexions ouvertes mais jamais fermées
Un système peut réussir un test de charge progressif et s’effondrer malgré tout quand la foule arrive en quelques secondes, et c’est pourquoi il vaut la peine de mener un test de pics à part. Pour tout produit qui tourne en continu, notre guide sur le test de saturation et les fuites de mémoire explique la durée que doit avoir chaque exécution.
Ce que notre test de charge réel a révélé sur le serveur d’un jeu mobile
Nous avons soumis Couple Up !, un jeu mobile inspiré des émissions de téléréalité sur les rencontres, à un test de charge quand son audience a commencé à croître. Le studio voulait savoir si le serveur resterait rapide et stable pendant une affluence bien plus forte.
Nos ingénieurs ont utilisé Apache JMeter, un outil de test de charge gratuit, pour mener quatre séries de joueurs simulés :
- 1 joueur ajouté en 1 seconde
- 100 joueurs ajoutés en 1 seconde
- 1 000 joueurs ajoutés en 10 secondes
- 10 000 joueurs ajoutés sur environ 17 minutes
Chaque requête devait aboutir en 3 secondes, quel que soit le nombre de joueurs connectés.
La série de 10 secondes, qui a fonctionné comme un petit test de pics, a largement dépassé cette limite. La plupart des requêtes ont pris plus de 3 secondes, et la plus lente en a demandé 27. Une sur cinq a échoué purement et simplement avec une erreur serveur, ce qui, dans un jeu, peut signifier qu’un joueur perd sa progression enregistrée.
La plus grande série s’est mieux déroulée. Quand 10 000 joueurs sont arrivés progressivement sur environ 17 minutes, la plupart des requêtes sont revenues à temps, même si les temps de réponse dépassaient encore ponctuellement 6 secondes. La vitesse d’arrivée peut compter autant que le nombre d’utilisateurs, et c’est pourquoi les lancements et les ventes flash comportent plus de risques qu’une croissance régulière. Les studios à gros budget anticipent eux aussi ce risque. Ainsi, avant la sortie de Battlefield 6 en octobre 2025, EA a mis en place des files d’attente à la connexion parce que l’équipe s’attendait à de nombreuses connexions simultanées.
Parallèlement au test de charge de Couple Up !, nous avons cherché la cause des ralentissements. Notre ingénieur DevOps, spécialisé dans l’hébergement, a vérifié la configuration du serveur. Dans le même temps, notre développeur Python senior a relu le code du serveur. Ensemble, les deux spécialistes ont remis au studio un plan étape par étape, des correctifs rapides et peu coûteux aux refontes plus profondes.
Vous préparez le lancement de votre propre jeu ? Suivez les mêmes étapes de test de charge dans notre checklist de tests de jeux mobiles.
Quand avez-vous besoin d’un test de charge ?
Menez un test de charge chaque fois que votre trafic ou votre système est sur le point de changer fortement. Les moments typiques sont :
- Le lancement d’un produit ou une nouvelle version majeure
- Des soldes ou une promotion saisonnière
- Une campagne marketing, un spot télévisé ou une publication d’influenceur qui envoie une vague de visiteurs
- Un passage à un nouvel hébergement ou une modification majeure de l’architecture du système
- Une croissance régulière qui vous a rapproché du trafic pour lequel vous aviez testé la dernière fois
À l’extrême, le réseau de Shopify a culminé à 489 millions de requêtes par minute lors du Black Friday et du Cyber Monday 2025. La plupart des boutiques ne verront jamais un trafic de cette ampleur, mais des soldes fonctionnent de la même façon à toute échelle : une foule arrive sur une fenêtre courte, et le paiement doit tenir. Si vous gérez une boutique en ligne, notre service de tests pour le Black Friday prépare votre site à ces heures de pointe.
Le test de charge ne concerne pas uniquement les produits qui n’ont pas encore été lancés. Couple Up ! était déjà sur le marché et en croissance quand nous avons testé le jeu. Le test de charge s’exécute généralement contre une copie du système en production, afin que les vrais clients ne soient pas affectés. Le bon moment se situe avant votre prochaine journée chargée.
Cela dit, tous les produits n’ont pas besoin de milliers d’utilisateurs simulés. Pour le site web d’Elsewhen, nous avons volontairement écarté l’exécution à forte charge. Elsewhen est un studio de produits numériques, et les sites interentreprises reçoivent rarement des afflux soudains de visiteurs.
Nous avons plutôt vérifié la vitesse de chargement et trouvé le vrai problème. Sur mobile, certaines pages mettaient plus de 10 secondes à afficher le contenu principal, alors que les internautes attendent 2 à 3 secondes au maximum.
En règle générale, commencez par des contrôles de vitesse sur des pages précises si votre trafic est faible et régulier. Si vous attendez des foules, même occasionnellement, le test de charge est le choix le plus sûr.
Quels outils de test de charge les équipes utilisent-elles ?
Les outils de test de charge créent la foule simulée. Chaque utilisateur fictif suit un script décrivant ce que fait un vrai client, par exemple ouvrir l’application, rechercher et payer. L’outil exécute ensuite des milliers de ces scripts en même temps. Nos ingénieurs choisissent l’outil adapté à votre produit, écrivent les scripts et mènent les tests.
Voici les outils avec lesquels nous travaillons, et les forces de chacun :
- JMeter est un logiciel gratuit de l’Apache Software Foundation doté d’une interface visuelle, et il couvre un large éventail de tests de sites et d’applications. Nous l’avons utilisé sur le projet Couple Up !.
- k6 vient de Grafana Labs, et ses tests en JavaScript s’intègrent naturellement aux vérifications automatiques que les développeurs lancent à chaque version.
- Gatling convient bien aux grandes suites de tests écrites en code et produit des rapports détaillés après chaque exécution.
- Locust exécute des tests écrits en Python, un choix naturel quand le code de votre produit utilise le même langage.
- LoadRunner est un outil payant avec une longue histoire dans les grandes entreprises qui exploitent des systèmes complexes.
- Grafana est un tableau de bord plutôt qu’un générateur de charge, et il nous permet de suivre les résultats en direct pendant l’exécution d’un test.
Nous choisissons parmi ces outils selon votre produit, les logiciels que vos développeurs utilisent déjà et ce qui doit être testé. Si vous vous préoccupez davantage de la façon dont votre produit fonctionne sur les téléphones, ce qui est distinct de la manière dont le serveur absorbe le trafic, notre sélection d’outils de test de performance des applications mobiles couvre cet aspect.
Comment QAwerk aborde le test de charge
Vous n’avez pas besoin d’une équipe interne de test de performance pour vous préparer à un pic de trafic. QAwerk peut rejoindre un projet à n’importe quelle étape, avant le lancement ou pendant la croissance. Nous commençons par une estimation de la charge de travail, afin que le périmètre soit clair avant le démarrage. Nous nous accordons ensuite sur des objectifs de performance, construisons des tests autour des comportements réels des utilisateurs et livrons un rapport qui place les correctifs les plus urgents en tête. Comme notre équipe comprend des ingénieurs DevOps et des développeurs aux côtés des testeurs, le rapport explique à la fois ce qui a échoué et ce qu’il faut changer.
Une date chargée est inscrite à votre calendrier ? Contactez notre équipe QA pour planifier un test de charge avant cette échéance.
FAQ
Qu’est-ce que le test de charge en test logiciel ?
Le test de charge en test logiciel est une répétition générale de votre journée la plus chargée. Un outil envoie des milliers de visiteurs virtuels vers un site ou une application en même temps. Pendant que cette foule navigue, les testeurs vérifient que les pages restent rapides, que les connexions et les paiements aboutissent et que les serveurs disposent d’assez de puissance. Les résultats montrent quel volume de trafic le système supporte avant de ralentir, de sorte que les problèmes sont corrigés avant que les clients ne les remarquent.
Le test de charge est-il la même chose que le test de performance ?
Non, même si le test de charge et le test de performance sont étroitement liés. Le test de performance est la catégorie large qui couvre la vitesse, la stabilité et la capacité. Le test de charge en est une composante et vérifie comment un système se comporte au nombre d’utilisateurs qu’il est censé servir, pics normaux compris. Les tests de stress, de pics, de saturation, de montée en charge et de volume appartiennent à la même famille, et chacun examine un type de risque différent.
Combien d’utilisateurs un test de charge doit-il simuler ?
Fondez le nombre sur vos propres données de trafic. Prenez le trafic le plus élevé enregistré par vos outils d’analyse, puis ajoutez les visiteurs supplémentaires attendus du prochain lancement, des soldes ou de la campagne. Une approche courante consiste à mener le test à ce pic attendu, puis de nouveau légèrement au-dessus, pour garder une marge de sécurité. Un test de pics distinct vaut aussi la peine, avec des milliers d’utilisateurs qui se connectent en quelques secondes.
Peut-on tester en charge une application déjà en production ?
Oui, et le test de charge est souvent le plus utile après le lancement, quand la croissance pousse un produit au-delà du trafic pour lequel il a été conçu. L’option la plus sûre est un environnement de test bâti à l’identique du vrai, afin que les clients ne remarquent jamais la charge supplémentaire. Quand ce n’est pas possible, les testeurs peuvent viser le système en production aux heures creuses, augmenter le trafic progressivement et s’arrêter dès que les temps de réponse ou les erreurs franchissent une limite convenue.
À quelle fréquence faut-il mener un test de charge ?
Le test de charge donne les meilleurs résultats quand il devient une habitude. Planifiez un test à pleine échelle avant chaque événement censé apporter un trafic inhabituel, et répétez-le après des changements majeurs d’hébergement ou d’architecture. Les équipes qui livrent souvent des mises à jour peuvent aussi ajouter un petit test de charge automatisé à chaque version, ce qui détecte un nouveau ralentissement le jour même où il apparaît.
Découvrez comment nous avons aidé Couple Up !
à effectuer des tests de charge
et à améliorer considérablement
les performances du serveur
sur plusieurs appareils
