Panne de Cloudflare : dévoiler le faux vernis de décentralisation de l'industrie crypto

4 pannes majeures en 18 mois, pourquoi le dilemme de la centralisation reste-t-il insoluble ?

Source : rekt news

Traduction : Saoirse, Foresight News

Le 18 novembre 2025, à 6h20, heure de l'Est des États-Unis. Beaucoup d'entre nous ont subi une interruption du réseau.

Il ne s'agissait pas d'une interruption progressive, ni d'un quelconque signal d'alerte. Une seconde auparavant, vous faisiez défiler votre téléphone, passiez des transactions, discutiez avec une intelligence artificielle, et la seconde d'après, partout où vous regardiez, il n'y avait presque que des pages d'erreur 500.

Twitter s'est soudainement figé en plein tweet, ChatGPT a cessé de répondre au milieu d'une conversation, et Claude s'est tout simplement bloqué.

Même Downdetector — ce site où vous vérifiez les pannes lorsque toutes les plateformes sont en panne — ne pouvait pas se charger, incapable de vous dire que « tous les services sont hors service ».

20 % du réseau mondial ont ainsi disparu comme par magie, simplement parce que Cloudflare, censé protéger Internet contre les attaques, s'est accidentellement « attaqué » lui-même.

Un simple changement de configuration (mise à jour des droits de la base de données) a déclenché une faille cachée dans son système de protection contre les bots, et en un instant, ce « gardien » a rejeté tout le monde à la porte.

En octobre, lorsque Amazon Web Services (AWS) a provoqué la mise hors ligne de Coinbase, les utilisateurs crypto sur Twitter se moquaient encore des inconvénients de la « centralisation ».

Mais lors de la panne de Cloudflare en novembre ? Du moins pendant les premières heures, tout l'écosystème crypto est resté silencieux.

Après tout, lorsque l'infrastructure sur laquelle repose Twitter est elle-même en panne, il est impossible de discuter sur Twitter de la « fragilité de l'infrastructure ».

De nombreux services clés se sont retrouvés à l'arrêt (systèmes de transport paralysés), certaines interfaces d'entreprise étaient défaillantes, et des explorateurs blockchain comme Arbiscan ou DeFiLlama affichaient à leur tour des erreurs 500 — mais la blockchain elle-même ne montrait aucun signe d'interruption du consensus.

Quand la révolution « décentralisée » que vous prônez ne peut fonctionner à cause d'un simple fichier de configuration trop volumineux d'une entreprise, qui détient vraiment le contrôle ?

Chronologie de la panne : du « changement de configuration » à la « paralysie du réseau »

Heure UTC 11:05 : le changement de contrôle d'accès à la base de données est déployé.

23 minutes plus tard, à 11:28 UTC, le changement s'étend à l'environnement utilisateur, et des erreurs apparaissent pour la première fois dans le trafic HTTP des utilisateurs.

En d'autres termes : la panne s'est déjà produite, mais personne ne savait encore où était le problème.

À 11:48 UTC, la page de statut officielle de Cloudflare admet enfin « une panne de service interne » — ce qui, en langage d'entreprise, signifie : « tout est sens dessus dessous, et tout le monde peut le voir ».

La réaction en chaîne a été soudaine : ce changement a détruit la couche de gestion des bots de Cloudflare, et lorsque le système a chargé un fichier de fonctionnalités dont la taille avait doublé, son service proxy s'est tout simplement « effondré ».

Les systèmes en aval se sont effondrés à leur tour : Workers KV (service de stockage clé-valeur) et Access (service de contrôle d'accès) ne pouvaient plus se connecter au proxy ; le taux d'erreur sur tout le réseau a explosé, la charge sur les outils de surveillance a augmenté, et l'utilisation du CPU a atteint des sommets.

Le trafic continuait d'affluer vers les nœuds périphériques de Cloudflare — mais le service proxy ne pouvait plus répondre à aucune requête.

Cloudflare a d'abord cru être victime d'une attaque, et pas n'importe laquelle : une attaque DDoS (déni de service distribué) à très grande échelle.

Plus étrange encore, même la page de statut officielle, entièrement hébergée en dehors de l'infrastructure Cloudflare, s'est retrouvée paralysée, poussant les ingénieurs à soupçonner une attaque coordonnée contre leur système central et leur système de surveillance.

Mais ce n'était pas le cas. Ils n'ont pas subi d'attaque externe, le problème venait de chez eux.

Peu après le rétablissement du service, le CTO de Cloudflare, Dane Knecht, a publié une déclaration d'excuses publiques, qualifiant l'incident d'« absolument inacceptable » et attribuant la panne à un simple changement de configuration — c'est ce changement qui a provoqué l'effondrement de la couche de protection contre les bots.

« Nous avons déçu nos clients, ainsi que la communauté Internet au sens large », écrit Knecht dans sa déclaration, « un service sous-jacent à notre protection contre les bots comportait une faille latente, qui s'est effondrée après un changement de configuration de routine, entraînant une panne massive de notre réseau et d'autres services. Ce n'était pas une attaque externe. »

Au pic de la panne, la plateforme Downdetector a reçu jusqu'à 11 183 signalements d'incidents.

Ce « blackout numérique » a duré plus de 5 heures et demie, jusqu'à 17:06 UTC, moment où le service a été entièrement rétabli ; cependant, dès 14:30, le déploiement mondial du bon fichier de gestion des bots avait déjà atténué les effets les plus graves.

Impact de la panne : du Web2 à la crypto, personne n'est épargné

Les plateformes Web2 en première ligne

La plateforme X a reçu 9 706 signalements de panne.

Les utilisateurs ne voyaient plus leur fil d'actualité habituel, mais un message d'erreur « Oups, quelque chose s'est mal passé ».

ChatGPT est soudainement devenu « silencieux » au milieu d'une conversation, ne répondant plus à aucune commande.

Le service de streaming Spotify a été interrompu, la plateforme de design Canva a refusé l'accès aux designers, Uber et Door Dash (plateforme de livraison) ont également connu des dysfonctionnements.

Même les joueurs n'ont pas été épargnés : les joueurs de League of Legends ont été déconnectés en pleine partie.

On rapporte même que les bornes de commande automatique de McDonald's affichaient un écran d'erreur — en plein rush du déjeuner, coïncidant avec la panne d'infrastructure.

Le secteur des crypto-monnaies n'a pas été épargné non plus.

Arrêt massif des plateformes crypto

Le front-end de Coinbase s'est complètement effondré, les utilisateurs ne voyaient qu'une page de connexion impossible à charger.

Les versions web et mobile de Kraken sont toutes deux « tombées » — conséquence directe de la panne mondiale de Cloudflare.

BitMEX a publié une annonce sur sa page de statut : « Enquête en cours sur la cause de la panne, performance de la plateforme dégradée, mais les fonds des utilisateurs sont en sécurité. » — même scénario, juste une autre plateforme d'échange.

Etherscan ne pouvait pas se charger, Arbiscan était complètement hors service.

Le tableau d'analyse de données de DeFiLlama affichait par intermittence des erreurs internes du serveur.

Même Ledger a publié une annonce indiquant qu'en raison de la panne de Cloudflare, la disponibilité de certains services était réduite.

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

Mais les systèmes suivants n'ont pas été affectés :

Selon les rapports, Binance, OKX, Bybit, Crypto.com, KuCoin et d'autres grandes plateformes d'échange n'ont pas connu de panne front-end, les transactions on-chain se sont déroulées normalement — pendant ce temps, la blockchain elle-même fonctionnait parfaitement, sans aucun signe d'interruption du consensus.

Les protocoles blockchain fonctionnent toujours de manière indépendante — le problème ne vient pas de la chaîne, mais de l'infrastructure Web2 utilisée pour y accéder.

Si la blockchain fonctionne toujours, mais que personne ne peut y accéder, la crypto-monnaie est-elle vraiment « en ligne » ?

Analyse approfondie : comment une requête de base de données a-t-elle pu paralyser 20 % du réseau ?

Cloudflare n'héberge pas de sites web, et ne fournit pas de serveurs cloud comme AWS.

Son rôle est celui d'un « intermédiaire » — entre l'utilisateur et Internet, il sert 24 millions de sites web, traite 20 % du trafic mondial via des nœuds répartis dans 120 pays et 330 villes.

Le discours marketing de Cloudflare est le suivant : il se positionne comme le « bouclier et l'accélérateur d'Internet », offrant une protection DDoS 24/7, une protection contre les bots, le routage du trafic, un pare-feu d'applications Web mondial (WAF), la terminaison TLS, le calcul en périphérie basé sur Workers et des services DNS — toutes ces fonctions opérant sur un réseau unifié « sécurité - performance ».

En réalité : il détient 82 % de part de marché dans la protection DDoS, une bande passante totale de 449 Tbps sur ses nœuds périphériques, et est connecté à de nombreux fournisseurs de services Internet (ISP) et de cloud majeurs dans le monde.

Le cœur du problème : lorsque l'intermédiaire échoue, tous les services derrière deviennent simultanément « inaccessibles ».

Le CTO de Cloudflare, Dane Knecht, l'a dit sans détour sur la plateforme X :

« Je vais être franc : plus tôt aujourd'hui, en raison d'un problème sur le réseau Cloudflare, une grande partie du trafic qui dépend de nous a été affectée, nous avons déçu nos clients et la communauté Internet au sens large. »

Le PDG Matthew Prince a été encore plus direct :

« Aujourd'hui, c'est la pire panne de Cloudflare depuis 2019... En plus de 6 ans, nous n'avions jamais eu de panne empêchant la majorité du trafic principal de transiter par notre réseau. »

La racine technique de la panne

Tout a commencé par une simple mise à jour des droits de la base de données. À 11:05 UTC, Cloudflare a modifié son cluster de bases de données ClickHouse pour améliorer la sécurité et la fiabilité — permettant aux utilisateurs qui avaient auparavant des « droits d'accès implicites » de voir « explicitement » les métadonnées des tables.

Où est le problème ? La requête de base de données générant le fichier de configuration du service de protection contre les bots de Cloudflare n'a pas filtré le « nom de la base de données ».

La requête gérant le trafic malveillant a commencé à renvoyer des entrées dupliquées — une dupliquée de la base de données par défaut, une autre de la base de stockage r0 sous-jacente. Cela a doublé la taille du fichier de fonctionnalités, passant d'environ 60 à plus de 200 caractéristiques.

Cloudflare avait fixé une limite codée en dur de 200 caractéristiques pour la pré-allocation mémoire, pensant que « c'était bien au-dessus de notre utilisation réelle d'environ 60 caractéristiques ». C'est typique de l'ingénierie : on fixe une marge de sécurité « suffisamment large », jusqu'à ce qu'un imprévu survienne.

Le fichier surdimensionné a déclenché cette limite, le code Rust s'est effondré, affichant l'erreur : « thread fl2_worker_thread panicked: called Result::unwrap () on an Err value » (le thread fl2_worker_thread a planté : appel de Result::unwrap () sur une valeur Err).

Le système de protection contre les bots est un composant central de la couche de contrôle de Cloudflare. Une fois effondré, le système de vérification de l'état de santé, qui indique au load balancer « quels serveurs fonctionnent normalement », est également « hors service ».

Pire encore : ce fichier de configuration est régénéré toutes les 5 minutes.

Ce n'est que lorsque la requête s'exécutait sur un « nœud de cluster mis à jour » qu'elle générait des données erronées. Ainsi, toutes les 5 minutes, le réseau Cloudflare alternait entre « normal » et « en panne » — parfois le bon fichier était chargé, parfois le mauvais.

Cette « oscillation » a fait croire aux ingénieurs qu'ils subissaient une attaque DDoS — une erreur interne ne provoque généralement pas de cycles « panne/rétablissement ».

Finalement, tous les nœuds ClickHouse ont été mis à jour, et chaque fichier généré était erroné. L'oscillation a cessé, remplacée par une « panne totale et stable ».

Sans signal système précis, le système passe en « mode conservateur » par défaut, considérant la plupart des serveurs comme « non sains ». Le trafic continue d'affluer, mais ne peut pas être routé correctement.

Les nœuds périphériques de Cloudflare pouvaient recevoir les requêtes des utilisateurs — mais ne pouvaient rien en faire.

« Ce n'était pas une attaque externe », insiste Knecht, « il n'y a pas eu de comportement malveillant, ni d'attaque DDoS. C'est juste une requête de base de données qui a omis un filtre, coïncidant avec la mise à jour des droits, ce qui a finalement provoqué la panne. »

Cloudflare avait promis « 99,99 % de disponibilité » — mais cette fois, la promesse n'a pas été tenue.

C'est bel et bien le cas.

Histoire qui se répète : 4 pannes majeures en 18 mois, pourquoi le dilemme de la centralisation reste-t-il insoluble ?

20 octobre 2025 — panne AWS de 15 heures. Échec de la résolution DNS de la base de données DynamoDB dans la région US East 1, entraînant le gel de Coinbase, des ralentissements sur Robinhood, l'interruption du service Infura (affectant MetaMask), et la mise hors ligne de Base, Polygon, Optimism, Arbitrum, Linea, Scroll et d'autres réseaux blockchain. Bien que les fonds des utilisateurs soient en sécurité sur la chaîne, beaucoup voyaient leur solde affiché à « zéro ».

29 octobre 2025 — panne Microsoft Azure. Problème de synchronisation de configuration sur Azure Front Door, entraînant la mise hors ligne de la suite Microsoft 365, la panne de Xbox Live et l'interruption des services d'entreprise.

Juillet 2024 — le package de mise à jour Windows de CrowdStrike (entreprise de sécurité) comportait une faille. Cette panne a entraîné l'immobilisation des vols, des retards dans les soins hospitaliers, le gel des services financiers, et la restauration complète a pris plusieurs jours.

Juin 2022 — précédente panne majeure de Cloudflare. Plusieurs plateformes d'échange crypto ont dû suspendre leurs services — même schéma, juste une autre année.

Juillet 2019 — panne antérieure de Cloudflare. Coinbase hors ligne, CoinMarketCap inaccessible — c'était le premier « signal d'alarme » ignoré par tous.

En seulement 18 mois, 4 pannes majeures d'infrastructure se sont produites.

Quatre pannes, une même leçon : une infrastructure centralisée conduit inévitablement à des « pannes centralisées ».

Quatre pannes auraient pu accélérer la transition du secteur crypto vers la décentralisation — mais il dépend toujours de l'infrastructure de trois entreprises.

Combien d'avertissements faudra-t-il pour que l'industrie passe de « supposer que la panne peut arriver » à « construire les systèmes en partant du principe que la panne arrivera » ?

Le « mensonge » de la décentralisation : décentralisation du protocole ≠ décentralisation de l'accès

On vous a déjà brossé ce tableau :

« Finance décentralisée, monnaie résistante à la censure, systèmes sans confiance, pas de point de défaillance unique, « pas vos clés privées, pas vos coins », le code fait loi. »

Mais la réalité du 18 novembre a été un choc : une panne de Cloudflare un matin a suffi à paralyser certains services crypto pendant des heures.

La vérité technique :

Aucun protocole blockchain n'a été signalé comme défaillant. Le réseau Bitcoin fonctionnait normalement, le réseau Ethereum aussi — la chaîne elle-même n'avait aucun problème.

La réalité de l'usage :

Interfaces d'échange effondrées, explorateurs blockchain paralysés, interfaces de portefeuille hors service, plateformes d'analyse de données en panne, interfaces de trading affichant des erreurs 500.

Les utilisateurs ne pouvaient pas accéder à la blockchain « décentralisée » qu'ils étaient censés « posséder ». Le protocole fonctionnait — à condition d'y « accéder ».

Ces propos heurteront peut-être certains…

David Schwed, COO de SovereignAI, n'a pas mâché ses mots :

« Aujourd'hui une panne Cloudflare, il y a quelques semaines une panne AWS, cela montre clairement : on ne peut pas simplement externaliser la « résilience » de l'infrastructure à un seul fournisseur. Si votre organisation doit fonctionner 24h/24, vous devez construire votre infrastructure en partant du principe que la panne arrivera. Si votre plan de continuité se limite à « attendre que le fournisseur rétablisse le service », c'est pure négligence. »

« Pure négligence » — pas un accident, pas un oubli, mais de la négligence.

Le commentaire de Jameson Lopp est sans appel :

« Nous avons une technologie décentralisée remarquable, mais en concentrant la plupart des services chez quelques fournisseurs, nous la rendons extrêmement fragile. »

Ce que Ben Schiller a dit lors de la dernière panne AWS reste valable :

« Si votre blockchain tombe à cause d'une panne AWS, elle n'est pas vraiment décentralisée. »

Remplacez « AWS » par « Cloudflare », le problème est identique — l'industrie n'a jamais tiré les leçons.

Pourquoi choisir la « commodité » plutôt que les « principes » ?

Construire sa propre infrastructure signifie : acheter du matériel coûteux, garantir une alimentation stable, maintenir une bande passante dédiée, embaucher des experts en sécurité, assurer la redondance géographique, mettre en place des systèmes de secours, surveiller 24h/24 — chaque point demande d'importantes ressources.

Utiliser Cloudflare, c'est juste : cliquer sur un bouton, saisir une carte bancaire, déployer en quelques minutes.

La protection DDoS est assurée par d'autres, la disponibilité aussi, la montée en charge également.

Les startups veulent « aller vite sur le marché », les VC exigent « l'efficacité du capital » — tout le monde choisit la « commodité », pas la « résilience ».

Jusqu'à ce que la « commodité » ne le soit plus.

La panne AWS d'octobre a déclenché des débats sans fin sur Twitter autour de la « décentralisation ».

Et la panne Cloudflare de novembre ? Silence radio.

Ce n'est pas un « silence philosophique », ni une « réflexion profonde ».

C'est juste que : ceux qui voulaient râler ont découvert que leur plateforme favorite (Twitter) était elle-même en panne à cause de l'infrastructure.

Quand le « point de défaillance unique » est justement la plateforme que vous utilisez pour vous moquer du « point de défaillance unique », il n'y a rien à dire.

Quand la couche d'accès dépend de trois entreprises, dont deux ont connu une panne le même mois, la « décentralisation au niveau du protocole » n'a aucun sens.

Si les utilisateurs ne peuvent pas accéder à la blockchain, alors de quoi « décentralisons-nous » vraiment ?

Le dilemme du monopole : trois entreprises contrôlent 60 % du cloud, quel avenir pour la crypto ?

AWS contrôle environ 30 % du marché mondial de l'infrastructure cloud, Microsoft Azure 20 %, Google Cloud 13 %.

Trois entreprises contrôlent plus de 60 % de l'infrastructure cloud qui soutient l'Internet moderne.

L'industrie crypto, censée être la solution à la « centralisation », dépend aujourd'hui de l'infrastructure la plus centralisée au monde.

Liste des « dépendances centralisées » de l'industrie crypto

• Coinbase — dépend d'AWS ;
• Binance, BitMEX, Huobi, Crypto.com — tous dépendent d'AWS ;
• Kraken, bien que construit sur AWS, a tout de même été affecté par la panne du CDN (Content Delivery Network) de Cloudflare.

De nombreux échanges se revendiquant « décentralisés » fonctionnent en réalité sur une infrastructure centralisée.

Il y a une différence clé entre les pannes d'octobre et de novembre :

Lors de la panne AWS, la plateforme X (ex-Twitter) fonctionnait encore, permettant aux utilisateurs crypto de se moquer de la « fragilité de l'infrastructure ».

Mais lors de la panne Cloudflare, la plateforme X est tombée aussi.

Quand la plateforme que vous utilisez pour « vous moquer du point de défaillance unique » est elle-même un « point de défaillance unique », il n'y a rien à en rire.

Ce sentiment ironique a étouffé le débat sectoriel dès le départ.

Trois pannes majeures en 30 jours, les régulateurs sont désormais très attentifs.

Questions clés pour les régulateurs

• Ces entreprises doivent-elles être considérées comme des « institutions d'importance systémique » ?
• Les services d'infrastructure Internet doivent-ils être soumis à une « régulation de type service public » ?
• Quels risques lorsque la notion de « trop gros pour faire faillite » s'applique à l'infrastructure technologique ?
• Si Cloudflare contrôle 20 % du trafic mondial, cela pose-t-il un problème de monopole ?

Corinne Cath-Speth de l'organisation Article 19 l'a dit sans détour lors de la dernière panne AWS : « Quand un fournisseur tombe, les services critiques tombent aussi — les médias sont inaccessibles, Signal et d'autres applications de communication sécurisée cessent de fonctionner, l'infrastructure qui soutient la société numérique s'effondre. Nous avons un besoin urgent de diversification du cloud. »

En d'autres termes : les gouvernements réalisent peu à peu qu'une poignée d'entreprises peut suffire à paralyser Internet.

En réalité, des alternatives décentralisées existent déjà, mais personne ne veut les adopter.

Par exemple, Arweave pour le stockage, IPFS pour le transfert de fichiers distribué, Akash pour le calcul, Filecoin pour l'hébergement décentralisé.

Pourquoi les solutions décentralisées peinent-elles à s'imposer ?

Les performances sont inférieures aux solutions centralisées, la latence est perceptible pour l'utilisateur.

Le taux d'adoption est très faible, et comparé à la simplicité du « déployer sur AWS », l'expérience utilisateur des solutions décentralisées est complexe et fastidieuse.

Le coût est souvent supérieur à la location d'infrastructure auprès des « trois géants » (AWS, Azure, Google Cloud).

La réalité :

Construire une véritable infrastructure décentralisée est extrêmement difficile, bien plus qu'on ne l'imagine.

La plupart des projets ne font que parler de « décentralisation », mais la mettent rarement en pratique. Choisir une solution centralisée reste toujours plus simple et moins cher — jusqu'à ce que 4 pannes en 18 mois fassent réaliser le coût caché de cette « simplicité ».

Max Li, PDG de OORT, a pointé l'hypocrisie du secteur dans une tribune récente sur CoinDesk :

« Pour une industrie qui se targue de « décentralisation » et en vante les mérites, dépendre autant d'une infrastructure cloud centralisée et fragile est en soi une hypocrisie. »

Sa solution : adopter une stratégie cloud hybride, et répartir les systèmes critiques des plateformes d'échange sur des réseaux décentralisés.

Les plateformes cloud centralisées ont des avantages de performance et d'échelle irremplaçables — mais lorsqu'il s'agit de milliards de dollars et que chaque seconde de transaction compte, leur résilience est bien inférieure à celle des solutions distribuées.

Ce n'est que lorsque le coût de la « commodité » sera suffisamment lourd pour changer les comportements du secteur que les « principes » l'emporteront sur la « commodité ».

De toute évidence, la panne du 18 novembre n'a pas été assez grave, celle du 20 octobre sur AWS non plus, ni celle de CrowdStrike en juillet 2024.

Jusqu'où faudra-t-il aller pour que « l'infrastructure décentralisée » passe du « sujet de discussion » à « l'exigence incontournable » ?

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

Ce qui a vraiment « échoué », c'est le mensonge collectif de l'industrie : croire qu'on peut bâtir des « applications inarrêtables » sur une « infrastructure stoppable » ; croire que la « résistance à la censure » a un sens quand trois entreprises contrôlent les « points d'accès » ; croire que la « décentralisation » est réelle quand un simple fichier de configuration Cloudflare décide si des millions de personnes peuvent trader.

Si la blockchain continue de produire des blocs mais que personne ne peut soumettre de transactions, est-elle vraiment « en ligne » ?

L'industrie n'a aucun plan d'urgence.

En cas de panne, il ne reste qu'à attendre que Cloudflare répare, qu'AWS rétablisse le service, qu'Azure déploie un correctif.

Voilà la « stratégie de reprise après sinistre » actuelle du secteur.

Imaginez : que se passerait-il si l'identité numérique était profondément liée à la blockchain ?

Le Trésor américain pousse à intégrer les justificatifs d'identité dans les smart contracts, exigeant que chaque interaction DeFi passe par une vérification KYC.

Lors de la prochaine panne d'infrastructure, les utilisateurs perdront non seulement le droit de trader — mais aussi la capacité de « prouver leur identité » dans le système financier.

Une panne de 3 heures deviendra 3 heures d'« impossibilité de charger l'interface de vérification humaine » — simplement parce que le service de vérification tourne sur une infrastructure en panne.

Les « garde-fous » que veulent mettre en place les régulateurs supposent une « infrastructure toujours en ligne ». Mais la panne du 18 novembre prouve que cette hypothèse ne tient pas.

Quand le problème de la « surveillance excessive » devient évident, les professionnels de la tech se tournent vers la « protection de la vie privée ».

Peut-être est-il temps d'inclure aussi la « résilience de l'infrastructure » dans cette catégorie.

Ce ne doit pas être un « bonus optionnel », mais une « exigence fondamentale » — sans cela, tout le reste n'a pas de sens.

La prochaine panne est déjà en préparation — peut-être d'AWS, peut-être d'Azure, peut-être de Google Cloud, ou une nouvelle panne de Cloudflare.

Ce sera peut-être le mois prochain, peut-être la semaine prochaine. L'infrastructure n'a pas changé, les dépendances non plus, ni les incitations du secteur.

Choisir une solution centralisée reste toujours plus simple, plus rapide, plus économique — jusqu'à ce que ça ne le soit plus.

Lors du prochain changement de configuration Cloudflare, lorsqu'une faille cachée sera déclenchée dans un service clé, nous reverrons le même « scénario » familier : des pages d'erreur 500 partout, des transactions suspendues, une blockchain qui fonctionne mais inaccessible, l'envie de tweeter sur la « décentralisation » mais Twitter déjà en panne, des promesses d'entreprise « on fera mieux la prochaine fois » jamais tenues.

Rien ne changera, car la « commodité » l'emporte toujours sur la « gestion des risques » — jusqu'au jour où le coût de la « commodité » deviendra impossible à ignorer.

Cette fois, le « gardien » a été paralysé pendant 3 heures et demie.

La prochaine fois, la panne pourrait durer plus longtemps ; la prochaine fois, elle pourrait survenir lors d'un krach où chaque seconde de transaction compte ; la prochaine fois, le système d'authentification pourrait aussi être impliqué.

Quand l'infrastructure dont vous dépendez tombe en panne au pire moment, à qui la faute ?

Sources : The Guardian, Johnny Popov, PC Magazine, IT Professional, CNBC, Cloudflare, TechCrunch, Associated Press, CoinDesk, Tom's Hardware, Dane Knecht, Tom's Guide, Surya, Sheep Esports, TheBlock, Kraken, BitMEX, Ledger, Blockchain News, Statista, PC Scream, Jameson Lopp, Ben Schiller, Article 19, CoinTelegraph