Le pic est une date, la préparation aussi
Le Black Friday tombe le lendemain de Thanksgiving, que le droit fédéral américain fixe au quatrième jeudi de novembre. En 2026, cela donne le jeudi 26 novembre pour Thanksgiving, le vendredi 27 novembre pour le Black Friday et le lundi 30 novembre pour le Cyber Monday. Ces dates sont calculées à partir de cette règle : recoupez-les avec le calendrier commercial de votre marché, qui peut avancer ou prolonger ses propres opérations.
Il reste quatre semaines à la date de cet article. C'est assez pour geler, mesurer et corriger, pas assez pour tout reconstruire. L'enjeu n'est donc pas d'avoir le plus gros serveur possible, mais de connaître la limite du vôtre avant que le trafic la trouve à votre place, puis de décider à l'avance ce que vous faites si elle est atteinte.
Ce qui fait tomber une boutique pendant le pic
- Un cache qui ne sert que les visiteurs anonymes — dès qu'un cookie de panier ou de session est présent, la page est recalculée par PHP et la base de données à chaque requête.
- Des requêtes SQL tolérables à faible trafic — une requête lente ne gêne personne à cinq visiteurs. À deux cents visiteurs simultanés, elle occupe des connexions et fait attendre toutes les suivantes.
- Trop de processus PHP pour la mémoire disponible — chaque processus consomme de la RAM.
- Un changement de dernière minute — une extension, un thème ou un code promo mal configuré poussé la veille. C'est la cause la plus évitable, et le gel la supprime.
- Un service tiers appelé à chaque page vue — module de livraison, d'avis ou de fidélité interrogé de façon synchrone. S'il ralentit, la boutique ralentit avec lui, sans que votre serveur soit en cause.
- Aucune consigne écrite — personne ne sait qui décide de désactiver une fonction, à quel seuil, ni qui prévient le client. On improvise pendant la panne, ce qui allonge la panne.
Geler les changements : quatre semaines, une date de coupure
Le gel est la mesure la moins coûteuse et la plus efficace : tant que le code et la configuration ne bougent pas, ce que vous avez mesuré reste vrai. Choisissez une date de coupure, par exemple le vendredi 20 novembre, une semaine avant le pic. Après elle, plus de mise à jour du CMS, plus de nouvelle extension, plus de changement de thème. Seules passent les corrections de bugs critiques, testées sur la copie puis notées dans un journal.
Le gel ne couvre pas les mises à jour automatiques : désactivez-les pour la période. Le tableau ci-dessous se rejoue chaque année en décalant les dates.
Prenez une sauvegarde complète juste avant le gel (fichiers, base de données, configuration du serveur), puis restaurez-la une fois sur la copie en chronométrant l'opération : cette durée est une donnée du plan de repli. La différence entre instantané et sauvegarde est expliquée dans snapshot ou sauvegarde de VPS.
Calendrier de préparation à rejouer chaque année
Faites défiler le tableau
| Période | Ce qui se fait | Preuve attendue |
|---|---|---|
| D'ici au 6 novembre | Inventaire : version du CMS, extensions, services tiers, tâches planifiées, plan d'hébergement | Un tableau daté, avec une personne responsable par ligne |
| Du 9 au 13 novembre | Copie de la boutique et test de charge de référence | Résultat conservé avec la commande exacte et le scénario |
| Du 16 au 19 novembre | Réglages de cache, de base de données et de PHP, puis nouveau test | Même scénario, mêmes paramètres, résultats comparés |
| Vendredi 20 novembre | Gel des changements, sauvegarde complète | Restauration testée, pas seulement la sauvegarde prise |
| Du 21 au 26 novembre | Corrections critiques uniquement, après essai sur la copie | Journal des changements tenu à jour |
| Du 27 au 30 novembre | Surveillance du pic, plan de repli prêt à l'emploi | Alertes actives et une personne d'astreinte nommée |
Mesurer sur une copie avec k6 et ab
Préparer une copie de la boutique
Ne testez jamais la boutique en ligne : un test de charge peut la faire tomber, polluer vos statistiques et créer de fausses commandes. Restaurez une sauvegarde sur un VPS ou un hébergement de test de même famille que la production, avec la même version de PHP et la même base. Anonymisez les clients, coupez l'envoi d'e-mails et mettez les modules de paiement en mode test.
Écrire le scénario avant l'outil
Listez le parcours d'un acheteur : page d'accueil, page de catégorie, page produit, ajout au panier, page panier, puis début du tunnel de commande. Décidez de la part de chaque étape, par exemple beaucoup de pages produit et peu de paiements. Un scénario limité à la page d'accueil mesure le cache, pas la boutique.
Installer k6
k6 est l'outil de test de charge open source de Grafana, un binaire unique. Suivez l'installation décrite dans la documentation officielle de k6 sur la machine qui émet la charge, jamais sur le serveur testé, puis vérifiez avec
k6 version.Écrire le script sur un modèle de montée progressive
Dans un fichier
charge.js, importezhttpdepuisk6/httpetcheckdepuisk6. Déclarez un scénario avecexecutor: 'ramping-arrival-rate'(documentation de k6) : il fixe un nombre d'itérations par seconde, indépendamment de la vitesse de réponse du site, ce qui ressemble davantage à une arrivée de visiteurs qu'un nombre fixe d'utilisateurs virtuels. RenseignezstartRate,timeUnit,preAllocatedVUs,maxVUset desstagesqui montent par paliers. Dans la fonction par défaut, enchaînezhttp.getsur la page produit puishttp.postsur l'ajout au panier, avec unchecksur le code 200.Fixer des seuils qui font échouer le test
Ajoutez
thresholdsaux options :http_req_failed: ['rate<0.01']ethttp_req_duration: ['p(95)<800']. Les valeurs sont les vôtres, à décider selon ce que vos clients tolèrent, pas selon un chiffre recopié. Si un seuil n'est pas tenu, k6 se termine avec un code de sortie non nul, ce qui rend le test rejouable dans une routine automatique. Notez que lescheckn'ont pas cet effet : seuls les seuils font échouer le test.Lancer le test et observer le serveur en même temps
Exécutez
k6 run -e BASE_URL=https://copie.votre-domaine.com charge.js. Dans une session SSH sur le serveur testé, laissez tournertopouhtop, et surveillezfree -mpour la mémoire et le swap. Relevez à quel palier de la montée les temps de réponse décollent et quelle ressource sature en premier : processeur, mémoire, connexions à la base ou disque.Compléter par un test rapide avec ab
ApacheBench vérifie en une ligne une page précise :
ab -n 500 -c 20 -k https://copie.votre-domaine.com/produit/exemple/. L'option-ndonne le nombre total de requêtes,-cle nombre de requêtes simultanées et-kactive la connexion persistante. La documentation d'Apache précise que l'outil n'implémente pas HTTP/1.x en totalité : réservez-le aux comparaisons avant et après un réglage, pas à la mesure d'une capacité.Rejouer le même test après chaque réglage
Modifiez une seule chose à la fois : cache, nombre de processus PHP, index de base. Relancez exactement la même commande et conservez les résultats dans un fichier daté.
Lire le résultat : le pic, pas la moyenne
Une moyenne de temps de réponse masque ce que vit l'acheteur malchanceux. Lisez le percentile 95, ou le 99 pour les cas les plus lents, et le taux d'erreurs. Une boutique dont la moyenne reste correcte mais dont un acheteur sur vingt attend plusieurs secondes perd des paniers sans que la moyenne l'indique.
Regardez aussi la forme de la courbe. Un temps stable puis une chute brutale signale une limite dure, comme un nombre maximal de connexions à la base ou de processus PHP. Ce test ne dit pas combien de visiteurs réels vous recevrez : il dit à quel rythme d'arrivées votre copie, dans les conditions du test, commence à se dégrader.
Aucun résultat chiffré n'est publié ici, et c'est voulu : un chiffre mesuré sur une machine de test ne dit rien de la vôtre, et le script ci-dessus n'a été exécuté que contre une cible factice pour en valider la syntaxe, ce qui ne prouve aucune capacité. La seule mesure qui compte est celle que vous prendrez sur votre copie.
Symptômes pendant le test et pistes à suivre
Faites défiler le tableau
| Ce que vous observez | Cause probable | Ce qu'il faut mesurer |
|---|---|---|
| Temps de réponse qui monte avec la charge, processeur à son maximum | Trop de pages calculées par PHP au lieu d'être servies par le cache | Taux de pages servies par le cache pour les visiteurs anonymes |
| Mémoire pleine puis usage du swap | Trop de processus PHP pour la RAM disponible | Mémoire par processus PHP et nombre de processus autorisés |
| Erreurs 502 ou 504 par rafales | Processus PHP tous occupés, ou file d'attente saturée | Réglage du pool PHP et temps des requêtes les plus lentes |
| Processeur calme mais temps de réponse élevé | Attente de la base de données ou d'un service tiers | Journal des requêtes lentes, durée des appels externes |
| Erreur « too many connections » | Limite de connexions de la base atteinte | Valeur de `max_connections` et connexions réellement utilisées |
| Pages produit rapides mais panier lent | Le panier contourne le cache, comme il le doit, et pèse sur la base | Requêtes déclenchées par l'ajout au panier |
Cache : ce qui se sert vite, ce qui ne doit jamais l'être
La documentation de WooCommerce est nette : les pages panier, commande et compte client doivent rester dynamiques, car elles affichent des informations propres au client. Excluez-les de tout cache, côté plugin comme côté serveur et réseau de diffusion, et vérifiez les cookies de session et de panier que votre version de WooCommerce utilise. Une page de panier mise en cache par erreur montre le panier d'un autre acheteur, ce qui est pire qu'une panne.
Pour le reste, cataloguez ce qui peut être servi tel quel : accueil, catégories, fiches produit pour les visiteurs sans cookie. Le détail des chemins à exclure côté réseau de diffusion est traité dans notre guide sur Cloudflare et le cache d'un site client. Sous PrestaShop, la documentation des développeurs recommande d'activer le cache Smarty dans la page Performances, et de ne pas activer la section Cache lorsque MySQL ou MariaDB tourne sur la même machine. Contrôlez ces réglages dans l'administration de votre version, puis rejouez le test après chaque modification.
Base de données et cache d'objets
Activez le journal des requêtes lentes de MariaDB avant le test : SET GLOBAL slow_query_log=1; puis SET GLOBAL long_query_time=1; pour un seuil à une seconde, valeur qui reste à ajuster. Ces réglages à chaud disparaissent au redémarrage ; pour les conserver, placez-les dans la configuration. À partir de MariaDB 10.11, les variables sont renommées avec le préfixe log_slow_, vérifiez donc le nom propre à votre version.
Un cache d'objets comme Redis soulage la base en gardant en mémoire les résultats répétés. Fixez-lui une limite avec maxmemory et choisissez la politique d'éviction avec maxmemory-policy : la documentation de Redis indique que allkeys-lru est un bon choix par défaut quand une partie des clés est lue bien plus souvent que le reste, alors que noeviction renvoie une erreur quand la mémoire est pleine. Surveillez keyspace_hits et keyspace_misses dans INFO stats pendant le test : un taux de réussite bas signale un cache qui ne sert à rien.
Ne chargez que ce qui vous appartient
Pointez le test vers votre copie, jamais vers la passerelle de paiement, un service de livraison ou une API tierce : l'outil les enverrait en surcharge et pourrait vous faire bloquer votre compte. Si votre scénario doit traverser le paiement, utilisez le mode test du prestataire, avec son accord.
Dimensionner : une hypothèse à valider par la mesure
Si le test révèle que la copie sature trop tôt, deux voies existent : corriger le logiciel, ou changer de plan. Si la machine reste le facteur limitant, augmentez la mémoire ou les cœurs par paliers et rejouez le même test après chaque palier, jusqu'à ce que la courbe tienne avec une marge que vous jugez suffisante.
Une recommandation de ressources lue sur un site, y compris celui-ci, reste une hypothèse : seule votre mesure sur votre boutique fait foi. La méthode de lecture de la consommation est détaillée dans dimensionner un VPS pour le site d'un client. Quand une machine ne suffit plus, HAProxy sur un VPS répartit la charge, au prix d'une architecture plus complexe.
Si vous ne faites pas ce test vous-même
Beaucoup de commerçants confient la boutique à une agence ou à un hébergeur. Le test reste nécessaire : il se demande. Réclamez trois choses par écrit avant la date de gel : le résultat daté d'un test de charge sur une copie, avec le scénario et le temps de réponse au percentile 95 lu au pic ; la liste des changements prévus et la date de gel acceptée ; un plan de repli signé, qui nomme la personne autorisée à désactiver des fonctions ou à restaurer la sauvegarde. Un rapport qui ne cite que la moyenne, ou un « tout est prêt » sans résultat, ne répond pas à la demande.
Décidez aussi, avec eux, qui tranche le jour J : le repli coûte des fonctions, donc des ventes, et cette décision revient à l'activité, pas au seul prestataire technique.
Le plan de repli, une ligne par décision
- Qui décide — une personne nommée, avec un suppléant, autorisée à déclencher le repli sans consulter un comité.
- À quel seuil — par exemple un taux d'erreurs ou un temps de réponse que vous avez défini pendant les tests, relevé par la supervision et non à l'œil.
- Action de délestage — désactiver les fonctions non essentielles : recommandations de produits, avis, recherche prédictive, extensions lourdes testées une à une lors de l'essai.
- Deuxième action — activer une page de file d'attente ou de maintenance claire, avec l'heure de retour prévue, plutôt qu'une erreur brute.
- Dernier recours — restaurer la sauvegarde d'avant le gel, avec le temps de restauration mesuré et l'accord de la personne qui décide.
- Qui prévient — le client, l'équipe marketing qui pousse la campagne et votre hébergeur, avec un message déjà rédigé.
Après le pic : garder la mesure pour l'an prochain
Conservez le script, la commande, les résultats et le journal des changements dans un dossier daté. L'an prochain, vous rejouerez le même test sur la nouvelle version de la boutique, et la comparaison vous montrera si les extensions ajoutées dans l'année ont alourdi le parcours.
Pour suivre la disponibilité des boutiques pendant la période, voir le rapport de disponibilité des sites clients.
