Mais que se passe-t-il chez Cloudflare ? (Et pourquoi vos sites Webflow trinquent)

Depuis juin 2025, Cloudflare a subi trois pannes majeures : le 12 juin, le 18 novembre puis le 5 décembre. Trois incidents, trois causes techniques différentes… mais un même problème de fond : des changements internes mal maîtrisés, propagés à l’échelle du réseau mondial, qui ont temporairement mis à l’arrêt une partie significative d’Internet.

1. Trois pannes en 2025 : ce qui s’est vraiment passé

1.1 – 12 juin 2025 : la panne “Workers KV” (≈ 2 h 30)

Le 12 juin, Cloudflare rencontre un incident d’environ 2 h 30 qui touche plusieurs briques clés : Workers KV (stockage distribué), Access, WARP, Gateway, mais aussi des services comme Images, Stream, Workers AI et le dashboard.

• Cause : panne d’un fournisseur de base de données externe utilisé par Workers KV.
• Effet domino : Workers KV ne répond plus, donc les produits qui s’appuient sur lui ne peuvent plus charger leurs politiques de sécurité, règles ou identités.
• Mode “fail-closed” : quand la configuration n’est pas disponible, Cloudflare préfère bloquer l’accès plutôt que laisser passer n’importe quoi — ce qui est sain en sécurité, mais brutal en termes de disponibilité.

Pour un site Webflow, ce type de panne se traduit surtout par :

• des erreurs 5xx intermittentes sur certaines ressources,
• un accès dégradé à l’interface Webflow (hébergement, API, assets).

1.2 – 18 novembre 2025 : la grande panne “Bot Management” (≈ 5–6 h)

Le 18 novembre, Cloudflare subit sa pire panne depuis 2019. Un fichier de configuration utilisé par la brique Bot Management (filtrage des bots / trafic automatisé) est mal généré et mal validé avant d’être poussé sur le réseau mondial.

• Cause : bug dans un fichier de fonctionnalités (feature file) de Bot Management, combiné à des modifications de droits dans une base de données interne.
• Propagation : la configuration est déployée trop largement et trop vite, sans limiter le blast radius (zone d’impact initiale).
• Impact : environ 5 à 6 heures d’erreurs 5xx massives sur une portion énorme du trafic mondial, touchant des services comme X, ChatGPT, Spotify, des plateformes de jeux, etc.

Vu de vos clients, c’est “Internet qui rame” ou “votre site qui ne marche plus”. Vu de vous, studio Webflow, c’est surtout un problème de :

• disponibilité perçue : on vous attribue la panne,
• crédibilité : alors que la cause est 100 % côté fournisseur d’infrastructure.

1.3 – 5 décembre 2025 : la panne “React2Shell” (≈ 25 min, 28 % du trafic HTTP Cloudflare)

Le 5 décembre, nouvelle panne, plus courte mais spectaculaire. À 08:47 UTC, une mise à jour de configuration liée à des règles de sécurité fait échouer une partie des requêtes, provoquant des 500 Internal Server Error pour environ 28 % du trafic HTTP traité par Cloudflare. L’incident est résolu vers 09:12 UTC.

Contexte : Cloudflare déploie en urgence des protections contre une vulnérabilité critique dans l’écosystème React / Next.js (CVE-2025-55182, parfois surnommée “React2Shell”). Pour inspecter correctement les requêtes potentielles, ils augmentent la taille de certains buffers de lecture dans le WAF et désactivent un outil de test interne via un killswitch.

Problème : un bug dormant dans le code se déclenche lors de cette désactivation et provoque une erreur interne dans une partie du proxy Cloudflare. Résultat : les requêtes tombent en 500 pour une partie des clients, dont LinkedIn, Zoom, Canva, Shopify, GitLab, Fortnite et d’autres services très visibles.

2. Pourquoi cela vous concerne directement si vous êtes sur Webflow

Depuis 2025, Webflow migre progressivement son hébergement vers Cloudflare : nouveaux DNS, nouvelles IP, nouvelle couche CDN / proxy, etc. Concrètement, cela signifie que :

• la résolution DNS et l’acheminement HTTP(S) de vos sites vitrine ou e-commerce passent par Cloudflare ;
• des pannes Cloudflare peuvent provoquer des erreurs 5xx côté visiteurs, même si votre projet Webflow, lui, est en parfait état côté Designer ;
• si vous ajoutez par-dessus un proxy Cloudflare privé, des règles WAF custom ou d’autres couches réseau, vous augmentez le couplage et donc le risque d’effet domino.

3. Ce que ces pannes révèlent sur le modèle Cloudflare

3.1 Un design très “fail-closed”

Cloudflare est conçu avec une logique de sécurité fail-closed : si les données de configuration ou de contrôle (politiques, identités, règles) ne peuvent pas être lues, la requête est bloquée plutôt que laissée passer. C’est logique pour protéger les clients… mais cela signifie qu’un incident sur une base de données ou une config peut rapidement se transformer en coupure visible à grande échelle.

3.2 Des configs propagées à l’échelle mondiale

Dans les trois cas, on retrouve le même problème de fond :

• un changement de config (fichier Bot Management, killswitch WAF, droits DB) est publié globalement très vite ;
• les tests n’avaient pas anticipé tous les cas extrêmes (par exemple, désactiver une règle d’un certain type) ;
• le déploiement progressif n’a pas assez limité la zone d’impact initiale.

Cloudflare annonce vouloir renforcer :

• le rollout progressif et le versioning de ses configs,
• des mécanismes fail-open ciblés (accepter temporairement un peu plus de risque plutôt que tout casser),
• des options de “break glass”, c’est-à-dire des voies de contournement d’urgence pour garder le trafic en vie même si certains systèmes de contrôle sont en panne.

3.3 Le vrai sujet : la concentration du risque

Au-delà de la technique, il y a un enjeu de modèle : une part croissante du Web dépend de quelques grands acteurs d’infrastructure (Cloudflare, AWS, Google Cloud, etc.). Quand l’un d’eux vacille, ce n’est pas “un site” mais des millions qui sont touchés.

4. Comment en parler à vos clients Webflow (et quoi mettre en place)