Activer le petit nuage orange de Cloudflare devant un domaine paraît anodin : un simple bouton à basculer dans l’interface, et le trafic commence à transiter par leur réseau plutôt que de frapper directement le serveur. En réalité, ce changement transforme complètement l’architecture réseau du site, et plusieurs comportements de WordPress qui reposaient sur une connexion directe cessent de fonctionner comme prévu.
Ce n’est pas une raison pour éviter Cloudflare — le service reste précieux pour son cache en périphérie et sa protection contre certaines attaques — mais il faut connaître les pièges classiques avant de l’activer sur un site en production, plutôt que de les découvrir après coup en support.
L’IP du visiteur n’est plus ce qu’elle semblait être
Sans Cloudflare, le serveur voit directement l’adresse IP du visiteur dans la variable REMOTE_ADDR. Avec le mode proxy activé, toute requête arrive en réalité depuis un serveur Cloudflare, et REMOTE_ADDR contient donc systématiquement une adresse Cloudflare, identique pour tous les visiteurs. Cela casse silencieusement tout mécanisme qui reposait sur cette adresse : limitation de tentatives de connexion, journalisation de sécurité, blocage géographique.
La véritable adresse IP du visiteur est transmise dans un en-tête HTTP dédié, CF-Connecting-IP, qu’il faut explicitement récupérer côté serveur ou via une extension de sécurité compatible :
function recuperer_ip_reelle() {
if ( ! empty( $_SERVER['HTTP_CF_CONNECTING_IP'] ) ) {
return sanitize_text_field( $_SERVER['HTTP_CF_CONNECTING_IP'] );
}
return $_SERVER['REMOTE_ADDR'];
}
Sans cette adaptation, une extension de protection contre les tentatives de connexion abusives (comme un limiteur de tentatives) devient inutile : elle bloquera systématiquement l’IP de Cloudflare plutôt que celle de l’attaquant réel, ou pire, bloquera tous les visiteurs après quelques tentatives malveillantes cumulées.
Le mode SSL flexible, une fausse bonne idée
Cloudflare propose plusieurs modes de chiffrement entre son réseau et le serveur d’origine. Le mode « flexible » chiffre la connexion entre le visiteur et Cloudflare, mais laisse la connexion entre Cloudflare et le serveur en HTTP simple. C’est une configuration tentante quand le serveur n’a pas encore de certificat TLS installé, mais elle expose le trafic en clair sur le dernier tronçon, et surtout, elle provoque une boucle de redirection infinie si WordPress force par ailleurs une redirection HTTPS côté serveur.
Le mode recommandé est « complet strict », qui exige un certificat TLS valide sur le serveur d’origine (par exemple via Let’s Encrypt) et chiffre l’intégralité du trajet, y compris entre Cloudflare et le serveur.
Le cache Cloudflare et le contenu dynamique
Le cache de Cloudflare, activé par défaut sur certains types de ressources, peut mettre en cache des pages qui devraient rester dynamiques, notamment sur un site e-commerce où le panier ou le compte utilisateur changent à chaque visite. Une règle de cache mal configurée peut afficher à un visiteur le panier d’un autre, une faille de confidentialité sérieuse plutôt qu’un simple bug d’affichage.
- Exclure explicitement les URL de panier, de compte et de paiement des règles de cache Cloudflare.
- Vérifier que les cookies de session ne sont jamais mis en cache par une règle trop large.
- Tester en navigation privée depuis deux appareils différents avant de considérer la configuration validée.
Purger le cache après une mise à jour
Après une modification de contenu ou une mise à jour de thème, le cache Cloudflare peut continuer à servir une version obsolète pendant la durée du TTL défini. Une purge manuelle, ou l’intégration d’un plugin qui déclenche automatiquement la purge via l’API Cloudflare au moment de publier un article, évite ce décalage.
Le mode proxy de Cloudflare est un contrat implicite : en échange de sa protection et de son cache, il faut accepter de ne plus voir directement le trafic tel qu’il arrive vraiment sur le serveur. Ignorer ce contrat produit des bugs qui ressemblent à des mystères.
En résumé
Cloudflare apporte un vrai gain en performance et en résilience pour un site WordPress, à condition d’adapter la récupération de l’IP réelle, de choisir le mode SSL complet strict, et d’exclure soigneusement le contenu dynamique du cache en périphérie. Ces trois réglages, une fois faits correctement, évitent la majorité des incidents rencontrés après une activation trop rapide du service.
