Comment une mise à jour de la base de données peut paralyser 20 % de l'Internet mondial

11 novembre 18, alerte de panne : lorsque Cloudflare tombe en panne, qui paie pour l’infrastructure ?

À 6h20, heure de l’Est américain, environ 20 % du trafic Internet mondial s’est soudainement arrêté. Une modification de permission de base de données de routine a déclenché une réaction en chaîne, provoquant une panne massive des services essentiels au fonctionnement du web moderne.

Ce n’est pas une attaque de hackers, ni une menace extérieure. La cause du problème est simplement qu’un fichier de configuration, après avoir doublé de volume, a dépassé la limite prédéfinie du système.

Le début d’un désastre à partir d’une simple requête en base de données

Le calendrier de l’incident est clair et brutal :

UTC 11:05 — Cloudflare met à jour les permissions du cluster de bases de données ClickHouse, pour renforcer sécurité et fiabilité.

UTC 11:28 — La modification s’étend à l’environnement utilisateur, avec pour la première fois des erreurs enregistrées.

UTC 11:48 — La page d’état officielle reconnaît la panne.

UTC 17:06 — Le service est complètement restauré, après plus de 5 heures d’indisponibilité.

La vérité technique

Le problème central réside dans une erreur apparemment simple : une requête en base de données responsable de générer le fichier de configuration de la protection contre les robots de Cloudflare ne comporte pas de filtre par « nom de la base ».

Cela a entraîné le retour d’entrées en double — une provenant de la base par défaut, l’autre du stockage sous-jacent r0. La taille du fichier de configuration a ainsi doublé, passant d’environ 60 caractéristiques à plus de 200.

Cloudflare avait fixé une limite codée en dur de 200 caractéristiques pour la mémoire pré-allouée, les ingénieurs pensant « que c’était bien supérieur à notre utilisation réelle ». Jusqu’à ce que l’incident survienne, cette marge de sécurité semblait suffisante, mais elle a instantanément cédé.

Le fichier dépassant la limite a déclenché une erreur dans le code Rust : “thread fl2_worker_thread panicked: called Result::unwrap() on an Err value”

Le système de protection contre les robots est au cœur de la couche de contrôle du réseau Cloudflare. Lorsqu’il tombe en panne, le système de vérification de la santé — qui indique « quels serveurs fonctionnent normalement » aux équilibrages de charge — échoue également.

Ce qui est particulièrement ironique, c’est que ce fichier de configuration est régénéré toutes les 5 minutes. Dès qu’une requête s’exécute sur un nœud du cluster après la mise à jour, elle génère des données erronées. Résultat : le réseau Cloudflare oscille entre « normal » et « panne » — parfois il charge le bon fichier, parfois le mauvais.

Ce cycle de « panne répétée » a conduit les ingénieurs à croire qu’ils étaient victimes d’une attaque DDoS massive. Car une erreur interne ne provoque généralement pas ce cycle de récupération et de crash périodique.

Finalement, après la mise à jour de tous les nœuds ClickHouse, chaque fichier généré est erroné. Sans signal précis du système, la protection entre en « mode prudent » par défaut, considérant la majorité des serveurs comme « non sains ». Le trafic Internet afflue vers les nœuds Edge de Cloudflare, mais ne peut pas être routé correctement.

Le silence sur le réseau mondial

Plateforme Web2 totalement paralysée

• X a reçu 9 706 rapports de panne
• ChatGPT a cessé de répondre en cours de conversation
• Spotify en streaming interrompu
• Uber et autres plateformes de livraison en dysfonctionnement
• Les joueurs ont été déconnectés brutalement
• Même les bornes de commande automatique de McDonald’s affichent des erreurs

Aucun secteur n’est épargné dans la cryptosphère

Les interfaces web des principales exchanges ont crashé, empêchant les utilisateurs de se connecter ou de trader.

Les explorateurs de blockchain (comme Etherscan, Arbiscan) sont tombés en panne.

Les plateformes d’analyse de données (DeFiLlama) rencontrent des erreurs intermittentes.

Les fournisseurs de portefeuilles hardware ont publié des annonces signalant une baisse de disponibilité des services.

La seule « exception » : le protocole blockchain lui-même

Selon les rapports, aucune panne côté front-end des principales exchanges, et les transactions sur la chaîne se poursuivent normalement. La blockchain reste totalement opérationnelle, sans signe de rupture de consensus.

Ce qui soulève une question cruciale : si la blockchain continue de produire des blocs, mais que personne ne peut y accéder, la cryptomonnaie est-elle toujours « en ligne » ?

Le rôle de Cloudflare dans le trafic Internet mondial

Cloudflare ne héberge pas de sites web ni de serveurs cloud. Son rôle est celui d’un « intermédiaire » — entre l’utilisateur et le réseau.

Données clés :

• Service pour 24 millions de sites
• Présence dans 120 pays, 330 villes via ses nœuds Edge
• Gère environ 20 % du trafic Internet mondial
• Part de marché dans la protection DDoS : 82 %
• Bande passante totale des nœuds Edge : 449 Tbps

Lorsqu’un « intermédiaire » comme Cloudflare échoue, tous les services qui en dépendent deviennent « inaccessibles » simultanément.

Le CEO de Cloudflare, Matthew Prince, a déclaré dans un communiqué officiel : « C’est la panne la plus grave depuis 2019… En plus de 6 ans, nous n’avons jamais connu une panne empêchant la majorité du trafic Internet essentiel de passer par notre réseau. »

Quatre incidents majeurs en 18 mois : pourquoi l’industrie n’a-t-elle pas changé ?

Juillet 2024 — Une vulnérabilité de mise à jour de sécurité de CrowdStrike paralyse les systèmes IT mondiaux (vols de vols, retards hospitaliers, gel des services financiers)

20 octobre 2025 — La panne d’AWS dure 15 heures, le service DynamoDB dans l’est des États-Unis est interrompu, provoquant la déconnexion de plusieurs réseaux blockchain

29 octobre 2025 — Problème de synchronisation des configurations chez Microsoft Azure, panne de Microsoft 365 et Xbox Live

18 novembre 2025 — Panne de Cloudflare, impactant environ 20 % du trafic Internet mondial

Le risque du modèle de sous-traitance unique

AWS contrôle environ 30 % du marché mondial de l’infrastructure cloud, Microsoft Azure 20 %, Google Cloud 13 %. Ces trois géants détiennent plus de 60 % de l’infrastructure supportant le web moderne.

L’industrie crypto aurait dû être une « solution décentralisée », mais elle dépend aujourd’hui de ces fournisseurs d’infrastructure hyper-centralisés.

En cas de panne, la seule « stratégie de reprise » consiste à attendre : attendre que Cloudflare répare, que AWS récupère, que Azure déploie des correctifs.

La fausse décentralisation : la décentralisation au niveau protocole ne signifie pas décentralisation d’accès

L’industrie crypto a toujours présenté la vision suivante :

Finance décentralisée, monnaies résistantes à la censure, systèmes sans confiance, absence de point unique de défaillance, code comme loi

Mais la réalité du 18 novembre est : une panne matinale a mis à l’arrêt la majorité des services crypto pendant plusieurs heures.

Sur le plan technique : aucune faille n’a été signalée dans les protocoles blockchain.

Dans la pratique : interfaces de transaction en panne, navigateurs bloqués, plateformes de données indisponibles, erreurs 500 à l’écran.

Les utilisateurs ne peuvent pas accéder à la « décentralisation » qu’ils croyaient posséder sur la blockchain. Le protocole fonctionne normalement — à condition de pouvoir « y accéder ».

Pourquoi l’industrie privilégie-t-elle encore la « commodité » plutôt que la « principes » ?

Construire une infrastructure décentralisée en interne implique : acheter du matériel coûteux, assurer une alimentation stable, maintenir une bande passante dédiée, embaucher des experts en sécurité, réaliser une redondance géographique, construire des systèmes de sauvegarde, surveiller 24/7.

Utiliser Cloudflare, c’est simplement : cliquer sur un bouton, entrer ses infos de carte bancaire, déployer en quelques minutes.

Les startups veulent « aller vite », les investisseurs exigent « l’efficacité du capital » — tout le monde privilégie la « commodité » plutôt que la « résilience ».

Jusqu’au jour où la « commodité » ne sera plus si commode.

Pourquoi les alternatives décentralisées « ne décollent » pas ?

Les solutions décentralisées de stockage (Arweave), de transfert de fichiers (IPFS), de calcul (Akash), d’hébergement (Filecoin) existent bel et bien.

Mais elles rencontrent des problèmes tels que :

• performance inférieure aux solutions centralisées, la latence étant perceptible par l’utilisateur
• adoption très faible, processus d’utilisation complexe
• coûts souvent supérieurs à la location d’infrastructures chez les trois grands fournisseurs cloud

Construire une véritable infrastructure décentralisée est extrêmement difficile, bien au-delà de ce qu’on imagine.

La majorité des projets ne font que brandir la « décentralisation » en slogan, sans jamais la concrétiser. Opter pour une solution centralisée reste plus simple, moins coûteux — jusqu’au prochain incident.

Les nouvelles problématiques réglementaires

Trois incidents majeurs en 30 jours ont déjà suscité une forte attention réglementaire :

• Ces entreprises sont-elles « d’importance systémique » ?
• Les services de backbone réseau doivent-ils être régulés comme des « services publics » ?
• Quelles risques posent la combinaison « trop gros pour faire faillite » + infrastructure critique ?
• Cloudflare, qui contrôle 20 % du trafic Internet mondial, constitue-t-il un monopole ?

Le ministère américain des Finances pousse à intégrer l’identité dans les smart contracts, en exigeant que chaque interaction DeFi passe par une vérification KYC. Lors de la prochaine panne d’infrastructure, ce que l’utilisateur perdra ne sera pas seulement la capacité de trader — mais aussi la capacité de prouver son identité dans le système financier.

Une panne de 3 heures pourrait devenir une « incapacité à passer la vérification humaine » pendant 3 heures — simplement parce que le service de vérification fonctionne sur une infrastructure en panne.

De la « commodité » à l’« inévitable » : quand sera le tournant ?

Le 18 novembre, l’industrie crypto n’a pas « échoué » — la blockchain elle-même fonctionne parfaitement.

Ce qui a « échoué », c’est la déception collective de l’industrie :

• croire qu’on peut bâtir des « applications invulnérables » sur une « infrastructure susceptible de s’effondrer »
• penser qu’en contrôlant « les accès » via trois géants, l’« anti-censure » a un sens réel
• croire qu’un simple fichier de configuration de Cloudflare peut décider si des millions de personnes peuvent trader ou non, c’est encore « décentralisé »

L’aptitude d’une infrastructure à résister aux pannes ne doit pas être un « bonus » optionnel, mais la « base fondamentale » — sans elle, tout le reste n’a pas de sens.

Une nouvelle panne se prépare — peut-être chez AWS, peut-être chez Azure, peut-être chez Google Cloud, ou encore une seconde panne chez Cloudflare. Peut-être le mois prochain, ou la semaine prochaine.

Opter pour une solution centralisée reste plus économique, plus rapide, plus simple — jusqu’au jour où ce ne sera plus le cas.

Lorsque la prochaine configuration de Cloudflare déclenchera une faille cachée dans un service critique, nous reverrons le même scénario : erreurs 500 en cascade, interruptions de trading, blockchain fonctionnant sans que personne ne puisse y accéder, promesses d’« améliorer la résilience » qui ne seront jamais tenues.

C’est cela, la crise actuelle du secteur : rien ne change, car « la commodité » triomphe toujours de « la gestion des risques » — jusqu’au jour où le prix de cette « commodité » devient si élevé qu’on ne peut plus l’ignorer.