Test de charge : valider son site avant un pic de trafic

Un test de charge de site web simule des centaines ou des milliers de visiteurs simultanés pour vérifier que votre site tient la charge. C'est la seule façon de savoir, avant le jour J, si votre boutique survivra au Black Friday ou si votre serveur tombera au premier passage média. Voici comment mener un test utile, sans se noyer dans les chiffres.

Ce que mesure un test de charge de site web

Un test de charge ne mesure pas l'esthétique de votre site, mais sa solidité. Il répond à trois questions précises :

• Combien d'utilisateurs simultanés le site peut-il servir sans dégrader l'expérience ?
• Quel est le temps de réponse quand la charge monte ?
• À quel moment les erreurs commencent-elles à apparaître ?

L'objectif n'est pas de faire tomber le site pour le plaisir, mais de trouver le point de rupture avant vos visiteurs. Vous découvrez ainsi ce qui plie en premier : le serveur web, la base de données, le cache ou le réseau.

Définir un scénario réaliste

Un test ne vaut que par son scénario. Simuler dix mille requêtes sur la page d'accueil ne sert à rien si vos visiteurs passent l'essentiel de leur temps sur le catalogue ou le panier.

Construisez un scénario qui ressemble à votre trafic réel :

• Reprenez les pages les plus consultées, pas seulement l'accueil.
• Mélangez les profils : visiteur qui lit, client qui cherche, acheteur qui commande.
• Reproduisez la montée en charge : un pic de lancement n'arrive pas d'un coup, il monte en quelques minutes.
• Tenez compte des requêtes authentifiées, plus coûteuses que les pages publiques.

Un scénario réaliste révèle les vrais goulots d'étranglement. Un scénario artificiel vous rassure à tort.

Les outils : k6 et Locust

Deux outils open source dominent le sujet.

k6 est un outil de test de performance développé en Go et scriptable en JavaScript, pensé pour les développeurs. Il est léger, fonctionne en ligne de commande et couvre les tests de pointe (spike), de charge progressive (stress) et d'endurance (soak). Il s'intègre aussi aux pipelines d'intégration continue pour tester automatiquement à chaque mise en production.

Locust est un outil Python où chaque utilisateur simulé est orchestré par une coroutine légère. Il offre une interface web pour lancer et suivre les tests, la distribution de la charge sur plusieurs machines et un mode sans interface pour les scripts d'automatisation.

Les deux font le même métier : injecter du trafic et mesurer la réponse. Le choix dépend surtout des compétences de votre équipe — JavaScript ou Python.

Lire les résultats : temps de réponse et erreurs

Un test de charge produit des montagnes de données. Concentrez-vous sur les deux métriques déterminantes.

Le temps de réponse ne se lit pas en moyenne, mais en percentile. Le 95e percentile (p95) indique le temps sous lequel 95 % des requêtes sont servies : si la moyenne est à 200 ms mais que le p95 est à 3 secondes, une minorité de visiteurs subit des lenteurs critiques — et ce sont souvent eux qui abandonnent leur visite.

Le taux d'erreur est plus parlant encore. Dès que les erreurs (timeouts, 500, connexions refusées) dépassent une fraction de pour cent, vous avez atteint une limite. Un site qui répond vite mais renvoie des erreurs sous charge n'est pas un site qui tient.

Corriger : cache, requêtes, dimensionnement

Le test montre le symptôme ; à vous de traiter la cause. Les corrections reviennent presque toujours aux mêmes leviers :

• Cache : une page servie depuis le cache ne sollicite ni le processeur ni la base. C'est le gain le plus immédiat.
• Requêtes : une requête lente ou non indexée suffit à saturer toute la base. Optimisez les plus coûteuses.
• Dimensionnement : si l'infrastructure est simplement sous-dimensionnée, ajoutez de la mémoire ou des vCPU.

Chez Atlas Hoster, les tests de charge font partie de la méthode haute disponibilité : l'équipe simule votre pic avec k6 ou Locust, puis corrige ce qui plie — cache, requêtes, limites, dimensionnement — avant que vos clients n'arrivent.

Un test de charge ne sert pas qu'à la performance : il valide aussi votre architecture haute disponibilité. Et pour les boutiques, c'est un préalable à toute opération commerciale, comme l'explique notre article sur la vitesse d'une boutique en ligne.

Quand refaire le test

Un test de charge est un instantané, pas un acquis. Refaites-le :

• avant chaque lancement ou opération commerciale majeure ;
• après chaque changement important : nouvelle version, nouveau thème, nouveau plugin ;
• à chaque changement d'hébergement ou de dimensionnement ;
• à intervalles réguliers, même sans changement, pour détecter une dérive de performances.

Pour ne pas oublier, vous pouvez planifier un test léger à intervalles réguliers via une tâche programmée : notre aide sur les tâches cron montre comment faire. Surveillez aussi vos limites de ressources, car l'espace disque et la bande passante figurent parmi les premiers signaux de saturation.

Si votre site doit encaisser un pic soudain et imprévisible, un test préalable est votre meilleure assurance : notre article sur la gestion d'un pic viral explique comment s'y préparer.

Pour un site qui doit tenir la charge avant, pendant et après le pic, découvrez l'offre haute disponibilité d'Atlas Hoster, qui inclut les tests de charge dans sa méthode de travail.

Les pièges à éviter

• Tester depuis la même machine que le site : vous mesurez la latence locale, pas ce que vivent vos visiteurs. Lancez le test depuis l'extérieur.
• Simuler une charge irréaliste : un scénario qui ne ressemble pas à votre trafic réel ne prédit rien.
• Ne regarder que la moyenne : un temps de réponse moyen correct peut masquer des lenteurs graves au 95e percentile.
• Ignorer le taux d'erreur : un site qui répond vite en renvoyant des erreurs est un site qui ne tient pas.
• Conclure après un seul test : la charge, le code et l'hébergement évoluent ; un test isolé n'a qu'une valeur ponctuelle.

Questions fréquentes

Combien d'utilisateurs simulés faut-il pour un test ?

Partez de votre trafic de pointe actuel et visez 1,5 à 2 fois ce niveau pour garder une marge. Pour un lancement inédit, estimez le pic attendu à partir de vos canaux d'acquisition et ajoutez une marge de sécurité.

Un test de charge peut-il faire tomber mon site en production ?

Oui, c'est précisément le risque — c'est pourquoi il vaut mieux tester sur un environnement de préproduction ou de recette identique à la production, plutôt que sur le site qui accueille vos vrais clients.

Quelle différence entre test de charge et test de performance ?

Le test de charge mesure la tenue sous un trafic volumineux et simultané ; le test de performance mesure la vitesse et l'expérience d'un visiteur individuel. Les deux sont complémentaires.