Cloudflare & CDN

Un site qui met trois secondes à afficher sa page d’accueil, ou qui tombe en pleine promotion parce qu’un bot scrape toutes les fiches produit en boucle : ce sont deux visages du même problème. Le serveur d’hébergement encaisse tout, sans filtre, et le visiteur paie la note en temps de chargement ou en page blanche.

Cloudflare — et les CDN équivalents — se placent devant votre hébergement pour absorber une partie de ce trafic avant qu’il n’atteigne le serveur. Concrètement : les images, le CSS et le JS sont servis depuis un point de présence proche du visiteur au lieu de traverser l’Atlantique ou de solliciter votre mutualisé à chaque requête ; les attaques par déni de service et les tentatives de brute force sur /wp-login.php sont filtrées en amont ; le certificat SSL est géré sans y penser. Sur un site WordPress ou PrestaShop qui reçoit du trafic réel, le gain est mesurable en secondes de chargement et en tickets d’incident en moins.

Je mets en place cette couche pour des clients qui ont un vrai motif — lenteur constatée, attaque en cours, ou exigence de résilience — pas par réflexe. Un CDN mal configuré peut aussi casser un site : cache qui sert une page obsolète après une mise à jour, règle WAF trop stricte qui bloque un formulaire de commande. C’est pour ça que la configuration se fait à la main, poste par poste, pas en cochant toutes les options par défaut.

Ce que change concrètement une mise en place Cloudflare

Le CDN et le pare-feu applicatif ne sont pas une brique unique : ce sont plusieurs réglages distincts, chacun avec son propre risque s’il est mal calibré. Voici les quatre volets que je configure systématiquement.

Ma méthode : je configure, je ne coche pas des cases

Activer Cloudflare en mode « tout par défaut » prend cinq minutes et casse régulièrement quelque chose : un panier PrestaShop qui affiche un prix en cache, une page de connexion qui boucle à cause d’une règle WAF trop agressive, un formulaire de devis qui déclenche un captcha à chaque soumission. Je préfère passer plus de temps en amont à identifier ce qui doit être mis en cache, ce qui doit rester dynamique, et quelles routes de votre back-office doivent être exclues des règles de sécurité.

Une fois la configuration posée, elle demande un suivi : purge de cache après chaque mise à jour de contenu, vérification que les règles WAF n’ont pas bloqué un partenaire légitime, ajustement si un nouveau bot apparaît. C’est un travail qui s’intègre naturellement dans une supervision et sauvegardes mensuelle plutôt qu’une intervention ponctuelle qu’on oublie ensuite.

Les cas où je vous déconseille cette mise en place

Je ne facture pas une couche de protection à quelqu’un qui n’en a pas besoin. Voici les situations où je vous dis franchement de garder votre budget :

• Trafic faible et site vitrine simple — un one-page ou une petite vitrine avec quelques centaines de visites par mois n’a aucune raison d’être une cible, et le gain de vitesse d’un CDN reste marginal sur un hébergement déjà correct.
• Hébergeur qui propose déjà l’équivalent — certains hébergeurs mutualisés ou infogérés (souvent ceux que je recommande via un conseil en hébergement) intègrent déjà un cache et une protection basique suffisante pour un petit site.
• Aucune preuve d’un problème réel — si votre site n’a jamais été attaqué et se charge en moins de deux secondes, ajouter une couche de configuration supplémentaire, c’est de la complexité pour rien.

Dans ces cas-là, je préfère orienter le budget vers autre chose : optimisation d’images, mise à jour du thème, ou simplement rien du tout si le site tourne bien.

Un cas réel : Petite Boussole

Ce type d’intervention suit toujours le même ordre : d’abord comprendre comment le site a été compromis ou pourquoi il est lent, ensuite seulement configurer la protection adaptée à cette cause précise. Mettre un WAF devant un site sans savoir par où il a été attaqué la première fois, c’est soigner un symptôme sans traiter la cause.

Tarifs et déroulé d’une mission

La mise en place initiale — audit du trafic, configuration du cache, des règles WAF et du DNS, tests de non-régression sur les fonctionnalités critiques (paiement, formulaires, back-office) — se facture en régie, entre 400 et 700 € HT par jour selon la complexité du site et le nombre de règles à ajuster. Pour un site vitrine standard, ça tient généralement en une demi-journée à une journée.

Le suivi ensuite — purge de cache, ajustement des règles, surveillance des faux positifs — s’intègre dans un forfait de maintenance mensuel.

Je ne vends pas la configuration Cloudflare seule et isolée : elle a du sens rattachée à une réflexion plus large sur votre hébergement et votre infrastructure, surtout si une migration d’hébergeur est déjà à l’ordre du jour — autant régler les deux ensemble plutôt que de reconfigurer le DNS deux fois.

Questions fréquentes