--- service: "Publicasta" schema_version: "1.0" article_id: 343 title: "La controverse Cloudflare Web Analytics : quand les réglages CDN deviennent des changements en production" language: "fr" default_language: "en" canonical_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance?lang=fr" json_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance.json?lang=fr" api_url: "https://publicasta.com/api/public/v1/channels/it_today_news/articles/cloudflare_web_analytics_rum_edge_defaults_governance?lang=fr" channel_url: "https://publicasta.com/api/public/v1/channels/it_today_news" channel_articles: "https://publicasta.com/api/public/v1/channels/it_today_news/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-08-17T13:42:03+00:00" updated_at: "2026-08-17T13:42:03+00:00" translations: - language: "ar" html_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance?lang=ar" markdown_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance.md?lang=ar" json_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance.json?lang=ar" - language: "de" html_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance?lang=de" markdown_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance.md?lang=de" json_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance.json?lang=de" - language: "en" html_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance?lang=en" markdown_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance.md?lang=en" json_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance.json?lang=en" - language: "es" html_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance?lang=es" markdown_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance.md?lang=es" json_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance.json?lang=es" - language: "fr" html_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance?lang=fr" markdown_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance.md?lang=fr" json_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance?lang=pl" markdown_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance.md?lang=pl" json_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance?lang=ru" markdown_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance.md?lang=ru" json_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance?lang=zh" markdown_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance.md?lang=zh" json_url: "https://publicasta.com/it_today_news/cloudflare_web_analytics_rum_edge_defaults_governance.json?lang=zh" --- # La controverse Cloudflare Web Analytics : quand les réglages CDN deviennent des changements en production > Le débat sur le RUM de Cloudflare rappelle que les réglages edge doivent être audités comme des mises en production. Un fil Hacker News très commenté le 16 août a transformé un réglage Cloudflare discret en leçon d’exploitation. Le propriétaire d’un site attendait une page sans JavaScript, a déplacé son domaine vers Cloudflare et a découvert dans le HTML livré un script `static.cloudflareinsights.com/beacon.min.js` accompagné de `data-cf-beacon`. Le titre du fil accusait le changement de nameservers, mais la frontière technique est plus précise : le DNS seul ne réécrit pas le HTML. L’insertion concerne le trafic proxied, lorsque la réponse passe par l’edge de Cloudflare. ![Schéma montrant le HTML d’origine passant par un proxy edge où un petit beacon RUM est ajouté avant le navigateur](https://publicasta.com/storage/projects/17/pages/343/2026/08/b94fcc9f-2caf-4787-b702-af6b19ae2ad1.webp) ## Ce qui s’est passé Le signal public vient du fil “Tell HN: Cloudflare silently injects its analytics when you switch nameservers”, qui comptait des centaines de votes et plus d’une centaine de commentaires au moment de la vérification. Un forum ne suffit pas comme preuve produit ; la base fiable est la documentation Cloudflare. Les pages Web Analytics et Observatory RUM décrivent un beacon JavaScript qui peut être injecté automatiquement pour les sites proxied. Le billet du 17 septembre 2025 annonçait l’activation par défaut de Web Analytics pour les domaines gratuits à partir du 15 octobre 2025, hors trafic EU et UK. La documentation actuelle prévoit aussi la désactivation ou l’installation manuelle du snippet. Cette combinaison explique la réaction. Pour Cloudflare, il s’agit de mesure de performance centrée sur la confidentialité. Pour des opérateurs, c’est une modification d’une réponse de production par un tiers sans déploiement depuis l’origin. Les deux lectures peuvent coexister : le beacon peut être documenté et utile, mais l’ajout d’un script à l’edge reste un changement visible par l’utilisateur. ## DNS-only et proxied La précision évite de mauvaises conclusions. Un enregistrement DNS-only résout un nom ; il ne place pas Cloudflare dans le chemin HTTPS qui transporte le HTML et ne peut pas ajouter du code au corps de la page. Un enregistrement proxied est différent : le reverse proxy reçoit la requête, peut appliquer WAF, cache, compression, observabilité, contrôles anti-bots et transformations, puis renvoie la réponse au navigateur. Dans le tableau de bord, cela ressemble parfois à une différence d’icône. En architecture, c’est la question de savoir qui contrôle le dernier kilomètre applicatif. Pour des domaines R2, Pages, origins classiques ou sous-domaines, il faut identifier quels hostnames sont proxied et quels produits s’y appliquent. Si le fournisseur peut ajouter des headers, lancer un challenge, injecter un beacon ou transformer le HTML, il fait partie du runtime de l’application. ## Web Analytics et RUM Cloudflare Web Analytics est présenté comme une analytique de performance respectueuse de la vie privée. Le beacon RUM collecte des données issues des APIs de performance du navigateur : navigation timing, resource timing, paint timing, Core Web Vitals comme LCP, CLS, TTFB et INP, et mesures liées au chargement. La documentation data origin indique `https://static.cloudflareinsights.com/beacon.min.js` comme source du script et `/cdn-cgi/rum` comme endpoint pour les sites proxied. Il faut également rappeler les limites documentées. Cloudflare affirme que le beacon n’accède pas aux cookies, à `localStorage`, `sessionStorage`, l’adresse IP ou `IndexedDB`, et que l’adresse IP reçue durant le traitement HTTP normal est supprimée au centre de données le plus proche. Le sujet ne doit donc pas être présenté comme du pistage par cookies ou un malware. Le problème est qu’un réglage d’infrastructure a modifié la page livrée. ## Pourquoi les opérateurs protestent Le problème n’est pas seulement un fichier JavaScript en plus. Certains sites promettent l’absence de JavaScript. Des organisations publiques, médicales, financières, éducatives ou médiatiques tiennent un inventaire des scripts tiers. Beaucoup exigent une revue des notices de confidentialité, registres de traitement, consentement, CSP, SRI, tests de sécurité et fournisseurs avant tout code exécuté dans le navigateur. La confiance est aussi en jeu. L’origin a produit une séquence d’octets, le navigateur en reçoit une autre. Pour les équipes qui s’appuient sur des déploiements reproductibles, une CSP stricte, l’intégrité des ressources ou un audit de supply chain, la mutation à l’edge n’est pas un détail. Si elle est découverte par un utilisateur ou un fil de forum plutôt que par un ticket de changement, le processus est déjà insuffisant. ## Ce n’est pas une panique malware Le bon ton est technique. Cloudflare est un fournisseur majeur, Web Analytics est un produit officiel et l’injection automatique est documentée. Le beacon mesure la performance réelle ; il n’est pas décrit comme un code de vol d’identifiants ou de lecture du stockage navigateur. Qualifier tout script ajouté d’attaque rend l’analyse moins utile. La distinction utile est l’autorisation. Un script peut être bénin mais non autorisé sur un site donné. Un réglage par défaut peut aider des clients gratuits tout en étant trop large pour du trafic réglementé. Un fournisseur peut réduire les données personnelles tout en déclenchant une revue conformité. Une décision mature peut être différenciée : acceptable sur des pages marketing, interdite dans une application authentifiée, autorisée sur la documentation après approbation. ## Le problème de gouvernance L’edge moderne n’est plus une tuyauterie passive. CDN, WAF, bot management, fonctions serverless, analytique, optimisation d’images, obfuscation d’e-mail, challenges et produits de performance se placent entre l’origin et l’utilisateur. Leurs réglages par défaut peuvent modifier octets, headers, exécution JavaScript, cache, latence, télémétrie et erreurs. C’est une surface de supply chain. Les organisations ont donc besoin d’un modèle de changement pour l’edge. Les actions dans le tableau de bord doivent avoir un propriétaire. Les defaults gratuits doivent être revus comme des dépendances. Les annonces fournisseurs doivent être reliées à des zones et hostnames concrets. Toute transformation automatique du response body doit entrer dans le change management quand le site est sensible, réglementé ou annoncé comme sans JavaScript. ## Checklist d’audit Commencez par un diff. Récupérez la même page directement depuis l’origin et via le hostname public, puis comparez HTML, headers et inventaire des scripts. Cherchez `static.cloudflareinsights.com`, `data-cf-beacon`, `/cdn-cgi/rum`, scripts anti-bots, email decode, Rocket Loader, Zaraz, challenge scripts, URLs d’images transformées et endpoints de reporting inattendus. Faites-le aussi sur les sous-domaines. Revoyez Web Analytics, Observatory, Speed, Zaraz, Rules, Transform Rules, Page Rules, Workers routes, Snippets, Bot Management, WAF managed challenges et cache settings. L’objectif n’est pas de désactiver tout produit, mais de connaître ceux qui changent ce que voit le navigateur et qui les a approuvés. Utilisez CSP avec méthode. Le guide MDN explique que Content Security Policy limite les ressources qu’une page peut charger. Un `script-src` strict peut bloquer un beacon inattendu, et `Content-Security-Policy-Report-Only` permet de mesurer l’impact avant enforcement. Mais CSP ne remplace pas l’hygiène de configuration : bloquer un script inséré par le fournisseur peut créer du bruit et des métriques manquantes si la fonction reste active. Testez `Cache-Control: public, no-transform` lorsque c’est adapté. La FAQ Cloudflare indique qu’avec cet en-tête le proxy ne peut pas modifier le payload original, donc le beacon n’est pas injecté automatiquement. Ce n’est pas une règle universelle : elle peut supprimer des optimisations utiles et doit être testée sur des pages représentatives. ## Checklist de migration Avant de déplacer un domaine, décidez par hostname s’il doit être DNS-only ou proxied. Si le cache CDN ou le WAF est nécessaire, le proxy peut être la bonne option. Si les octets de l’origin doivent rester exacts, DNS-only ou une autre architecture peut être préférable. Ne laissez pas un assistant de migration prendre implicitement cette décision. Après activation du proxy, auditez depuis le navigateur et la ligne de commande : HTML livré, headers, rapports CSP, beacons de performance, source maps, service workers, scripts tiers et requêtes vers les endpoints du fournisseur. Testez plusieurs zones géographiques lorsqu’une exclusion régionale est documentée. Pour les sujets légaux, fournissez les faits à la conformité ou au conseil juridique. ## Leçon générale Le débat se répétera avec d’autres plateformes. Plus l’edge est utile, moins il est neutre. L’observabilité a de la valeur, mais elle doit être explicite, vérifiable et réversible. La règle pratique est simple : si un réglage peut changer ce que reçoit le navigateur, il doit être traité comme un changement de production.