Un matin, le directeur e-commerce d’un de nos clients découvre un trafic organique amputé de 35 %. Dans la Search Console, 8 000 pages viennent de basculer en « Exploration bloquée ». La panique. L’équipe a passé la nuit à chercher une cause SEO, une balise noindex mal placée, un déploiement foireux. Le coupable était ailleurs : une règle de pare-feu poussée la veille sans vérifier le comportement vis-à-vis de Googlebot.
Depuis, je vérifie toujours deux choses avant qu’un client active un nouveau WAF. Ce que Google voit. Et ce que ça coûte en millisecondes.
Un pare-feu applicatif, ce n’est pas un bouclier magique
Un WAF intercepte le trafic HTTP avant l’application. Injections SQL, force brute, scans automatisés : il bloque l’essentiel. Puis il devient zélé.
Sur un site e-commerce en Next.js, j’ai mesuré un TTFB multiplié par trois parce qu’une règle de filtrage inspectait chaque requête, y compris les statiques déjà en cache à l’edge. LCP à 4.8s sur les fiches produit, contre 200 ms en HTML sans pare-feu.
Un WAF ajoute toujours de la latence. La question est combien. La plupart des équipes ne mesurent pas.
Le WAF qui efface 40 % du crawl en une nuit
Googlebot ne se comporte pas comme un navigateur classique. Il envoie des en-têtes spécifiques, utilise des plages d’IP dédiées, et ne conserve pas de cookies de session. Une règle qui exige un cookie de session ou un token CSRF pour accéder à une page bloque l’exploration, point.
On a vu un site perdre 40 % de son crawl après une config WAF plus stricte. Le pare-feu redirigeait Googlebot en boucle vers un challenge JavaScript. Aucune alerte n’est remontée : le monitoring applicatif ne vérifiait pas la perspective du bot.
Test rapide : curl -I -H "User-Agent: Googlebot" sur tes URLs critiques. Un 403 ou un 302 vers un challenge, et ton crawl s’assèche en silence.
Le vrai coût du WAF sur le LCP : 500 ms qui n’apparaissent pas dans le flamegraph
Le LCP est mesuré côté utilisateur, via le navigateur. Le TTFB, lui, inclut le temps passé dans le réseau, y compris le traitement par le pare-feu. Quand un WAF inspecte le contenu avant de le servir, cette latence s’ajoute à la réponse, avant que le HTML ne commence à être parsé.
Un piège classique : le WAF est configuré pour analyser toutes les réponses 200, y compris les assets statiques comme les fichiers CSS ou les polices. Ces ressources contribuent au rendu et leur retard repousse le LCP. Dans un test réel, j’ai retiré l’inspection des fichiers statiques d’un CDN avec WAF intégré. Le LCP a chuté de 1.2s dans le champ. La mesure de laboratoire, elle, ne montrait rien parce que l’environnement de test ne simulait pas le pare-feu.
Le diagnostic passe par l’observation des timings réseau dans les DevTools, ou via l’API PerformanceObserver pour récupérer le responseStart. Si le delta entre requestStart et responseStart dépasse 400 ms sur des ressources légères, le firewall mérite toute ton attention.
Googlebot n’est pas un humain : les User‑Agents à ne jamais toucher
Les listes noires par User-Agent sont une fausse bonne idée. Google utilise plusieurs User‑Agents pour l’exploration desktop, mobile, et pour les médias audio ou vidéo. Autoriser explicitement Googlebot et Googlebot-Image sans CAPTCHA ni cookie obligatoire est la base. Si ton WAF a une protection anti-bot, base-la sur le comportement, pas sur le User-Agent.
Edge computing : pourquoi le WAF doit vivre avant le cache
Là où déployer le pare-feu change tout, c’est la position dans la chaîne de traitement. Si le WAF s’exécute après la réponse servie par le cache, chaque visiteur subit l’inspection, même quand le contenu n’est pas dynamique. La charge CPU des edge functions augmente, le TTFB grimpe, et le LCP des utilisateurs réels encaisse.
En inversant l’ordre, le WAF filtre la requête en amont du cache. Une fois la requête validée, la réponse est délivrée directement depuis le cache, sans repasser par la couche de sécurité. Les visiteurs légitimes bénéficient alors de la même latence que sans pare-feu, tandis que les requêtes malveillantes sont arrêtées avant d’atteindre l’application. Cette approche s’applique à la plupart des plateformes d’edge computing, et c’est le schéma que nous adoptons pour ne jamais sacrifier le Core Web Vitals sur l’autel de la sécurité.
Quand on déploie ce genre de règles, on passe souvent plus de temps à éplucher les logs qu’à coder. Naviguer dans des fichiers de configuration et tester des règles à la volée exige un environnement réactif. Certains collègues préfèrent Claude Code en ligne de commande, d’autres restent fidèles à Cursor pour éditer et débugger leurs edge functions directement dans un IDE. Peu importe l’outil, l’essentiel est de pouvoir simuler l’impact du pare-feu avant de l’activer en production.
Reprendre le contrôle : un plan en trois mesures
La première chose à faire, c’est isoler le trafic de test. Active le WAF sur une fraction du trafic via un système de routage conditionnel (par cookie ou par pourcentage) et observe le TTFB, le crawl et les erreurs Search Console pendant 48 heures. Ne déploie jamais une règle de blocage avant d’avoir validé qu’elle épargne Googlebot.
Deuxième mesure : déplace l’inspection des contenus statiques hors du chemin critique. Si ton WAF le permet, exclue les extensions .css, .js, .woff2 de l’analyse corps de réponse. Ou place le cache devant le pare-feu pour ces ressources. Le gain est immédiat.
Troisième point : instrumente la surveillance. Ajoute un test synthétique qui simule Googlebot toutes les heures, et un monitoring côté client qui mesure le TTFB ventilé par percentile. Trop d’équipes vérifient la sécurité mais pas la performance. Un WAF qui te coûte 15 % de taux de rebond sur mobile parce que le LCP dépasse 4s n’est pas un succès, même s’il bloque toutes les attaques.
Questions fréquentes
Un pare-feu réseau suffit-il pour un site statique ?
Non. Un pare-feu réseau filtre par IP et port, il ne comprend pas le HTTP. Pour un site statique hébergé sur CDN, un WAF au niveau application est nécessaire si tu veux bloquer des attaques par injection ou des scans de mots de passe sur un formulaire. Mais tu peux limiter son périmètre aux seuls endpoints dynamiques pour éviter de pénaliser le LCP.
Comment détecter qu’un WAF bloque Googlebot sans accès aux logs serveur ?
Utilise l’outil d’inspection d’URL de la Search Console. Si le test d’exploration renvoie « bloquée » ou « redirigée », croise la date avec les changements récents de configuration. Tu peux aussi programmer un script qui appelle tes URLs avec le User-Agent Googlebot et vérifie le code de statut. Un 200 suivi d’un contenu vide ou d’un challenge JavaScript est aussi suspicieux qu’un 403.
Est-ce qu’un WAF peut casser le rendu d’une application React ?
Oui, si une règle bloque les appels API ou altère les en-têtes CORS. L’application se retrouve avec des données partielles, ce qui peut laisser le state management dans un état incohérent. C’est une situation proche des bugs qu’on rencontre avec une librairie comme Zustand quand l’état initial est absent. Dans les deux cas, la couche réseau est le premier suspect à éliminer.
