La frontière du cache spécifique à une boutique

Les pages WooCommerce se répartissent en trois catégories étanches : les pages du catalogue (produits, catégories), identiques pour tous et cachables ; les pages client (panier, checkout, mon-compte), jamais cachables ; les endpoints machine (webhooks de paiement, APIs de commandes), qui doivent atteindre l'origine intactes, à chaque appel. Une règle imprécise dans un sens ou l'autre produit soit des paniers vides, soit une boutique lente.

Configurer pas à pas

Étape 1 : SSL/TLS strict et cookies protégés. Même base que tout WordPress : mode Full (strict) contre les boucles, puis une Cache Rule qui contourne le cache quand un cookie de session WooCommerce est présent (woocommerce_items_in_cart, wp_woocommerce_session) ou sur les chemins /panier, /commande et /mon-compte.

Étape 2 : cacher le catalogue délibérément. Pages produits et catégories sont vos candidates au cache : TTL longs pour /wp-content/, et cache edge du HTML catalogue quand le contenu est identique pour les visiteurs anonymes. Vérifiez au curl que cf-cache-status passe de DYNAMIC à HIT sur une page produit.

Étape 3 : exempter explicitement les webhooks de paiement. Stripe, PayPal et les PSP bancaires appellent votre site de serveur à serveur pendant le paiement. Une règle de maintenance, WAF ou de rate limiting qui touche ces routes casse de vraies commandes en silence. Listez les routes de webhooks dans une règle Skip prioritaire, comme décrit dans notre guide sur les faux positifs WAF sur inscriptions et paiements.

Étape 4 : maîtriser l'abus automatisé. Scraping de prix, réservation de stock et card testing se manifestent d'abord comme des motifs de requêtes. Un rate limiting ciblé sur les /?add-to-cart=, les POST de checkout et les paiements échoués protège à la fois vos données de stock et vos frais PSP.

Étape 5 : mesurer ce qui compte. Hit ratio sur le catalogue, temps de réponse du checkout, nombre de faux positifs dans Security Events : une règle e-commerce n'est terminée que quand ces trois indicateurs arrêtent de partir de travers.

Les erreurs fréquentes qui coûtent des commandes

  • Mettre en cache la page de paiement. La catastrophe classique : un client voit le checkout d'un autre. En cas de doute, on ne cache pas ; les pages produits apportent déjà l'essentiel du gain.
  • Rate limiter le POST du checkout. Un seuil serré attrape les paiements multi-étapes et les clients qui corrigent un numéro de carte. Des seuils généreux, spécifiques au chemin, avec un défi plutôt qu'un blocage.
  • Bloquer les IP des PSP. Les plages IP des passerelles évoluent sans préavis ; une liste statique tue les webhooks un jour. Passez par des exemptions explicites de routes plutôt que par des listes d'IP.
  • Oublier le chemin mobile. La majorité du trafic est mobile ; testez le parcours d'achat complet sur un vrai téléphone après chaque changement de règle.
  • Négliger cron et AJAX. admin-ajax.php et les endpoints AJAX alimentent les ajouts au panier ; une règle trop large provoque des échecs aléatoires difficiles à reproduire.

Questions fréquentes

Peut-on cacher les pages produits WooCommerce sans risque ?

Oui, quand la page ne contient rien de spécifique à l'utilisateur et qu'aucun cookie de session n'est présent, ce que garantit la règle de contournement. Les zones dynamiques restent fraîches pour les requêtes qui portent une session.

Pourquoi des paiements échouent depuis l'activation des règles Cloudflare ?

Généralement une règle WAF ou de rate limiting qui touche le webhook ou les routes de retour du PSP. Consultez Security Events pour les blocages venant de l'ASN de votre PSP et exemptez ces routes en priorité maximale, comme dans notre guide des faux positifs WAF.

Faut-il un plan Cloudflare payant pour WooCommerce ?

Le plan Free couvre cache rules, redirections et lutte anti-bots de base. Pro ajoute les rulesets WAF managés et l'optimisation d'images, utiles à partir d'un certain trafic. La plupart des boutiques commencent en Free.

Comment limiter le scraping de vos prix ?

La prévention parfaite n'existe pas, mais rate limiting par IP et ASN, exemptions réservées aux bots vérifiés et défis agressifs sur le catalogue rendent l'opération coûteuse. Gardez des seuils compatibles avec les crawlers de recherche.

Une boutique plus rapide sans casser le paiement ?

CF Garage trace les frontières du cache, exempte les webhooks de paiement et règle les bots pour WooCommerce. Prix fixe, garantie de satisfaction.

Découvrir les tarifs & commander

Ressources et guides complémentaires