WooCommerce : préparer l’infrastructure aux pics de trafic et campagnes

Table des matières :

1. Cartographier un pic WooCommerce (avant de “scaler au pif”)
2. La pile “edge → app → data” qui survit au Black Friday
3. Cache WooCommerce sans casser panier, checkout et SEO
4. Base MySQL/MariaDB : le vrai goulet d’étranglement (et comment le déboucher)
5. Autoscaling, conteneurs et déploiements sûrs pendant les campagnes
6. Observabilité, SLO et alerting : détecter la catastrophe avant Twitter
7. Sécurité et anti-fraude en période de campagne (bots, DDoS, paiement)
8. Runbook “J-30 à J+1” : tests de charge, FinOps et plan de retour arrière

Quand une campagne marketing WooCommerce “explose”, ce n’est pas le marketing qui casse. C’est votre infrastructure qui révèle, avec une délicatesse toute relative, tout ce qui était déjà fragile : base MySQL sous-dimensionnée, cache bricolé, workers PHP-FPM à la diète, plugins qui font des SELECT comme on respire, et un WAF absent parce que “on verra plus tard”.

Préparer l’infrastructure aux pics de trafic et campagnes sur WooCommerce, ce n’est pas “mettre plus de CPU”. C’est savoir où se situe la contrainte (CPU, I/O, DB locks, réseau, tiers de paiement, API shipping…), quels parcours doivent rester fluides (PDP → panier → checkout), et quelle marge vous acceptez avant la chute libre.

Ce guide s’adresse aux gens qui savent déjà ce qu’est un reverse proxy, qui ont déjà vu une table wp_postmeta de 40 Go, et qui aimeraient que le prochain Black Friday ne se transforme pas en atelier post-mortem improvisé.

Avant d’attaquer, posez un principe simple : pendant une campagne, vous ne cherchez pas “la perf max”, vous cherchez la perf prévisible. Autrement dit : un site un peu moins rapide mais stable (et monitoré) convertit souvent mieux qu’un site parfois très rapide… et parfois KO.

Cartographier un pic WooCommerce (avant de “scaler au pif”)

Un pic de trafic WooCommerce se décrit mieux avec des métriques qu’avec des émotions. Les trois variables de base : concurrency (sessions simultanées), RPS (requêtes par seconde) et latence (p95/p99, pas “la moyenne qui rassure”). Sur WooCommerce, la même page peut coûter 20 ms (cache) ou 800 ms (cache raté + requêtes meta + appels externes). Sans modèle de charge, vous ne “préparez” rien : vous jouez au loto avec votre chiffre d’affaires.

Un point qui évite beaucoup d’illusions : concurrency ≠ users/jour. Une campagne peut faire “seulement” 100 000 visites sur la journée… et quand même provoquer un mur à 18h si 15% arrivent en 5 minutes. En pratique, vous voulez estimer (même grossièrement) :

• la montée (combien de temps pour passer de 1× à 5× le trafic normal),
• le plateau (durée à haut trafic),
• la pointe (le vrai maximum de sessions simultanées),
• le mix de pages (catégories vs recherche vs checkout).

Astuce simple mais efficace : prenez vos logs NGINX/HAProxy (ou votre observabilité) et calculez le RPS par endpoint (pas seulement par page “vue”). Sur WooCommerce, certains endpoints “invisibles” comptent énormément : /?wc-ajax=..., admin-ajax.php, webhooks paiement, endpoints de recherche, etc. Si vous ignorez ces routes, vous sous-estimez le trafic réel côté PHP/DB.

Ensuite, segmentez le trafic de campagne : SEO (plutôt stable), ads (spiky), newsletter (spike brutal), influence (spike + bots), comparateurs (spike + patterns bizarres). Ce point est crucial, parce que l’infra n’a pas la même réponse selon le profil : une newsletter à 14:00 va envoyer 30k sessions en 3 minutes, alors qu’une montée SEO est progressive. Le résultat, si vous ne distinguez pas : vous dimensionnez trop cher… ou trop tard.

Voici une façon pragmatique de cartographier les sources (à adapter à votre contexte) :

Source	Forme du trafic	Risque technique typique	Signal à surveiller
Newsletter / push	Pointe très abrupte	saturation PHP-FPM + DB (trop de requêtes “non cache”)	queue PHP-FPM, Threads_running, 502
Ads (Meta/Google)	Pics + variations	pages d’atterrissage pas assez cacheables	hit ratio cache, TTFB p95
Influence / live	Pic + bots/scrapers	WAF/rate limit insuffisant, scraping fiches produit	429/403, bande passante, IPs répétitives
Comparateurs	Pattern “robotique”	explosion des pages catégorie + filtres	latence DB + slow queries
SEO	Montée progressive	accumulation de dettes (cache froid, indexation)	tendances p95/p99 sur 24–72h

Dernière étape : définir les parcours critiques et leur budget de latence. Exemple réaliste (B2C, 20k SKU) : on accepte que les pages catégorie soient servies en 150 ms p95 (cache), la PDP en 250 ms p95, mais le checkout doit rester < 600 ms p95 hors latence PSP (Stripe/Adyen/etc.). Ce budget doit aussi intégrer le front (Core Web Vitals), parce que un serveur rapide qui renvoie 2 Mo de JS reste une expérience lente. Côté repères, les seuils Core Web Vitals (LCP, INP, CLS) sont expliqués par Google sur web.dev : Core Web Vitals (web.dev).

• Cache froid : si votre CDN/Varnish n’a rien en cache au début (nouvelle campagne, nouveaux URLs, purge), le pic est plus violent. Prévoyez un “warm-up” ciblé (top pages + top catégories + top PDP).
• Tiers externes : shipping, tax, paiement, avis, anti-fraude, recommandations. En campagne, le maillon faible est souvent hors de votre infra. Le modèle de charge doit intégrer la latence et les timeouts de ces API (et une stratégie de repli).

La pile “edge → app → data” qui survit au Black Friday

La recette robuste, c’est une architecture en couches : CDN/WAF en edge, reverse proxy / load balancer au milieu, app PHP derrière, et data stores (DB, cache objet, files) isolés. Concrètement, vous voulez absorber 80–95% des requêtes en edge (assets, pages cacheables), limiter les connexions entrantes, et n’exposer à PHP que ce qui doit réellement exécuter du code.

En edge, quelques points “peu glamour” mais très rentables :

• activer la compression (Brotli/Gzip selon support),
• limiter les méthodes HTTP (souvent GET/HEAD/POST suffisent),
• poser des limites sur le body size des requêtes (upload, abuse),
• utiliser un WAF et du rate limiting avant d’atteindre l’app.

Côté reverse proxy, NGINX et HAProxy restent les couteaux suisses les plus rentables. NGINX est excellent pour le HTTP moderne, le TLS et le serving statique (voir : NGINX : maîtriser HTTP/2, HTTP/3 QUIC et TLS 1.3). HAProxy brille en load balancing, health-checks agressifs, et rate limiting au plus près du trafic (voir : HAProxy : déployer un reverse proxy et load balancer sécurisé). Les deux ensemble ne sont pas “redondants”, ils sont complémentaires.

Mini-scenario typique (qui évite de “sur-investir” trop tôt) :

• 1 CDN/WAF devant tout (assets + cache + filtrage),
• 2 reverse proxies (HA) pour lisser les connexions et faire le routage,
• 2 à 4 nœuds applicatifs PHP-FPM (stateless autant que possible),
• 1 DB principale + réplica(s) si besoin (lecture / reporting),
• 1 Redis (object cache + éventuellement files légères selon design).

Au niveau applicatif, votre triptyque est : PHP-FPM, OPcache, et une politique stricte de ressources. Un “fix” classique avant campagne : augmenter pm.max_children… puis découvrir que MySQL s’effondre parce que vous venez de multiplier les connexions concurrentes. Préférez un dimensionnement par capacité : CPU pour PHP, mémoire pour OPcache + buffers, et surtout limitation des spikes (queue, backpressure, 429) plutôt que laisser la plateforme s’autodétruire par enthousiasme.

• Si MySQL est à genoux, plus de PHP n’aide pas : vous augmentez juste la pression (et donc les locks et les timeouts).
• La file d’attente “contrôlée” vaut mieux que la panne “aléatoire” : un 429/503 bien géré (avec retry-after) est souvent moins destructeur qu’un effondrement en cascade qui tue le checkout.

Cache WooCommerce sans casser panier, checkout et SEO

Le cache sur WooCommerce, c’est l’art de servir vite sans servir faux. Les pages publiques (home, catégories, PDP) sont cacheables si vous gérez correctement les cookies et la variation (devise, langue, segmentation). Les pages sensibles (panier, checkout, compte) doivent être bypass cache, sinon vous offrez aux clients une expérience “surprise” (et à la CNIL un hobby).

Dans WooCommerce, quelques éléments demandent une attention particulière :

• les cookies de session WooCommerce (qui rendent la réponse “personnalisée”),
• les fragments de panier (souvent via AJAX),
• la géolocalisation (taxes, shipping, devise) si activée,
• les promos dynamiques (règles panier, prix variables).

Une approche solide : CDN pour les assets et le micro-cache, puis cache HTTP type Varnish pour le full-page cache. Varnish reste l’un des meilleurs rapports performance/contrôle sur WordPress/WooCommerce (voir : Varnish Cache : optimiser le cache HTTP et réduire la charge serveur). Exemple de logique simple (conceptuelle) : bypass dès qu’un cookie WooCommerce de session est présent, ou dès qu’on touche /cart/, /checkout/, /my-account/.

Ajoutez aussi au périmètre des bypass ce qui suit (selon votre implémentation) : wp-login.php, xmlrpc.php, wp-admin/, admin-ajax.php, et les endpoints wc-ajax. Le but n’est pas de “tout passer”, mais d’éviter les bugs d’état (panier) et les fuites de personnalisation.

sub vcl_recv {
  if (req.url ~ "^/(cart|checkout|my-account)" ) { return (pass); }
  if (req.http.Cookie ~ "woocommerce_items_in_cart|wp_woocommerce_session" ) { return (pass); }
}

Checklist rapide pour valider que votre cache est “safe” (utile avant campagne) :

• un utilisateur A ne voit jamais le panier / le compte de B ;
• les pages cacheables ont des en-têtes cohérents (Cache-Control, Vary) ;
• les variantes (langue/devise) ne se mélangent pas ;
• un cache purge (ou une mise à jour de stock/prix) se propage dans un délai acceptable ;
• le crawler Googlebot reçoit une page stable (pas un HTML incomplet).

Enfin, attention aux “optimisations” qui sabotent le SEO et la qualité : cache qui sert une page partiellement vide, edges qui servent une erreur 200 avec du HTML bancal, ou variantes non maîtrisées qui génèrent des duplications. Si vous avez déjà eu des pages qui se retrouvent indexées sans contenu (oui, ça arrive), gardez sous le coude : HTML vide : identifier les causes et impacts SEO d’une page sans contenu. Un cache agressif sans observabilité, c’est juste un bug qui répond plus vite.

Base MySQL/MariaDB : le vrai goulet d’étranglement (et comment le déboucher)

Sur WooCommerce, la base est souvent le point de rupture numéro 1. Historiquement, beaucoup de données vivent dans des tables génériques (wp_posts, wp_postmeta) et le meta storage adore les requêtes peu sélectives. Les pics de trafic transforment alors des requêtes “pas très jolies” en un festival de verrous, de buffer pool saturé, et de Threads_running qui grimpe comme votre tension.

La préparation sérieuse commence par un diagnostic : slow_query_log, analyse des top queries, et vérification des index sur les filtres réellement utilisés (ex : meta_key, post_type, colonnes Woo). Puis, tuning InnoDB : innodb_buffer_pool_size dimensionné (souvent 60–75% de la RAM sur serveur dédié DB), innodb_log_file_size cohérent avec le write load, et surtout un contrôle des connexions (ProxySQL, max connections réalistes, timeouts). Pour un rappel très orienté WordPress/MySQL : Optimisation base de données WordPress : diagnostic et réparation MySQL.

Deux commandes “sanity check” (pendant un test de charge ou une répétition) qui donnent vite la température :

SHOW GLOBAL STATUS LIKE 'Threads_running';
SHOW FULL PROCESSLIST;

Si Threads_running grimpe et que PROCESSLIST montre des requêtes qui s’empilent sur les mêmes tables/indices, vous êtes typiquement dans un mix : requêtes non indexées + concurrence trop élevée + cache insuffisant.

Ajoutez un object cache (Redis/Memcached) pour réduire la pression DB sur les options, transients, sessions, fragments Woo. Sans object cache, vous payez la DB pour des lectures répétitives que la RAM sait faire les yeux fermés. Et si vous êtes sur une infra distribuée : pensez cohérence (cache invalidation) et TTL. Oui, c’est pénible. Oui, c’est moins pénible qu’un checkout qui time-out.

Enfin, si votre boutique a un volume de commandes significatif, regardez sérieusement du côté des évolutions WooCommerce visant à réduire la dépendance à wp_posts/wp_postmeta pour les commandes (selon version, compatibilités et plugins). L’idée n’est pas de “migrer pour migrer”, mais de diminuer le coût DB des opérations critiques (création commande, mise à jour statut, consultation). Comme toujours : test en préprod isomorphe, mesure avant/après, et plan de retour arrière.

Autoscaling, conteneurs et déploiements sûrs pendant les campagnes

Le scaling horizontal WooCommerce est possible, mais pas “gratuit”. Vous pouvez multiplier les pods PHP… à condition que l’état soit externalisé : sessions, cache, fichiers (uploads), cron, jobs, etc. Si vous scalez des instances qui écrivent localement, vous venez d’inventer un système distribué involontaire. Et comme tout système distribué involontaire, il vous déteste.

Points souvent oubliés sur WordPress/WooCommerce quand on “containerise” :

• WP-Cron / Action Scheduler : si plusieurs pods déclenchent des jobs en double, vous créez des effets de bord (emails, stocks, webhooks). Il faut une stratégie (cron externalisé, verrouillage, ou worker dédié).
• Uploads : local = non partagé ; il faut du partagé (RWX) ou un stockage objet.
• Sessions : si vous faites du sticky session au load balancer, vous perdez une partie des gains (et vous compliquez la résilience). Mieux : externaliser (Redis) quand c’est applicable.
• Cache : un cache local par pod peut être utile (OPcache), mais pour l’object cache vous voulez un store commun.

Sur Kubernetes, l’énorme piège est le stockage : ReadWriteOnce vs ReadWriteMany, latence des volumes, contention, et sauvegardes. Pour une vue très pratico-pratique des choix (Ceph, Longhorn, CSI, RWX), voir : Stockage distribué Kubernetes : PVC/CSI, RWO-RWX, Ceph et Longhorn. Dans beaucoup de cas, la meilleure stratégie consiste à sortir les médias vers un object storage (S3-compatible) + CDN, et garder vos pods applicatifs réellement stateless.

Déploiements en période de campagne : canary, blue/green, feature flags, et rollback automatisé. Un pipeline CI/CD qui pousse “en prod” comme en 2012 est une manière élégante de transformer une promo en incident majeur. Si vous êtes dans une logique GitOps, cet article est un bon point de départ : Pipeline CI/CD Kubernetes : GitHub Actions et Argo CD étape par étape. Et oui : geler les releases pendant les heures chaudes, ce n’est pas être lâche, c’est être adulte.

Ajoutez une règle opérationnelle : si un déploiement augmente la latence p95 de 20% ou fait monter les 5xx, rollback automatique. Vous ne débattez pas en war room : vous revenez à l’état stable, puis vous analysez.

Observabilité, SLO et alerting : détecter la catastrophe avant Twitter

Sans observabilité, “préparer l’infrastructure” revient à installer des airbags sans tableau de bord. Vous voulez des métriques edge (cache hit ratio, 4xx/5xx, latence TLS), app (PHP-FPM queue, opcache hit rate), et data (MySQL p95, locks, buffer pool, replication lag). Prometheus reste un standard efficace, avec Alertmanager et Grafana pour sortir du mode “je regarde les logs quand ça brûle” : Prometheus : architecture monitoring, PromQL, Alertmanager et Grafana.

Les SLO (Service Level Objectives) vous évitent de confondre “ça marche chez moi” et “ça marche pour 99% des clients”. Exemples WooCommerce (à calibrer sur votre historique) :

• taux de succès checkout ≥ 99,5% sur 30 min (hors abandons volontaires),
• latence p95 serveur PDP ≤ 300 ms (pages cacheables),
• erreurs 5xx < 0,2%,
• webhooks paiement : taux d’échec < 0,1% (sinon divergence commande/paiement).

Tableau utile pour garder l’alerting orienté “impact boutique” :

SLI (ce que vous mesurez)	Pourquoi c’est critique	Exemple de symptôme	Où regarder
Succès checkout	chiffre d’affaires direct	erreurs 502/timeout au paiement	logs app + PSP + 5xx
Add-to-cart réussi	conversion	endpoints wc-ajax en erreur	reverse proxy + PHP
Hit ratio cache	capacité infra	DB saturée alors que pages publiques	CDN/Varnish
Latence DB p95	stabilité	montée de Threads_running	MySQL + APM
Taux 429/403	anti-bot	trop strict (perte clients) ou trop laxiste (scraping)	WAF + analytics

Pour aller plus loin que les métriques, instrumentez en traces et logs corrélés (APM). OpenTelemetry est aujourd’hui une approche standard pour unifier métriques/traces/logs via des exports compatibles selon vos outils, sans vous enfermer trop vite dans un agent propriétaire.

Et côté expérience réelle, le RUM est souvent ce qui révèle les régressions front liées aux campagnes (scripts marketing, tags, A/B tests) : Real User Monitoring : RUM vs monitoring synthétique pour la performance web.

Note “terrain” (souvent oubliée en Europe/France) : la collecte de logs et de métriques en campagne explose (plus de trafic = plus d’événements). Prévoyez volumétrie, rétention, et filtrage (sampling, masquage) pour éviter à la fois la facture surprise… et la capture inutile de données sensibles (ex. paramètres d’URL contenant des identifiants). Ce n’est pas un conseil juridique, juste de l’hygiène opérationnelle.

Sécurité et anti-fraude en période de campagne (bots, DDoS, paiement)

Un pic de trafic attire aussi son lot de “fans” : scrapers, credential stuffing, bots d’achat, et DDoS opportunistes. Le minimum vital : WAF + rate limiting + règles spécifiques sur endpoints sensibles (login, API, recherche, add-to-cart). Cloudflare Custom Rules est un bon exemple d’approche pragmatique : Cloudflare Custom Rules : créer et gérer des règles WAF personnalisées.

Endpoints typiquement à protéger (sans casser l’expérience) :

• wp-login.php et wp-json (selon exposition),
• xmlrpc.php (souvent inutile en e-commerce moderne : à restreindre si possible),
• /?s=... (recherche) si elle tape fort la DB,
• /?wc-ajax=add_to_cart, get_refreshed_fragments, etc.,
• formulaires de coupon/checkout (anti-bruteforce et anti-fraude).

Ne sous-estimez pas la résilience DDoS : même une boutique “moyenne” peut se faire saturer le jour où elle devient visible (et c’est souvent le jour de la campagne, comme par hasard). Si vous devez benchmarker des solutions, vous avez un comparatif récent : Protection DDoS cloud 2026 : comparatif des 12 meilleures solutions. Le but n’est pas d’être parano, c’est d’éviter qu’un attaquant transforme votre budget ads en don caritatif.

Enfin, le checkout, c’est aussi un endroit où la fraude prospère : tentatives massives, cartes volées, identités synthétiques, et automation. En Europe, vous devez aussi composer avec l’authentification forte (SCA / 3DS2) selon les cas : la latence et les échecs ne sont pas “que techniques”, ils sont aussi liés au parcours et au scoring du PSP. Ce n’est pas qu’un sujet PSP, c’est un sujet produit + sécurité : friction adaptative, règles anti-bot, et authentification forte quand nécessaire. Pour un panorama utile côté e-commerce : Fraude aux paiements 2026 : menaces IA, deepfakes et identités synthétiques. Et si vos comptes clients sont une cible, les passkeys réduisent drastiquement le phishing et le credential stuffing : Passkeys e-commerce : réduire la friction de connexion et limiter le phishing.

Une nuance importante : trop de sécurité “front” (captcha partout, règles trop strictes) peut faire baisser la conversion. Le bon compromis est souvent : filtrer fort sur les endpoints à risque, laisser respirer les pages publiques cacheables, et basculer vers de la friction seulement quand les signaux (IP, ASN, vitesse, répétition, empreinte navigateur) deviennent suspects.

Runbook “J-30 à J+1” : tests de charge, FinOps et plan de retour arrière

À J-30, on sort du storytelling et on fait un test de charge. k6, Gatling, Locust… peu importe, tant que vous simulez des parcours réalistes : navigation catégorie, filtres, recherche, PDP, add-to-cart, checkout (avec sandbox PSP), et appels externes (shipping/tax). Faites-le sur une préprod isomorphe (mêmes versions, mêmes caches, taille de DB comparable). Sinon, vous mesurez une maquette, pas votre boutique.

Un test de charge utile n’est pas “un gros GET sur la home”. Il doit inclure :

• un ratio réaliste de cache hit/miss (sinon vous sous-estimez la DB),
• des utilisateurs connectés et non connectés (si votre business l’implique),
• des paniers avec variations (taille/attributs), pas un seul SKU,
• des coupons/promos si utilisés (souvent coûteux côté calcul/règles),
• des timeouts réalistes sur les API externes (sinon vous vous mentez).

À J-14, vous finalisez la capacité et le budget. Les campagnes “réussies” coûtent plus cher en infra : plus de bande passante, plus de cache, plus de logs, plus d’anti-DDoS. La question n’est pas “comment payer le moins possible”, c’est “comment payer le juste prix pour éviter l’indisponibilité”. Pour cadrer ça proprement (budgets, alertes de dépassement, allocation coûts), relisez : FinOps : optimiser les coûts cloud avec reporting et budgétisation.

À J-7, verrouillez ce qui doit l’être :

• versions plugins/thème (gel fonctionnel si possible),
• stratégie de purge cache (qui peut purger, quand, comment),
• seuils d’alerte (ajustés au trafic “campagne”, pas “hors campagne”),
• plan de communication interne (qui décide quoi, qui exécute quoi).

À J-1 et J, vous déroulez un runbook sans improvisation : TTL DNS réduit (ex. 300 s si cela fait sens chez vous), cache warm (pages top trafic), monitoring en war room, seuils d’alerte revus, et surtout un plan de retour arrière. Exemple concret : si la recherche explose la DB, on bascule temporairement vers une recherche simplifiée ; si un plugin marketing surcharge, on le désactive via feature flag ; si le checkout devient instable, on active une page de dégradation contrôlée plutôt que laisser les clients face à des 502.

Voici une liste de “dégradations contrôlées” typiques en e-commerce (à préparer à l’avance, pas à inventer pendant l’incident) :

• désactiver recommandations/avis externes si timeouts,
• limiter ou simplifier les filtres (facettes) si ça tue MySQL,
• désactiver le calcul de frais de port temps réel et afficher une estimation,
• réduire la fréquence de rafraîchissement panier/fragments,
• mettre en pause certaines intégrations marketing non essentielles.

Et si vous n’avez ni hébergement taillé e-commerce ni équipe pour l’opérer, il existe des solutions dédiées : Hébergement spécial e-Commerce et, pour les environnements vraiment sensibles, Hébergement d’infrastructures THD (Très Haute Disponibilité). En cas d’incident sécurité pendant la campagne (ça arrive), le bouton “panique” existe : Urgence cybersécurité.

Et après J+1 ? Post-mortem sans langue de bois : top pages, cache hit ratio, p95/p99, erreurs, coût infra, et actions backlog. Un format simple qui marche bien :

• Ce qui s’est passé (timeline factuelle)
• Impact (conversion, CA, erreurs checkout, latence)
• Causes (techniques et organisationnelles)
• Ce qu’on garde (ce qui a bien marché)
• Actions (priorisées, avec owner et date)

L’objectif n’est pas de “tenir une fois”, c’est de rendre le prochain pic boring. La stabilité, c’est quand votre équipe marketing s’excite… et que votre infra s’en fiche.