L'illusion de la décentralisation : comment une erreur de base de données d'une seule entreprise a exposé la fragilité de l'infrastructure crypto

Le 18 novembre 2025, environ 20 % d’Internet est tombé hors ligne — non pas à cause d’une cyberattaque, mais suite à une mise à jour routinière des permissions de la base de données qui a déclenché un bug caché chez Cloudflare, une entreprise qui « protège » Internet contre ce genre de défaillance.

En quelques minutes, la cascade a commencé : Twitter a crashé en plein tweet, ChatGPT s’est figé, Spotify a cessé de diffuser. Et dans le monde de la crypto ? Les plateformes de trading se sont éteintes, les explorateurs de blockchain ont échoué, les interfaces de portefeuille ont renvoyé des erreurs 500. Pendant cinq heures et demie, l’industrie qui se voulait résistante à la censure et inarrêtable s’est retrouvée complètement stoppée.

L’ironie cruelle ? Les blockchains elles-mêmes continuaient de fonctionner parfaitement. Bitcoin minait des blocs. Ethereum traitait des transactions. Aucun échec de consensus, aucune panne de protocole. Les utilisateurs ne pouvaient simplement pas accéder à ce qu’ils « possédaient » supposément.

Ce qui s’est réellement passé : une erreur technique avec des conséquences catastrophiques

Cloudflare n’héberge pas de sites web ni ne vend de puissance de calcul comme d’autres grands fournisseurs de cloud. Au lieu de cela, il agit comme le contrôleur du trafic Internet — se plaçant entre les utilisateurs et les services dans 120 pays. La société traite environ 20 % du trafic Internet mondial via son réseau global.

Le 18 novembre à 11h05 UTC, Cloudflare a effectué un changement apparemment routinier sur son cluster de bases de données ClickHouse. L’objectif était raisonnable : améliorer la sécurité et la fiabilité en mettant à jour les contrôles d’accès. Mais c’est ici que la pseudo-résilience de l’infrastructure moderne s’est effondrée.

La requête de la base de données qui générait les configurations de protection contre les bots n’incluait pas de filtre pour les noms de bases de données. Cela signifiait que la requête commençait à renvoyer des entrées dupliquées — une depuis la base de données par défaut, une autre depuis la couche de stockage sous-jacente. Le fichier de configuration a soudainement doublé de taille, passant d’environ 60 fonctionnalités à plus de 200.

Les ingénieurs de Cloudflare avaient fixé une limite codée en dur à 200 fonctionnalités, pensant que cela dépassait largement leur utilisation réelle. La logique classique en ingénierie : fixer une marge de sécurité généreuse et supposer qu’elle ne sera jamais dépassée. Jusqu’à ce que ce soit le cas.

Le fichier surdimensionné a crashé le système de protection contre les bots — un composant central de toute la couche de contrôle de Cloudflare. Lorsqu’un système échoue, les systèmes dépendants suivent. Le système de surveillance de la santé, qui indique aux équilibrages de charge « quels serveurs sont opérationnels », a également échoué. Le trafic continuait d’arriver aux nœuds de Cloudflare en périphérie, mais il n’y avait aucun moyen de le router.

Pendant les premières heures, les ingénieurs de Cloudflare ont cru qu’ils étaient victimes d’une attaque DDoS massive. Le système oscillait entre « fonctionnel » et « complètement cassé » toutes les cinq minutes, le temps que la configuration problématique se régénère. Mais il n’y avait pas d’attaque — juste un filtre de base de données manquant et une hypothèse qui s’est avérée fausse.

À 17h06 UTC, la configuration correcte a été déployée globalement. Le service a été restauré. La crise a été évitée.

L’industrie crypto n’a pas le droit de se réjouir — elle a été exposée

Alors que les plateformes Web2 ont souffert en premier et de manière la plus visible — flux Spotify interrompus, sessions de jeu déconnectées, systèmes de livraison de nourriture crashés — le monde de la crypto a été confronté à une vérité plus inconfortable.

Plusieurs plateformes d’échange n’ont pas pu charger. Les explorateurs de blockchain sont tombés hors ligne. Les services de portefeuille ont échoué. Les interfaces de trading ont affiché des messages d’erreur. Et toute l’industrie voulait en parler sur Twitter — pour découvrir que Twitter était aussi en panne.

Cela a créé un silence étrange. Lors de la panne d’AWS en octobre, le crypto Twitter a passé des heures à se moquer de la « fragilité de l’infrastructure » et du « risque de centralisation ». Cette fois ? Personne ne pouvait se moquer de rien. La plateforme que vous utilisez pour critiquer les points de défaillance uniques est elle-même un point de défaillance unique.

Voici la partie inconfortable : les protocoles blockchain eux-mêmes n’ont jamais été affectés. Les transactions pouvaient être traitées en chaîne. Le consensus a continué. Toute la fondation technique de la « finance sans confiance, résistante à la censure » fonctionnait exactement comme prévu.

Mais peu importe. Parce qu’en l’absence d’accès, une blockchain fonctionnelle n’est qu’un enregistrement historique que personne ne peut lire.

Le schéma que personne ne brise : Quatre grandes pannes, le même problème sous-jacent

• juillet 2019 : panne de Cloudflare. Coinbase hors ligne, données de marché inaccessibles.
• juin 2022 : nouvelle panne de Cloudflare. Plusieurs plateformes crypto suspendent leurs services.
• 20 octobre 2025 : panne d’AWS durant 15 heures. Les défaillances de DynamoDB se propagent à travers les services dépendants.
• 18 novembre 2025 : encore Cloudflare. Cinq heures et demie de perturbation généralisée.

Quatre incidents majeurs d’infrastructure en environ 18 mois. La leçon devrait être évidente : une infrastructure centralisée crée des défaillances centralisées.

Et pourtant, l’industrie ne l’a pas encore apprise.

Pourquoi la « décentralisation » reste un terme marketing plutôt qu’une réalité technique

L’industrie crypto a construit toute sa philosophie sur une seule prémisse : éliminer les intermédiaires, supprimer les points de défaillance uniques, créer des systèmes inarrêtables.

La réalité est différente.

La « chaîne de dépendance » de l’infrastructure crypto actuelle ressemble à une blague que quelqu’un a peur de raconter :

• Les grands échanges dépendent d’Amazon Web Services
• Le DNS et la livraison de contenu dépendent de Cloudflare
• Les explorateurs de blockchain dépendent de Cloudflare
• Les plateformes d’analyse dépendent de Cloudflare
• Les interfaces de portefeuille dépendent d’une infrastructure centralisée similaire

Donc, quand Cloudflare met à jour une configuration de base de données et casse sa protection contre les bots, toute l’industrie — supposément conçue pour éviter ce scénario précis — se retrouve hors ligne.

La pseudo-décentralisation devient évidente : la couche protocolaire est réellement distribuée, mais la couche d’accès est bottleneckée par trois entreprises qui contrôlent environ 60 % de l’infrastructure cloud (Amazon Web Services à 30 %, Microsoft Azure à 20 %, Google Cloud à 13 % ).

Trois entreprises. Deux d’entre elles ont subi des pannes le même mois. Ce n’est pas de la redondance — c’est une fragilité concentrée.

La logique économique de la négligence

Pourquoi cela continue-t-il ? Pourquoi les plateformes crypto ne construisent-elles pas une infrastructure en supposant que des pannes surviendront ?

La réponse est déprimante de simplicité : c’est coûteux et complexe.

Construire sa propre infrastructure implique d’acheter du matériel, d’assurer la stabilité électrique, de maintenir une bande passante dédiée, d’embaucher des spécialistes en sécurité, d’établir une redondance géographique, de concevoir une récupération après sinistre, et de fournir une surveillance 24/7. Cela demande un capital important et des coûts opérationnels continus.

Utiliser Cloudflare, c’est entrer un numéro de carte de crédit et déployer en quelques minutes.

Les startups privilégient la rapidité d’accès au marché. Les investisseurs exigent une efficacité capitalistique. Tout le monde choisit la commodité plutôt que la résilience.

Jusqu’à ce que la commodité devienne profondément gênante — et apparemment, même quatre pannes majeures en 18 mois ne suffisent pas à changer de comportement.

Des alternatives décentralisées existent : Arweave pour le stockage, IPFS pour le transfert de fichiers distribué, Akash pour les ressources de calcul, Filecoin pour l’hébergement décentralisé. Aucune d’elles n’a connu une adoption significative parce qu’elles sont plus lentes, plus complexes, et souvent plus coûteuses que les alternatives centralisées.

L’industrie fait semblant de prôner la décentralisation tout en choisissant systématiquement des solutions centralisées dès qu’un vrai compromis entre principe et commodité se présente.

Ce que voient les régulateurs — et pourquoi ils commencent à s’y intéresser

Trois grandes pannes en 30 jours ont attiré l’attention des décideurs qui voient maintenant ce qui aurait dû être évident : quelques entreprises technologiques peuvent désactiver une infrastructure critique.

Les questions posées :

• Les entreprises contrôlant 20 % du trafic Internet mondial sont-elles des « institutions d’importance systémique » ?
• L’infrastructure Internet doit-elle être régulée comme une utilité publique ?
• Que se passe-t-il quand « trop gros pour faire faillite » s’applique aux plateformes technologiques ?
• Où est la redondance quand les pannes se propagent à travers des fournisseurs supposément indépendants ?

Lors de précédentes défaillances d’infrastructure, les experts politiques étaient explicites : quand un seul fournisseur échoue, les médias deviennent inaccessibles, les communications sécurisées cessent de fonctionner, et l’infrastructure qui soutient la société numérique s’effondre.

Les gouvernements reconnaissent que la concentration de l’infrastructure Internet crée un risque systémique.

Mais la régulation seule ne suffira pas. La vraie solution passe par une adoption volontaire d’une infrastructure décentralisée par l’industrie elle-même — un changement qui nécessite que la douleur des défaillances centralisées dépasse la commodité des solutions centralisées.