Le 5 décembre 2025, Cloudflare a de nouveau plongé une partie d’Internet dans le noir. En quelques minutes, des milliers de sites et services majeurs sont devenus inaccessibles, de LinkedIn à ChatGPT. Une panne courte, mais systémique, qui pose une question centrale : jusqu’où accepter cette dépendance à un seul acteur ?
A retenir :
- Panne mondiale de Cloudflare le 5 décembre 2025, d’environ 30 à 40 minutes
- Origine : modification d’urgence du pare-feu (WAF) pour corriger une faille React
- Deuxième incident majeur en trois semaines, après celui du 18 novembre 2025
Une panne éclair, mais massive : ce qui s’est passé le 5 décembre 2025
Lorsque je me suis penché sur cette panne, un fait m’a frappé d’emblée : en moins d’une heure, une portion gigantesque du web mondial a vacillé. Peu avant 9 h 00 UTC, l’erreur 500 s’affiche en rafale sur une multitude de sites appuyés sur Cloudflare.
Selon Cloudflare, la chronologie est désormais assez claire : pic de perturbations entre 8 h 56 et 9 h 20 UTC, correctif déployé vers 9 h 12, retour progressif à la normale dans les minutes suivantes. La plupart des utilisateurs auront ressenti une vraie coupure de 30 à 40 minutes, avec impossibilité de se connecter à leurs outils de travail ou de divertissement.
Dans les faits, cela signifie que des plateformes comme LinkedIn, Zoom, ChatGPT, Discord, Spotify, Shopify, ou encore des sites de trading, ont eu le même symptôme au même moment : pages blanches, “Internal Server Error”, services qui refusent de charger. Selon plusieurs observateurs spécialisés, cela représente potentiellement jusqu’à 20 % du trafic web mondial impacté, Cloudflare étant l’un des principaux CDN et boucliers anti-DDoS de la planète.
De mon côté, j’ai revu le scénario vécu en 2021 lors d’une précédente grande panne Cloudflare : on rafraîchit une page, puis une autre, puis on ouvre un onglet “DownDetector” qui… ne répond pas non plus. C’est le signe typique que le problème dépasse largement un simple site ou un seul hébergeur.
Les coulisses techniques : une règle WAF pour corriger une faille React
La grande inquiétude, dans ces situations, porte toujours sur la même question : cyberattaque ou erreur interne ? Ici, Cloudflare a rapidement tranché. Selon l’entreprise, il ne s’agissait pas d’une attaque, mais d’un changement de configuration du Web Application Firewall (WAF) déployé en urgence.
L’objectif de cette modification : atténuer une vulnérabilité critique dans React Server Components, une faille d’exécution de code à distance jugée très sérieuse par l’écosystème. Selon des analyses de sécurité publiées ces derniers jours, cette vulnérabilité permettrait à un attaquant non authentifié d’exécuter du code arbitraire, ce qui justifie une réaction rapide des grands intermédiaires de l’Internet.
Cloudflare a donc choisi de pousser une nouvelle règle WAF, censée identifier et bloquer certains motifs d’attaque liés à cette faille. Mais l’équilibre a été rompu : au lieu de filtrer proprement le trafic malveillant, la règle a provoqué des erreurs internes sur le réseau Cloudflare lui-même, entraînant une cascade de réponses 5xx.
« Une mesure défensive mal calibrée peut transformer un Internet “plus sûr” en Internet momentanément inaccessible pour des millions de personnes. »
Le CTO de Cloudflare a expliqué que l’intention était de protéger les clients le plus vite possible, mais que le changement s’est avéré trop large, trop strict, et surtout insuffisamment sécurisé par des garde-fous. Selon des échanges techniques relayés dans la presse spécialisée, le système a basculé de fait en mode “fail-closed” : face au doute, il a préféré bloquer.
Principaux défis mis à nu : dépendance et point unique de défaillance
En analysant cette panne, plusieurs défis structurels apparaissent très clairement.
Un web trop centralisé autour de quelques acteurs d’infrastructure
La première difficulté, c’est la concentration. Cloudflare, comme quelques autres grands acteurs, s’est progressivement imposé comme un maillon incontournable : CDN, proxy, DNS, protection DDoS, WAF, Workers… Cette accumulation de fonctions est confortable pour les entreprises, mais elle crée un gigantesque point unique de défaillance.
Selon plusieurs experts en infrastructures, la panne du 18 novembre 2025 avait déjà joué le rôle d’alerte rouge. Celle du 5 décembre la transforme en signal systémique : confier à un seul prestataire le DNS, la sécurité, la mise en cache et parfois même l’exécution d’une partie de la logique applicative revient à mettre tous ses œufs techniques dans le même panier.
Une chaîne de responsabilités floue pour les entreprises
Autre difficulté : la complexité de la chaîne technique. Dans les retours que j’ai pu étudier après les précédentes pannes, une réalité revient souvent : au moment de la coupure, beaucoup de directions métiers ignorent qu’elles dépendent de Cloudflare.
Pour elles, quand le site ne répond plus, c’est “le site” qui tombe, point. La responsabilité exacte se perd entre hébergeur, éditeur, prestataires, opérateurs. Cette opacité complique la gestion de crise : qui doit parler, quoi dire aux clients, à quel horizon de rétablissement se préparer ?
Des changements de sécurité à haut risque opérationnel
Enfin, cette panne illustre un problème récurrent : la sécurité déployée dans l’urgence. Quand une vulnérabilité majeure est découverte, les équipes ont peu de temps pour réagir. Déployer une règle WAF globale paraît logique. Mais sans stratégie de tests ciblés, de déploiement progressif et de mécanismes de rollback très rapides, chaque “patch” peut devenir un vecteur de panne mondiale.
À titre personnel, j’ai déjà vu des équipes internes vivre des incidents similaires, à une échelle plus réduite : une règle de firewall trop stricte, déployée en production, qui bloque soudain tout le trafic légitime. La différence, avec Cloudflare, c’est l’échelle : ici, l’erreur touche simultanément des millions d’utilisateurs.
Impacts concrets : du télétravail au e-commerce en passant par le support
Télétravail et outils collaboratifs figés
Pour de nombreux salariés, l’incident a pris une forme très concrète : réunion visio impossible à lancer, chat d’entreprise indisponible, documents Cloud ou Notion inaccessibles. Même si la panne est courte, le ressenti reste fort. On l’a déjà observé en novembre : une seule matinée dégradée peut suffire à perturber grosso modo toute la journée de travail.
E-commerce à l’arrêt et paniers abandonnés
Côté e-commerce, l’impact se mesure immédiatement en revenus manqués. Lors de la panne du 18 novembre, certains marchands avaient partagé des courbes de trafic tombant brutalement à zéro à l’instant de l’incident. Le 5 décembre, la logique est la même.
On imagine très bien le scénario de ces sites : pages produit qui refusent de charger, paiement bloqué au dernier clic, tunnel de commande interrompu. Pour un client, la confiance s’effrite vite. On referme l’onglet, on ira acheter ailleurs ou plus tard.
Témoignage métier : “Ce qui manque, c’est une information claire”
Un retour revient souvent dans les témoignages recueillis lors des précédents incidents, et que l’on peut aisément transposer à ce 5 décembre :
“Ce qui nous a le plus manqué, ce n’est pas tant la disponibilité absolue que l’information claire : est-ce notre faute, celle d’un prestataire, combien de temps cela va durer, que dire à nos clients ?”
Ce témoignage illustre la fracture entre le monde technique, qui parle de WAF, de règles et de CVE, et les métiers, qui ont surtout besoin d’une narration lisible de la crise.
Un précédent récent : la panne du 18 novembre 2025 comme avertissement ignoré
La panne de ce 5 décembre ne surgit pas de nulle part. Elle intervient moins de trois semaines après une autre défaillance majeure, le 18 novembre 2025. Ce jour-là, Cloudflare avait déjà dérouté Internet pendant environ six heures.
Selon le billet d’analyse publié ensuite par l’entreprise, la cause tenait à un fichier de configuration lié au Bot Management, devenu trop volumineux. En se propageant, ce fichier a provoqué des défaillances sur une large partie du réseau, avec là encore des erreurs 5xx massives.
Pour beaucoup d’observateurs, cet épisode devait marquer un tournant : revoir les processus de déploiement, renforcer les garde-fous, limiter la surface de risque. Le fait qu’une nouvelle panne survienne le 5 décembre, même plus courte, donne l’impression que le chantier est loin d’être terminé.
De mon point de vue, c’est cette dimension de répétition qui change la nature du débat. Un incident isolé peut être vu comme un “accident”. Deux incidents graves, rapprochés, deviennent un sujet de gouvernance, et plus seulement de technique.
Comment les entreprises peuvent réagir : pistes de résilience et bonnes pratiques
Diversifier les dépendances : ne plus tout confier à un seul prestataire
La première piste, logique, consiste à ne plus confier tous les rôles critiques à un seul acteur. Cela ne veut pas dire bannir Cloudflare, mais réfléchir à des architectures où :
- le DNS peut être repris ailleurs,
- un second CDN peut être activé en cas de besoin,
- le site d’origine reste accessible, au moins partiellement, en contournant le proxy.
Dans certaines entreprises, j’ai vu se mettre en place des stratégies de “multi-CDN” ou, à défaut, des plans de bascule documentés pour réorienter rapidement le trafic. Même si ces approches coûtent plus cher et demandent plus de travail, elles réduisent fortement l’effet “tout ou rien” constaté lors de cette panne.
Tester régulièrement l’application sans Cloudflare
Un retour d’expérience que je trouve particulièrement parlant vient de petites équipes SaaS qui avaient gardé la possibilité de tester leur application sans passer par Cloudflare. Le jour de la panne du 18 novembre, elles ont rapidement vérifié que l’origine répondait parfaitement.
Résultat : au lieu de passer deux heures à chercher un bug inexistant dans leur code, elles ont immédiatement communiqué à leurs clients que le problème venait d’un incident d’infrastructure externe, et qu’aucune donnée n’était compromise. Cette simple capacité à isoler l’origine du problème fait gagner un temps précieux.
Documenter un véritable plan de continuité numérique
Pour beaucoup d’organisations, ces pannes sont aussi un crash-test des plans de continuité. Combien ont réellement défini des scénarios précis pour “panne Cloudflare” ?
Un plan concret, c’est :
- qui décide de désactiver certaines règles ou services en mode dégradé,
- qui met à jour en temps réel la page de statut ou les réseaux sociaux,
- quels messages types envoyer aux clients,
- quelles métriques suivre pour décider du retour à la normale.
Dans plusieurs entreprises que j’ai suivies, la panne du 18 novembre a servi de déclencheur pour lancer ce travail. Le 5 décembre ne fait que renforcer l’urgence de le mener sérieusement.
Retours d’expérience : ce que révèle la panne dans le quotidien des équipes
Retour d’expérience n° 1 : la start-up qui a gagné la bataille de la communication
Lors d’un incident précédent, une jeune start-up SaaS m’expliquait avoir “perdu moins de clients que prévu” grâce à une seule chose : la transparence. Dès les premières minutes, elle a publié un bandeau expliquant clairement que l’incident venait de Cloudflare, que les données n’étaient pas en danger et que le suivi des travaux était accessible sur sa page de statut.
Cette fois-ci, on peut imaginer le même réflexe : reconnaître rapidement la cause externe, rassurer sur l’intégrité des données, donner des estimations honnêtes plutôt que des promesses intenables. Selon plusieurs études sur la confiance numérique, c’est souvent la gestion de crise – plus que la panne elle-même – qui façonne la perception des utilisateurs.
Retour d’expérience n° 2 : l’ETI qui découvre sa dépendance cachée
À l’inverse, j’ai vu des entreprises de taille intermédiaire découvrir leur dépendance à Cloudflare au pire moment : quand tout leur front-office s’est effondré. Le contrat avait été signé des années plus tôt, lors d’un projet de refonte, et plus personne n’en mesurait réellement les implications au quotidien.
Le 5 décembre, on retrouve sans doute ce schéma : des comités de direction apprennent dans l’urgence que 100 % du trafic client transite par un fournisseur américain, sur lequel ils n’ont ni regard ni levier direct. Ce type de prise de conscience tardive montre l’importance d’une cartographie claire des dépendances numériques.
Une alerte pour la gouvernance d’Internet, pas seulement pour Cloudflare
Au fond, cette panne dépasse le cas particulier de Cloudflare. Elle nous renvoie à une question plus large : voulons-nous d’un Internet qui tient sur quelques épaules, aussi compétentes soient-elles ?
D’un côté, ces grands acteurs ont permis d’industrialiser des services de sécurité et de performance qui auraient été inaccessibles à beaucoup de petites structures. De l’autre, ils créent une fragilité systémique : quand l’un d’eux tousse, des millions d’utilisateurs n’ont plus accès à leurs outils, leurs services publics, leur banque, leurs réseaux sociaux.
Selon plusieurs observateurs, l’Europe pourrait saisir ce genre d’incident pour alimenter le débat sur la souveraineté numérique : encourager des alternatives, imposer des exigences de transparence et de résilience renforcées, mieux encadrer les dépendances critiques. Il ne s’agit pas de “punir” un acteur en particulier, mais de reconnaître que l’infrastructure du web est devenue un sujet politique autant que technique.
Si vous avez vous aussi constaté des erreurs 500, des pages blanches ou une chute brutale de votre activité en ligne ce 5 décembre 2025, n’hésitez pas à partager votre expérience en commentaire. Vos retours de terrain sont précieux pour comprendre, au-delà des rapports techniques, ce que signifie réellement une panne de Cloudflare dans la vie numérique de chacun.
