La panne majeure de Cloudflare le 18 novembre - Résumé

Le 18 novembre 2025, une grande partie de l'internet s'est effondrée.
Si vous ouvriez ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase ou d'innombrables sites plus petits, vous étiez accueilli par une page d'erreur 5xx de Cloudflare - ou les sites ne se chargeaient tout simplement pas. Ce qui ressemblait à première vue à un nouveau grand moment de "l'internet est cassé" s'est avéré être quelque chose de plus subtil et, à certains égards, de plus inquiétant : un bug auto-infligé au sein de l'infrastructure même de Cloudflare.

Voici un aperçu détaillé de ce qui s'est passé lors de la panne de Cloudflare d'hier (18 novembre 2025), des raisons de cette panne, des personnes touchées et des leçons que les équipes chargées de l'infrastructure devraient en tirer.

Que s'est-il réellement passé hier ?

Le mardi 18 novembre 2025, vers la fin de la matinée (UTC), Cloudflare a commencé à renvoyer un grand nombre d'erreurs de serveur HTTP 5xx pour le trafic qui passait par son réseau. Pour les utilisateurs finaux, cela signifiait des pages "Internal Server Error" ou "Gateway Error" lorsqu'ils essayaient d'accéder à de nombreux sites web et applications populaires.

Selon le blog de Cloudflare qui a suivi l'incident, la panne :

• L'impact sur le trafic HTTP des clients a commencé à 11:28 UTC

• Des erreurs 5xx ont été constatées sur l'ensemble des services CDN et de sécurité.

• Des mesures d'atténuation importantes ont été prises entre 13 h 05 et 14 h 30 (UTC).

• Le volume d'erreurs 5xx est revenu à son niveau de base à 17:06 UTC Le blog de Cloudflare

Cloudflare lui-même a décrit cette panne comme la pire depuis 2019, car elle n'a pas seulement affecté une fonctionnalité ou un tableau de bord - elle a perturbé la couche proxy centrale qui achemine la majorité du trafic des clients à travers son réseau. Le blog de Cloudflare

La surveillance par des tiers a étayé ce constat. Cisco ThousandEyes a constaté une panne globale affectant Cloudflare, avec des dépassements de temps et des erreurs 5xx sur des services tels que X, OpenAI (ChatGPT) et Anthropic, alors que les chemins du réseau eux-mêmes semblaient sains. Cela indique clairement qu'il s'agit d'une défaillance d'un service dorsal, et non d'un problème de routage ou de fournisseur d'accès à Internet. Mille yeux

Qui a été touché ?

Étant donné que Cloudflare se trouve devant une partie importante d'Internet (environ 20 % des sites Web dépendent de Cloudflare pour leurs performances et leur sécurité), le rayon d'action de l'explosion a été énorme. AP News+1

Parmi les services signalés comme touchés :

• ChatGPT / OpenAI

• X (anciennement Twitter)

• Canva, Shopify, Dropbox, Coinbase

• League of Legends et autres plateformes de jeux

• Divers sites de transport public et de gouvernement, dont New Jersey Transit et les systèmes numériques de la SNCF en France AP News+1

Les traqueurs de pannes comme Downdetector ont enregistré des milliers de rapports de problèmes simultanés au plus fort de la panne. Reuters a fait état d'environ 5 000 utilisateurs affectés pour le seul système X à un moment donné, avant que les chiffres ne diminuent au fur et à mesure que les correctifs étaient mis en place. Reuters

Du point de vue de l'utilisateur, cela s'est traduit par

• Les sites ne se chargent pas du tout

• Les flux de connexion se bloquent ou échouent (en particulier lorsque Cloudflare Access ou Turnstile sont impliqués).

• Les API répondent de manière intermittente ou avec des erreurs 5xx

• Tableaux de bord et panneaux d'administration interrompus

En d'autres termes, de vastes parties de l'internet se sont retrouvées en panne, même si la cause profonde était concentrée dans les systèmes internes d'un seul fournisseur d'accès.

Fonctionnement normal de Cloudflare (en termes simples)

Pour comprendre pourquoi cette panne a été si grave, il est utile de connaître le cheminement approximatif d'une requête à travers le réseau de Cloudflare.

Cloudflare agit comme un proxy inverse CDN et une couche de sécurité:

1. Votre navigateur ou votre application se connecte à Cloudflare au lieu de se connecter directement au site d'origine.

2. Cloudflare termine TLS et HTTP à sa périphérie.

3. Les requêtes sont acheminées vers le système de proxy central de Cloudflare, appelé FL ("Frontline") et sa nouvelle génération FL2.

4. Ce proxy central

   • applique les règles WAF (pare-feu d'application web)

   • Exécute des modèles de gestion des robots

   • gère la protection DDoS, la mise en cache, la sortie vers l'origine

   • Routage du trafic vers d'autres produits internes tels que Workers, R2, Access, etc. Le blog de Cloudflare

En fonctionnement normal, cette architecture est très résiliente : si un centre de données a un problème, le trafic est acheminé par d'autres ; les changements de configuration sont déployés avec précaution ; les fonctionnalités individuelles devraient tomber en panne de manière contenue.

La panne d'hier était précisément mauvaise parce que la défaillance se situait à l'intérieur du chemin de proxy commun lui-même, et qu'elle était étroitement liée à un fichier de configuration qui est poussé dans le monde entier fréquemment et automatiquement.

La cause première : un fichier de gestion des robots qui a été détourné

L'explication officielle de Cloudflare pointe vers un coupable principal :
un fichier de configuration de fonctionnalité utilisé par leur système de gestion des bots. Le blog de Cloudflare

Voici la chaîne des événements en langage clair :

1. Bot Management utilise un "fichier de fonctionnalités"

   • Le modèle de détection des robots de Cloudflare repose sur un ensemble de "caractéristiques", c'est-à-dire des signaux relatifs à chaque demande utilisés pour déterminer s'il s'agit d'un humain ou d'un robot.

   • Ces caractéristiques sont regroupées dans un fichier de configuration qui est régénéré toutes les quelques minutes et déployé à l'échelle mondiale, afin que Cloudflare puisse s'adapter rapidement aux nouveaux schémas d'attaque. Le blog de Cloudflare

2. Un changement dans le comportement des requêtes ClickHouse

   • Le fichier de caractéristiques est généré par des requêtes contre une base de données ClickHouse.

   • Cloudflare a effectué un changement vers 11:05 UTC pour améliorer la sécurité et les permissions pour les requêtes distribuées - permettant aux utilisateurs de voir les métadonnées non seulement à partir d'un schéma par défaut, mais aussi à partir des tables r0 sous-jacentes. Le blog de Cloudflare

   • La requête qui construit la liste des fonctionnalités n'a pas filtré par nom de base de données ; soudainement, elle a commencé à obtenir des colonnes dupliquées à la fois de default et de r0, doublant ainsi le nombre de lignes de fonctionnalités.

3. La taille du fichier d'éléments a explosé

   • Le module Bot Management a une limite stricte sur le nombre d'éléments qu'il accepte (fixée à 200, bien au delà des ~60 normalement utilisés).

   • Lorsque le fichier nouvellement généré a dépassé cette limite, le module a atteint le plafond et a paniqué, à cause d'une erreur non gérée dans le code Rust qui utilisait Result::unwrap() sur une valeur d'erreur. Le blog de Cloudflare

4. Les services proxy de base ont commencé à renvoyer des erreurs 5xx

   • Parce que Bot Management est intégré dans le chemin de proxy principal, la panique est apparue sous forme de réponses HTTP 5xx pour tout trafic dépendant de ce module.

   • Sur le nouveau moteur FL2, les clients ont vu des erreurs 5xx explicites.

   • Sur l'ancien moteur FL, les scores des bots passaient silencieusement à zéro, ce qui pouvait entraîner des faux positifs dans les règles de blocage des bots. Le blog de Cloudflare

5. La partie la plus désagréable : le fichier ne cessait de basculer entre "bon" et "mauvais"

   • Le cluster ClickHouse était progressivement mis à jour, et le fichier de caractéristiques était régénéré toutes les cinq minutes.

   • Parfois, la requête était exécutée sur des nœuds mis à jour (produisant un mauvais fichier), parfois sur des nœuds non mis à jour (produisant un bon fichier).

   • Cela signifie que pendant un certain temps, le réseau de Cloudflare a oscillé entre le fonctionnement normal et la défaillance, au fur et à mesure que les différentes versions du fichier se propageaient. Le blog de Cloudflare

Cette oscillation a rendu la situation extrêmement confuse en interne. Dans un premier temps, les équipes de Cloudflare ont soupçonné une attaque DDoS massive car le schéma d'erreur ne ressemblait pas à une simple panne logicielle. Même la page d'état de Cloudflare, qui est hébergée en dehors de leur propre infrastructure, a brièvement montré des erreurs - une coïncidence qui a alimenté les soupçons d'une attaque externe. Le blog+1de Cloudflare

Ce n'est que lorsqu'ils ont réalisé que le facteur commun était le fichier de caractéristiques du bot que la situation est devenue claire.

Chronologie de l'incident

Sur la base de l'analyse rétrospective de Cloudflare et des rapports de tiers, nous pouvons établir une chronologie approximative de l'incident survenu le 18 novembre 2025 : The Cloudflare Blog+2ThousandEyes+2

• 11:05 UTC - Un changement de contrôle d'accès à la base de données est déployé dans ClickHouse.

• 11:20-11:30 UTC - De mauvaises versions du fichier de fonctionnalité Bot Management commencent à être générées et propagées.

• 11:28 UTC - Premier impact sur les clients : des erreurs HTTP 5xx élevées sont observées sur le trafic des clients.

• 11:30-11:32 UTC - Des outils de surveillance externes et des tests automatisés commencent à détecter des défaillances intermittentes.

• 11:35 UTC - Cloudflare ouvre un appel d'incident interne ; l'enquête commence.

• ~11:48 UTC - Cloudflare publie une mise à jour de statut confirmant un incident. Renvoi

• 11:30-13:05 UTC - Les équipes se concentrent sur ce qui semble être un comportement dégradé de Workers KV et enquêtent sur de multiples causes possibles (y compris des scénarios d'attaque).

• 13:05 UTC - Atténuation clé : Workers KV et Cloudflare Access sont déplacés pour contourner le proxy central ; l'impact est réduit. Le blog de Cloudflare

• 14:30 UTC - La cause première est identifiée ; la génération et la propagation des mauvais fichiers de caractéristiques sont stoppées. Un fichier de configuration connu est inséré manuellement et le proxy central est redémarré. La plupart du trafic revient à la normale. Le blog de Cloudflare

• 14:40-15:30 UTC - Les problèmes de tableau de bord et de connexion persistent alors que le Turnstile et l'accumulation de tentatives d'authentification créent des pics de charge secondaires. Le blog de Cloudflare

• 17:06 UTC - Les taux d'erreur reviennent à la normale ; Cloudflare déclare que les systèmes sont entièrement normaux. Le blog de Cloudflare

Du point de vue de l'utilisateur, la panne a été ressentie comme la plus grave entre la fin de la matinée et le début de l'après-midi (UTC), bien que les fenêtres d'impact exactes varient en fonction de la région et des produits Cloudflare dont dépend chaque service.

Pourquoi cette panne est-elle si importante ?

Risque de centralisation

Cloudflare fait partie d'un petit groupe de fournisseurs d'infrastructures internet centrales, aux côtés des principales plateformes de cloud (AWS, Azure, GCP) et d'autres grands CDN. Lorsque l'un de ces acteurs tombe en panne, l'impact est important et souvent peu évident.

Cette panne :

• n'est pas due à un problème de routage BGP ou à une coupure de câble d'un fournisseur d'accès.

• Elle n'est pas due à une attaque malveillante (malgré les soupçons initiaux).

• Elle est due à une configuration unique et aux limites d'un bogue dans un composant interne.

C'est important car cela montre comment des systèmes complexes et étroitement couplés peuvent tomber en panne de manière catastrophique, même en l'absence d'interférences extérieures. Lorsque de nombreuses organisations s'appuient sur le même fournisseur, celui-ci devient de facto un élément important de l'internet sur le plan systémique.

Les dépendances "douces" sont également touchées

Certains des services touchés ne se contentaient pas d'utiliser Cloudflare comme un simple CDN. Ils le faisaient :

• Utilisaient Cloudflare Access pour l'authentification et l'accès de confiance zéro.

• Utilisaient Workers KV dans le cadre de plans de contrôle internes.

• S'appuyer sur Turnstile pour des connexions résistantes aux robots. Le blog de Cloudflare+1

Lorsque ces produits tombent en panne, ce n'est pas seulement le contenu du site Web qui s'effondre, mais aussi les connexions, les fonctions d'administration et les API internes. Cela rend la reprise plus complexe : votre page d'état, votre outil d'incident ou votre interface d'administration peuvent également s'appuyer sur le fournisseur qui vient de tomber en panne.

Ce que Cloudflare dit vouloir changer

Le blog de Cloudflare présente plusieurs mesures correctives que l'entreprise a déjà prises pour réduire le risque qu'une telle situation se reproduise : Le blog de Cloudflare

1. Durcir l'ingestion des fichiers de configuration générés automatiquement
   Traiter les fichiers de configuration générés en interne avec le même scepticisme et la même validation que les données fournies par l'utilisateur, y compris une vérification stricte du schéma et de la taille avant le déploiement.

2. Plus d'interrupteurs globaux
   Faciliter la désactivation rapide des modules internes problématiques (comme Bot Management) à travers le réseau, de sorte qu'ils échouent ouverts au lieu de paniquer l'ensemble du chemin de proxy.

3. Protéger les ressources du système contre les tempêtes d'erreurs
   S'assurer que les dumps du noyau, les métadonnées de débogage et les outils d'observabilité ne peuvent pas submerger le CPU et la mémoire lorsque les erreurs commencent à se multiplier.

4. Examiner les modes de défaillance des principaux modules du proxy
   Auditer systématiquement le comportement de chaque module interne en cas d'entrée ou de configuration inattendue, et assurer une dégradation gracieuse au lieu d'une défaillance globale.

5. Affiner les déploiements et l'isolation
   Bien que l'incident ne soit pas très détaillé, il suggère que Cloudflare va probablement segmenter davantage la façon dont les nouvelles configurations et les comportements DB se propagent, afin de réduire le risque qu'un seul mauvais changement affecte l'ensemble de la flotte.

Cloudflare a également qualifié l'incident d'échec absolu de ses attentes en matière de résilience, le qualifiant d'"inacceptable" et reconnaissant explicitement la douleur qu'il a causée aux clients et aux utilisateurs ordinaires d'Internet. Le blog de Cloudflare

Leçons pour les équipes d'infrastructure et de SRE

Même si vous ne gérez pas quelque chose d'aussi énorme que Cloudflare, il y a des leçons très pratiques à tirer de cette panne en matière de conception et d'exploitation :

Traiter la configuration interne comme un intrant non fiable

Il est facile de supposer que "notre propre" configuration générée est toujours correcte. La journée d'hier a montré pourquoi c'est dangereux :

• Toujours valider la taille, la forme et les limites des fichiers de configuration avant de les appliquer.

• Envisager l'application canarienne de la configuration à un petit sous-ensemble de trafic ou de nœuds en premier lieu, avec un retour en arrière automatisé en cas d'anomalie.

• Gardez des limites supérieures strictes et des coupe-circuits autour du nombre de fonctionnalités, de la pré-allocation de mémoire et de l'utilisation de l'unité centrale.

Concevoir pour une défaillance partielle gracieuse

Un bogue dans le module de gestion des robots ne devrait pas être en mesure de paniquer l'ensemble du chemin du proxy:

• Utiliser par défaut fail-open vs fail-closed dans certaines couches de sécurité lorsque l'alternative est une panne complète.

• Construire des interrupteurs d'arrêt clairs et testés pour les fonctionnalités non essentielles.

• S'assurer que les sous-systèmes critiques (authentification, page de statut, outil d'incident) peuvent fonctionner en mode dégradé ou via des routes alternatives.

Observer les bons signaux

L'oscillation entre "bonne configuration" et "mauvaise configuration" toutes les cinq minutes fait ressembler le signal à un trafic d'attaque ou à un comportement externe bruyant :

• Assurez-vous d'avoir une corrélation par version ou par configuration dans votre pipeline d'observabilité.

• Créez des tableaux de bord qui rendent les changements de configuration visuellement évidents au-dessus des graphiques d'erreurs.

• Incluez des tests synthétiques solides à partir d'un point de vue externe, afin que vous puissiez rapidement distinguer les défaillances internes des problèmes de réseau/chemins d'accès.

Ne mettez pas tous vos œufs dans le même panier d'infrastructure

Pour les organisations utilisant Cloudflare :

• Envisagez des configurations multi-CDN pour les propriétés réellement critiques.

• Evitez de rendre votre page de statut entièrement dépendante du même fournisseur que votre pile principale (Cloudflare le fait, mais il y a eu un problème coïncident avec l'hôte de leur page de statut hier, ce qui a rendu les choses encore plus confuses). Le blog de Cloudflare+1

• Pensez-y à deux fois avant de coupler étroitement votre authentification, vos plans de contrôle API et votre livraison frontale au même fournisseur sans chemins de repli.

Vue d'ensemble

Rien qu'au cours des derniers mois, nous avons assisté à des pannes majeures chez Microsoft Azure, Amazon Web Services et maintenant Cloudflare, qui ont toutes temporairement mis hors ligne des pans entiers de services destinés aux consommateurs et aux entreprises. AP News+2TheWashington Post+2

Le schéma est clair :

• L'internet dépend de plus en plus d'une poignée de fournisseurs d'infrastructure géants.

• Les pannes sont souvent auto-infligées, dues à des changements internes complexes plutôt qu'à des attaques extérieures.

• Même les fournisseurs dotés de pratiques SRE de classe mondiale peuvent encore être perturbés par des interactions inattendues entre la configuration, le comportement de la base de données et les limites codées en dur.

L'incident survenu hier chez Cloudflare nous rappelle brutalement que le "nuage" n'est pas magique. Au fond, il s'agit toujours d'un logiciel écrit par des humains, sujet aux mêmes catégories de bogues que n'importe quelle autre application, mais avec des ordres de grandeur plus élevés de personnes qui en dépendent.

Les utilisateurs se souviendront surtout de l'incident comme de "ce matin où X et ChatGPT ne se chargeaient pas".
Pour les ingénieurs, il sera probablement étudié comme un exemple classique de la manière dont de subtils bogues de configuration dans un système distribué central peuvent se répercuter sur un événement Internet mondial.