Cloudflare est un poste avancé que l’on place entre vos visiteurs et votre serveur. Tout le trafic passe par lui : il filtre ce qui est malveillant, sert depuis sa mémoire ce qui peut l’être, et ne laisse remonter à votre hébergement que le strict nécessaire. C’est puissant, gratuit dans sa version de base, et parfaitement inutile mal configuré. Cet article décrit ce que le service apporte réellement, les quatre réglages qui font la différence, les cinq pièges classiques, et surtout ce qu’il ne répare pas.
Ce que Cloudflare fait réellement
Quatre fonctions, quatre bénéfices distincts qu’il vaut mieux ne pas confondre.
- La distribution géographique. Vos fichiers statiques sont copiés dans un réseau de points de présence répartis dans le monde. Un visiteur de Lille télécharge une image depuis un serveur proche plutôt que depuis Amsterdam. Gain : quelques dizaines de millisecondes par ressource, très visible sur une page qui en charge soixante.
- Le cache de pages. Le levier le plus puissant et le plus délicat. Une page HTML servie depuis la périphérie n’atteint jamais votre serveur : ni PHP, ni base de données, ni extensions. Sur un site vitrine, cela décharge l’hébergement de la quasi-totalité de son travail.
- Le filtrage. Robots d’analyse de vulnérabilités, connexions en force brute et attaques par déni de service sont absorbés avant votre serveur. La protection anti-déni de service est incluse sans limite de volume dans toutes les offres, y compris la gratuite.
- Le chiffrement. Un certificat universel est fourni et renouvelé automatiquement, ce qui règle la panne bête du certificat expiré un dimanche.
| Fonction | Offre gratuite | Offres payantes |
|---|---|---|
| Certificat SSL universel | Inclus | Inclus |
| Réseau de diffusion et cache | Inclus | Inclus |
| Protection anti-déni de service | Incluse, non facturée au volume | Incluse |
| Pare-feu applicatif, jeu de règles gratuit | Inclus | Inclus, avec les jeux de règles gérés complets |
| Règles de limitation de débit | 1 règle | 2 règles en Pro, 5 en Business |
| Optimisation d’images | Non | À partir de l’offre Pro |
Avant de commencer : ce que vous déplacez
Passer par Cloudflare, dans le mode le plus courant, signifie confier la gestion de la zone de votre nom de domaine à un nouvel acteur. Ce n’est pas un détail de configuration : c’est le déplacement du point le plus critique de votre présence en ligne. Une erreur ici ne casse pas le site, elle casse la messagerie, de loin la panne la plus mal vécue en entreprise.
Relevez d’abord l’intégralité de vos enregistrements existants dans un fichier, y compris ceux dont vous ignorez l’usage. La commande suivante donne l’essentiel de ce qui concerne la messagerie :
dig +short MX exemple.fr
dig +short TXT exemple.fr
dig +short TXT _dmarc.exemple.fr
dig +short TXT selecteur._domainkey.exemple.frVérifiez ensuite, après import, que Cloudflare a bien repris ces enregistrements : son analyse automatique en oublie régulièrement, en particulier les signatures de courrier et les sous-domaines techniques. Gardez enfin un accès actif à votre bureau d’enregistrement : c’est votre seule porte de sortie, et le retour en arrière consiste simplement à remettre les serveurs de noms d’origine. Dernier point de vigilance : les enregistrements de messagerie doivent rester en mode « DNS seul ». Un enregistrement de courrier passé par erreur en mode filtré coupe la réception.
Les réglages qui changent vraiment quelque chose
La configuration par défaut n’apporte presque rien. Quatre réglages font l’essentiel du travail.
Le mode de chiffrement
Le mode « Flexible » chiffre la liaison entre le visiteur et Cloudflare mais laisse la seconde moitié du trajet en clair : le cadenas s’affiche, la sécurité est en trompe-l’œil, et sur WordPress ce mode provoque en prime des boucles de redirection. La documentation recommande explicitement les modes « Full » ou « Full (strict) », ce dernier vérifiant en plus la validité du certificat de votre serveur. Le service sélectionne désormais lui-même le mode le plus sûr que votre origine supporte, avec une montée progressive du trafic. Vérifiez quand même le résultat.
Les règles de cache
Mettre en cache images, feuilles de style et scripts est automatique et sans risque. Mettre en cache les pages HTML entières est le vrai gain, et le vrai danger : c’est ici que la plupart des sites cassent. Un panier partagé entre deux visiteurs est un incident de confidentialité, pas un bogue d’affichage.
La règle de contournement doit donc être écrite avant la règle de mise en cache, jamais après :
(http.request.uri.path contains "/panier"
or http.request.uri.path contains "/commande"
or http.request.uri.path contains "/mon-compte"
or http.request.uri.path contains "/wp-admin"
or http.request.uri.path contains "/wp-login.php"
or http.request.uri.path contains "/wp-json"
or http.cookie contains "wordpress_logged_in_"
or http.cookie contains "woocommerce_items_in_cart")Action associée : contournement du cache. Toutes les autres adresses peuvent alors passer en « éligible au cache ». Le contrôle se fait en une commande, l’en-tête cf-cache-status devant afficher HIT sur une page publique et BYPASS sur le tunnel de commande :
curl -sI https://exemple.fr/ | grep -i "cf-cache-status\|cache-control"La compression et les images
Attention aux articles périmés qui circulent encore : la minification automatique du HTML, du CSS et du JavaScript a été retirée de Cloudflare le 5 août 2024. Si un tutoriel vous demande de l’activer, il date d’avant et son auteur ne l’a pas relu. La compression du transport, elle, reste automatique.
Pour les images, ne pas empiler deux couches. Si vos visuels sont déjà servis en WebP ou en AVIF et redimensionnés à la bonne taille, l’optimisation en périphérie n’apporte qu’un gain marginal et complique le diagnostic. Optimisez à la source : plus sobre, plus prévisible.
Le pare-feu applicatif et la limitation de débit
Le jeu de règles gratuit couvre les vulnérabilités les plus exploitées et suffit à faire disparaître une grande partie du bruit. Au-delà, la limitation de débit est l’outil le plus rentable : une seule règle est disponible dans l’offre gratuite, et le meilleur usage que l’on puisse en faire est de protéger la page de connexion, par exemple dix tentatives par minute et par adresse IP sur /wp-login.php.
Surveillez ensuite les faux positifs pendant une semaine : appels internes de l’administration, notifications du prestataire de paiement, robots légitimes de vos outils de mesure. Un client bloqué à la commande coûte plus cher qu’un robot passé au travers.
Les cinq pièges qui font perdre du temps
- La page connectée servie à un anonyme. Symptôme : un visiteur voit le panier ou le nom d’un autre. Vérification : l’en-tête
cf-cache-statusdoit valoirBYPASSsur toute page personnalisée. - Les modifications invisibles. Vous publiez, rien ne change. Le cache n’a pas été purgé. Automatisez-le en fin de déploiement plutôt que d’y penser à chaque fois.
- Les enregistrements de messagerie mal recopiés. Symptôme : les courriels partent mais n’arrivent plus, ou tombent en indésirables. Comparez votre relevé initial avec la zone actuelle, enregistrement par enregistrement.
- Le filtrage trop zélé. Un appel interne de l’administration ou une notification de paiement bloquée provoque des pannes fantômes, visibles seulement dans les journaux de sécurité.
- La double couche de cache. Cache serveur chez l’hébergeur plus cache en périphérie : le comportement devient imprévisible et le débogage impossible. Choisissez lequel des deux sert les pages, et neutralisez l’autre.
La purge se scripte, ce qui évite d’avoir à y penser :
curl -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/purge_cache" \
-H "Authorization: Bearer $CF_TOKEN" \
-H "Content-Type: application/json" \
--data '{"purge_everything":true}'Ce que cela ne répare pas
Un poste avancé ne corrige aucun défaut situé derrière lui. Une base mal indexée reste lente, une extension qui exécute quarante requêtes par page reste coûteuse. Pire : le cache masque le problème en le rendant invisible aux mesures, jusqu’au jour où une page non mise en cache, le tunnel de commande par exemple, s’effondre sous le trafic.
Diagnostiquez donc avant de configurer. Si votre serveur met 1,8 seconde à produire une page pour un visiteur connecté, aucun réglage en périphérie n’y changera rien ; notre méthode pour diagnostiquer la vraie cause d’un site lent décrit la chaîne de mesure. Même logique côté sécurité : le filtrage en amont ne remplace pas les mesures de notre guide pour sécuriser WordPress en profondeur.
Aller plus loin : le calcul en périphérie
Pour les projets sur mesure, le réseau devient un lieu d’exécution à part entière : redirections gérées en périphérie sans toucher au serveur, tests de mise en page, personnalisation légère selon le pays, points d’accès applicatifs simples, stockage d’objets pour les médias volumineux. Ce n’est plus un réglage, c’est du développement, avec les exigences correspondantes en matière de versionnement et de tests.
Un signal sur la direction que prend l’écosystème : Cloudflare a annoncé le 16 janvier 2026 le rachat de l’équipe qui développe le framework Astro, en s’engageant à le maintenir en logiciel libre et utilisable ailleurs. La frontière entre hébergement, réseau et socle de construction se déplace, ce qui pèse désormais dans le choix d’une architecture, comme nous l’expliquons dans notre comparaison des socles techniques. C’est aussi ce qui ouvre la voie aux développements sur mesure en périphérie.
Notre position : un multiplicateur, pas un correcteur
Nous mettons Cloudflare devant la plupart des sites que nous suivons, pour trois raisons dans cet ordre : le certificat qui ne périme jamais, le filtrage qui divise par dix le bruit dans les journaux, et la disponibilité les jours de pic. La vitesse arrive en quatrième position, parce que sur un site déjà léger le gain est modeste.
Nous refusons en revanche de le proposer comme un correctif : sur un site malade, la configuration déplace le problème et rend le diagnostic plus difficile. Nous auditons d’abord, nous configurons ensuite. Il y a enfin une lecture de sobriété, cohérente avec notre démarche Ocean Friendly : servir une ressource depuis un point proche et cesser de recalculer mille fois la même page réduit réellement l’énergie mobilisée, à condition que la page soit légère au départ. Un site de 4 Mo servi depuis la périphérie reste un site de 4 Mo, sujet que nous détaillons à propos d’un hébergement réellement sobre. Pour la mise en œuvre, notre assistance technique par tickets couvre la configuration et le contrôle des enregistrements de messagerie.
Questions fréquentes
Faut-il changer d’hébergeur pour utiliser Cloudflare ?
Non. Le service se place devant l’hébergement existant : votre site reste exactement là où il est, seuls les enregistrements DNS changent de gestionnaire. C’est réversible en quelques minutes.
Est-ce utile pour un petit site vitrine ?
Oui pour le certificat, la protection contre les robots et la disponibilité en cas de pic. Moins pour la vitesse si le site est déjà léger et correctement hébergé : sur une page de 400 Ko bien mise en cache, le gain perçu est marginal.
Mon site affiche une version périmée, pourquoi ?
Deux causes possibles. Le cache n’a pas été purgé après une modification, ou une règle met en cache une page qui ne devrait jamais l’être. Purgez, puis vérifiez l’en-tête cf-cache-status de la page concernée.
Cloudflare remplace-t-il une extension de sécurité ?
Non. Il filtre en amont, ce qui réduit énormément le bruit, mais il ne voit pas ce qui se passe à l’intérieur du site. Un compte administrateur compromis ou une extension vulnérable restent des problèmes applicatifs.
Cloudflare est un multiplicateur : sur un site sain, il apporte beaucoup pour très peu d’effort ; sur un site malade, il déplace le problème et vous le rend plus difficile à voir. Avant de créer votre compte, relevez vos enregistrements DNS et mesurez le temps de réponse de votre serveur. Ces deux données vous diront ce que vous avez réellement à y gagner.
À lire aussi : Hébergement web : bien choisir l’hébergement de son site internet
