Cloudflare Just Took the Internet Offline — And It Wasn’t Even a Hack
Cloudflare a mis Internet hors ligne — et ce n’était même pas un piratage
blog.cloudflare.com
So Cloudflare, the company that literally protects the internet from DDoS attacks, just bricked its entire network because of a typo in a database permissions change? That’s like a firefighter accidentally setting the fire station on fire while testing the sprinklers.
Cloudflare, l’entreprise censée protéger Internet des attaques DDoS, vient de planter tout son réseau à cause d’une faute de frappe dans une modification des droits d’accès à une base de données ? C’est comme un pompier qui met le feu à la caserne en testant les sprinklers.
The real kicker? Their status page went down too — hosted off their network. Coincidence? Or was the universe trolling them? Either way, imagine realizing mid-incident that your ‘incident response’ channel has no working bot to parse logs because, oh right, the bot system is the thing that’s broken.
Le pire ? Leur page de statut est tombée aussi — hébergée en dehors de leur réseau. Coïncidence ? Ou l’univers se moquait d’eux ? Dans les deux cas, imaginez vous rendre compte en plein incident que votre canal ‘gestion d’incident’ n’a pas de bot pour analyser les logs parce que, ah oui, c’est justement le système des bots qui est cassé.
Un seul changement de permissions. C’est tout. Pas d’alerte, pas de préproduction, pas de retour arrière automatique. Je sais qu’on est tous humains, mais quand ton infrastructure touche 20 % du web, tu devrais vraiment avoir un déploiement progressif pour les mises à jour de configuration.
C’est pourquoi il nous faut une surveillance réglementaire des infrastructures internet critiques. Cloudflare n’est plus une petite start-up. C’est devenu une utility essentielle. Laisser une seule entreprise détenir autant de pouvoir sans responsabilité est un risque systémique.
Ils avaient des sécurités — la limite de 200 caractéristiques était censée éviter les débordements mémoire. L’ironie, c’est que la barrière de sécurité justement conçue pour éviter les pannes est ce qui a causé la panne parce qu’elle n’était pas correctement gérée.
Tout ingénieur que je connaisse a ce moment ‘mon dieu’ qui attend de se produire. La vraie question n’est pas ‘qui a merdé’ — c’est ‘comment construire des systèmes où une erreur ne met pas Internet hors ligne ?’
Exactement. Accuser des individus passe à côté du sujet. Il s’agit de concevoir des systèmes qui échouent en douceur, pas héroïquement.
Oui, c’est grave. Mais ils ont admis leur erreur immédiatement, publié un rapport complet en quelques heures et réparé. Comparez avec d’autres entreprises qui disparaissent pendant des jours après une panne. Au moins, eux sont transparents.
1998, 2002, 2016, maintenant 2025. À chaque décennie, Internet devient plus centralisé, et chaque panne nous rappelle à quel point il est fragile.
Voyons le bon côté : cela prouve le pouvoir des rapports post-mortem ouverts. La prochaine génération d’ingénieurs apprendra de cette erreur. Moi-même, j’ai ajouté une étape de relecture de configuration à ma checklist.