Cloudflare peut améliorer la vitesse et la sécurité d’un site WordPress, mais une mauvaise configuration crée vite des boucles HTTPS, des caches incohérents, ou un checkout WooCommerce instable. L’objectif de ce guide : poser une configuration simple, mesurée, et facile à maintenir, utile autant pour une PME à Fribourg, Bulle (FR), Delémont, Porrentruy (JU), Sion, Martigny (VS), Neuchâtel, La Chaux-de-Fonds (NE), Nyon, Vevey (VD) que pour une activité à Meyrin, Carouge (GE).
Sources officielles : Cloudflare (proxy DNS) | Cloudflare (modes SSL/TLS) | Cloudflare (Cache Rules) | Cloudflare (APO WordPress) | Cloudflare (APO FAQ) | Cloudflare (WAF) | Cloudflare (Managed Rules) | Cloudflare (OWASP, paranoia level) | Cloudflare (HTTP/3) | WordPress (HTTPS)
1) DNS : comprendre le proxy (nuage orange) avant d’activer
Le statut « proxied » (nuage orange) change la manière dont Cloudflare traite le trafic. Cloudflare précise que seuls certains types d’enregistrements DNS peuvent etre proxys (notamment A, AAAA, CNAME). Cela compte pour le cache, le WAF et HTTP/3.
- A / AAAA : domaine ou sous-domaine vers une IP.
- CNAME : sous-domaine vers un autre nom (ex. www vers racine).
- Proxied : Cloudflare s’interpose (CDN, WAF, optimisations).
- DNS only : Cloudflare ne fait que la résolution DNS.
2) SSL/TLS : éviter « Flexible », viser Full ou Full (strict)
Cloudflare explique que le mode SSL/TLS pilote deux connexions : visiteur → Cloudflare, puis Cloudflare → serveur d’origine. Si possible, Cloudflare recommande Full ou Full (strict) pour éviter des connexions malveillantes vers l’origine.
- Recommandé : Full (strict) si un certificat valide est installé sur l’origine.
- Alternative : Full si le certificat d’origine n’est pas validé de manière stricte (à traiter dès que possible).
Coté WordPress, l’usage de HTTPS est fortement recommandé. Avant de modifier Cloudflare, vérifier que WordPress est bien configuré en HTTPS (URL du site et redirections cohérentes).
3) Cache : privilégier Cache Rules, et rester prudent avec les pages dynamiques
Cloudflare indique que Cache Rules permettent d’ajuster l’éligibilité au cache et les durées, et précise que ces règles exigent des enregistrements DNS proxys. Pour WordPress, le principe est simple : mettre en cache ce qui est public et stable, et éviter de mettre en cache ce qui dépend d’une session.
Pages a exclure du cache (bon sens)
- Connexion et administration : /wp-login.php, /wp-admin/
- WooCommerce : panier, checkout, compte
- Pages de paiement, retours de prestataires, pages de confirmation sensibles
Astuce : si un problème apparait (utilisateur « déconnecté », panier qui se vide, contenu incohérent), commencer par vérifier les exclusions de cache avant toute autre action.
4) APO (Automatic Platform Optimization) : utile, mais a cadrer
Cloudflare présente APO comme une optimisation spécifique WordPress pour servir davantage de pages depuis l’edge. Dans sa FAQ, Cloudflare précise qu’avec le plugin WordPress, APO met en cache automatiquement (30 jours) et invalide rapidement lors d’un changement (dans un délai court annoncé). Cela peut simplifier la performance si le site est surtout public (vitrine, blog).
- Bon candidat : site vitrine et blog, contenu majoritairement public.
- Attention : site avec beaucoup de personnalisation par utilisateur ou zones très dynamiques.
- Règle pratique : en cas de doute, tester sur un sous-domaine ou une fenêtre de faible trafic, puis valider avec des pages types (Accueil, Service, Article, Contact, Produit, Checkout).
Cloudflare note aussi l’interaction entre anciennes Page Rules et APO, et suggère d’utiliser plutot Cache Rules pour plus de contrôle.
5) WAF : activer une protection raisonnable, sans bloquer les vrais clients
Le WAF Cloudflare filtre le trafic entrant via des ensembles de règles (rulesets). Cloudflare fournit des Managed Rules préconfigurées, mises a jour régulièrement. Une bonne approche consiste a activer, observer, puis durcir progressivement.
OWASP Core Ruleset : comprendre les niveaux de sévérité
Cloudflare documente le concept de « paranoia level » (PL1 a PL4). Plus le niveau est élevé, plus la protection est stricte, avec un risque accru de faux positifs. Pour la plupart des PME, démarrer au niveau par défaut est plus prudent.
- Départ conseillé : configuration par défaut, puis monitoring.
- Durcissement : augmenter seulement si le site est ciblé et si le parcours client reste fluide.
- Priorité test : formulaires, recherche, connexion, panier et paiement.
Cloudflare explique aussi comment déployer le ruleset OWASP dans l’interface WAF (Managed rules), avec une configuration par défaut.
6) HTTP/3 : activer quand le reste est stable
Cloudflare documente HTTP/3 (avec QUIC) et précise que ce réglage concerne la connexion entre l’utilisateur et Cloudflare (pas la connexion Cloudflare vers l’origine). Le gain est surtout visible sur des réseaux instables (mobile, Wi-Fi chargé).
- Activer HTTP/3 une fois HTTPS et le cache stables.
- Vérifier que le site ne dépend pas de réglages réseau particuliers (rare sur WordPress standard).
Checklist rapide (20 minutes)
- DNS : A/AAAA/CNAME en « proxied » uniquement là ou c’est utile.
- SSL/TLS : Full (strict) si possible, sinon Full (temporaire).
- Cache Rules : cache pour le public, exclusions pour les zones dynamiques.
- APO : activer seulement si le site s’y prete, tester et purger si besoin.
- WAF : Managed Rules activées, observer les blocages, ajuster progressivement.
- HTTP/3 : activer après stabilisation, puis contrôler l’absence d’effets de bord.
FAQ Cloudflare et WordPress (Suisse romande)
Pourquoi mon site WordPress boucle en HTTPS après activation Cloudflare ?
Une boucle apparait souvent quand la connexion Cloudflare → origine n’est pas correctement chiffrée ou quand le mode SSL/TLS n’est pas adapté. Cloudflare explique les modes SSL/TLS (deux connexions) et recommande Full ou Full (strict) si possible.
Cache Rules nécessite-t-il le nuage orange (proxied) ?
Oui. Cloudflare indique que Cache Rules exigent que les enregistrements DNS concernés soient proxys.
APO est-il adapté à une boutique WooCommerce ?
Tout dépend de la part de pages publiques et de vos exclusions. Cloudflare décrit APO pour WordPress et précise ses comportements de cache et d’invalidation avec le plugin. Une boutique demande davantage de prudence sur les pages dynamiques (panier, checkout, compte).
Le WAF peut-il bloquer un formulaire ou un paiement ?
Oui, surtout si la configuration est trop stricte. Cloudflare explique que les Managed Rules protègent contre des techniques d’attaque, et détaille les niveaux d’agressivité (paranoia level) pour l’OWASP ruleset. L’approche la plus sûre : activer, observer, puis ajuster.
HTTP/3 change-t-il quelque chose sur mon serveur d’hébergement ?
Cloudflare précise que le réglage HTTP/3 concerne la connexion utilisateur → Cloudflare. Le serveur d’origine n’est pas « forcé » en HTTP/3 par ce simple réglage.
Besoin d’une configuration Cloudflare propre et testée sur WordPress ou WooCommerce ?
Pour configurer DNS, SSL/TLS, cache, WAF et tests de non-régression (formulaires, WooCommerce, comptes), contactez clickclick.ch.
