Panne mondiale chez Cloudflare : 2 h 28 d’interruption pour des services critiques

Le 12 juin 2025, Cloudflare a subi une panne majeure de 2 h 28, paralysant plusieurs de ses services critiques dans le monde entier.

Le 12 juin, il est presque 20 heures à Paris, l’équipe WARP de Cloudflare (son VPN) signale des échecs dans l’enregistrement de nouveaux appareils ; moins de 15 minutes plus tard, le service Access déclenche une alerte en raison d’une hausse anormale des erreurs. À 18 h 06, les incidents isolés sont regroupés après identification du problème : l’indisponibilité de Workers KV. La priorité passe à P1, puis à P0 dès 20 h 21, signe d’une urgence maximale. L’incident est maîtrisé à partir de 22 h 23, avec retour aux niveaux de service habituels à 22 h 28.

Origine du problème et localisation

Le cœur du dysfonctionnement provient d’un composant de stockage central utilisé par Workers KV, rupture provenant d’un fournisseur tiers, identifié comme une infrastructure Google Cloud Platform. Cette infrastructure, pourtant critique, présentait un point de défaillance singulier, malgré le caractère « coreless » supposé de Workers KV. Si l’enregistrement de nouveaux clients a posé probléme, le fait de ne pas se connecter à son dashboard (son administration client) est plus problématique. Plus possible de connexions par mot de passe, Google OIDC et SSO inaccessibles . L’API v4 est restée fonctionnelle.

Aucune intrusion ou incident lié à la sécurité n’est signalé. Aucun perte de données n’est constatée. Les services Magic Transit, Magic WAN, DNS, CDN, proxy, WAF et API v4 sont restés opérationnels.

Des analystes rapportent que l’incident s’inscrit dans un contexte global de défaillance Google Cloud, qui a affecté d’autres grands noms de la tech comme Google, Spotify ou Discord. La ruée vers le cloud unique est montrée du doigt, malgré les systèmes multi régionaux. Dans les forums (Reddit, …), de nombreux retours soulignent la dépendance de Cloudflare à GCP pour le stockage KV « cold » en soulignant une mauvaise protection contre les points de défaillance.

Cloudflare a accélère plusieurs actions comme la migration vers une infrastructure propre (R2 interne) pour le stockage central de KV. Renforcement de la redondance, suppression de toute dépendance unique. Outils pour réactiver progressivement des namespaces durant un incident.

Ce qui est « ballot » c’est que ces actions étaient en cours lors de la panne, avec une bascule en temps réel sur une architecture alternative.

Cet incident a révélé la fragilité d’une dépendance essentielle à un prestataire externe, malgré des architectures multi régions. Cloudflare revendique sa responsabilité entière, promet des renforts de résilience et anticipe d’autres améliorations dans les mois à venir.