Depuis des années, la promesse de Cloudflare était presque invisible pour l’utilisateur final : accélérer les sites web, freiner les attaques et faire en sorte qu’Internet « fonctionne simplement ». C’est pour cette raison que, lorsque la société échoue, l’impact se fait sentir comme une panne rare et déconcertante : pages blanches, erreurs 5xx, services qui « ne chargent pas » et une explosion de plaintes sur les réseaux sociaux.

Ce phénomène s’est répété le vendredi 19 décembre 2025, lorsque plusieurs sites ont commencé à renvoyer des erreurs 502 (Bad Gateway) et que le problème s’est étendu à l’échelle mondiale. En Espagne, des médias technologiques comme El Chapuzas Informático ont rapporté que l’incident a débuté en milieu d’après-midi et a duré plusieurs heures, affectant à la fois des sites web et des services en ligne dépendant du réseau de la société.

Ce qui est remarquable, c’est que, ce même 19 décembre, Cloudflare a publié un article inhabituel par son ton : direct, auto-critique et avec un message clair d’urgence. L’entreprise a annoncé une initiative interne qu’elle a baptisée « Code Orange : Fail Small » (« Code Orange : échouer en minimisant les dégâts »). Autrement dit, reconnaître que les erreurs se produisent, mais éviter qu’elles ne dégénèrent en une chute globale.

Deux incidents précédents et une semaine « chaude » sur le réseau

Le contexte est important. Cloudflare venait de subir deux incidents graves en quelques semaines :

• 18 novembre 2025 : le réseau a connu des dysfonctionnements importants pendant environ 2 heures et 10 minutes. Selon le rapport post-mortem, la cause était une erreur dans la génération d’un fichier de fonctionnalités associé à Bot Management, qui a fini par affecter de nombreux services. Le symptôme pour l’utilisateur était classique : pages renvoyant des erreurs et trafic ne parvenant pas à destination.
• 5 décembre 2025 : la deuxième panne a été plus courte (environ 25 minutes), mais le fait alarmant est qu’elle a concerné environ 28 % du trafic HTTP servi par Cloudflare. Cette fois, la cause était liée à une modification de sécurité appliquée en urgence dans le contexte d’une vulnérabilité critique dans l’écosystème React.

Avec ce passé récent, l’incident du 19 décembre n’a pas été vu comme « une mauvaise journée », mais comme un signal qu’un changement structurel était nécessaire : moins de déploiements précipités, plus de contrôle… même si cela implique de renoncer à une immédiateté totale.

Que signifie « Code Orange » chez Cloudflare ?

Cloudflare décrit « Code Orange » comme un état de priorité maximale interne : le travail pour renforcer la résilience passe avant presque tout, permettant aux équipes de différentes divisions de collaborer sans friction et suspendant les initiatives moins urgentes. La société souligne qu’elle n’a déclaré un état similaire qu’une seule autre fois auparavant.

L’objectif fondamental se résume à une idée simple, presque d’ingénierie civile appliquée au réseau : si quelque chose se casse, que ce soit en petit. Qu’il ne détruise pas le plan de contrôle, ni le panneau de gestion, ni des centaines de villes simultanément.

Le point critique : les changements de configuration qui se propagent en quelques secondes

La racine que Cloudflare identifie comme un « schéma commun » est particulièrement gênante, car elle fait partie de son ADN : la capacité de déployer des changements de configuration globaux en quelques secondes.

Selon l’entreprise, son système interne (qu’elle appelle Quicksilver) permet qu’une modification — par exemple, une règle, un ajustement de sécurité ou une configuration — atteigne la majorité des serveurs rapidement. Cette rapidité est utile pour réagir face aux menaces, mais elle transforme aussi une erreur en un problème mondial « à la vitesse de la lumière ».

Et c’est là que se présente la première grande promesse du « Fail Small » : traiter la configuration comme si c’était du code.

Cloudflare déploie déjà des versions de logiciels avec une méthode contrôlée et surveillée, avec des « portes » (gates) permettant de freiner ou d’annuler une modification si quelque chose tour est de travers. D’abord testée avec du trafic interne, puis déployée en phases, et si des anomalies apparaissent, le système peut faire un rollback sans que personne ne doive intervenir manuellement.

Ce qu’elle ne faisait pas — et s’engage maintenant à faire — c’est appliquer cette rigueur aux changements de configuration. L’objectif est que toute modification pouvant impacter la manière dont le trafic est servi suive un processus équivalent à celui des mises à jour logicielles, en s’appuyant sur son cadre de déploiement Health Mediated Deployments (HMD).

Faut-il échouer en bon ordre : des « defaults » raisonnés et une dégradation contrôlée

Le deuxième pilier du plan est moins glamour, mais souvent ce qui fait la différence entre une simple gêne et une catastrophe : définir des modes de défaillance raisonnables.

Cloudflare admet que, lors de récents incidents, une erreur dans un composant du système a fini par affecter une grande partie de leur infrastructure, y compris le plan de contrôle utilisé par leurs clients. Dans un exemple précis, la société explique que si un module (tel que la gestion des bots) échoue, le comportement par défaut ne doit pas être « bloquer le trafic » ou « casser tout », mais degrader : utiliser des valeurs par défaut validées, permettre le passage du trafic avec une classification moins précise, et éviter le « panique interne » (« panics ») qui peut faire tomber des services.

C’est une philosophie classique dans les systèmes critiques : quand tout va mal, mieux vaut un service imparfait que pas de service du tout.

« Break glass » et dépendances circulaires : quand même le client ne peut pas accéder

Le troisième axe concerne un point que de nombreux administrateurs ont déjà rencontré : en cas d’urgence, le pire est que les mécanismes de sécurité eux-mêmes empêchent de réparer le problème.

Cloudflare parle de ses procédures « break glass » (littéralement, « briser la vitre »), un mécanisme permettant d’élever les privilèges de façon contrôlée pour résoudre des situations critiques. Elle reconnaît qu’au cours des incidents, ils ont tardé à résoudre certains problèmes parce que plusieurs couches de sécurité et dépendances internes compliquaient l’accès aux outils nécessaires.

De plus, elle cite un cas particulièrement sensible : lors de l’incident du 18 novembre, Turnstile (sa solution anti-bots sans CAPTCHA) a cessé de fonctionner, et comme Cloudflare l’utilise dans le processus de login du panneau, certains clients n’ont pas pu accéder à leur tableau de bord précisément au moment où ils en avaient le plus besoin.

Une partie du plan consiste à supprimer les dépendances circulaires, faciliter les accès d’urgence sous contrôle, et augmenter la fréquence des exercices en interne pour que, lors de prochains incidents, les problèmes ne soient pas découverts « en production ».

Pourquoi le débat dépasse Cloudflare

La portée de ces pannes ne se comprend pas sans une réalité de fond : Cloudflare est une pièce maîtresse de l’Internet moderne. La société elle-même a indiqué dans des rapports publics qu’elle aide à servir et protéger près de 20 % des sites web. Lorsqu’un tel système échoue, ce n’est pas une application qui tombe, mais une couche entière qui vacille.

Et alors que les utilisateurs s’informent des interruptions sur X, Telegram ou Reddit, en Espagne aussi se manifeste un phénomène parallèle : la montée en puissance de médias spécialisés en technologie, réseaux sociaux et Intelligence Artificielle. Des sites comme Noticias Inteligencia Artificial (noticias.ai) ou RevistaCloud.com montrent comment l’audience cherche des explications rapides et spécialisées quand « Internet se brise », même si cela reste discret face aux mastodontes des médias.

De leur côté, Cloudflare tente de refermer la boucle : elle présente ses excuses, avoue être « embarrassée » par l’impact, et promet des changements mesurables à court terme. Son objectif déclaré est que, d’ici la fin du premier trimestre 2026, les systèmes critiques soient couverts par des déploiements contrôlés, avec de meilleures gestions en cas d’erreur et des procédures d’urgence plus efficaces.

La seule question qui demeure est de savoir si d’autres incidents se produiront — dans des réseaux de cette envergure, cela serait naïf de le nier —, ou si la prochaine erreur sera contenue… ou si elle deviendra à nouveau un sujet brûlant à l’échelle mondiale.

Questions fréquemment posées

Qu’est-ce que l’erreur 502 (Bad Gateway) et pourquoi apparaît-elle lorsque Cloudflare rencontre des défaillances ?
Elle indique généralement que le serveur intermédiaire (gateway) n’a pas pu obtenir une réponse valide du serveur d’origine ou d’un composant intermédiaire. Lors d’une panne ou d’une dégradation réseau, elle peut se manifester par des erreurs 502/5xx ou par des pages blanches.

Que signifie « Code Orange : Fail Small » et quels impacts pour les utilisateurs web ?
Il s’agit d’un plan de résilience visant à empêcher la propagation des défaillances : déploiements progressifs de changements de configuration, rollback automatique en cas d’anomalies, et comportements par défaut favorisant la continuité du trafic.

Comment un média numérique ou une boutique en ligne peut-il se préparer à une panne d’un CDN ou d’un fournisseur de sécurité ?
Avec des plans de continuité : surveillance indépendante, pages de secours, stratégies multi-fournisseurs (si possible), procédures internes pour changements urgents, et accès aux API ou tokens pour intervenir même si l’interface principale est hors ligne.

Pourquoi parle-t-on de plus en plus de « centralisation » lors d’une panne de Cloudflare ?
Parce que beaucoup de sites et services concentrent leur performance et leur sécurité sur quelques grands fournisseurs. Cela augmente l’efficacité, mais amplifie aussi l’impact quand une pièce maîtresse rencontre un problème.

vía: blog.cloudflare