Pour écrire cette édition un peu spéciale, je me suis plongé dans les deux rapports d’incident publiés par Cloudflare : celui du 18 novembre et celui du 5 décembre. Ils ont tous les deux été publiés le jour des incidents et reprennent en détail les incidents et leurs causes. Le sujet touchant à des sujets assez complexes, on va y aller par étape.
Le concept expliqué à quelqu’un qui découvre
Imagine que tous les magasins de ta ville passent par le même livreur pour s’approvisionner et qu’un matin, le livreur se trompe de dépôt, crève un pneu, et finit coincé dans un rond-point. Toute la ville est alors paralysée car :
les supermarchés n’ont plus de pâtes,
la pharmacie n’a plus de médicaments,
la boulangerie n’a plus de farine.
Cloudflare, c’est un peu ce livreur qui est au centre de la majorité des requêtes faites sur internet et lorsqu’il est en panne, une grande partie des requêtes ne peuvent plus être acheminées correctement.
Let’s dive in
Qu’est-ce que Cloudflare ?
Avant de parler de panne, il faut comprendre le rôle de Cloudflare dans une architecture web moderne. Lorsque tu dois servir une application aussi utilisée que Notion par exemple, tu ne peux pas directement diriger tes utilisateurs vers ton serveur, car cela poserait de nombreux problèmes de performance et de sécurité.
Cloudflare va justement te permettre d’agir comme une interface entre internet et ton serveur grâce à de nombreux services :
filtrage avec un Web Application Firewall et un service de bot management
caching pour ne pas renvoyer 1000 fois la même réponse
protection de ton adresse IP
CDN pour distribuer le contenu le plus proche de tes utilisateurs
C’est ultra performant…mais ça pose un problème : quand tu déploies une mauvaise config, tu la déploies partout. C’est là que la notion de blast radius (rayon d’impact) devient critique.
Qu’est-ce que le core proxy de Cloudflare ?
C’est le composant principal de Cloudflare, celui qui contient les applications permettant de faire toute la partie de filtrage pour protéger ton serveur des requêtes malveillantes, des robots, des attaques DDos, etc.
Mais ce composant est actuellement en plein chantier avec deux versions qui coexistent :
une ancienne version du Core Proxy (FL1) basée sur Nginx + Lua : robuste, facile à faire évoluer mais basée sur une énorme base de code et un langage devenu obsolète.
une nouvelle version (FL2) réécrite en Rust avec un proxy maison appelé Pingora : le Rust, c’est le chouchou de tous les développeurs qui doivent faire des applications performantes et robustes.
Les résultats sont là, la nouvelle version fonctionne aussi bien que la précédente mais en consommant beaucoup moins de CPU et de RAM. Néanmoins, la migration n’est pas encore finie et une partie des fonctionnalités passent encore par FL1.
C’est la dernière édition de 2025.
Des sujets à suggérer pour l’année prochaine ? Un feedback à faire ?
C’est par ici 👇
Qu’est-ce qu’il s’est passé le 18 novembre ?
Ce premier incident a eu lieu dans l’application de Bot Management qui permet d’éviter que des bots s’attaquent à ton application. Cette application est basée sur du machine learning pour déterminer si une requête provient d’un humain ou d’un robot.
Ce modèle utilise une liste de caractéristiques (navigateur, IP, etc.) qui est générée automatiquement et stockée dans une base analytique ClickHouse. Elle est récupérée à intervalle régulier avec une requête SQL qui ne précise pas la database (normal, il n’y en a qu’une seule à laquelle la requête peut accéder).
Mais le 18 novembre, l’équipe Data change la configuration des permissions de ClickHouse pour des raisons de sécurité, donnant accès maintenant à la base de caractéristiques et à une autre base contenant un réplicat. La requête SQL renvoie donc deux fois chaque caractéristique, faisant doubler de taille le fichier de configuration utilisé par le modèle.
Dans la version en Rust, un composant lit ce fichier et charge les caractéristiques dans un tableau de taille fixe (200, qui est codé en dur dans le code). Avec le changement, la requête renvoie maintenant plus de 200 résultats. Rust détecte qu’on essaie d’écrire hors du tableau et se met en mode panic, qui correspond en gros à :
Je préfère m’arrêter proprement plutôt que corrompre la mémoire.
Cela entraîne un crash du core proxy qui va redémarrer, puis relire le même fichier de configuration et crasher de nouveau : le début d’une crash loop.
Tous les sites déployés sur la nouvelle version du core proxy ont alors retourné des erreurs 500 et sont devenus inaccessibles, paralysant internet pendant environ 3 heures.
Et le 5 décembre alors ?
Vu qu’on ne change pas une équipe qui gagne, l’incident du 5 décembre a aussi été causé par un des composants du core proxy : le WAF ou Web Application Firewall, chargé de filtrer le trafic afin d’éviter des requêtes malveillantes, mais sur l’ancienne version FL1. Et l’ironie du sort, c’est que l’incident a été causé par une tentative d’améliorer la sécurité de ses clients.
En effet, le 3 décembre, une vulnérabilité critique a été rendue publique concernant React qui permettrait potentiellement de faire planter ou de compromettre des serveurs. Afin de sécuriser ses clients, Cloudflare doit analyser le corps des requêtes HTTP pour bloquer celles qui essaieraient d’exploiter cette vulnérabilité.
Mais il y a un problème : Cloudflare jusqu’à présent ne gardait en mémoire, le temps de l’analyse, que 128 kb, alors que les serveurs à risques acceptent des requêtes allant jusqu’à 1 MB. La décision est alors prise de passer donc à 1M cette mise en mémoire temporaire. Le déploiement est fait de manière progressive pour pouvoir réagir vite en cas de problème.
Mais ce changement n’est pas compatible avec un outil interne de test du WAF qui plante et se met à bloquer le déploiement du changement. L’équipe de sécurité est alors face à un choix : bloquer la mitigation de la faille React ou désactiver temporairement l’outil interne.
La faille étant critique, on décide de désactiver l’outil via une configuration globale. Et chez Cloudflare, une configuration globale c’est une configuration à déploiement instantané sur l’ensemble du réseau.
Et pour simplifier, il y avait un bug dans FL1 qui faisait que cette action de désactivation non pas d’une simple règle, mais d’une règle qui exécute un subset de règles, faisait planter le serveur. Ils ne le savaient pas car c’est la première fois qu’ils se sont retrouvés dans la situation de désactiver une telle règle.
Par chance, le problème a été identifié rapidement, ne touchait que les clients sur l’ancienne version du core proxy et a entraîné une indisponibilité de moins d’une demi-heure.
Et d’un point de vue Product ?
Mais du coup, à part comprendre ce qui s’est passé, qu’est-ce que ça nous apporte en tant que PM et quelles leçons on peut en tirer ? Heureusement, il y en a pas mal :
La dette technique ne peut être ignorée et peut avoir un impact financier. Certes, le passage de FL1 à FL2 coûte cher, prend du temps, mais il a permis de réécrire des composants critiques dans un langage bien plus robuste (le bug du 5 décembre n’aurait pas pu avoir lieu en Rust). En tant que PM, il faut aussi intégrer la réduction de risque comme de la valeur produit à part entière.
La config, c’est du code et parfois plus dangereux.
Dans les deux incidents, la cause, ce n’est pas du code mais le changement d’une configuration. Les process de review, de rollback des changements de configuration sont souvent bien plus light que pour le code. En tant que PM, tu peux challenger ton équipe sur les permissions, l’existence de process de review, de rollback.Une limite hard-codée peut devenir un incident.
Un tableau limité à 200 a réussi à arrêter la tech pendant 3h (le PM qui a écrit ou relu cette limite a dû passer une mauvaise nuit). Alors fais très attention la prochaine fois que tu dois définir ce genre de “magic numbers”. L’idée, ce n’est pas de tripler les limites, mais plutôt de définir avec tes développeurs : ce qu’il se passe si jamais on la dépasse, comment on est alerté, comment éviter qu’on la dépasse, etc. Dans le cas de Cloudflare, une simple règle de monitoring aurait permis de réduire le temps de l’incident.Sécurité vs fiabilité : à toi d’arbitrer consciemment. Le 5 décembre, Cloudflare a poussé une mitigation de sécurité très vite, en contournant certains garde-fous (outil interne désactivé via config globale). Et ce genre de décision, chaque PM a l’habitude de le vivre pour diverses raisons :
push d’un hotfix critique sans full QA
contournement de process pour livrer avant un événement marketing
activation d’une feature flag pour un gros client sans passage par tous les tests
L’important, ce n’est pas d’éviter tout risque, mais plutôt d’être conscient que tu joues à la roulette russe, si possible d’avoir un plan clair de rollback et surtout d’aligner tout le monde sur l’arbitrage.
Le dernier apprentissage, qui me permet d’écrire cet article, c’est l’intérêt d’écrire des post-mortem et de le faire avec transparence pour permettre à tout le monde d’apprendre de ses erreurs. Les incidents dans la tech sont inévitables, alors autant faire de chacun de ces incidents une opportunité d’apprentissage.
