Votre boutique en ligne survit aux semaines calmes d'octobre grâce à un plan d'hébergement conçu pour un trafic ordinaire. Le Black Friday ne demande pas la permission avant de multiplier ce trafic par dix ou vingt en une seule heure. Effectuer des tests de montée en charge avant novembre permet de savoir où votre infrastructure flanche : la page de paiement, la base de données, le serveur d'images ou le plan d'hébergement lui-même. Si vous faites l'impasse, vous le découvrirez en direct, devant des clients prêts à payer, le jour même où une page lente coûte le plus cher. Cet article détaille les outils qui fonctionnent réellement, leur coût, l'ordre dans lequel effectuer les tests et les points où les sites WordPress ont tendance à faillir en premier.
Ce que le trafic du Black Friday fait réellement subir à un site
Un mardi normal génère un mince filet de visiteurs qui naviguent, ajoutent un article et s'en vont. Le Black Friday envoie une foule qui atterrit sur les cinq mêmes pages produit quelques minutes après l'envoi de votre e-mail de promotion. Le serveur traite chaque visite comme une nouvelle requête : une interrogation de base de données, un calcul de panier, une écriture de session. Chaque couche de l'infrastructure — le serveur web, PHP, la base de données, la passerelle de paiement — possède une limite.
Lorsque l'affluence dépasse cette limite, les pages ralentissent et le paiement expire. Certains de ces visiteurs partent sans rien acheter, et reviennent rarement essayer plus tard. Les tests de montée en charge permettent de trouver cette limite en octobre, alors qu'il est encore temps de l'augmenter, plutôt qu'en novembre, où la seule option est de regarder le système s'effondrer en temps réel.
Outils de test de montée en charge et leurs coûts réels
Trois outils reviennent systématiquement pour cette tâche : Apache JMeter, k6 et Gatling. JMeter est gratuit et reste la solution par défaut pour de nombreuses équipes d'assurance qualité en entreprise. Cependant, pour bien l'utiliser, il faut un environnement suffisamment proche de la production, des générateurs de charge qui ne soient pas le simple ordinateur portable de quelqu'un, et une facture qui augmente avec le trafic que vous simulez.
k6, le moteur de test de montée en charge de Grafana, résout une partie de ce problème. Le moteur k6 est entièrement open source sous licence AGPL-3.0 et gratuit pour une exécution locale illimitée, vous permettant ainsi de faire tourner autant d'utilisateurs virtuels que vous le souhaitez sur votre propre matériel sans frais. Une seule machine bien équipée peut généralement supporter des dizaines de milliers d'utilisateurs virtuels à elle seule, ce qui couvre la plupart des boutiques indépendantes.
Le coût apparaît dès que vous avez besoin de monter en charge ou d'utiliser des sites de test distribués. Grafana Cloud facture k6 à $0.150 par heure d'utilisateur virtuel au-delà d'un palier gratuit mensuel de 500 heures. Prenons un test modéré : 500 utilisateurs virtuels pendant 30 minutes, effectué deux fois par semaine. Cette session représente 250 heures d'utilisateur virtuel, et le total mensuel est de 2,000 VUh. Faites le calcul : Grafana Cloud k6 Pro revient à environ $244 par mois, le plan Team d'Artillery Cloud facture un forfait fixe de $199 quel que soit l'usage, et le plan Enterprise Team de Gatling équivaut à environ $413 par mois, bien que le plan Team de Gatling ne permette que 5 heures de test par mois.
Si vous passez à l'échelle supérieure pour simuler une répétition réelle du Black Friday, disons 10,000 utilisateurs virtuels pendant deux heures, le prix augmente en conséquence. Grafana Cloud k6 est listé à environ $0.15 par heure-VU sur son offre Pro, ce qui donne environ $3,000 pour 20,000 heures-VU. Cette simple répétition peut coûter plus cher qu'un mois d'hébergement, c'est pourquoi la plupart des boutiques effectuent un test sérieux avant novembre plutôt que chaque semaine.
Que tester en premier et dans quel ordre ?
Commencez par le processus de paiement, pas par la page d'accueil. Une page d'accueil qui se charge lentement agace, mais un paiement qui échoue fait perdre la vente immédiatement ; il mérite donc le premier test. Simulez le parcours exact d'un acheteur : page produit, ajout au panier, formulaire d'adresse, étape de paiement, page de confirmation.
Testez la passerelle de paiement séparément et en mode bac à sable (sandbox) avant de l'intégrer au reste du processus. Les fournisseurs de paiement limitent le débit des appels en bac à sable beaucoup plus sévèrement que le trafic réel. Un test de montée en charge qui inonde le bac à sable peut déclencher cette limite et produire de faux échecs qui n'ont rien à voir avec votre propre serveur. Effectuez le test complet combiné deux à trois semaines avant le Black Friday, pas la semaine même, afin d'avoir le temps de corriger les problèmes identifiés et de relancer le test.
Faites monter la charge simulée rapidement plutôt que progressivement. Le trafic réel du Black Friday arrive par rafales, déclenché par l'envoi d'un e-mail ou une publication sur les réseaux sociaux, et non par une montée lente sur une heure. Un test qui monte en douceur masque justement le mode de défaillance que vous essayez de détecter.
Où les sites WordPress s'effondrent-ils réellement ?
La plupart des défaillances WordPress sont dues à l'une de ces trois limites, et aucune ne se manifeste avant que le pic de trafic n'arrive. PHP-FPM, le gestionnaire de processus qui exécute PHP sur la plupart des plans d'hébergement, limite le nombre de requêtes simultanées qu'il peut traiter. Les hébergements partagés économiques et les petits plans VPS fixent souvent cette limite à quelques unités seulement, ce qui signifie que le dixième visiteur arrivant sur le site à la même seconde devra attendre, ou subira une expiration de délai.
La base de données raconte une histoire similaire. MySQL et MariaDB limitent tous deux le nombre de connexions ouvertes, et une installation WordPress riche en extensions peut saturer cette limite avec un trafic normal, avant même qu'un seul visiteur attiré par une promotion n'arrive. Les extensions de mise en cache et les CDN aident énormément, mais seulement pour les pages qu'ils peuvent mettre en cache. Une bannière de promotion avec un compte à rebours en temps réel, un compteur de stock sur une page produit ou un message personnalisé du type « articles restants » peut forcer une page à revenir en mode non mis en cache, avec une requête complète en base de données au moment exact où le trafic culmine.
Que corriger en priorité et ce qui peut attendre
Réparez le tunnel de paiement en priorité absolue. C'est l'étape où une défaillance coûte directement de l'argent, et c'est aussi là que la plupart des tests de montée en charge révèlent les problèmes en premier. Augmentez ensuite les limites des travailleurs PHP-FPM et des connexions à la base de données, car il s'agit généralement d'une modification de configuration sur une ligne plutôt que d'une migration.
Les éléments dynamiques comme les compteurs de stock en direct et les comptes à rebours peuvent attendre, ou être remplacés par une version mise en cache plus simple pour la période de solde. Un badge « presque épuisé » mis à jour toutes les quelques minutes consomme beaucoup moins de ressources serveur qu'un compteur en temps réel, et les acheteurs remarquent rarement la différence. Effectuez un vrai test de montée en charge en octobre, corrigez les problèmes trouvés, puis relancez le test deux semaines plus tard pour confirmer que la correction tient la route.
