导航|地址|刷新
Le projet Code Orange: Fail Small arrive…




Aller au contenu
















Toutes les catégories

IA

Développeurs

Radar

Nouveautés produits

Sécurité

Politique et juridique

Zero Trust

Rapidité et fiabilité

La vie chez Cloudflare

Partenaires



Cet article est disponible en

English

Deutsch

Español

Español (Latinoamérica)

Italiano

日本語

한국어

繁體中文

简体中文

Português

Polski

Changer la langue du site

English

Deutsch

Español

Español (Latinoamérica)

Français

Italiano

日本語

한국어

繁體中文

简体中文

Português

Русский

Bahasa Indonesia

ภาษาไทย

Tiếng Việt

Polski

العربية

עברית

Svenska

Nederlands

Türkçe

ConnexionContacter le service commercial










Blog

Analyse post-incidentCode OrangePanne


3 tagsAfficher 3 tags






Tags sélectionnés

Analyse post-incidentCode OrangePanne

Toutes les étiquettes

Tags correspondants

Aucun tag trouvé

1.1.1.1

Acquisitions

Agents

Agents Week

AI Bots (FR)

AI Gateway (FR)

AI-SPM

AI Week

Alertes d'attaques DDoS

Always Online (FR)

AMD (FR)

Amérique latine

Analyse approfondie

Analyse post-incident

Anonymous (FR)

Anycast (FR)

API

Athenian Project (FR)

Attaques

Attaques avec demande de rançon

Attaques DDoS

Automatisation

Awards (FR)

AWS

Base de données

Bêta

Bilan de l'année

Botnet (FR)

Bots

Browser Rendering

Browser Run

Bug Bounty (FR)

Bureaux

Cache

CASB

Centre de sécurité

Certificate Authority (FR)

Certification

China (FR)

CIO Week

CISA (FR)

Cloud Email Security

Cloudflare Access

Cloudflare Calls

Cloudflare for Startups

Cloudflare Gateway

Cloudflare One

Cloudflare Pages

Cloudflare Queues

Cloudflare Tunnel

Cloudflare Workers

Cloudflare Zero Trust

Cloudforce One

Code Orange

Coinbase

Compression

Confidentialité

Conformité

Connectivity (FR)

Conteneurs

Contexte

Coupure d'Internet

Crawler Hints

CrowdStrike (FR)

Cryptographie

Crypto Week (FR)

D1

Data Catalog

Data Localization (FR)

Data Localization Suite (FR)

Data Privacy Day (FR)

des flux de travail

Developer Week

Développeurs

DevOps (FR)

Digital Experience Monitoring (FR)

Disponibilité générale

Diversity (FR)

DLP

DMARC (FR)

DNS

DNS Flood (FR)

Documentation destinée aux développeurs

Dogfooding (FR)

DoH (FR)

Données analytiques

Durable Objects

Early Hints (FR)

EC2 (FR)

Éléments aléatoires

Emissions

Entropie

État de préparation aux agents

Fancy Bear (FR)

Forrester

Foundation DNS (FR)

France (FR)

Fraude

Freedom of Speech (FR)

Free (FR)

Front-end

full-stack

Gartner (FR)

Gatebot (FR)

GDPR (FR)

Geo Key Manager (FR)

Germany (FR)

Gestion des bots

Gestion des risques

Gestion du niveau de sécurité

GitHub

Google Cloud

HTTP2 (FR)

Hyperdrive

IA

IA générative

impact

Impact Week (FR)

Informations sur les menaces

Ingénierie

Intégration cloud & cloud de connectivité

Intel

Interconnection

JAMstack (FR)

Jengo (FR)

Journée de l'indépendance du contenu

Killnet (FR)

LavaRand

La vie chez Cloudflare

Lazarus Group (FR)

Le post-quantique

L’équipe

Lettre des fondateurs

Lisbonne

LLM

Log4J (FR)

Log4Shell (FR)

Logs (FR)

MCP

Menaces

Meris (FR)

Microsoft Azure (FR)

Mirai

Mobile (FR)

Model Context Protocol,

Multi-Cloud (FR)

MySQL

NaaS (FR)

Network Interconnect (FR)

Network Protection (FR)

NGINX

Notifications (FR)

Nouveautés produits

Olympics (FR)

Opérations liées aux menaces

Panne

Pare-feu d'applications web

Pare-feu WAF

Partenaires

Passerelle web sécurisée

PCI Certified (FR)

Peering (FR)

Performances

Performances d'Internet

Phishing

Pipelines

Plateforme pour développeurs

Politique et juridique

Portugal

Project Safekeeping (FR)

Projet Galileo

Protection avancée contre les attaques DDoS

Python (FR)

Qualité d'Internet

Queues

R2 Super Slurper

Radar

Radar API (FR)

Rapidité

Rapidité et fiabilité

Rapid Reset (FR)

Rapports DDoS

Rate Limiting (FR)

Reading List (FR)

Recherche

Recherche par IA

Regional Services (FR)

Réseau de diffusion de contenu (CDN)

REvil (FR)

Routing (FR)

Rust

Saas (FR)

Sable (FR)

Sandbox

Sans client

SASE

SDK

Sécurité

Sécurité des API

Sécurité des applications

Sécurité des e-mails

Sécurité SaaS

Security Posture (FR)

Security Service Edge (FR)

Security Week

Semaine anniversaire

Serverless

Serveur d'inscription

Serveur TURN

Services aux consommateurs

Services pour applications

Services réseau

SIEM (FR)

SIM (FR)

South America (FR)

Speed Week (FR)

Sports (FR)

SSE (FR)

Stockage

Sumo Logic (FR)

Supercloud (FR)

Sustainability (FR)

SYN Flood (FR)

Teams Dashboard (FR)

Temps réel

Tendances

Tendances Internet

Testing (FR)

Tor (FR)

Trafic Internet

Transparence

Trust & Safety (FR)

Vectorize (FR)

VoiP (FR)

Waiting Room (FR)

WARP Connector (FR)

WASM (FR)

WebAssembly (FR)

WebRTC

Workers AI

Workers Launchpad

Workers VPC

x402

Zero Day Threats (FR)

Zero Trust

Zero Trust Week (FR)




Analyse post-incidentCode OrangePanne






1 mai 2026
Le projet Code Orange: Fail Small arrive à son terme et le réseau Cloudflare s'en trouve renforcé




Jeremy Hartman



Lecture : 15 min.
Copier l'URL



Cet article est également disponible en English,Deutsch,Español,Español (Latinoamérica),Italiano,日本語,한국어,繁體中文,简体中文,Português et Polski.








Ces deux derniers trimestres (et même un peu plus), nous avons entrepris un effort de développement intensif, baptisé en interne « Code Orange: Fail Small », un projet axé sur le renforcement de la résilience, de la sécurité et de la fiabilité de l'infrastructure Cloudflare pour chacun de nos clients.

L'équipe Cloudflare a achevé ces travaux au début du mois.

Nous ne considérerons jamais l'amélioration de la résilience comme un « travail fini ». Il s'agira d'ailleurs toujours d'une de nos priorités en tête de liste tout au long de notre cycle de développement. Nous avons néanmoins achevé le travail qui nous aurait évité les deux défaillances mondiales survenues les 18 novembre et 5 décembre 2025.

Le projet s'axait autour de plusieurs domaines essentiels : l'amélioration de la sécurité des modifications de configuration, la réduction de l'impact des défaillances, ainsi que la révision de nos procédures d'urgence (break-glass) et de gestion des incidents. Nous avons également introduit des mesures destinées à éviter la dérive et les régressions au fil du temps, mais aussi à renforcer la manière dont nous communiquons avec nos clients lors d'une défaillance.

Cet article détaille en profondeur les fonctionnalités que nous avons lancées et leurs implications pour vous.

Amélioration de la sécurité des modifications de configuration

Les implications pour vous : dans la plupart des cas, les modifications de configuration du réseau Cloudflare effectuées en interne ne se propagent plus instantanément sur notre réseau, mais sont déployées progressivement, en surveillant l'intégrité de ce dernier en temps réel. Ce processus permet à nos outils d'observabilité de détecter les problèmes et de résoudre les dysfonctionnements avant qu'ils n'affectent votre trafic.

Afin d'intercepter les déploiements potentiellement dangereux avant leur mise en production, nous avons identifié les pipelines de configuration à haut risque et développé de nouveaux outils conçus pour mieux gérer les modifications apportées aux configurations.

Nous ne déployons ainsi plus ces changements instantanément sur l'ensemble du réseau pour les produits qui s'appuient sur notre réseau pour traiter le trafic client et recevoir les modifications apportées. De ce fait, les équipes concernées ont adopté une méthodologie de « déploiement piloté par l'intégrité », qui se révèle strictement la même que celle que nous utilisons pour la mise en œuvre de toutes les configurations lorsque nous lançons des logiciels. Cette approche inclut, sans toutefois s'y limiter, les équipes produits directement affectées par les incidents.

La clé de cette stratégie réside dans un nouveau composant interne que nous nommons Snapstone et que nous avons développé pour mettre en place le déploiement piloté par l'intégrité au niveau des modifications de configurations. Le système Snapstone regroupe ces modifications au sein d'un package et permet ensuite de procéder à un déploiement progressif de ces dernières en suivant les principes du pilotage par l'intégrité. Avant Snapstone, l'application de cette méthodologie aux configurations était possible, mais demeurait une tâche des plus ardues. L'opération demandait un travail considérable à chacune des équipes et les modifications n'étaient pas appliquées de manière cohérente sur l'ensemble du réseau. Snapstone comble cette lacune en proposant, par défaut, un moyen unifié d'incorporer les notions de mise en œuvre progressive, de surveillance de l'intégrité en temps réel et de roll-back automatique aux déploiements de configurations.

Le principal atout de Snapstone réside dans sa flexibilité. Plutôt que de corriger les défaillances spécifiques déjà passées, la solution Snapstone permet aux équipes de définir de manière dynamique n'importe quelle unité de configuration nécessitant un pilotage par l'intégrité, qu'il s'agisse d'un fichier de données (comme celui qui causé la panne du 18 novembre) ou d'un indicateur de contrôle au sein de notre système de configuration mondial (comme celui impliqué dans la défaillance du 5 décembre). Les équipes produisent ces unités de configuration à la demande et Snapstone s'assure que ces dernières soient déployées de manière sécurisée, partout où elles sont utilisées.

Cette opération nous offre quelque chose dont nous ne disposions pas auparavant. La solution est désormais des plus simples lorsqu'un processus d'examen des risques ou une expérience opérationnelle identifie une configuration dangereuse : il nous suffit d'aiguiller l'élément en question vers Snapstone et la configuration bénéficiera immédiatement d'un déploiement sécurisé. 

Réduction de l'impact des défaillances

Les implications pour vous : en cas de problème observé au sein de notre réseau, nos systèmes tombent désormais en panne avec davantage de souplesse. Cette situation réduit le champ potentiellement affecté dans des proportions considérables et nous permet d'assurer la diffusion de votre trafic, même dans les scénarios les plus catastrophiques.

Les équipes produit ont analysé avec soin (de façon manuelle et programmatique) les modes de défaillance potentiels de leurs produits essentiels au traitement du trafic de nos clients. Elles ont ainsi supprimé les dépendances non essentielles de l'environnement d'exécution et déployé de meilleurs modes de défaillance. Nous employons désormais la dernière configuration fonctionnelle connue si possible (« fail stale »). Si l'opération ne se révèle pas possible, nous examinons chaque scénario d'erreur et mettons en œuvre une solution « fail open » (basculement en position ouverte) ou « fail close » (basculement en position fermée) selon que la diffusion du trafic sous fonctionnalité réduite s'avère préférable au fait ne pas diffuser du tout le trafic.

Illustrons ce fonctionnement par un exemple. Notre panne survenue au mois de novembre 2025 résulte de l'échec du déploiement de notre classificateur (soutenu par apprentissage automatique) chargé de la détection et de la gestion des bots. Avec nos nouvelles procédures, si des données que notre système ne pouvait pas lire étaient générées à nouveau, ce dernier refuserait d'utiliser la configuration mise à jour et emploierait dès lors l'ancienne configuration. Si l'ancienne configuration n'était pas disponible pour une raison quelconque, le système basculerait en mode « fail open » afin de faire en sorte que le trafic de production du client continue d'être diffusé. Il s'agit là d'une bien meilleure solution que de passer par un épisode d'interruption de service.

Par conséquent, si la modification de la solution Bot Management qui était à l'origine de la défaillance de novembre devait être déployée aujourd'hui, le système détecterait l'erreur à une phase avancée du déploiement, avant qu'elle n'affecte davantage qu'un faible pourcentage du trafic.

Nous avons également commencé à segmenter davantage notre système afin que des copies indépendantes des services soient exécutées pour différents groupes de trafic. Cloudflare tire déjà parti de ces groupes de clients aujourd'hui pour atténuer le rayon d'action des attaques grâce à diverses techniques de gestion du trafic. Cette segmentation supplémentaire des processus nous permet désormais de disposer de puissantes capacités en termes de fiabilité.  

L'environnement d'exécution de Workers, par exemple, est segmenté en plusieurs services indépendants qui gèrent chacun un groupe de trafic différent et seul l'un de ces groupes gère le trafic de nos clients titulaires de l'offre gratuite. Les modifications sont déployées sur ces segments en fonction des groupes de clients, en commençant par nos clients gratuits. Nous envoyons également plus rapidement et plus fréquemment les mises à jour vers les segments moins critiques, et à un rythme plus lent vers les segments les plus essentiels.

De ce fait, si une modification était déployée au sein de l'environnement d'exécution de Workers et engendrait une perturbation du trafic, cette modification n'affecterait qu'un faible pourcentage de nos clients gratuits, avant d'être automatiquement détectée et annulée.

Pour en revenir à l'environnement d'exécution de Workers, le processus de déploiement s'est, par exemple, déclenché plus de 50 fois au cours d'une période de sept jours au début du mois. Le graphique ci-dessous montre comment chacun de ces scénarios se déroule « par vagues », lorsque la modification se propage vers la périphérie du réseau (l'edge), souvent de manière parallèle aux versions suivantes et précédentes :





Nous comptons étendre ce principe de déploiement à bien d'autres de nos systèmes à l'avenir.

Révision de nos procédures d'urgence et de gestion des incidents

Les implications pour vous : si un incident se produit, nous disposons des outils et des équipes nécessaires pour nous permettre de communiquer plus clairement sur le problème et de résoudre ce dernier plus rapidement, tout en réduisant l'épisode d'interruption de service au minimum.

Cloudflare s'exécute sur Cloudflare. Nous sécurisons notre infrastructure à l'aide de nos propres produits Zero Trust, mais cette situation entraîne une dépendance. Dès lors, si une panne à l'échelle du réseau affecte ces outils, nous perdons les liaisons même que celles dont nous avons besoin pour les corriger. Avant l'initiative « Code Orange », nos protocoles d'urgence étaient réservés à une poignée de personnes et ne proposaient qu'un accès limité aux outils. Nous avons besoin de ces outils et de liaisons plus largement disponibles en cas de défaillance.

Pour résoudre ce problème, nous avons conduit un audit complet des outils essentiels à la visibilité du système, au débogage et aux modifications apportées à l'environnement de production. Nous avons finalement développé des liaisons d'autorisation de secours composées de 18 services essentiels, pris en charge par de nouveaux scripts et proxys d'urgence.

Le programme Code Orange nous a permis de passer de la théorie à la pratique. Après une phase d'exercices en petites équipes, nous avons organisé un exercice impliquant l'ensemble de notre service technique (soit plus de 200 collaborateurs) le 7 avril 2026. Les exercices de ce type permettent à nos techniciens de développer des automatismes sur lesquels ils pourront compter en cas de crise, même si nos processus automatisés nous permettent de préserver le bon fonctionnement de ces liaisons.
…(内容过长已截断)

------
导航页 打开网址