Le 18 novembre 2025, une erreur dans un fichier de configuration du système Bot Management a provoqué la pire panne de Cloudflare depuis 2019. Analyse technique de l’incident et leçons à retenir.
Contenu :
📅 Chronologie officielle
11:05 UTC – Modification des permissions ClickHouse
Cloudflare change les permissions d’accès à sa base de données ClickHouse pour améliorer la sécurité.
11:10 UTC – Début de la panne
Les serveurs Cloudflare commencent à renvoyer des erreurs HTTP 500. Les sites utilisant Cloudflare deviennent inaccessibles.
11:15 UTC – Détection de l’incident
Les systèmes de monitoring alertent les équipes. Le diagnostic initial suspecte une attaque DDoS en raison des fluctuations intermittentes.
11:30 UTC – Escalade majeure
Activation du protocole de crise. Toutes les équipes techniques mobilisées.
11:45 UTC – Isolation de la cause
Identification du système Bot Management comme source du problème.
12:20 UTC – Déploiement du correctif
Désactivation temporaire du Bot Management et déploiement d’un fichier de configuration corrigé.
14:00 UTC – Rétablissement complet
Tous les services Cloudflare fonctionnent normalement. Début de l’analyse post-mortem.
🔍 Analyse technique détaillée
Comment fonctionne le Bot Management de Cloudflare ?
Le système de détection de bots de Cloudflare repose sur deux composants principaux :
- Un fichier de configuration (« feature file »)
- Un modèle de machine learning qui lit ce fichier
- Régénération automatique toutes les 5 minutes
Ce qui s’est passé :
1. Changement de permissions (11:05)
Cloudflare a modifié les permissions d’accès à sa base de données ClickHouse pour améliorer la sécurité.
2. Requête SQL problématique
-- Cette requête génère le fichier de configuration
SELECT name, type
FROM system.columns
WHERE table = 'http_requests_features'
ORDER BY name;
Problème : La requête ne filtrait pas par nom de base de données.
Avant le changement :
- Résultat : ~60 features (colonnes de la table « default »)
- Taille fichier : normale
Après le changement :
- Résultat : ~200+ features (colonnes « default » + « r0 » dupliquées)
- Taille fichier : DOUBLÉE ❌
3. Dépassement de limite mémoire
Le code Rust du système Bot Management avait une limite hardcodée :
const MAX_FEATURE_FILE_SIZE: usize = 1024 * 100; // 100 KB max
if feature_file.len() > MAX_FEATURE_FILE_SIZE {
panic!("Feature file too large!"); // ❌ CRASH
}
Conséquence :
Chaque worker Cloudflare qui chargeait le nouveau fichier de configuration crashait instantanément avec un panic!() en Rust.
4. Effet domino mondial
- Zone 1 (11:10) : Les workers reçoivent le nouveau fichier → crash
- Zone 2 (11:15) : Régénération automatique → nouveau fichier → crash
- Zone 3 (11:20) : Idem → effet domino mondial
- Résultat : 12% du web mondial inaccessible (sites utilisant Cloudflare)
🛠️ La correction appliquée
Solution immédiate (11:45) :
- Désactivation du Bot Management via kill switch d’urgence
- Correction de la requête SQL :
-- Requête corrigée avec filtre base de données
SELECT name, type
FROM system.columns
WHERE database = 'default' -- ✅ AJOUT DU FILTRE
AND table = 'http_requests_features'
ORDER BY name;
- Augmentation de la limite mémoire dans le code Rust
- Remplacement du panic!() par gestion d’erreur gracieuse
Solution long terme :
- ✅ Tests automatisés sur la taille des fichiers de configuration
- ✅ Alertes si fichier > seuil normal
- ✅ Rollback automatique en cas d’anomalie détectée
- ✅ Kill switch plus granulaire par zone géographique
📊 Impact de la panne
Sites et services affectés :
- 12% du web mondial utilise Cloudflare
- Sites majeurs impactés : Discord, Shopify, Coinbase, GitLab, Canva
- 3 heures d’indisponibilité totale ou partielle
- Pertes estimées : plusieurs millions de dollars en CA perdu pour les e-commerces
Statistiques Cloudflare :
- 280+ millions de requêtes HTTP/seconde en temps normal
- 25+ millions de sites et applications protégés
- 100+ pays desservis par le réseau CDN
💡 Leçons à retenir
1. Toujours valider les données entrantes
Même si elles viennent de votre propre base de données. Cloudflare supposait que le fichier serait toujours < 100 KB.
2. Les systèmes distribués sont complexes
Les fluctuations (OK → KO → OK) ont fait croire à une attaque DDoS. Difficile de diagnostiquer en temps réel.
3. Importance de la gestion d’erreurs
Un simple panic!() en Rust a mis KO tout le réseau. Toujours gérer les erreurs gracieusement.
4. La transparence compte
Cloudflare a publié un post-mortem ultra-détaillé 24h après. Exemple à suivre.
5. Même les géants se trompent
Si Cloudflare (infrastructure mondiale, équipe de centaines d’ingénieurs) peut avoir une panne, tout le monde peut. Importance de l’humilité et de la préparation.
📚 Points techniques à retenir
Concept : ClickHouse
Base de données orientée colonnes pour analytics temps réel
Concept : Feature file
Fichier config listant les caractéristiques analysées par l’IA
Concept : Panic (Rust)
Arrêt brutal du programme en cas d’erreur non gérée
Concept : Distributed table
Table qui agrège données de plusieurs shards ClickHouse
Concept : Kill switch
Bouton d’urgence pour désactiver une feature instantanément
Pourquoi c’est important :
Cet incident est une leçon d’humilité : même une entreprise comme Cloudflare peut connaître une panne majeure à cause d’une erreur apparemment mineure. En tant qu’étudiant en BTS SIO, cela me rappelle l’importance de la validation des données, de la gestion d’erreurs robuste, et des tests rigoureux. La transparence de Cloudflare avec leur post-mortem détaillé est aussi un excellent exemple de communication de crise.
Application pratique :
Dans mes projets, je vais désormais systématiquement : 1) Valider toutes les données d’entrée même internes, 2) Gérer les erreurs avec try/catch plutôt que laisser crasher, 3) Tester les cas limites (fichiers trop gros, valeurs inattendues), 4) Documenter mes hypothèses sur les données (ex: « ce fichier fera toujours X lignes »).
Comments are closed