Un test de charge site e-commerce ne consiste pas à lancer un outil qui envoie des requêtes jusqu'à ce que quelque chose casse. Il consiste à reproduire le comportement réel des acheteurs, à monter progressivement jusqu'à une cible chiffrée et à observer ce qui se dégrade en premier. La différence entre les deux approches se mesure le jour du pic.
Fixer une cible chiffrée avant toute chose
Commencez par sortir les statistiques des deux derniers pics de novembre. Trois nombres suffisent : le maximum de sessions simultanées observé, le nombre de commandes passées sur l'heure la plus chargée, et la répartition entre visiteurs mobiles et ordinateurs. Multipliez ensuite par l'ambition commerciale de l'année. Si le marketing prévoit un budget publicitaire doublé, la cible de charge double aussi.
Exemple : une boutique de mobilier qui a atteint 250 sessions simultanées et 40 commandes sur l'heure de pointe l'an dernier vise cette année 500 sessions et 80 commandes. C'est cette valeur, et non un nombre rond arbitraire, qui pilotera les paliers du test.
Construire des scénarios qui ressemblent à vos clients
Un visiteur réel ne fait pas que charger la page d'accueil. Une campagne de test crédible répartit le trafic entre plusieurs parcours :
- arrivée sur une page de catégorie depuis une publicité, puis défilement et filtres ;
- recherche interne avec un mot-clé, souvent la requête la plus coûteuse du site ;
- consultation de deux ou trois fiches produit, avec variantes et stock affiché ;
- ajout au panier, modification de quantité, retrait d'un article ;
- tunnel de commande complet : adresse, choix du transporteur, page de paiement ;
- comptes clients : connexion, consultation de commandes passées.
Pondérez ces parcours selon vos statistiques réelles, en général une majorité de navigation pure et une minorité de commandes. Exécutez les paiements en mode test, les environnements de recette de Stripe et de PayPlug étant prévus pour cela, et neutralisez les appels facturés aux transporteurs pour ne pas générer d'étiquettes Colissimo ou Mondial Relay fantômes.
Les indicateurs à surveiller pendant l'exécution
| Indicateur | Signification | Seuil d'alerte courant |
|---|---|---|
| Temps de réponse au 95e centile | ce que vit le visiteur le moins chanceux | au-delà de 2 secondes sur une fiche produit |
| Taux d'erreurs HTTP | pages blanches et erreurs serveur | au-delà de 0,5 % |
| Charge processeur applicative | saturation du serveur web | au-delà de 80 % soutenu |
| Processus applicatifs occupés | file d'attente qui se forme | plus de 80 % des processus pris |
| Requêtes lentes en base | index manquant ou requête non optimisée | toute requête au-delà de 200 ms |
| Taux de succès du cache | efficacité de la mise en cache | en dessous de 80 % sur les pages listes |
Ces six lignes se lisent ensemble. Un temps de réponse qui grimpe alors que le processeur reste bas signale presque toujours une attente en base de données ou un appel externe lent, pas un manque de puissance.
Testez en montée par paliers de cinq minutes, avec un palier de maintien à la cible pendant vingt minutes. Beaucoup de problèmes, fuites de mémoire et saturation de connexions notamment, n'apparaissent que dans la durée, jamais dans un pic de deux minutes.
Les goulots d'étranglement classiques d'une boutique
Le premier est presque toujours la base de données. Un catalogue de dix mille références avec des filtres combinés produit des requêtes qui passent en développement et s'écroulent à quarante utilisateurs simultanés. Le deuxième est le cache mal configuré : pages panier et compte non mises en cache, ce qui est normal, mais aussi pages de catégorie exclues par erreur à cause d'un paramètre d'URL publicitaire.
Le troisième est le module de trop. Chaque extension ajoutée à PrestaShop, WooCommerce ou Magento consomme des requêtes sur chaque page. Une bannière promotionnelle installée pour l'occasion peut ajouter trois requêtes par affichage, soit plusieurs milliers par minute au pic. Le quatrième est la dépendance externe : service de recommandation, widget d'avis, calcul de frais de port en temps réel. Si l'un ralentit et qu'aucun délai maximal n'a été fixé, il bloque la page entière.
Les outils les plus utilisés pour produire la charge sont k6, Gatling, JMeter et Locust. Le choix importe moins que la qualité des scénarios. La méthode et le dépouillement sont décrits sur la page tests de charge.
Un calendrier sur six semaines
| Semaine | Travaux |
|---|---|
| S-6 | définition de la cible, préparation d'un environnement de recette identique à la production |
| S-5 | écriture des scénarios, jeux de données produits et comptes de test |
| S-4 | premier tir, identification des trois goulots principaux |
| S-3 | corrections : index, cache, délais maximaux sur les appels externes |
| S-2 | second tir à la cible, puis tir de rupture pour connaître le point de bascule |
| S-1 | gel des mises en production, page de repli prête, astreinte organisée |
Le gel de la semaine précédant le pic est la mesure la moins technique et la plus efficace. Aucune mise en production non urgente entre le lundi précédant l'opération et la fin du week-end de ventes.
Après le test : ce qui change en production
Un test ne sert à rien s'il ne produit pas trois décisions. D'abord une configuration cible : nombre de processus applicatifs, taille du cache, paramètres de connexions à la base. Ensuite une supervision adaptée, avec des alertes sur le taux d'erreurs et le temps de réponse plutôt que sur la seule disponibilité. Enfin un plan de dégradation contrôlée : désactiver la recherche interne coûteuse, servir une page de catégorie statique, afficher un message d'attente plutôt qu'une erreur.
Pour une boutique construite ou reprise dans le cadre d'un projet, ces réglages s'intègrent au suivi décrit sur la page boutique en ligne. Les enjeux de saison, stock, transporteurs et places de marché, sont rassemblés sur la page commerce et e-commerce.
Un mot enfin sur les données : un environnement de recette contient souvent une copie de la base de production, donc des données personnelles de clients réels. Anonymisez-les avant de commencer. Le sujet rejoint les exigences de gouvernance évoquées dans l'article sur les entreprises visées par NIS2, et un test de charge mal cadré ne doit pas créer la fuite qu'il était censé prévenir.
Rédaction Apply
Développement web