Configurer correctement DNS, cache et Page Rules Cloudflare est l’étape qui détermine si votre site sera fast ou lent en Afrique. Voici les patterns essentiels en 2026 (informations vérifiées en avril 2026, susceptibles d’évoluer).

Voir notre guide Cloudflare.

DNS records essentiels

Type  Name  Content                  Proxy
A     @     IP_VPS                   Proxied (orange)
A     www   IP_VPS                   Proxied
A     api   IP_VPS                   Proxied
MX    @     mx.brevo.com             DNS only (gris)
TXT   @     v=spf1 include:_spf...    DNS only
CNAME mail  brevo.com                DNS only

Règle : tout ce qui sert HTTP/S → orange. Tout ce qui est mail/autre protocole → gris.

Cache Rules (remplace Page Rules)

Cloudflare a remplacé les « Page Rules » historiques par les « Rules » plus puissantes. Configurer dans Rules → Cache Rules :

Static assets long cache : si URI matches *.js | *.css | *.woff2 | *.webp | *.avif | *.png → Cache eligibility: Eligible for cache, Edge TTL: 1 year, Browser TTL: 1 year
HTML pas caché par défaut : si URI matches *.html ou / → Bypass cache (laisser le serveur décider)
API toujours bypass : si URI matches /api/* → Bypass cache

Compression

Speed → Optimization → Brotli : Activé (par défaut depuis 2024)
Auto Minify : Désactivé (laissez votre build outil le faire mieux)
Rocket Loader : Désactivé (peut casser certains scripts)

Smart Routing (Argo)

Argo Smart Routing (~5 USD/mois option) optimise le routing entre Cloudflare et votre origin. Réduit la latence de 20-40 % sur connexions intercontinentales. Pour PME africaines avec origin Hetzner Helsinki et visiteurs Afrique, ROI excellent.

Tiered Cache

Caching → Tiered Cache : Enable. Plusieurs niveaux de cache (regional + edge) → moins de requêtes vers votre origin, charge réduite, meilleure perf.

Pour étoffer le tableau

Cloudflare DNS, cache et regles en 2026 : ce qui a change

Depuis 2025, Cloudflare a opere une transition majeure : les Page Rules historiques (limitees a 3 sur le plan gratuit, 20 sur Pro) sont en mode legacy. Le remplacement officiel s appelle Cache Rules, Configuration Rules, Origin Rules et Redirect Rules. Tout nouvel utilisateur voit directement les nouvelles interfaces, et toute infrastructure existante doit migrer avant la fin du cycle de support des Page Rules. Cette migration n est pas optionnelle a moyen terme.

Pour un freelance ouest-africain qui gere une boutique WooCommerce a Dakar ou un site institutionnel a Abidjan, comprendre cette nouvelle architecture est crucial : un cache mal configure peut soit servir des pages obsoletes (panier vide, prix faux) soit au contraire ne rien mettre en cache et faire exploser la facture origin chez Hostinger.

Etape 1 : configurer le DNS Cloudflare proprement

Avant de toucher au cache, validez le DNS. Connectez-vous au dashboard Cloudflare, selectionnez la zone, allez dans DNS – Records. Verifiez que les enregistrements A et AAAA pointent vers l IP du serveur origin avec le nuage orange (proxified). Pour les sous-domaines techniques (cpanel, ftp, mail), nuage gris (DNS only) sinon Cloudflare casse les protocoles non-HTTP.

# Verification depuis un terminal local
dig +short votredomaine.com
# Doit retourner une IP Cloudflare type 104.x ou 172.x

dig +short ftp.votredomaine.com
# Doit retourner l IP reelle de votre serveur

Sortie de référence : la commande dig doit montrer une IP Cloudflare pour le domaine principal, et l IP origin pour les sous-domaines en gris. Si l IP origin fuit sur le domaine principal, le proxy n est pas actif et toute la protection DDoS et le cache sont court-circuites.

Etape 2 : activer SSL Full strict pour eviter le fallback insecure

Dans SSL/TLS – Overview, choisissez Full (strict). Ce mode force HTTPS de bout en bout et verifie que le certificat origin est valide. Origin Certificate de Cloudflare (gratuit, 15 ans) est une bonne pratique car il n est valide que pour Cloudflare et evite la fuite d IP origin si quelqu un fait un dump TLS.

Generez le certificat dans SSL/TLS – Origin Server – Create Certificate, copiez la cle privee et le certificat dans /etc/ssl/cloudflare-origin/ sur votre serveur, configurez Nginx pour les utiliser, redemarrez. Sortie de référence : curl -I https://votredomaine.com retourne HTTP/2 200 sans avertissement TLS.

Etape 3 : creer une Cache Rule pour les assets statiques

Allez dans Caching – Cache Rules – Create rule. Nom : Cache assets statiques. Champ When incoming requests match : selectionnez URI Path puis Operator matches regex puis Value \.(css|js|jpg|jpeg|png|webp|svg|woff2|ico)$. En section Then : Cache eligibility = Eligible for cache. Edge TTL = Override origin et 1 month. Browser TTL = Override origin et 1 day.

Sortie de référence apres deploiement : un curl -I https://votredomaine.com/wp-content/themes/twenty-twenty-six/style.css retourne le header cf-cache-status: HIT apres la deuxieme requete. Le HIT confirme que la regle s applique. Un MISS persistant indique soit que la regle ne matche pas (verifier la regex), soit que le navigateur envoie un Cache-Control: no-cache.

Etape 4 : exclure le panier WooCommerce du cache

Une boutique WooCommerce ne doit jamais cacher /panier, /commande, /mon-compte, /checkout. Creez une seconde Cache Rule au-dessus de la precedente (ordre de priorite descendant). Nom : Bypass cache pages dynamiques. When : URI Path matches regex /(panier|cart|commande|checkout|mon-compte|my-account|wp-admin|wp-login)/. Then : Cache eligibility = Bypass cache.

Ce que vous devez voir : tester en logue, ajouter un produit, le compteur doit refleter la realite. Le header cf-cache-status doit etre BYPASS sur ces URLs. Si vous voyez HIT, la regle a un ordre incorrect ou la regex est trop laxiste. Reordonnez via le drag-and-drop dans l interface Cache Rules.

Etape 5 : Configuration Rule pour activer Auto Minify proprement

Auto Minify a quitte le menu legacy en 2025. Pour minifier CSS et JS sur certaines URLs, creez une Configuration Rule. Rules – Configuration Rules – Create rule. When : Hostname equals votredomaine.com. Then settings : Auto Minify – JavaScript on, CSS on, HTML off (HTML minify casse souvent les editeurs visuels Elementor ou Divi).

Sortie attendue : verifier la taille d un fichier .js avant et apres avec curl -sI https://votredomaine.com/wp-content/plugins/wc/assets/js/frontend/cart.js | grep content-length. La difference doit etre de 15 a 30 pourcents en moins. Si aucune variation, la Configuration Rule n est pas active ou la regle precedente l ecrase.

Etape 6 : Redirect Rule plutot que Page Rule de redirection

Pour rediriger www vers apex (ou inverse), n utilisez plus Page Rules. Allez dans Rules – Redirect Rules – Create rule. Nom : Redirect www vers apex. When : Hostname equals www.votredomaine.com. Then : Type Static, URL https://votredomaine.com et le Path ${http.request.uri.path}, Status 301 permanent.

Ce que vous devez voir : curl -I https://www.votredomaine.com/article-test retourne HTTP/2 301 et Location: https://votredomaine.com/article-test. Si le code retourne est 302, vous avez choisi temporary par erreur. Le 301 est crucial pour le SEO car il transmet le link juice, contrairement au 302.

Etape 7 : Origin Rule pour modifier le port ou l host envoye a l origin

Si votre serveur origin ecoute sur un port custom (ex : 8443) ou si vous voulez forcer un Host header specifique pour un multisite, utilisez Origin Rules. Rules – Origin Rules – Create rule. When : Hostname equals api.votredomaine.com. Then : Override Origin Server avec api-internal.votredomaine.com et port 8443.

Cette indirection permet de masquer la topologie reelle. L IP origin reste invisible pour quiconque inspecte les en-tetes publics, et vous pouvez basculer un service vers un autre backend sans changer le DNS visible. C est extremement utile pendant une migration progressive.

Etape 8 : verifier la facture cache hit ratio dans Analytics

Apres 48 heures, ouvrez Analytics & Logs – Traffic. Le panneau Cache analytics affiche le ratio HIT vs MISS vs DYNAMIC vs BYPASS. Pour un site WooCommerce typique, viser 60 a 75 pourcents de HIT global. Sous 50 pourcents, soit votre cache rules sont trop restrictives, soit votre site genere trop de pages dynamiques (chercher cookies, query strings).

Résultat attendu : un graphique avec une majorite de HIT (vert) sur les pages de contenu et une minorite de DYNAMIC (rouge) sur les pages de compte et panier. Si DYNAMIC domine partout, revisitez la Cache Rule de l etape 3 et abaissez l Edge TTL si necessaire.

Etape 9 : purge selective pour ne pas tout casser

Apres une mise a jour de theme ou de plugin WooCommerce, purgez uniquement les URLs concernees. Dashboard – Caching – Configuration – Purge by URL. Saisissez par exemple https://votredomaine.com/wp-content/themes/twenty-twenty-six/style.css. Evitez Purge Everything qui invalide tout le cache et provoque un pic de charge sur l origin pendant le rerouage.

Pour automatiser depuis WordPress, le plugin officiel Cloudflare ou WP Rocket avec connecteur Cloudflare purgent automatiquement les bons URLs apres save d un article. Verifiez avec curl que le cf-cache-status repasse a MISS puis HIT lors des requetes suivantes.

Etape 10 : alternatives, limites et integration avec votre stack

Cloudflare gratuit suffit pour 95 pourcents des sites freelance. Le passage a Pro (20 USD par mois, soit environ 13 100 FCFA mensuels) debloque WAF managed rules, image optimization Mirage, Polish, et plus de regles. Pour un site WordPress sous trafic faible (moins de 50 000 vues mois), restez en gratuit.

Pour completer la chaine de supervision, voyez notre guide Prometheus node-exporter VPS qui expose des metriques d origin permettant de correler les pics de cache MISS avec une charge serveur anormale, et notre comparatif Uptime Kuma vs Healthchecks pour mesurer le temps de reponse percu cote utilisateur.

Etape 11 : strategie de cache par type de contenu

Tous les contenus n ont pas la meme volatilite. Une image de produit WordPress change rarement (TTL 1 an), un article de blog change parfois (TTL 1 jour avec purge auto), une page de categorie WooCommerce change souvent en stock et prix (TTL 5 minutes max). Definissez 3 a 4 Cache Rules avec des TTL differencies plutot qu une seule regle universelle.

Concretement : regle 1 pour /wp-content/uploads/ avec Edge TTL 1 month et Browser TTL 1 week. Regle 2 pour /produit/ avec Edge TTL 5 minutes et Bypass cookie wordpress_logged_in. Regle 3 pour /blog/ avec Edge TTL 1 day. Cette granularite multiplie le hit ratio par 1.5 a 2 fois sans risque de servir des donnees obsoletes critiques.

Etape 12 : Cache Reserve et Tiered Cache pour Pro et superieur

Cache Reserve (payant a l usage R2) garde les objets en cache 30 jours minimum, contournant l eviction agressive du cache standard. Pour un site avec long-tail (anciens articles toujours visites), c est tres rentable. Tiered Cache (gratuit, optionnel a activer) regroupe les requetes des datacenters edge vers un upper-tier avant de hit l origin, augmentant le hit ratio global de 5 a 15 points.

Activation : Caching – Tiered Cache – Smart Tiered Caching Topology. Aucune regle a creer, ca s applique automatiquement. Verifier dans Analytics que le ratio Cached bytes augmente apres 24 heures. Pour la majorite des sites freelance, Tiered Cache est gratuit et benefique sans contrepartie.

Etape 13 : Bot Fight Mode et regles de securite minimales

Activer Bot Fight Mode (gratuit) dans Security – Bots filtre les bots evidents. Lectures complémentaires, creez un WAF Custom Rule : Security – WAF – Custom rules – Create rule. When : http.user_agent contains scrapy ou http.user_agent contains curl ET ip.src.country ne France ne Senegal ne Cote d Ivoire. Then : Block. Ajustez selon vos pays cibles.

Vous devriez obtenir : un curl -A scrapy https://votredomaine.com depuis un VPS hors zone retourne 403. Depuis un navigateur Chrome legitime, retourne 200. Si vous obtenez des faux positifs (Googlebot bloque par exemple), excluez explicitement les IP officielles via une rule de skip prioritaire.

Etape 14 : pieges courants et debug

Premier piege : oublier que les cookies invalident le cache par defaut. Si votre site pose un cookie analytics avant meme l acceptation RGPD, chaque visiteur recoit un MISS et le cache devient inutile. Solution : delayer le set-cookie apres consentement, ou ajouter une Cache Rule avec Cache Key qui ignore certains cookies.

Deuxieme piege : penser que Purge Everything est gratuit en consequences. Sur un site a trafic moyen, le pic vers origin apres purge totale peut saturer un VPS 2 GB pendant 5 a 10 minutes. Privilegiez la purge ciblee, et si purge totale necessaire, faites-la en heure creuse (3h du matin heure locale).

Troisieme piege : tester en navigation privee pensant que c est neutre. Cloudflare distingue mobile vs desktop par defaut, et certains plans servent un cache different selon le User-Agent. Testez aussi avec curl pour avoir une mesure non polluee.

Etape 15 : recapitulatif et migration depuis Page Rules

Si vous avez encore des Page Rules legacy actives, listez-les dans Rules – Page Rules. Pour chacune, identifiez le type d action et migrez vers la rule correspondante : Cache Level vers Cache Rules, Forwarding URL vers Redirect Rules, Host Header Override vers Origin Rules, Auto Minify et SSL settings vers Configuration Rules. Cloudflare propose un convertisseur automatique dans Rules – Overview qui suggere les equivalences.

Apres migration, gardez les Page Rules en pause une semaine pour comparer. Si tout fonctionne, supprimez-les. Cette discipline de migration progressive evite les regressions silencieuses qu un cutover brutal provoquerait.