Mardi, Cloudflare a vécu sa pire panne depuis 2019. Si une cyberattaque était redoutée même du côté de l'entreprise, cette dernière révèle les raisons de cet incident qui aura duré plus de six heures.
La panne historique de Cloudflare a démarré mardi 18 novembre 2025 à 12h20 heure française, avec des erreurs en cascade sur son réseau mondial. Pannes, puis rétablissements temporaires, puis nouvelles coupures. Les équipes ont navigué à vue, celles de Clubic comme celles de ChatGPT, X/Twitter, Canva et d'autres services massivement utilisés partout dans le monde. La première hypothèse de Cloudflare fut celle de la cyberattaque, d'une très grosse attaque DDoS. Le comportement de ses services nourrissait cette thèse, c'est vrai. Mais la réalité est plus prosaïque et tout aussi dévastatrice.
Un fichier de configuration qui double de volume et paralyse tout
L'histoire a démarré quinze minutes plus tôt, à 12h05 précisément. Une équipe Cloudflare déploie une modification sur un cluster de bases de données ClickHouse. L'objectif est alors de renforcer la sécurité en rendant explicites les permissions d'accès des utilisateurs aux tables de données. Sur le papier, c'est une évolution logique. Dans les faits, c'est le début d'un chaos technique.
Le changement provoque un effet de bord inattendu. Le système se met à voir double. Chaque colonne de données apparaît désormais deux fois dans les métadonnées, une pour la base « default » et une pour la base « r0 » sous-jacente. Ces informations servent à générer un fichier crucial pour le système Bot Management, qui analyse le trafic en temps réel pour distinguer les vrais utilisateurs des robots malveillants.
Ce fichier contenait habituellement une soixantaine d'« empreintes » permettant à l'intelligence artificielle de Cloudflare de détecter les bots. Avec les doublons, il explose à plus de 200 entrées. Le problème, c'est que le logiciel qui le traite a une limite de sécurité fixée à 200 éléments maximum, pour éviter une consommation excessive de mémoire. Quand le fichier défectueux se propage sur les milliers de serveurs du réseau, c'est l'hécatombe. Les machines plantent les unes après les autres et renvoient des erreurs 500 aux internautes du monde entier.
Cloudflare a longtemps cru à une attaque DDoS
Ce qui rend le diagnostic cauchemardesque, c'est l'intermittence du problème. Toutes les cinq minutes, le fichier est régénéré automatiquement. Selon que la requête tombe sur un serveur mis à jour ou non du cluster ClickHouse, le fichier produit est bon ou défectueux. Résultat, le système oscille entre panne totale et fonctionnement normal, ce qui rend l'origine du bug quasi-impossible à identifier.
Matthew Prince, le PDG de Cloudflare, fait un mea culpa public, en reconnaissant que l'équipe technique s'est fourvoyée pendant deux heures. Dans le chat interne de gestion de crise, on espère qu'il ne s'agit que d'une coïncidence. On parle de la panne simultanée de leur page de statut, pourtant hébergée chez un concurrent (Amazon CloudFront). À 13h16, Matthew Prince dit craindre « que ce ne soit la démonstration de force d'un grand réseau de bots ». Cloudflare avait subi des attaques DDoS d'ampleur inédite au mois de juin.
Cette fausse piste coûte un temps précieux. Les équipes tentent de bloquer du trafic, de limiter certains comptes, persuadées d'avoir affaire à une attaque coordonnée. Ce n'est qu'à 14h04 qu'une première lueur apparaît. En contournant le système principal (le « core proxy ») pour Workers KV, un service de stockage clé-valeur, l'impact diminue sensiblement. Bingo, le problème vient bien de l'intérieur.
À 14h37, les soupçons se cristallisent sur le fichier Bot Management. À 15h24, les équipes stoppent sa génération automatique et le remplacent par une version antérieure. À 15h30, le trafic principal reprend. Mais il faudra encore près de trois heures pour redémarrer tous les services annexes et absorber l'afflux de connexions différées.
Des millions d'utilisateurs bloqués devant des pages d'erreur 500
Pendant la panne, c'est l'ensemble de l'écosystème Cloudflare qui vacille. Les sites utilisant le CDN affichent des pages d'erreur 500. Turnstile, le système anti-bot utilisé sur d'innombrables sites web, disparaît des radars. Et Workers KV, plateforme sur laquelle reposent des applications entières, accumule les défaillances. Même le tableau de bord Cloudflare devient inaccessible, et il est impossible de se connecter puisque la page de login utilise... Turnstile.
L'impact sur Cloudflare Access est particulièrement critique. Ce service gère l'authentification de milliers d'entreprises. Entre 12h28 et 14h05, toute tentative de connexion échoue. Les salariés en télétravail se retrouvent bloqués devant leur écran, incapables d'accéder aux outils internes de leur société. Ils ont pour seule consolation les sessions déjà ouvertes, qui restent actives, et les rares connexions réussies sont correctement enregistrées.
Un détail technique aggrave la situation. Cloudflare déploie actuellement une nouvelle version de son proxy, baptisée FL2. Les clients migrés vers FL2 subissent sur le moment de nombreuses erreurs 500. Ceux restés sur l'ancienne version FL voient leurs sites fonctionner, mais avec un effet secondaire sournois : tous les visiteurs reçoivent un score de bot à zéro, c'est-à-dire qu'ils sont considérés comme des robots. Pour les sites configurés pour bloquer les bots, cela signifie des milliers de vrais utilisateurs rejetés à tort.
Après le retour du fichier correct à 15h30, un nouvel écueil surgit. Le dashboard Cloudflare s'effondre à nouveau entre 15h40 et 16h30, submergé par l'arriéré de tentatives de connexion accumulées pendant la panne. Les équipes doivent augmenter en urgence la capacité de traitement pour absorber le choc. Ce n'est qu'à 18h06 que les services ont été rétablis.
Cloudflare annonce un plan de remédiation après l'incident
Dans un long billet de blog publié un peu plus tard, Matthew Prince ne mâche pas ses mots. « Une panne comme celle d'aujourd'hui est inacceptable ». Le PDG promet d'ores et déjà des changements structurels. Les fichiers de configuration générés en interne seront désormais traités avec la même rigueur que les données fournies par les clients, avec validation stricte avant déploiement. Des « coupe-circuits » globaux seront ajoutés pour pouvoir désactiver rapidement une fonctionnalité défaillante.
Les systèmes de débogage ont aussi aggravé la situation. Quand un serveur rencontre une erreur, il génère automatiquement un rapport détaillé pour faciliter le diagnostic. Pendant la panne, ces rapports se sont multipliés, consommant tellement de ressources processeur qu'ils ont ralenti encore davantage le traitement des requêtes légitimes. Cloudflare va aussi plafonner cette consommation.
Pour l'entreprise, qui est l'un des piliers d'Internet avec 20% des sites qui tournent grâce à elle, la leçon est brutale. Depuis la panne majeure de 2019 (une mise à jour d'une règle de pare-feu mal testée), Cloudflare n'avait pas connu telle défaillance aussi généralisée. Cette fois, c'est l'excès de prudence qui a failli : vouloir améliorer la sécurité des accès aux bases de données a déclenché un effet papillon dévastateur. Dans un système aussi complexe, le moindre grain de sable peut gripper la machine entière.
