Internet devait survivre à l'apocalypse : il s'effondre à cause d'un fichier corrompu

En 1969, Paul Baran concevait un réseau capable de résister à l'apocalypse nucléaire : fragmenté, décentralisé, sans point de défaillance unique. En 2025, trois fournisseurs cloud contrôlent 67 % de l'infrastructure Internet mondiale. Cloudflare seul protège 20 % du trafic web.

Quand l'un tombe, c'est une partie significative du web qui disparaît. Comment en sommes-nous arrivés là ?

Le 18 novembre 2025 à 11h20 UTC, une simple erreur de configuration dans les fichiers de gestion de Cloudflare a paralysé une partie significative du web mondial. ChatGPT, X, Spotify, Canva, des milliers de sites d'information, des services gouvernementaux : tous inaccessibles. Pas en raison d'une attaque, pas d'une défaillance matérielle généralisée, mais parce qu'un changement d'accès à une base de données a causé le doublement d'un fichier de configuration dans le système de gestion des bots de Cloudflare.

Ce qui rend l'incident particulièrement absurde, c'est son origine : une anomalie si banale que les ingénieurs ont d'abord cru à une attaque DDoS de grande envergure. Des lignes de code en trop, une mesure de sécurité automatique déclenchée, et l'ensemble du service s'écroule comme un château de cartes.

Près de six heures se sont écoulées avant que le service revienne à la normale. Pendant ce temps, environ 20 % de l'infrastructure Internet mondiale, celle qui dépend de Cloudflare, s'était tout simplement évanouie du paysage numérique.

Mais il y a quelque chose d'ironique, de presque comique dans cet incident. C'est précisément l'opposé de ce pour quoi Internet avait été conçu au départ.

ARPANET : une armure contre l'apocalypse

Il faut remonter à 1969, en pleine Guerre froide, pour comprendre d'où vient cette contradiction fondamentale.

Le Department of Defense américain n'a pas construit ARPANET, le réseau ancêtre d'Internet, pour optimiser la vitesse ou maximiser les profits. Ni même pour révolutionner la communication. Il l'a conçu pour survivre à une guerre nucléaire.

C'est Paul Baran qui, travaillant chez RAND Corporation, avait proposé en 1964 le concept révolutionnaire : fragmenter l'information en paquets, chacun capable de trouver son propre chemin à travers le réseau. Si une partie du réseau était détruite, les autres continueraient à fonctionner. Aucun point central de contrôle, aucun cœur à viser, aucune vulnérabilité unique.

Cette philosophie de résilience par décentralisation a été gravée au cœur d'Internet. Le premier message d'ARPANET, envoyé le 29 octobre 1969 entre UCLA et Stanford Research Institute, incarnait un principe fondamental : aucun serveur ne devrait être indispensable. TCP/IP, le protocole qui allait devenir la pierre angulaire d'Internet, était construit sur cette même hypothèse, un réseau intrinsèquement fragmenté où chaque nœud pouvait fonctionner indépendamment.

Cinquante-six ans plus tard, nous avons créé exactement l'inverse.

La grande centralisation : comment nous avons trahi la vision

Le chemin de la décentralisation vers la concentration centralisée n'a pas eu lieu par une décision consciente. C'était plus insidieux : une série de choix techniquement justifiés qui, accumulés, ont créé une architecture diamétralement opposée à celle prévue.

L'économie d'échelle a gagné

Il est énormément plus efficace qu'une poignée de géants gère l'infrastructure. AWS, Microsoft Azure et Google Cloud contrôlent collectivement 67 % du marché du cloud. Cloudflare seul assure la protection et l'accélération de 20 % du trafic web mondial.

Ces chiffres ne sont pas le résultat d'un monopole forcé. Ils reflètent une réalité technique simple : construire et maintenir des data centers coûte des milliards, investir dans des systèmes de protection DDoS mondiaux demande une expertise colossale, et gérer une infrastructure de CDN global nécessite une optimisation constante.

Aucune PME, aucun gouvernement décentralisé ne peut vraiment concurrencer ces titans. Les économies d'échelle les consolident naturellement à la position de quasi-monopoles.

Le confort a vaincu la résilience

Pour une startup, pourquoi construire sa propre infrastructure quand vous pouvez cliquer sur un bouton et déployer votre application en quelques minutes chez AWS ? Pourquoi maintenir vos propres serveurs DNS quand Cloudflare offre une sécurité incomparable ? L'ironie est que ce qui rend ces services si attractifs, leur centralité, leur simplification d'un web complexe, est exactement ce qui crée la vulnérabilité.

Les cloud providers deviennent des points de défaillance uniques

SPOF (Single Point of Failure) : c'est le terme qui hante les ingénieurs d'infrastructure. Un composant unique dont la défaillance paralyse le système entier.

L'architecture du web moderne en 2025 est devenue profondément SPOF-dépendante : le DNS est centralisé chez quelques fournisseurs, le CDN est contrôlé par Cloudflare et Akamai, le compute est fragmenté mais largement concentré dans trois clouds majeurs.

La panne d'AWS : un avertissement oublié

En octobre 2025, seulement un mois avant la panne Cloudflare, AWS avait connu un incident similaire qui avait affecté plus de 3 500 services et généré 17 millions de rapports d'utilisateurs frustrés dans le monde. Le coupable : un problème de résolution DNS dans sa région US-EAST-1 en Virginie du Nord.

Snapchat, Roblox, les applications de banque britanniques, les universités australiennes : tous ont suivi le même chemin. Une région AWS s'effondre, et des centaines de services dépendants disparaissent du paysage numérique.

Mais l'incident d'AWS n'a pas vraiment changé grand-chose. Les organisations qui en dépendaient n'avaient guère d'options viables. Signal, la plateforme de messaging sécurisée réputée pour être ultra-indépendante, s'est même retrouvée inaccessible lors de la panne AWS, car elle utilise les services d'AWS, Google et Azure pour la redondance supposée. Quand le premier cloud s'effondre, la théorie de la redondance s'effondre avec lui.

L'absurdité : prisonnier d'une centralisation programmée

Voici où se niche l'absurdité profonde. Internet a été conçu expressément pour ne pas avoir de point de défaillance unique. ARPANET était un réseau de mailles, chaque nœud pouvant communiquer avec d'autres sans passer par un serveur central.

Et pourtant, malgré cette architecture fondamentalement décentralisée, nous avons réussi à créer une couche applicative totalement centralisée, qui s'appuie sur quelques fournisseurs de services critiques. C'est comme avoir construit une maison avec des fondations capables de survivre aux tremblements de terre, puis avoir placé tout le poids du bâtiment sur une seule colonne.

L'ironie du cloud

Le cloud lui-même a été vendu comme une solution à la complexité. « Plus besoin de maintenir vos serveurs, laissez-nous gérer ça, et vous pourrez mettre à l'échelle instantanément. »

Sauf qu'en centralisant l'infrastructure, nous avons créé exactement le contraire de la résilience que nous cherchions. Nous avons échangé la résilience pour la commodité. En quête d'efficacité au niveau de chaque service individuel (protéger contre les DDoS, assurer la disponibilité globale), nous avons créé des dépendances centralisées qui introduisent des modes de défaillance systémiques au niveau écosystémique.

Quand 20 % d'Internet s'arrête pour six heures

Prenez un moment pour absorber cela : un simple fichier de configuration corrompu a rendu une partie significative du web inaccessible. Pas une attaque nucléaire, pas une catastrophe naturelle, pas même une véritable attaque cybernétique. Un bug qui aurait dû être attrapé par des tests unitaires de base.

Le fichier en question avait simplement deux fois sa taille normale, une anomalie mineure qui a dépassé les vérifications de validation des systèmes proxy de Cloudflare. Pendant que le système ne cessait de recevoir tantôt des fichiers valides, tantôt des fichiers corrompus (toutes les cinq minutes), l'ensemble du service oscillait entre le fonctionnement normal et la défaillance, confondant les ingénieurs pendant plus de trois heures.

Et les conséquences ont été globales. Des entreprises qui n'avaient rien à voir avec Cloudflare, dont les serveurs fonctionnaient parfaitement, se sont retrouvées hors ligne parce qu'elles utilisaient Cloudflare comme couche de sécurité et de distribution.

AWS + Azure + Google = 67 % du web

La concentration n'est pas seulement un problème Cloudflare. Elle est systémique.

Les trois principaux fournisseurs de cloud (AWS, Microsoft Azure, Google Cloud) contrôlent ensemble 67 % de l'infrastructure cloud mondiale. C'est une concentration stupéfiante. Lorsqu'AWS tombe en panne, c'est potentiellement le tiers d'Internet qui bascule. Quand Google Cloud a un problème, c'est un autre tiers en jeu.

Même les organisations qui pensent avoir diversifié leur infrastructure découvrent qu'elles dépendent de ces mêmes trois fournisseurs à un niveau ou un autre : certificats SSL via AWS Certificate Manager, DNS via Google Cloud DNS, etc.

L'illusion de la redondance

Voilà le point critique qui remet en question toute la théorie actuelle de la résilience : la redondance au sein d'un fournisseur centralisé n'élimine pas la dépendance au fournisseur centralisé.

Une organisation peut avoir dix serveurs dans AWS à travers différentes zones de disponibilité. Mais si AWS connaît un problème global de DNS ou de proxy, ses dix serveurs deviennent aussi inaccessibles que s'il n'en avait qu'un. La redondance aide uniquement contre les défaillances isolées et localisées. Elle ne protège pas contre les défaillances systémiques de l'infrastructure partagée.

Les organisations avec des stratégies cloud diversifiées (multi-cloud) pensent être protégées. Mais même ces stratégies échouent : Signal utilise AWS, Google et Azure en redondance, et s'est retrouvée affectée par la panne AWS seule.

Pourquoi nous ne corrigeons pas ce problème

La réponse honnête est simple : parce que c'est très difficile et cher.

Inertie technologique et économique

Les applications construites pour le cloud centralisé ne sont pas triviales à migrer. Une organisation qui a passé cinq ans à optimiser son architecture AWS ne peut pas simplement la « déplacer » ailleurs sans investissements massifs.

Expertise concentrée

Pour construire une infrastructure résiliente vraiment distribuée, vous avez besoin d'une expertise en infrastructure distribuée, une compétence relativement rare. Il est plus facile de trouver quelqu'un qui connaît AWS que quelqu'un qui peut construire une architecture distribuée robuste.

Les solutions alternatives n'existent pas à l'échelle

Les solutions décentralisées, Mastodon avec ActivityPub, PeerTube pour la vidéo, IPFS pour le stockage distribué, existent, mais elles ne sont pas prêtes à absorber le trafic et les exigences de performance des services grand public.

Canva n'a pas pu utiliser une alternative décentralisée à la place de Cloudflare le 18 novembre. Il n'y a simplement aucune alternative viable à cette échelle.

Les utilisateurs finaux ne se plaignent que pendant les pannes

Entre les pannes, le système fonctionne « assez bien ». L'utilisateur moyen ne réfléchit jamais à la possibilité d'une panne Cloudflare. Et quand elle arrive, elle dure quelques heures, puis c'est oublié. L'incitation à construire une alternative résiliente est faible tant que la panne ne coûte pas suffisamment cher pour justifier une réarchitecture majeure.

Pourrions-nous vraiment décentraliser Internet en 2025 ?

Solutions partielles

Il existe des approches qui réduisent le risque, même si elles ne l'éliminent pas complètement.

Multi-CDN. Utiliser Cloudflare, Akamai et AWS CloudFront en même temps. C'est plus cher et plus complexe, mais une panne d'un seul CDN n'affecte pas 100 % du trafic.

DNS Failover. Utiliser plusieurs fournisseurs DNS. Si l'un tombe, un autre prend le relais.

Self-hosting avec redondance géographique. Certains services qui en ont les ressources construisent des architectures vraiment distribuées, sans dépendre d'un unique fournisseur de services gérés.

Mais ces solutions sont coûteuses et demandent une expertise considérable. Elles ne sont réalistes que pour les plus grandes organisations.

La vraie décentralisation : émergence progressive

Les projets vraiment décentralisés existent et évoluent. Helium construit une infrastructure de réseau mobile décentralisée, Bluesky avec son AT Protocol tente de décentraliser les réseaux sociaux, les projets DePIN (Decentralized Physical Infrastructure Networks) explorent comment tokeniser et distribuer l'infrastructure physique.

Mais aucune de ces alternatives ne peut aujourd'hui remplacer les services centralisés à grande échelle. La vraie décentralisation d'Internet aurait probablement besoin d'un choix politique volontaire, une régulation qui forcerait les fournisseurs de services critiques à se fragmenter ou à supporter des standards d'interopérabilité plus stricts.

Une fenêtre qui se ferme

La panne de Cloudflare du 18 novembre 2025 ne sera pas la dernière. Elle sera probablement oubliée en quelques mois, remplacée par la prochaine panne, peut-être d'AWS en janvier 2026, ou de Google Cloud en avril.

Chaque fois, nous nous disons qu'il faut vraiment diversifier notre infrastructure. Et chaque fois, rien ne change vraiment, parce que les incitations économiques nous poussent tous vers les mêmes trois ou quatre fournisseurs.

Sauf que quelque chose change légèrement, à chaque panne. Les conversations deviennent plus sérieuses. Les gouvernements commencent à poser des questions sur la résilience critique de l'infrastructure. Les régulateurs envisagent des interventions.

La question n'est pas si nous reviendrons à un Internet plus décentralisé. La question est quand, et si ce sera par un choix conscient et volontaire, ou après une panne massive qui affecte l'économie mondiale pendant des jours.

Le paradoxe inévitable

Nous avons conçu Internet pour survivre à une apocalypse nucléaire. Puis nous l'avons réarchitecturisé pour être aussi centralisé que possible. Pendant 50 ans, ce choix nous a donné des performances exceptionnelles, une évolutivité remarquable, et une fiabilité suffisante pour que nous l'oubliions.

Et puis, le 18 novembre 2025 à 11h20 UTC, nous avons eu un rappel brutal : les décisions que nous prenons pour l'efficacité à court terme créent des vulnérabilités massives à long terme.

Une erreur de configuration dans un fichier de gestion de bots. C'est tout ce qu'il a fallu pour paralyser 20 % d'Internet pendant six heures.

Internet a 50 ans. Il était temps pour nous de reconnaître que nous avons construit quelque chose qui ressemble moins à la vision décentralisée d'ARPANET qu'à une cathédrale fragile qui tient debout par une force de volonté collective et par chance. La prochaine panne, et il y en aura une, devrait nous forcer à nous poser les bonnes questions.