Lorsqu’un site web subit un trafic élevé, il peut ralentir, générer des erreurs, voire planter s’il n’est pas correctement testé. C’est ce qui se passe lorsqu’un site ne peut pas gérer de nombreux utilisateurs simultanément.
Pour éviter cela, nous devons faire plus que simplement vérifier si les fonctionnalités de base fonctionnent. Nous devons tester comment notre site web se comporte sous pression. Cela s’appelle un test de charge ou test de résistance. Pensez-y comme au test d’un pont. Vous ne vous contenteriez pas de le traverser une fois, vous voudriez voir s’il peut supporter un trafic intense et même résister à des conditions extrêmes. Le test de charge nous aide à déterminer si notre site peut gérer un grand nombre d’utilisateurs sans ralentir ou planter.
Planifier votre test de charge : poser les bonnes questions
Avant de commencer les tests de charge, nous devons répondre à quelques questions clés :
- Combien d’utilisateurs devons-nous simuler ? Nous devons estimer le nombre d’utilisateurs que nous attendons sur notre site au moment de son trafic maximal.
- Que font les utilisateurs réels ? Nous devons créer des scénarios de test qui imitent les interactions réelles des utilisateurs avec notre site.
- D’où viennent nos utilisateurs ? Nous devrions simuler des utilisateurs de différentes régions du monde pour voir comment notre site fonctionne pour tous.
- À quel rythme devons-nous augmenter la charge ? Nous ne devons pas submerger soudainement le site avec des utilisateurs, mais augmenter progressivement le nombre d’utilisateurs pour observer la réaction du site.
- Combien de temps le test doit-il durer ? Nous devons faire durer le test suffisamment longtemps pour obtenir des résultats significatifs.
En planifiant soigneusement nos tests de charge, nous pouvons garantir que notre site offre une expérience fluide et agréable à tous les utilisateurs, même aux heures de pointe.
Mise à jour 2026 : Les applications modernes génèrent du trafic depuis de nombreuses sources au-delà des navigateurs web traditionnels, notamment les applications mobiles, les API et les intégrations tierces. Pour cette raison, les stratégies de test de charge simulent désormais souvent un mélange de comportements utilisateurs et de trafic API pour mieux refléter les environnements de production réels.
Utilisateurs concurrents requis pour les tests de charge
Avant de configurer un test qui reflète avec précision le comportement réel des utilisateurs, nous devons passer un peu de temps à déterminer combien d’utilisateurs concurrents nous devons simuler. Les utilisateurs concurrents définissent combien d’utilisateurs navigueront sur notre site ou application web et effectueront des transactions sur une période donnée. Le trafic sur vos sites et applications fluctue probablement au cours de la semaine, mais pour bien tester vos sites et applications, vous voudrez configurer votre test aux heures de trafic de pointe. Mais comment trouver correctement le nombre exact d’utilisateurs concurrents ?
Nous pouvons utiliser des outils d’analyse web pour déterminer les statistiques actuelles de trafic sur notre site avec des détails à rechercher comme le nombre de visites, la durée des sessions sur le site. Google Analytics et de nombreux autres outils fournissent des métriques de sessions par intervalle régulier, la durée moyenne des sessions et le temps passé par les utilisateurs sur le site. Nous pouvons utiliser la formule suivante pour estimer le nombre d’utilisateurs concurrents :
Utilisateurs concurrents = Sessions horaires x Durée moyenne de session (en minutes) / 60
Si nous n’avons pas de données d’analyse web, nous pouvons utiliser le nombre attendu de visites pour calculer le nombre d’utilisateurs concurrents :
Utilisateurs concurrents = Nombre de visites attendues par minute * Durée de la visite (en minutes)
Pour plus d’informations et conseils sur la configuration des utilisateurs actuels, consultez notre base de connaissances et lisez notre article sur le calcul des utilisateurs concurrents à partir des analyses web.
Simulation de scénarios de test utilisateur réels
Maintenant que nous connaissons le nombre d’utilisateurs concurrents, nous devons identifier les scénarios de test fréquents et à fort trafic pour nos tests de résistance. Gardez à l’esprit qu’il n’est pas nécessaire d’utiliser beaucoup de scripts pour chaque situation. En général, vous constaterez qu’un petit nombre de cas d’utilisation suffit pour déterminer la charge réelle de toutes vos transactions.
Une fois que nous avons défini le niveau pertinent d’utilisateurs concurrents, nous devons choisir l’approche de simulation de tâches adaptée au test, en fonction de l’application testée.
Test de charge des applications web et pages web
Pour simuler des scénarios utilisateurs et des transactions pour les applications web et sites, nous devons écrire des scripts décrivant les parcours utilisateurs de notre scénario de test. Pour cela, nous pouvons utiliser l’EveryStep Web Recorder, qui enregistre nos interactions dans le navigateur et crée un script à utiliser pour le test de charge. L’EveryStep Web Recorder est facile à utiliser, mais capable de créer des scripts pour les scénarios les plus complexes. De plus, les utilisateurs peuvent définir des délais, modifier des mots-clés ou variables de champs, régler la limitation du réseau, et bien plus encore. Pour en savoir plus sur la modification de scripts avec EveryStep Web Recorder, consultez notre base de connaissances.
Pour exécuter des tests de charge sur des pages web, les équipes peuvent utiliser l’option Page Web dans LoadView, qui lance le processus de test des pages web avec utilisateurs concurrents.
De plus, la plateforme LoadView permet aux équipes de développement de tester la charge des API et des médias en streaming. Pour plus d’informations sur les API et les pages de médias en streaming, consultez notre page Produits.
Charges virtuelles géo-distribuées
Comme vous le savez probablement déjà, la latence réseau a un impact énorme sur les sites web. Pendant nos tests de résistance, nous ne devons pas négliger la distribution géographique des utilisateurs concurrents, afin de simuler le même comportement que celui observé en environnement de production, ainsi que de vérifier les temps de réponse pour des utilisateurs situés loin de votre centre de données. Considérez une page web qui télécharge 2 Mo de contenu lors d’un rafraîchissement et 10 ms pour chaque requête en back-end. Le temps de chargement dans votre centre de données sera inférieur à cinq secondes grâce à la proximité et à la faible latence.
Dans certaines régions à l’étranger, comme l’Asie, avec une latence de 200 ms, les temps de réponse de ce site seront de cinq secondes pour le back-end, et plus de 200 ms pour le transfert réseau. Nous ne devons pas commettre l’erreur de mesurer les temps de réponse uniquement au sein de notre centre de données. Nous pouvons utiliser LoadView ici, qui propose un large éventail de machines d’injection de charge dans le monde. Parmi toutes ces options, nous pouvons sélectionner celles qui représentent les emplacements habituels de nos clients.
Période de montée en charge entre échelons
Habituellement, nos sites web ont des utilisateurs concurrents répartis de façon dispersée à différents moments de la journée, avec quelques heures de pointe durant lesquelles le trafic est maximal. Nous devons utiliser la même approche pour faire monter en charge et tester nos applications en stress avec la même stratégie de montée en charge. LoadView vous permet de définir votre montée en charge, les temps de maintien et le rythme de remise à l’échelle.
Durée du test de charge
La durée du test est un facteur très important lors d’un test de charge, car elle doit fournir assez de temps à l’application pour produire des résultats réalistes avec des détails comme le temps de réponse, le débit, et si un mécanisme de cache est présent dans l’application, qu’il s’active durant notre période de montée en charge. Pour décider de la durée du test, nous devons nous référer à notre scénario et à nos besoins. Nous pouvons envisager les cas suivants lors du choix de la durée du test :
- Nous devons nous assurer que chaque requête/étape du test soit exécutée au moins 10 fois. Nous devrions garder une durée de test plus élevée pour les scénarios longs comparativement aux plus courts.
- Nous devrons aussi décider du type de test de charge que nous prévoyons d’exécuter, car il pourrait être nécessaire de définir une durée plus longue si nous devons vérifier la stabilité et les caractéristiques de performance de l’application sur une période prolongée.
- Gardez toujours quelques minutes supplémentaires en réserve pour le « réchauffement » de l’application comme mentionné plus haut.
Conclusion : Comment simuler correctement le trafic sur des sites ou applications web
Comme vous pouvez le constater, de nombreux facteurs doivent être pris en compte avant de configurer et d’exécuter vos tests de charge. Assurer que vos applications et sites web fonctionnent parfaitement pour vos clients est crucial pour le succès de votre entreprise. La plateforme LoadView a été conçue pour vous guider rapidement et facilement à travers le processus étape par étape de configuration de vos tests. La plateforme peut mettre en place des scénarios réalistes et aider à mesurer la performance depuis plusieurs emplacements.
Inscrivez-vous pour l’essai gratuit de LoadView et recevez des tests de charge gratuits pour commencer, ou inscrivez-vous pour une démonstration de LoadView. Un de nos ingénieurs performance vous accompagnera dans toute la solution et répondra à toutes vos questions sur la plateforme ou le processus de test de charge.