Quand l’internet vacille : autopsie d’une panne Cloudflare

Introduction

Le 19 novembre 2025, une panne d’ampleur mondiale a frappé l’internet. En quelques minutes, des millions de sites sont devenus inaccessibles. L’incident, lié à Cloudflare, rappelle à quel point notre infrastructure numérique repose sur un nombre limité d’acteurs et de configurations critiques.

Un incident global en quelques minutes

La panne démarre vers 6 h (heure de la côte Est américaine). Des services majeurs affichent des erreurs, des plateformes comme X ou ChatGPT deviennent inaccessibles, et même les outils de surveillance rencontrent des difficultés. L’effet de cascade est immédiat, car Cloudflare joue un rôle central dans le DNS, la protection DDoS et la gestion du trafic.

Cause racine : un fichier trop volumineux

Selon les explications techniques, une modification de configuration a déclenché un bug latent dans un service de mitigation de bots. Le fichier de règles généré automatiquement a dépassé une taille attendue, provoquant un crash. La protection censée filtrer les menaces a fini par perturber l’ensemble du réseau.

Leçons d’architecture pour éviter l’effet domino

Les pannes de ce type ne sont pas exceptionnelles : elles illustrent une forte centralisation. Pour limiter les dégâts, il faut concevoir des systèmes résilients, testables et capables de dégrader leurs services de manière contrôlée.

Bonnes pratiques opérationnelles

La prévention passe par des garde-fous simples : limites de taille, tests d’intégration sur des règles générées, et possibilité de revenir en arrière en quelques minutes. Voici des exemples de pratiques et d’automatisations utiles.

// Vérifier la taille d'un fichier de config avant déploiement
import fs from "fs";

const MAX_BYTES = 5 * 1024 * 1024;
const path = "./generated-rules.json";

const size = fs.statSync(path).size;
if (size > MAX_BYTES) {
    throw new Error("Configuration trop volumineuse, déploiement bloqué.");
}

// Dégrader un service en cas d'erreurs répétés
let failures = 0;
const MAX_FAILURES = 5;

async function fetchWithFallback(url) {
    try {
        const res = await fetch(url);
        failures = 0;
        return res;
    } catch (err) {
        failures += 1;
        if (failures >= MAX_FAILURES) {
            return fetch("/cache/offline.json");
        }
        throw err;
    }
}

// Exemple de "circuit breaker" minimal
let state = "closed";
let openedAt = 0;
const COOLDOWN_MS = 30000;

export async function guardedCall(fn) {
    if (state === "open" && Date.now() - openedAt < COOLDOWN_MS) {
        throw new Error("Service temporairement coupé");
    }
    try {
        const result = await fn();
        state = "closed";
        return result;
    } catch (err) {
        state = "open";
        openedAt = Date.now();
        throw err;
    }
}

// Logging structuré pour faciliter l'analyse d'incidents
function logIncident(event, meta = {}) {
    console.log(JSON.stringify({
        event,
        severity: "high",
        timestamp: new Date().toISOString(),
        ...meta
    }));
}

Conclusion

Cette panne rappelle une réalité simple : notre internet est centralisé. Une seule configuration erronée suffit à perturber une grande partie du web. La meilleure réponse reste une architecture résiliente, testée à grande échelle, et pensée pour la dégradation contrôlée plutôt que l’indisponibilité totale.