Code Orange : Fail Small – notre plan de résilience après les récents incidents

Le 18 novembre 2025, le réseau de Cloudflare a subi des défaillances importantes dans l’acheminement du trafic réseau pendant environ deux heures et dix minutes. Près de trois semaines plus tard, le 5 décembre 2025, notre réseau a de nouveau été incapable d’assurer le trafic pour 28 % des applications protégées par notre réseau pendant environ 25 minutes.

Nous avons publié des articles de blog détaillés de type post-mortem à la suite de ces deux incidents, mais nous savons que nous devons en faire davantage pour regagner votre confiance. Aujourd’hui, nous partageons des informations détaillées sur les travaux actuellement menés chez Cloudflare afin d’éviter que des pannes de ce type ne se reproduisent.

Nous avons baptisé ce plan « Code Orange : Fail Small » (Code Orange : limiter l’impact des défaillances), ce qui reflète notre objectif de rendre notre réseau plus résilient face aux erreurs ou aux défaillances susceptibles d’entraîner une panne majeure. Un « Code Orange » signifie que ce projet est prioritaire par rapport à tout le reste. Pour rappel, nous n’avons déclaré un « Code Orange » chez Cloudflare qu’une seule fois auparavant, à la suite d’un autre incident majeur ayant nécessité une mobilisation prioritaire de l’ensemble de l’entreprise. Nous estimons que les événements récents exigent le même niveau d’attention.  Code Orange nous permet de concrétiser cet objectif en autorisant, si nécessaire, une collaboration transversale entre les équipes, tout en suspendant les autres projets.

Le programme Code Orange s’articule autour de trois grands axes :

• Imposer des déploiements contrôlés pour toute modification de configuration propagée sur le réseau, comme nous le faisons déjà aujourd’hui pour les versions logicielles.

• Examiner, améliorer et tester les modes de défaillance de tous les systèmes qui traitent le trafic réseau, afin de garantir qu’ils adoptent un comportement clairement défini dans toutes les situations, y compris en cas d’états d’erreur imprévus.

• Faire évoluer nos procédures internes de type « break glass »* et supprimer toute dépendance circulaire, afin que nous (tout comme nos clients) puissions agir rapidement et accéder à tous les systèmes sans difficulté lors d’un incident.

Ces projets apporteront des améliorations itératives au fur et à mesure de leur avancement, plutôt qu’un changement unique et massif à leur terme. Chaque mise à jour individuelle contribuera à renforcer la résilience de Cloudflare. À terme, nous nous attendons à ce que le réseau Cloudflare soit nettement plus résilient, y compris face à des problèmes similaires à ceux qui ont déclenché les incidents mondiaux que nous avons connus au cours des deux derniers mois.

Nous savons que ces incidents sont difficiles à vivre pour nos clients et pour Internet dans son ensemble. Ils nous embarrassent profondément, et c’est précisément pour cette raison que ce travail constitue la priorité absolue de toutes les équipes chez Cloudflare.

^{* Les procédures « break glass » chez Cloudflare permettent à certaines personnes d’élever temporairement leurs privilèges, dans des circonstances bien précises, afin d’effectuer des actions urgentes pour résoudre des situations particulièrement graves.}

Lors du premier incident, les utilisateurs qui visitaient un site client via Cloudflare voyaient des pages d’erreur indiquant que Cloudflare ne pouvait pas fournir de réponse à leur requête. Lors du second incident, ils voyaient des pages blanches.

Les deux défaillances ont suivi un schéma similaire. Dans les instants précédant chaque incident, nous avons déployé instantanément une modification de configuration dans nos datacenters, répartis dans des centaines de villes à travers le monde.

Le changement de novembre consistait en une mise à jour automatique de notre classificateur Bot Management. Nous exploitons différents modèles d’intelligence artificielle qui apprennent à partir du trafic transitant par notre réseau afin de créer des mécanismes de détection capables d’identifier les bots. Nous mettons constamment ces systèmes à jour pour garder une longueur d’avance sur les acteurs malveillants qui tentent de contourner nos protections de sécurité pour atteindre les sites de nos clients.

Lors de l’incident de décembre, alors que nous cherchions à protéger nos clients contre une vulnérabilité affectant le framework open source populaire React, nous avons déployé une modification d’un outil de sécurité utilisé par nos analystes afin d’améliorer nos signatures. Comme pour les mises à jour urgentes liées à la gestion des bots, nous devions agir rapidement pour devancer les attaquants qui cherchaient à exploiter cette vulnérabilité. Ce changement a déclenché le début de l’incident.

Ce schéma a mis en évidence une lacune importante dans notre manière de déployer les changements de configuration chez Cloudflare, par rapport à notre processus de publication des mises à jour logicielles. Lorsque nous publions de nouvelles versions logicielles, nous le faisons de manière contrôlée et surveillée. Chaque nouvelle version binaire doit franchir avec succès plusieurs étapes de validation avant de pouvoir prendre en charge le trafic à l’échelle mondiale. Nous déployons la mise à jour auprès des employés, puis l’étendons progressivement auprès d’un pourcentage croissant de clients dans le monde, en commençant par les utilisateurs gratuits. Si nous détectons une anomalie à une étape quelle qu’elle soit, nous pouvons revenir en arrière sans aucune intervention humaine.

Nous n’avons pas appliqué cette méthodologie aux changements de configuration. Contrairement aux mises à jour du logiciel central qui alimente notre réseau, les changements de configuration consistent à modifier les paramètres qui déterminent le comportement de ce logiciel, et ils peuvent être appliqués instantanément. Nous offrons d’ailleurs cette même capacité à nos clients : lorsqu’un paramètre est modifié dans Cloudflare, le changement se propage à l’échelle mondiale en quelques secondes.

Si cette rapidité présente des avantages, elle comporte également des risques que nous devons corriger. Les deux incidents récents ont démontré que toute modification affectant la manière dont nous assurons le trafic sur notre réseau doit être abordée avec le même niveau de prudence et de tests que les changements apportés au logiciel lui-même.

Notre capacité à déployer des modifications de configuration à l’échelle mondiale en quelques secondes a été le point commun principal des deux incidents. Dans les deux cas, une mauvaise configuration a mis notre réseau hors service en quelques secondes.

L’introduction de déploiements contrôlés pour nos configurations, comme nous le faisons déjà pour les mises à jour logicielles, constitue le chantier le plus important de notre plan Code Orange.

Les changements de configuration chez Cloudflare se propagent très rapidement sur le réseau. Lorsqu’un utilisateur crée un enregistrement DNS ou une règle de sécurité, cet enregistrement ou cette règle atteint 90 % des serveurs du réseau en quelques secondes. Cette rapidité est assurée par un composant logiciel que nous appelons en interne Quicksilver.

Quicksilver est également utilisé pour toute modification de configuration requise par nos équipes internes. Cette rapidité est une fonctionnalité : nous pouvons réagir et mettre à jour le comportement de notre réseau à l’échelle mondiale très rapidement. Cependant, lors des deux incidents, cette vitesse a provoqué la propagation d’un changement catastrophique sur l’ensemble du réseau en quelques secondes, sans passer par les étapes de validation nécessaires.

Si la possibilité de déployer presque instantanément des changements sur notre réseau est utile dans de nombreux cas, elle est rarement indispensable. Des travaux sont en cours pour traiter les modifications de configuration de la même manière que le code, en introduisant des déploiements contrôlés via Quicksilver pour toute modification de configuration.

Nous publions des mises à jour logicielles sur notre réseau plusieurs fois par jour grâce à ce que nous appelons notre système de déploiement piloté par ’état de santé (Health Mediated Deployment, ou HMD). Dans ce cadre, chaque équipe Cloudflare qui possède un service (un logiciel déployé sur notre réseau) doit définir les indicateurs permettant de déterminer si le déploiement a réussi ou échoué, le plan de déploiement et les actions à entreprendre en cas d’échec.

Différents services auront des variables légèrement différentes. Certains pourraient demander des temps d’attente plus longs avant de passer à d’autres datacenters, tandis que d’autres pourraient avoir des tolérances plus faibles pour les taux d’erreur, même si cela génère des signaux faussement positifs.

Une fois le déploiement lancé, notre kit HMD progresse soigneusement selon le plan défini, en surveillant chaque étape avant de continuer. En cas d’échec, la restauration se déclenche automatiquement et l’équipe peut être alertée si nécessaire.

À la fin du plan Code Orange, les mises à jour de configuration suivront le même processus. Nous nous attendons à ce que cela nous permette de détecter rapidement les problèmes similaires à ceux survenus lors des deux derniers incidents, bien avant qu’ils ne deviennent des problèmes généralisés.

Bien que nous soyons optimistes sur le fait qu’un meilleur contrôle des changements de configuration permettra de détecter davantage de problèmes avant qu’ils ne se transforment en incidents, nous savons que des erreurs peuvent et vont se produire. Lors des deux incidents, des erreurs sur une partie de notre réseau se sont propagées à la majorité de notre infrastructure, y compris au plan de contrôle sur lequel les clients s’appuient pour configurer l’utilisation de Cloudflare.

Nous devons penser en termes de déploiements gradués et prudents, et non seulement en termes de progression géographique (étendre à davantage de datacenters) ou en termes de progression de la population (étendre aux employés et selon les types de clients). Nous devons également prévoir des déploiements plus sûrs qui isolent les défaillances entre services (passer d’un produit comme notre service Bot Management à un autre produit non lié, comme notre tableau de bord).

À cet effet, nous sommes en train de réviser les contrats d’interface entre chaque produit et service critique de notre réseau pour nous assurer que : a) nous anticipons les défaillances entre chaque interface ; et b) nous gérons ces défaillances de la manière la plus raisonnable possible. 

Pour revenir à l’incident concernant le service Bot Management, il y avait au moins deux interfaces clés que nous aurions pu gérer de manière à ce qu’aucun client ne soit probablement impacté, si nous avions anticipé les défaillances. La première était l’interface qui lisait le fichier de configuration corrompu. Au lieu de provoquer une défaillance, il aurait dû exister un ensemble de valeurs par défaut validées permettant au trafic de continuer à circuler sur notre réseau, tandis que, dans le pire des cas, nous aurions seulement perdu le réglage en temps réel alimentant nos modèles de machine learning pour la détection des bots. La deuxième interface se situait entre le logiciel central de notre réseau et le module Bot Management lui-même. En cas de défaillance du module de gestion des robots (comme cela s’est produit), nous n’aurions pas dû bloquer le trafic par défaut. Nous aurions pu définir un comportement par défaut plus raisonnable, laissant passer le trafic avec une classification approximative, mais acceptable.

Pendant les incidents, il nous a fallu trop de temps pour résoudre les problèmes. Dans les deux cas, cela a été aggravé par nos systèmes de sécurité qui empêchaient certains membres de l’équipe d’accéder aux outils nécessaires, et, dans certains cas, des dépendances circulaires nous ont ralentis, car certains systèmes internes étaient également indisponibles.

En tant qu’entreprise de sécurité, tous nos outils sont protégés par des couches d’authentification avec des contrôles d’accès précis, afin de sécuriser les données clients et d’éviter tout accès non autorisé. Cela est nécessaire, mais nos processus et systèmes actuels nous ont ralentis lorsque la vitesse était une priorité absolue.

Les dépendances circulaires ont également affecté l’expérience client. Par exemple, lors de l’incident du 18 novembre, Turnstile, notre solution anti-bot sans CAPTCHA, est devenue indisponible. Comme nous utilisons Turnstile pour la connexion au tableau de bord Cloudflare, les clients n’ayant pas de session active ni de jeton d’API n’ont pas pu se connecter à Cloudflare au moment où ils en avaient le plus besoin pour effectuer des changements critiques.

Notre équipe va réviser et améliorer toutes les procédures et technologies « break glass » afin de garantir que, lorsque nécessaire, nous puissions accéder aux bons outils le plus rapidement possible tout en respectant nos exigences de sécurité. Cela inclut la révision et la suppression des dépendances circulaires, ou la possibilité de les « contourner » rapidement en cas d’incident. Nous allons également augmenter la fréquence de nos exercices de formation, afin que les processus soient bien compris par toutes les équipes avant toute situation de crise potentielle. 

Bien que nous n’ayons pas détaillé dans cet article l’ensemble des travaux internes, les axes décrits ci-dessus représentent les priorités principales sur lesquelles les équipes doivent se concentrer. Chacun de ces axes correspond à un plan détaillé impliquant presque tous les produits et équipes d’ingénierie de Cloudflare. Nous avons beaucoup de travail devant nous.

D’ici la fin du premier trimestre, et pour une grande partie avant cette date, nous prévoyons de :

• garantir que tous les systèmes de production sont couverts par des déploiements pilotés par l’état de santé (HMD) pour la gestion des configurations ;

• mettre à jour nos systèmes afin qu’ils respectent les modes de défaillance appropriés pour chaque ensemble de produits ;

• nous assurer que nous avons mis en place des processus garantissant que les bonnes personnes ont le bon accès pour appliquer les remédiations appropriées lors d’une urgence.

Certaines de ces mesures seront perpétuelles. Nous devrons toujours améliorer la gestion des dépendances circulaires lors du lancement de nouveaux logiciels, et nos procédures « break glass » devront évoluer en fonction des changements de nos technologies de sécurité.

Nous avons échoué auprès de nos utilisateurs et d’Internet dans son ensemble lors de ces deux derniers incidents. Nous avons beaucoup de travail pour réparer ces erreurs. Nous prévoyons de partager des mises à jour régulières au fur et à mesure de l’avancement de ce travail et nous apprécions les questions et les retours que nous avons reçus de la part de nos clients et partenaires.