Guide complet du bouclier 5 secondes Cloudflare : 3 astuces de configuration pour limiter l'impact SEO et UX

Introduction

CPU serveur à 100 %, trafic multiplié par 10 — attaque CC typique. J’active « I’m Under Attack » dans Cloudflare ; 30 secondes plus tard, la pression serveur redescend.

Le lendemain, Google Search Console : l’indexation passe de plus de 1200 à environ 800 pages, -30 %. Le bouclier 5 s bloque aussi les crawlers.

Sans bouclier 5 s, l’attaque tient ; avec, SEO et UX en souffrent. Cet article explique comment défendre efficacement tout en limitant l’impact SEO et l’expérience utilisateur.

Chapitre 1 : Qu’est-ce que le bouclier 5 secondes (mode Under Attack) ?

Fonctionnement : que se passe-t-il pendant ces 5 secondes ?

En bref, Cloudflare place une barrière de validation entre votre site et les visiteurs. Au lieu d’un accès direct, une page intermédiaire s’affiche pendant environ 5 secondes.

Ces 5 secondes ne sont pas perdues. Cloudflare effectue trois étapes :

Étape 1 : le navigateur envoie une première requête ; Cloudflare écrit le cookie __cfduid, un passe temporaire.

Étape 2 : seconde requête avec paramètres chiffrés ; après validation, Cloudflare écrit cf_clearance, le vrai passe, validité 30 minutes par défaut.

Étape 3 : le navigateur demande la page avec les deux cookies ; Cloudflare vérifie et laisse passer. Le contenu se charge alors.

En arrière-plan, Cloudflare fait aussi :

• Validation JavaScript : code JS obfusqué pour vérifier l’exécution JS du navigateur. Les crawlers simples et scripts d’attaque échouent souvent ici.
• Empreinte navigateur : résolution d’écran, extensions, polices système — une « empreinte » unique pour repérer les outils d’attaque déguisés en navigateur.
• Détection comportementale : fréquence des requêtes, User-Agent, trajectoire souris — humain ou bot ?

Différences avec les autres niveaux de sécurité

Cloudflare propose plusieurs niveaux, pas seulement le bouclier 5 s :

En pratique, Medium suffit au quotidien. I’m Under Attack uniquement sous attaque réelle. Ne pas laisser le bouclier 5 s actif en permanence.

Ce que le bouclier 5 s peut bloquer

Les attaques réseau suivent le modèle OSI en 7 couches ; plus haut = plus proche de l’application.

Le bouclier 5 s cible surtout les attaques couche 7 (application), les attaques CC (Challenge Collapsar) : trafic simulant des utilisateurs normaux en volume massif pour épuiser les ressources serveur.

Pour les DDoS volumétriques (UDP Flood, SYN Flood), l’effet est limité ; Cloudflare utilise d’autres mécanismes. La doc officielle le présente comme un « dernier recours », pas une solution universelle.

Formulation Cloudflare : « effectuer des contrôles de sécurité supplémentaires pour atténuer les attaques DDoS couche 7 ». « Atténuer », pas « bloquer totalement ». Face à un DDoS massif, le bouclier 5 s seul ne suffit pas — compléter avec d’autres mesures.

Chapitre 2 : Impact réel sur le SEO et l’expérience utilisateur

Les crawlers peuvent-ils passer le bouclier 5 s ?

J’ai testé : ça dépend.

Googlebot exécute JavaScript et peut théoriquement passer. Mais le temps de crawl est précieux — il ne « attend pas poliment » 5 s ; il part ailleurs et revient plus tard.

Observations dans Google Search Console après activation :

1. Fréquence de crawl en baisse : ~1200/jour → 400-600/jour.
2. Plus d’erreurs : timeouts et erreurs serveur.
3. Indexation plus lente : 1-2 jours → 4-5 jours pour un nouvel article.

Baiduspider est plus mal loti : faible JS, échec de crawl fréquent. Un ami sur site chinois : 3 jours de bouclier 5 s, indexation Baidu de 2000+ à un peu plus de 1000.

Bing est entre les deux : passage possible mais lent, baisse d’indexation de 15-20 %.

Données réelles sur l’expérience utilisateur

Un A/B test sur mon site :

Taux de rebond :

• Avant : 35 %
• Après : 62 %
• Hausse : 77 %

Environ 6 visiteurs sur 10 quittent après la page d’attente de 5 s. Sur mobile, jusqu’à 75 %.

Temps moyen sur site :

• Avant : 3 min 15 s
• Après : 1 min 48 s
• Baisse : 45 %

Conversion divisée par deux :

Avec objectifs d’inscription ou d’achat, attendez une chute de moitié. L’utilisateur clique, attend 5 s — l’enthousiasme retombe.

Un ami e-commerce : sous attaque, bouclier 5 s activé ; commandes de ~60/jour à 22. L’attaque est bloquée, le chiffre d’affaires aussi.

Distorsion des outils d’analyse

Piège discret. La doc Cloudflare : « L’interférence avec les outils d’analyse dépendant de JavaScript est attendue. »

Google Analytics sous-estime le trafic :

• Pas de code GA sur la page d’attente de 5 s
• Les rebonds ne sont pas comptés
• Les chiffres ne reflètent que les visiteurs validés — le trafic réel est plus élevé

Heatmaps inutilisables :

Hotjar, Crazy Egg, etc. ne capturent pas le comportement sur la page d’attente. Vous croyez que tout le monde entre ; la moitié part à la porte.

Suivi publicitaire aveugle :

Google Ads, Facebook Ads : le tracking de conversion s’effondre. Facebook Pixel, tags Google Ads ne se chargent pas — budget dépensé, données absentes.

Catastrophe pour API et services tiers

Pour le web, c’est gérable ; pour l’API, c’est critique.

Problème 1 : échec total des requêtes API

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

Les appels API sont machine-à-machine, pas navigateur. Pas de JavaScript, pas d’attente de 5 s — erreur directe.

Cas extrême : une app mobile sur API Cloudflare, bouclier 5 s activé par erreur sur tout le site — 50 000+ utilisateurs actifs bloqués instantanément.

Problème 2 : intégrations tierces coupées

• Callbacks paiement (PayPal, Stripe)
• Webhooks (GitHub, Slack)
• Abonnements RSS
• Monitoring (Uptime Robot)

Ces services ne passent pas la validation — tout est intercepté. Callback paiement en échec : l’utilisateur paie, votre site ne reçoit pas la notification, statut de commande figé.

Problème 3 : applications mobiles inaccessibles

App iOS/Android via Web API : bouclier 5 s site entier = app inutilisable. Loading infini, puis « erreur réseau ».

Conclusion : avec API, app mobile ou intégrations critiques, ne jamais activer le bouclier 5 s sur tout le site. Exclure ces chemins via Page Rules — chapitre 3.

Chapitre 3 : Activer le bouclier 5 s sur des chemins précis (Page Rules)

Qu’est-ce que Page Rules ?

Page Rules = règles conditionnelles Cloudflare. Niveau de sécurité, cache, etc. par chemin URL.

Exemples :

• example.com/api/* → Low, pas d’interception
• example.com/admin/* → I’m Under Attack
• Autres pages → Medium

Protection ciblée : seulement là où c’est nécessaire.

Mauvaise nouvelle : en juin 2024, Cloudflare annonce la dépréciation progressive de Page Rules au profit de Configuration Rules, Cache Rules, etc. Bonne nouvelle : les Page Rules existantes restent utilisables ; la migration est gérée par Cloudflare.

Gratuit : 3 Page Rules — suffisant pour beaucoup de sites personnels. Pro : 20. Business : 50.

Correspondance URL : utiliser le joker *

Le cœur de Page Rules : le motif URL avec *.

Règles de base :

• * = toute chaîne (y compris vide)
• Utilisable partout dans l’URL
• Plusieurs * possibles

Motifs courants :

example.com/api/*
→ correspond example.com/api/users
→ correspond example.com/api/posts/123
→ ne correspond pas example.com/apiv2/users (pas de slash après api)

example.com/*.jpg
→ correspond example.com/logo.jpg
→ correspond example.com/images/banner.jpg
→ ne correspond pas example.com/logo.png

example.com/*admin*
→ correspond example.com/wp-admin
→ correspond example.com/admin/users
→ correspond example.com/myadmin

Priorité (crucial) :

Exécution de haut en bas ; la première règle correspondante s’applique, les suivantes sont ignorées.

1. Règles spécifiques en haut, jokers en bas
2. Ordre inversé : le joker intercepte tout, les règles précises ne s’exécutent jamais

Exemple incorrect :

Règle 1: example.com/* → Security Level: I'm Under Attack
Règle 2: example.com/api/* → Security Level: Low

La règle 2 ne s’appliquera jamais.

Ordre correct :

Règle 1: example.com/api/* → Security Level: Low
Règle 2: example.com/* → Security Level: I'm Under Attack

Scénario 1 : protéger connexion et admin

Besoin fréquent : les attaques ciblent souvent la connexion (force brute).

WordPress, par exemple :

Règle 1 : wp-admin

• URL : example.com/wp-admin*
• Security Level → I’m Under Attack

Règle 2 : page de connexion

• URL : example.com/wp-login.php
• Security Level → I’m Under Attack

Règle 3 : reste du site

• URL : example.com/*
• Security Level → Medium

Seuls admin et connexion déclenchent le bouclier 5 s ; le reste du site et le SEO restent normaux.

Scénario 2 : exclure l’API

Ne jamais laisser le bouclier 5 s intercepter l’API.

Règle 1 : API faible sécurité

• URL : example.com/api/*
• Security Level → Low

Règle 2 : API sous-domaine mobile

• URL : api.example.com/*
• Security Level → Low

Règle 3 : reste haute sécurité

• URL : example.com/*
• Security Level → I’m Under Attack

Règles API en premier.

Plusieurs versions API :

example.com/api/v1/*
example.com/api/v2/*

Consomme des règles. Alternative :

example.com/api*

Tous les chemins commençant par /api.

Scénario 3 : pages dynamiques protégées, statiques autorisées

Images, CSS, JS n’ont généralement pas besoin du bouclier 5 s ; les bloquer casse le chargement.

Règle 1 : images

• URL : example.com/*.jpg
• Security Level → Low, Cache Level → Cache Everything

Règles similaires pour .png, .css, .js — ou mieux, CDN dédié :

• cdn.example.com/* → Security Level: Low

Règle 2 : pages dynamiques

• URL : example.com/*
• Security Level → I’m Under Attack

Le HTML est protégé ; images et CSS se chargent normalement — meilleure UX.

Configuration complète pas à pas

Étape 1 : Dashboard Cloudflare

cloudflare.com → connexion → choisir le domaine.

Étape 2 : Page Rules

Menu gauche : Rules → Page Rules
(Nouveau dashboard : Rules → Page Rules (Legacy))

Étape 3 : première règle

Create Page Rule → If the URL matches :

example.com/api/*

+ Add a Setting → Security Level → Low → Save and Deploy.

Étape 4 : autres règles

Répéter l’étape 3. L’ordre compte.

Étape 5 : priorité

Liste des règles : icône « trois barres » à gauche pour glisser-déposer. Spécifiques en haut, jokers en bas.

Étape 6 : tests

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

Navigation privée :

• Chemins API : pas de bouclier 5 s ✓
• Pages normales : bouclier 5 s ✓
• Statiques : chargement OK ✓

Optimiser 3 règles gratuites

Règle 1 : entrée critique

example.com/wp-admin*
Security Level: I'm Under Attack

Règle 2 : API et statiques

example.com/api*
Security Level: Low

Règle 3 : reste

example.com/*
Security Level: Medium

Zones critiques protégées, usage quotidien préservé. Sans attaque active, ne pas passer à I’m Under Attack.

Chapitre 4 : Durée de passage du défi (Challenge Passage)

Définition

Après la première validation, Cloudflare stocke cf_clearance dans le navigateur — un « passe temporaire ». Tant qu’il est valide, pas de nouvelle page de défi.

Challenge Passage = durée de validité de ce passe.

Défaut : 30 minutes — navigation libre pendant 30 min, puis revalidation.

Détails techniques :

Tampon décalage horaire : quelques minutes supplémentaires pour éviter les faux négatifs si horloge client/serveur diverge.

Requêtes XmlHTTP : pour Ajax, Cloudflare accorde jusqu’à 1 h supplémentaire — utile pour les SPA à cache court.

Héritage du niveau de sécurité : un cookie obtenu via Interactive Challenge (défi strict) passe tous les niveaux ; un cookie de niveau bas peut exiger une revalidation face à un défi plus strict.

Où configurer

Dashboard Cloudflare :

Security → Settings → Challenge Passage

Modifier le délai en minutes. Plage recommandée : 15-45 minutes.

Paramètre global pour tout le domaine — pas de réglage par chemin.

Valeurs recommandées par scénario

Haute sécurité (finance, paiement, données sensibles) : 15-20 min

• Banque en ligne, paiement, OA entreprise
• Sécurité maximale, sessions courtes, revalidation acceptable
• Revalidation toutes les 15 min — un peu pénible mais compréhensible

Équilibré (e-commerce, corporate, SaaS) : 30 min (défaut)

• La plupart des sites commerciaux
• Compromis sécurité/expérience ; suffisant pour un achat ou une visite
• La plupart des utilisateurs terminent en moins de 30 min

UX prioritaire (contenu, blog, média) : 40-45 min

• Presse, blogs techniques, vidéo
• Sessions longues, navigation multi-pages
• Lire plusieurs articles sans interruption

Mon blog technique : 40 min. Les lecteurs enchaînent souvent plusieurs articles ; 30 min peut être juste.

Trois idées reçues

Idée 1 : plus court = plus sûr

5 minutes = revalidation toutes les 5 min = sécurité maximale ? Faux.

Le bouclier 5 s distingue humains et machines, pas les revisites d’une même personne. Revalider un humain toutes les 5 min l’agace sans gain réel.

Le trafic malveillant est soit bloqué dès la première fois (pas de cookie), soit contourne la validation (5 ou 30 min, pareil).

Idée 2 : plusieurs heures pour le confort

2 heures = meilleure UX ? Non — cookie trop long = risque sécurité.

Scénario :

1. Utilisateur sur WiFi public de café, passe la validation
2. Il part, cookie encore valide
3. Quelqu’un d’autre sur le même WiFi (ou un attaquant) récupère le cookie
4. Pendant 2 h, accès libre pour l’attaquant

Plafond 45 min recommandé par Cloudflare — ne pas allonger arbitrairement.

Idée 3 : s’applique à toutes les règles

Piège personnel : Challenge Passage configuré, mais certaines règles déclenchent encore des validations.

Challenge Passage ne s’applique pas aux Rate Limiting Rules. Avec Rate Limiting, dépassement = revalidation, quelle que soit la durée de passage.

Comment juger si votre réglage convient

Ne vous fiez pas au ressenti seul. Indicateurs :

1. Plaintes utilisateurs

« Encore 5 secondes d’attente » → durée peut-être trop courte. Analyser le parcours type et ajuster.

2. Security Events

Security → Events : nombre de défis par jour. Même IP déclenchant souvent en peu de temps → durée peut-être trop courte.

3. Rebond et temps sur site

Rebond en hausse, temps en baisse → revalidation en cours de navigation, mauvaise UX.

Configurer, observer une semaine, ajuster. Éviter les valeurs extrêmes dès le départ.

Combiner avec le WAF

Souvent, pas besoin de bouclier 5 s site entier + revalidation fréquente. WAF + bouclier ciblé :

1. WAF pour le trafic manifestement malveillant

   • Blocage plages IP connues
   • Interception UA anormaux
   • Limitation de fréquence

2. Bouclier 5 s sur chemins critiques

   • Page Rules : connexion, inscription, paiement
   • Reste : Medium ou High

3. Challenge Passage raisonnable

   • Pas de cycle ultra-court
   • 30 min suffit pour la plupart des sites

~90 % du trafic malveillant filtré par le WAF ; le reste passe par le bouclier 5 s — sécurité sans pénaliser les utilisateurs légitimes.

Chapitre 5 : 7 bonnes pratiques pour le bouclier 5 secondes

Pratique 1 : ne pas activer en permanence sur tout le site

Erreur fréquente des débutants : panique sous attaque, activation du bouclier 5 s, oubli après la fin — des mois plus tard, toujours actif.

Bonnes pratiques :

• Activation temporaire en cas d’attaque visible
• Retour à Medium ou High 1-3 jours après la fin
• Monitoring (UptimeRobot, etc.)
• Rappel hebdomadaire du niveau de sécurité

Règle personnelle : alarme 48 h sur le téléphone après activation — réévaluation obligatoire.

Pratique 2 : Page Rules ciblées

Bouclier 5 s site entier = soudurer toutes les portes pour chasser un voleur. Mieux : ne verrouiller que les portes importantes.

Chemins à protéger :

1. Connexion (/login, /wp-login.php)
2. Inscription (/register, /signup)
3. Admin (/admin, /wp-admin)
4. Paiement (/checkout, /payment)
5. Formulaires (/contact, /comment)

Chemins à exclure :

1. API (/api/*, /rest/*)
2. Statiques (/*.jpg, /*.css, /*.js)
3. RSS (/feed, /rss.xml)
4. robots.txt et sitemap.xml
5. Health checks (/health, /status)

Config idéale pour un blog technique :

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

Règle 1: example.com/wp-admin* → I'm Under Attack
Règle 2: example.com/xmlrpc.php → I'm Under Attack
Règle 3: example.com/* → Medium

Pratique 3 : page de défi personnalisée

La page par défaut est en anglais — peu accueillante pour un public francophone. Offres payantes : personnalisation possible.

Configuration :

Custom Pages → 5-Second Shield → page HTML personnalisée.

Éléments recommandés :

• Logo et nom du site
• Message : « Vérification de la sécurité de votre navigateur, veuillez patienter… »
• Compte à rebours animé
• Brève explication : « Pour protéger le site contre les attaques, nous devons vérifier que vous êtes un utilisateur réel »
• Contact en cas de problème

Meilleur cas vu : mini-jeu pendant l’attente — collecter des étoiles — UX nettement améliorée.

Pratique 4 : combiner avec le WAF

Le bouclier 5 s est la dernière ligne de défense, pas le seul filtre. Le WAF élimine une grande part du trafic malveillant en amont.

Règles WAF recommandées :

Règle 1 : plages IP malveillantes connues

(ip.geoip.country in {"CN"} and cf.threat_score > 30)
→ Action: Block

(Exemple uniquement — adapter à votre audience)

Règle 2 : UA anormaux

(http.user_agent contains "curl" or http.user_agent contains "python")
→ Action: Challenge

Règle 3 : fréquence API

(http.request.uri.path contains "/api/" and rate > 100/1m)
→ Action: Block for 1h

Règle 4 : protection connexion

(http.request.uri.path eq "/wp-login.php" and rate > 5/5m)
→ Action: Challenge

~90 % du trafic malveillant intercepté en amont ; le bouclier 5 s ne traite que le reste.

Pratique 5 : liste blanche pour crawlers

Améliore nettement le SEO. Googlebot peut passer, mais un crawl fluide vaut mieux.

Méthode 1 : WAF sur User-Agent crawler

WAF Custom Rule :

(http.user_agent contains "Googlebot" or
 http.user_agent contains "Bingbot" or
 http.user_agent contains "Baiduspider")
→ Skip: Security Level for this request

Méthode 2 : plages IP crawlers connues

Google, Bing publient leurs plages IP. IP Access Rule en liste blanche.

Liste Google :
https://developers.google.com/search/docs/advanced/crawling/verifying-googlebot

Attention : User-Agent crawler falsifiable. Plus sûr : vérifier IP + UA, ou reverse DNS.

Pratique 6 : surveillance et ajustements

La configuration n’est pas figée — surveillance continue.

Checklist hebdomadaire :

1. Security Events

   • Security → Events
   • Interceptions, règles déclenchées, répartition IP
   • Faux positifs ? Ajuster ?

2. Analytics

   • Tendance trafic
   • Rebond anormal ?
   • Temps sur site en baisse ?

3. Google Search Console

   • Statistiques de crawl : fréquence en baisse ?
   • Couverture : indexation affectée ?
   • Erreurs : timeouts ou 403 en hausse ?

4. Retours utilisateurs

   • Support / e-mails « accès difficile » ?
   • Plaintes sur les réseaux sociaux ?

Habitude : chaque lundi 10 h, 15 min sur ces indicateurs, enregistrement dans un tableur. Anomalie → ajustement immédiat.

Pratique 7 : domaine dédié pour applications mobiles

Avec app iOS/Android : sous-domaine API dédié fortement recommandé.

Architecture :

• www.example.com — front web, bouclier 5 s possible
• api.example.com — API sans bouclier 5 s
• admin.example.com — admin avec bouclier 5 s + validation supplémentaire

Sécurité API :

• API Key ou JWT
• WAF pour limiter la fréquence
• Liste blanche IP sortantes de l’app mobile

Avantages :

1. App mobile non affectée
2. Front web protégable sans compromis
3. Découplage API/front, maintenance simplifiée
4. Stratégies CDN différentes par domaine

Cas client : site attaqué souvent, app 200 000 DAU. Domaine API dédié : bouclier 5 s sur le site, app intacte.

Conclusion

Trois points essentiels :

1. Le bouclier 5 s est une arme d’urgence, pas un bouclier permanent

Comme le frein d’urgence : vital au bon moment, pas pour conduire en continu. Medium + WAF au quotidien ; I’m Under Attack sous attaque réelle.

2. Page Rules = contrôle précis

Pas de bouclier 5 s site entier — le coût dépasse le bénéfice. Protéger connexion, inscription, paiement ; reste peu intrusif. 3 règles gratuites suffisent si bien configurées.

3. Équilibre sécurité/expérience = ajustement continu

Aucune config universelle. Selon type de site, comportement utilisateurs et menaces : surveiller, ajuster. 30 min est un bon point de départ — vos données tranchent.

Checklist d’action :

• Vérifier maintenant : quel niveau de sécurité Cloudflare ? Si I’m Under Attack, est-ce vraiment nécessaire ?
• Configurer Page Rules : au moins 2 règles selon le chapitre 3
• Régler Challenge Passage : 15-45 min selon votre type de site
• Tester : navigation privée sur différents chemins
• Monitoring : contrôle hebdomadaire Security Events et Analytics

Si cet article vous a aidé, partagez-le avec d’autres webmasters confrontés au DDoS. Questions ou retours d’expérience : commentaires bienvenus.