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

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.

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é. 

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.

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.

Cette initiative portait également sur le flux d'informations. Notre processus de réponse aux incidents ralentit en cas de perturbation de notre visibilité interne et notre capacité à communiquer avec le monde extérieur en pâtit. Traditionnellement, les observations techniques réalisées dans le feu de l'action ne se sont pas toujours traduites par des mises à jour précises pour nos clients.

Nous avons mis en place une équipe de communication dédiée pour remédier à ce problème. Cette dernière est chargée de travailler en étroite collaboration avec les équipes de réponse aux incidents lors des événements majeurs. Pendant que nos techniciens s'exerçaient à pratiquer leurs procédures d'urgence, cette équipe s'appuyait sur le programme Code Orange pour s'exercer à rationaliser le rythme et la clarté des mises à jour clients. Maintenant que nous nous sommes assurés que nous disposons à la fois des outils nécessaires à la visibilité et d'une structure adéquate pour communiquer, nous pouvons résoudre plus rapidement les incidents et mieux informer nos clients.

Les implications pour vous : nous nous souviendrons des enseignements tirés des incidents que nous avons subis et avons codifié nos résolutions en ce sens. Notre réseau ne peut désormais que devenir plus résilient.

Afin d'éviter tout dérapage et de réintroduire des vulnérabilités dans le travail accompli au fil du temps dans le cadre du programme Code Orange, notre équipe a mis au point un codex interne qui réunit l'ensemble de nos recommandations sous la forme de règles claires et concises.

L'utilisation du codex est désormais obligatoire pour l'ensemble de nos équipes techniques et produits. Cet ouvrage s'impose donc comme un composant central des procédures internes en vigueur chez Cloudflare. Ses règles sont mises en application par des processus de révision du code généré par IA qui mettent automatiquement en lumière les instances susceptibles de diverger de nos lignes directrices et qui impliquent la réalisation d'examens manuels supplémentaires. Le codex s'applique à l'intégralité de notre base de code, sans exception. L'objectif est simple : nous bâtir des automatismes à l'échelle de l'entreprise capables de s'appliquer eux-mêmes.

Les pannes des mois de novembre et de décembre partageaient un mode de défaillance commun, à savoir un code qui supposait que les entrées seraient toujours valides et qui ne disposait d'aucun mécanisme de dégradation en douceur lorsque cette hypothèse s'avérait fausse. Un service Rust appelait .unwrap() plutôt que de traiter une erreur, tandis que le code Lua indexait un objet qui n'existait pas. Ces deux schémas peuvent être évités si les leçons ont bien été assimilées et mises en application.

Le codex fait partie intégrante de notre processus de réponse. Ce référentiel vivant de normes techniques est rédigé par des experts de leur domaine par l'intermédiaire de notre processus RFC (Request for Comments, demandes de commentaires), avant d'être synthétisé sous la forme de règles exploitables. Les bonnes pratiques autrefois uniquement connues des techniciens expérimentés ou qui n'étaient identifiées qu'après un incident deviennent désormais une somme de savoir partagé et accessible à tous. Chaque règle suit un format simple : « Si vous avez besoin de X, servez-vous de Y ». Elle s'accompagne également d'un lien vers la RFC qui en explique les raisons.

Une RFC stipule désormais : « Ne pas utiliser .unwrap() » en dehors des tests et du fichier build.rs », par exemple. Une autre exprime un principe plus large : « Les services DOIVENT valider que les dépendances en amont sont bien dans l'état attendu avant de traiter une opération quelconque ».

Si ces règles avaient été appliquées plus tôt, les défaillances de novembre et décembre auraient pris la forme de demandes de fusion refusées plutôt que de se traduire par des incidents mondiaux.

Sans mise en application, les règles ne sont que des suggestions. Le codex s'intègre à des agents assistés par IA à chaque étape du cycle de vie du développement logiciel, de l'examen de la conception jusqu'au déploiement en passant par l'analyse des incidents. Ce mode de fonctionnement fait passer la mise en application du statut de « panne mondiale » à celui de « demande de fusion refusée ». Le rayon d'action d'une violation passe de millions de requêtes affectées à l'information d'un seul développeur par le biais d'un retour exploitable avant que le code n'atteigne la production.

Le codex est un document vivant, qui sera amélioré en permanence au fil du temps. Les experts de leur domaine rédigent des RFC afin de codifier les bonnes pratiques. Les incidents mettent en lumière les lacunes, qui deviennent ensuite de nouvelles RFC. Chaque RFC approuvée génère des règles qui viennent intégrer le codex. Ces règles nourrissent les agents qui examineront la demande de fusion suivante. L'ensemble se comporte un peu comme un volant d'inertie : l'expertise se transforme en normes, les normes deviennent des mesures d'application et ces mesures relèvent le niveau pour tout le monde.

Les implications pour vous : la transparence est essentielle à nos yeux. En cas de problème, nous nous engageons à vous tenir informés à chacune des étapes du cycle afin de vous permettre de continuer à vous concentrer sur l'essentiel.

Les défaillances à l'échelle mondiale nous ont amenés à remettre en question certains processus clés et certaines approches culturelles en vigueur au sein de notre entreprise, au-delà même de la technique et du développement produits. Nous avons ainsi ajouté des objectifs de niveau de service (Service Level Objectives, SLO) supplémentaires à l'ensemble de nos services dans le cadre des initiatives Code Orange au sens plus large. Nous avons en outre imposé un journal des modifications mondial, intégré toutes nos équipes à notre système de coordination de la maintenance et amélioré la transparence de notre backlog de tickets de « prévention » d'incidents sur l'ensemble de notre entreprise. 

Nous avons également renforcé la manière dont nous communiquons avec nos clients lors d'un épisode de défaillance. L'objectif poursuivi ici est de vous alerter d'un problème dès que nous pouvons le confirmer, et ce avant même que vous ne remarquiez le problème. Ainsi, lorsque vous constatez un délai ou une erreur, vous devriez déjà avoir un bulletin d'information de notre part dans vos notifications.

En cas d'incident, nous vous informons désormais à intervalles prévisibles (p. ex. toutes les 30 ou 60 minutes), même si ce n'est que pour vous indiquer « Nous sommes toujours en train de tester la solution. Aucune modification n'est déployée pour le moment ». Vous pouvez ainsi continuer à organiser votre journée plutôt que de devoir constamment actualiser une page d'état.

Notre travail ne se termine pas au moment où la situation revient à la normale. Nous vous proposons une analyse après incident détaillée afin de vous expliquer ce qui s'est passé, les raisons pour lesquelles l'incident s'est produit, ainsi que les changements structurels spécifiques que nous apportons à nos systèmes afin de nous assurer que cet événement ne se reproduise pas à l'avenir.

Nous prenons ces incidents très au sérieux et, en ce sens, avons adopté la notion de responsabilité partagée au sein de l'ensemble de Cloudflare en demandant à chacune de nos équipes : « Qu'aurait-on pu mieux faire ? » Les réponses à cette question ont guidé les travaux que nous avons entrepris ces deux derniers trimestres.

Bien que ce travail ne prenne jamais vraiment fin, nous sommes convaincus de nous trouver dans une position bien meilleure et Cloudflare en ressort désormais bien plus solide.