Le 5 décembre 2025, Cloudflare, pilier fondamental d'Internet, a subi une nouvelle panne majeure qui a brièvement paralysé d'importantes portions du web. Pour les propriétaires de sites, les équipes SRE et les utilisateurs, cet incident a brutalement rappelé la fragilité de notre internet « toujours connecté ».
Vous trouverez ci-dessous une analyse approfondie de cet événement, de son importance et des enseignements que les équipes d'infrastructure et d'application peuvent en tirer.
Résumé : que s'est-il passé le 5 décembre 2025 ?
Le matin du 5 décembre 2025, Cloudflare a connu une interruption de service mondiale qui a provoqué l'affichage de pages blanches ou d'erreurs sur de nombreux sites web pendant plusieurs minutes. La panne a affecté un large éventail de services majeurs, notamment des plateformes comme LinkedIn, Zoom, Coinbase, Canva, Groww, BookMyShow et d'autres, selon la région et les interconnexions. AP News+1
Les rédactions et les sites de surveillance ont rapporté :
Des utilisateurs voyaient des « pages vides » au lieu du contenu habituel lorsqu'ils visitaient les sites affectés. Sky News+1
Forte augmentation des erreurs 5xx et des problèmes de connectivité sur les sites web et les API utilisant le réseau périphérique de Cloudflare. Search Engine Journal
Des problèmes affectant non seulement le trafic client, mais aussi le tableau de bord et les API de Cloudflare, ce qui a dégradé la visibilité et le contrôle au moment où les clients en avaient le plus besoin. AP News+1
Bien que la panne n'ait duré que peu de temps (de 8h47 à 9h13 GMT environ, selon les premières informations), son impact a été suffisamment important pour affecter brièvement des plateformes critiques comme Coinbase et Claude AI d'Anthropic, et faire chuter le cours de l'action Cloudflare d'environ 4 à 4,5 % avant l'ouverture du marché. Reuters+1
Cloudflare a déclaré :
L'incident n'était pas dû à une cyberattaque.
Il est apparu suite à une modification interne du traitement des requêtes par le pare-feu, en réponse à une vulnérabilité récemment découverte dans React Server Components (RSC). Reuters+1
Autrement dit : une modification de la logique du pare-feu de Cloudflare, motivée par des raisons de sécurité, a entraîné un effet secondaire qui a rendu temporairement indisponible une grande partie de son réseau.
Quel a été le problème exactement ?
Du point de vue de l’utilisateur, deux symptômes principaux se sont manifestés :
Les principaux sites web affichaient des pages d’erreur ou des pages blanches.
Un grand nombre de sites présentaient des erreurs HTTP 5xx, ou simplement des pages blanches sans contenu. Sky News+1
Pour certaines plateformes, cela s’est traduit par l’impossibilité de charger les pages de connexion, l’affichage des tableaux de bord ou l’expiration des API.
Le plan de contrôle de Cloudflare a été dégradé.
Le tableau de bord Cloudflare et les API associées ont également été affectés, limitant la capacité des clients à modifier les configurations ou à visualiser l’activité en temps réel. AP News+1
Sur le plan technique, les premières déclarations de Cloudflare et les articles de presse indiquent qu’une modification du traitement des requêtes par le pare-feu a été introduite pour corriger une vulnérabilité dans les composants serveur React. Cette modification a involontairement provoqué l’arrêt du trafic sur le réseau de Cloudflare pendant plusieurs minutes. Reuters+1
Même une brève interruption chez un fournisseur qui gère un si grand nombre de sites web provoque une cascade de défaillances :
Les navigateurs tentent de se reconnecter, ce qui augmente la charge.
Les serveurs dépendants subissent des pics de trafic, une accumulation de files d’attente ou des délais d’attente.
Les outils de surveillance inondent rapidement les ingénieurs d’astreinte d’alertes, souvent incomplètes ou trompeuses, car la plateforme d’observabilité elle-même peut dépendre de Cloudflare.
Pourquoi cette panne est-elle remarquable : « deuxième incident majeur en trois semaines »
Il ne s’agissait pas d’un incident isolé. Elle est survenue moins de trois semaines après un incident Cloudflare beaucoup plus important, le 18 novembre 2025.
3.1 La panne du 18 novembre 2025 (contexte)
Le 18 novembre 2025, Cloudflare a subi une panne majeure qui :
A provoqué des erreurs 5xx généralisées et une dégradation des performances pour de nombreux sites dans le monde entier.
Des plateformes importantes, dont X (anciennement Twitter) et OpenAI/ChatGPT, ont été touchées. Decodo
L'incident a été attribué à un bug dans la logique de génération d'un fichier de fonctionnalités de gestion des bots, affectant de nombreux services clés de Cloudflare. Blog Cloudflare+1
Cloudflare a ensuite publié une analyse détaillée expliquant que le fichier de configuration de gestion des bots avait provoqué des défaillances en cascade au sein des systèmes internes – un cas classique d'un artefact de configuration défectueux perturbant des flux de trafic critiques. Blog Cloudflare
3.2 5 décembre vs 18 novembre : schéma similaire, déclencheur différent
Comparaison des deux :
18 novembre 2025
Déclencheur : Bug dans la génération du fichier de fonctionnalités de gestion des bots. Blog Cloudflare+1
Effet : Erreurs 5xx généralisées, problèmes de pipeline de configuration, perturbation globale.
5 décembre 2025
Déclencheur : Modification de la gestion du pare-feu déployée pour corriger une vulnérabilité des composants serveur React. Reuters+1
Effet : Indisponibilité brève mais généralisée, pages blanches, problèmes avec le tableau de bord et l’API Cloudflare.
Pour les clients, la distinction importe peu : il s’agit dans les deux cas de pannes classiques du plan de contrôle, où une modification de configuration ou de sécurité chez le fournisseur a eu des conséquences à l’échelle du système.
Un phénomène qui dépasse le cadre de Cloudflare
Cloudflare n’est pas un cas isolé. Ces deux dernières années, nous avons constaté une série de pannes à l’échelle d’Internet.
Des incidents causés par des erreurs de configuration, des mises à jour logicielles ou des mesures de sécurité chez les principaux fournisseurs :
Cloudflare, Microsoft, Amazon et CrowdStrike ont tous connu des incidents ayant affecté des milliers de services dépendants. Reuters+1
Une analyse des perturbations d'Internet recense des dizaines de pannes mondiales importantes au cours de la première moitié des années 2020, soulignant le risque croissant de concentration lié à la dépendance à un petit nombre de fournisseurs d'infrastructure. TrueSolvers
Ce récent dysfonctionnement de Cloudflare s'inscrit dans une tendance plus large :
Plus nous centralisons la sécurité, le DNS, le CDN et le calcul en périphérie chez quelques fournisseurs, plus un simple bug de configuration peut devenir un risque systémique pour l'ensemble d'Internet.
Leçons techniques tirées de la panne du 5 décembre
À partir des informations publiques limitées, nous pouvons déjà tirer plusieurs leçons techniques pertinentes pour les équipes SRE, DevOps et plateforme.
5.1 Les modifications de sécurité nécessitent la même rigueur que les déploiements de code
La cause première était une modification du traitement des requêtes du pare-feu, déployée dans le cadre de la correction d'une vulnérabilité des composants serveur React. Reuters+1
Points clés :
Correctifs de sécurité = modifications en production
Les mises à jour de configuration liées à la sécurité doivent suivre le même processus de déploiement, de test et de contrôle que les modifications de fonctionnalités classiques. « C’est un correctif de sécurité » ne justifie pas de contourner les contrôles habituels.
Déploiement progressif et contrôle de l’impact
Toute modification du comportement du pare-feu global doit être :
Déployée d’abord sur un sous-ensemble de points de présence (POP) ou de clients.
Protégée par des indicateurs de fonctionnalités et des mécanismes de restauration instantanée.
Surveillée à l’aide de métriques spécifiques (par exemple, taux d’erreurs 5xx, TTFB, taux de pages vides) afin de détecter les défaillances en quelques secondes.
5.2 La robustesse du plan de contrôle est aussi critique que la disponibilité du plan de données.
Le fait que le tableau de bord et les API de Cloudflare aient également été dégradés pendant l’incident est particulièrement préoccupant. AP News+1
Pour les opérateurs, cela signifie :
Vous avez besoin de méthodes hors bande ou indépendantes du fournisseur pour :
Changer de DNS.
Contournez ou désactivez les couches défaillantes (par exemple, en accédant temporairement directement à l'origine).
Accédez aux journaux et aux métriques, même si l'interface utilisateur ou l'API du fournisseur est hors ligne.
Si votre seule solution à un problème repose sur l'infrastructure actuellement défaillante, vous perdez un filet de sécurité essentiel.
5.3 Les artefacts de configuration peuvent être aussi dangereux que le code.
Les incidents du 18 novembre et du 5 décembre présentaient le même schéma structurel :
Un artefact de configuration ou de stratégie (fichier de gestion des bots/comportement d'une règle de pare-feu)
Déployé via une automatisation globale
Interagissant de manière inappropriée avec le trafic de production à grande échelle. Blog Cloudflare + 2 Decodo + 2
Leçon à retenir : traitez la configuration avec la même rigueur que le code :
Contrôle de version, revues de code et tests.
Validation par rapport à des simulations de trafic réalistes en préproduction.
Limiter l'impact d'une configuration erronée.
Conséquences pour les entreprises qui utilisent Cloudflare :
La plupart des organisations ne peuvent pas simplement « cesser d'utiliser Cloudflare ». Il est profondément intégré aux services suivants :
DNS et routage anycast
Protection contre les attaques DDoS
WAF et gestion des bots
CDN et mise en cache
Accès Zero Trust, WARP, Workers, Workers AI et bien plus encore. Blog Cloudflare
Vous pouvez toutefois atténuer l’impact des dysfonctionnements futurs.
6.1 Cartographiez votre dépendance à Cloudflare
Tout d’abord, identifiez votre dépendance à Cloudflare :
Votre DNS est-il entièrement hébergé chez Cloudflare ?
La terminaison TLS est-elle effectuée uniquement chez Cloudflare, ou également au niveau du serveur d’origine ?
Vos API critiques sont-elles accessibles publiquement uniquement via Cloudflare ?
Vos équipes internes utilisent-elles Cloudflare Tunnel/Access/WARP pour accéder à des services sensibles ?
Lors de la panne du 12 juin 2025, par exemple, Cloudflare a constaté que des produits tels que Workers KV, WARP, Access, Gateway, Images, Stream, Workers AI, Turnstile, Zaraz et certaines parties du tableau de bord ont été affectés – un rappel du nombre important de couches pouvant dépendre d’un seul fournisseur. Blog Cloudflare
6.2 Planification de la redondance DNS et CDN
Pour les services critiques, envisagez :
Un DNS secondaire auprès d’un autre fournisseur capable de prendre le relais rapidement.
Des stratégies multi-CDN ou de contournement de CDN, afin qu’en cas de défaillance de Cloudflare, vous puissiez :
Rediriger le trafic directement vers le serveur d’origine.
Ou basculer le trafic vers un CDN de secours, même si les performances sont temporairement dégradées.
Cette solution a rarement un coût (rapport coût/complexité), mais pour les services critiques, la résilience qu’elle offre peut s’avérer précieuse.
6.3 Renforcer la résilience au niveau de l’application
Même en cas de défaillance du serveur périphérique, votre application peut mieux gérer les erreurs :
Filmer des pages d’erreur statiques mises en cache expliquant la situation au lieu de réponses vides.
Développer une logique de nouvelle tentative côté client qui réduit la charge au lieu de surcharger un serveur périphérique défaillant.
Découpler les fonctionnalités non critiques (analyse, scripts tiers, personnalisation poussée) afin de pouvoir les désactiver rapidement.
6.4 Sur le plan opérationnel : traitez les pannes de fournisseurs comme des situations critiques.
Utilisez cet exemple et la panne du 18 novembre comme exemples pour vos interventions d’urgence :
À quelle vitesse pouvez-vous déterminer si le problème provient de Cloudflare ou de votre propre infrastructure ?
Vos procédures d’astreinte incluent-elles :
Des liens vers la page d’état de Cloudflare et les coordonnées de votre fournisseur ?
Des étapes pré-approuvées pour contourner ou rediriger le trafic ?
Assurez-vous une surveillance ?
Que se passe-t-il lors de contrôles externes qui sollicitent votre service sans passer par Cloudflare ?
Comment Cloudflare est-il susceptible de réagir ?
Cloudflare a pour habitude de publier des analyses détaillées après chaque incident majeur (par exemple, les incidents du 20 juin 2024 et du 27 juin 2024, ainsi que les pannes du 12 juin 2025 et du 18 novembre 2025). Blog Cloudflare
En nous basant sur cette pratique, nous pouvons raisonnablement nous attendre à :
Un article de blog technique expliquant :
La modification précise de la logique du pare-feu.
Pourquoi la mesure d’atténuation de la vulnérabilité des composants serveur React a eu un comportement inattendu.
La durée de l’impact dans les différentes régions.
Une liste de mesures correctives, telles que :
Une validation et des tests de configuration renforcés.
Des déploiements progressifs plus rigoureux et des déclencheurs de restauration automatisés.
Une meilleure séparation entre les systèmes qui gèrent le trafic client et ceux qui alimentent le tableau de bord et les API.
Pour les clients, cette transparence est précieuse, mais elle ne les dispense pas de concevoir leurs propres architectures pour pallier les défaillances des fournisseurs.
Vue d'ensemble : centralisation vs résilience
Le dysfonctionnement du 5 décembre s'inscrit dans un débat plus large qui anime déjà le secteur :
Nous avons centralisé une part considérable du routage, du DNS, de la sécurité, des WAF et de la distribution de contenu chez une poignée de fournisseurs.
Chaque incident majeur chez Cloudflare, Azure, AWS ou CrowdStrike se comporte désormais comme un choc pour le système financier : il ne se contente pas de paralyser un site, il affecte brièvement l'ensemble de l'économie numérique.
Pour les régulateurs et les grandes entreprises, cela soulève des questions concernant :
Le risque de concentration : dans quelle mesure les infrastructures critiques doivent-elles être soumises à une redondance multi-fournisseurs ?
La transparence et la responsabilité : avec quelle rapidité et clarté les fournisseurs communiquent-ils les détails des causes profondes ?
L'investissement dans la résilience : investissons-nous suffisamment dans les garde-fous par rapport au déploiement de nouvelles fonctionnalités ?
Résumé
Pour conclure, la dernière panne majeure de Cloudflare, survenue le 5 décembre 2025, peut se résumer ainsi :
Une interruption de service mondiale, mais brève, causée par une modification du traitement du pare-feu interne, déployée dans le cadre d’une mesure de sécurité.
Les utilisateurs ont constaté des pages blanches et des erreurs 5xx sur les principaux sites web, ainsi qu’une dégradation du tableau de bord et des API de Cloudflare.
Il s’agit du deuxième incident majeur en moins de trois semaines, après la panne beaucoup plus importante du 18 novembre 2025, liée à la gestion des bots.
Ce dysfonctionnement vient s’ajouter aux risques liés à la concentration des infrastructures, où des erreurs de configuration chez quelques fournisseurs peuvent paralyser brièvement Internet pour tous.
Pour les entreprises qui dépendent de Cloudflare, le message essentiel n’est pas de « paniquer et de migrer », mais plutôt :
Partez du principe que vos fournisseurs peuvent tomber en panne et concevez votre architecture, vos opérations et vos processus métier de manière à ce qu’une panne passagère ne se transforme pas en crise existentielle.
11248 
IT Pro 
