1. Le cache : vérifier qu’il sert, pas qu’il est installé
Un pic de trafic, c’est surtout des visiteurs anonymes qui regardent les mêmes pages. Si chacune de ces vues exécute PHP et interroge la base, le serveur fait mille fois le même travail. Trois couches comptent :- le cache de page : la page HTML complète, servie aux visiteurs non connectés sans toucher PHP ;
- le cache d’objets : les résultats de requêtes SQL gardés en mémoire, typiquement dans Redis, qui accélèrent ce que le cache de page ne peut pas servir ;
- les exclusions : ce qui ne doit jamais être mis en cache.
woocommerce_cart_hash, woocommerce_items_in_cart et wp_woocommerce_session_. Un panier mis en cache, c’est le panier d’un client affiché à un autre.
Puis vérifiez que le cache de page répond vraiment, en visiteur anonyme :
X-LiteSpeed-Cache: hit à partir de la deuxième requête, et X-LiteSpeed-Cache-Control: no-cache sur les pages volontairement exclues.
Redis comme cache d’objets, sur un VPS
/etc/redis/redis.conf :
keyspace_hits / (keyspace_hits + keyspace_misses). Un taux faible avec beaucoup d’evicted_keys signifie que le plafond est trop bas.
PrestaShop. Dans Paramètres avancés > Performances, laissez le cache Smarty activé, n’utilisez pas la compilation forcée des templates (réservée à l’édition d’un thème), et vérifiez que le mode debug est désactivé. La documentation PrestaShop 8 recommande de tester le site après avoir activé le cache JavaScript du CCC.
Bon résultat : un en-tête de cache hit sur les pages publiques, no-cache sur le panier et la commande, un TTFB nettement plus bas à la deuxième requête qu’à la première.
2. Un test de charge, avant le jour J
Vous ne savez pas combien de visiteurs votre serveur encaisse tant que vous ne l’avez pas mesuré. Le seul bon moment pour le découvrir, c’est avant la vente. k6 est libre, se lance en une commande via Docker, et s’arrête avec un code d’erreur si vos seuils ne sont pas tenus. Lancez-le depuis une autre machine que le serveur testé, sinon vous mesurez votre poste plus que votre site.http_req_waiting est, selon la référence des métriques k6, le temps d’attente du premier octet : le TTFB. Pendant le test, regardez le serveur en parallèle :
3. Un snapshot avant chaque changement, puis le gel
Chaque changement de la semaine (configuration du cache, redimensionnement, dernière mise à jour) commence par un snapshot depuis la console. Il coûte une minute et vous donne un point de retour daté. Pour qu’un snapshot de VPS capture une base de données dans un état cohérent, l’agent QEMU doit tourner : c’est lui qui gèle le système de fichiers pendant la capture.Un snapshot n’est pas une sauvegarde. Il sert à revenir en arrière après un changement raté, pas à survivre à la perte du serveur. C’est le rôle de la section 4.
wp plugin auto-updates status --all --enabled-only pendant la vente.
4. Des sauvegardes restaurées pour de vrai
Une sauvegarde qui n’a jamais été restaurée est une hypothèse. La règle 3-2-1, telle que la formule le guide de l’US-CERT publié par la CISA :- 3 copies de chaque fichier important : l’original et deux sauvegardes ;
- sur 2 supports différents ;
- dont 1 hors site.
Le snapshot n’entre pas dans le décompte : il vit au même endroit que le serveur.
Testez ensuite la restauration de la base, la partie qui casse le plus souvent :
ps_orders.
Bon résultat : les comptes concordent, le site redémarre sur l’environnement de test, et vous savez combien de temps prend une restauration complète. C’est ce chiffre qui vous dit combien de ventes vous perdriez un vendredi soir.
5. Surveiller le TTFB, pas seulement la disponibilité
Une sonde de disponibilité classique se contente d’un code 200. Une boutique qui répond 200 en neuf secondes est en ligne pour la sonde, et fermée pour vos clients. Mesurez le TTFB (temps jusqu’au premier octet). web.dev classe un TTFB de 0,8 s ou moins comme bon, et au-delà de 1,8 s comme mauvais, en précisant que c’est un repère indicatif et non un Core Web Vital. Partez de là, puis ajustez sur vos propres mesures. Surveillez deux adresses : une page en cache, qui mesure le serveur web, et le panier, qui ne l’est jamais et mesure donc PHP et la base. C’est le panier qui ralentit le premier.6. DNS : baisser le TTL 48 h avant toute migration
Le meilleur conseil DNS pour la semaine du Black Friday : ne migrez pas. Si vous devez quand même changer de serveur, préparez la bascule à l’avance. Les résolveurs gardent un enregistrement en cache pendant toute la durée de son TTL. Si votre enregistrementA a un TTL d’un jour, une partie de vos visiteurs continuera d’arriver sur l’ancien serveur jusqu’à un jour après le changement. Baissez donc le TTL avant, puis attendez au moins l’ancienne durée avant de basculer. Quarante-huit heures couvrent les TTL usuels d’un jour avec de la marge.
Lisez le TTL configuré directement sur un serveur qui fait autorité, pas dans le cache de votre résolveur :
dig sur le serveur faisant autorité affiche 300 au moins 48 h avant la bascule.
7. La sécurité sous charge : décidée avant, pas pendant
Le vendredi soir n’est pas le moment de découvrir comment bannir une adresse IP. Tout ce qui suit se pose et se teste maintenant. Extensions à jour avant le gel.rsyslog n’est plus installé par défaut selon les notes de version : il n’y a donc pas de /var/log/auth.log, et la prison sshd doit lire le journal systemd. Les paquets de Debian 13 et d’Ubuntu 24.04 le prévoient déjà, celui de Debian 12 non. L’écrire dans jail.local couvre les trois.
limit_req en détail. Pour wp-login.php :
fastcgi_pass n’est pas optionnel : sans lui, nginx servirait le fichier PHP comme un fichier statique. fail2ban fournit ensuite un filtre nginx-limit-req, qui lit le journal d’erreurs de nginx et bannit les adresses qui dépassent la limite de façon répétée :
backend = auto n’est pas décoratif : Ubuntu 24.04 règle toutes les prisons sur le journal systemd par défaut, alors que nginx écrit ses erreurs dans un fichier.
/wp-json/ dans son ensemble : un webhook de paiement bloqué, c’est une commande payée qui reste « en attente ».
WooCommerce : limiter les tentatives de commande. Si votre boutique utilise le bloc Checkout, WooCommerce propose une limitation de débit de la validation de commande, dans WooCommerce > Réglages > Avancé > Fonctionnalités. Selon la documentation de la Store API, elle est désactivée par défaut et, une fois activée, plafonne la validation à 3 requêtes par 60 secondes. Passez une commande de test après l’avoir activée.
La procédure, par écrit. Qui est d’astreinte, et comment bannir une adresse à la main :
Ce qui compte vraiment
Rien de tout cela ne rend un serveur infaillible. Ces vérifications déplacent le travail : du vendredi soir, quand chaque minute coûte des ventes, vers les semaines d’avant, quand une erreur ne coûte qu’un retour au snapshot. Si vous n’avez le temps que pour deux, faites le test de charge et la restauration. Ce sont les deux qui révèlent ce que vous croyez acquis. Une question sur un serveur hébergé chez nous ? Notre équipe est disponible depuis votre espace client.Black Friday chez OnetSolutions. Du vendredi 27 novembre 2026 à 00 h 00 au mardi 1er décembre 2026 à 23 h 59 (heure de Paris), une seule offre sur la première année de nos VPS et hébergements web en facturation annuelle. Réservée aux nouveaux services, une fois par client. Le renouvellement se fait au tarif annuel normal. Le principe et les dates.

