Le fournisseur d’infrastructure Cloudflare a présenté ses excuses après une panne d’une ampleur rare survenue le 18 novembre 2025 et ayant affecté de nombreux sites majeurs comme ChatGPT, X ou bien encore des portails d’entreprise. L’incident, qui a duré plusieurs heures, n’était pourtant pas le fruit d’une attaque mais d’une défaillance logicielle liée à la gestion des bots.
Une erreur logicielle au cœur de la panne
Contrairement aux premières spéculations, Cloudflare affirme qu’il ne s’agissait pas d’une attaque DDoS, mais d’une « erreur douloureuse » issue d’une mise à jour logicielle. Une modification des permissions dans une base de données ClickHouse a généré des lignes dupliquées dans un fichier de configuration utilisé par son système Bot Management. Résultat : ce « feature file » a doublé de taille, dépassant les limites prévues et provoquant des dysfonctionnements dans le routage du trafic.
Des symptômes erratiques et une première hypothèse de cyberattaque
Cloudflare explique avoir initialement pensé avoir affaire à une attaque massive, car le réseau tombait en panne toutes les cinq minutes dans un cycle de récupération puis de nouvelle défaillance. Cette oscillation venait en fait d’un fichier instable qui se régénérait toutes les cinq minutes à partir d’un cluster ClickHouse partiellement mis à jour. « Toutes les cinq minutes, il y avait une chance d’obtenir un ensemble de configuration mauvais ou bon ».
Remise en ligne et correctifs engagés
Pour résoudre la crise, Cloudflare a stoppé la propagation du fichier défaillant et a remis en place une version stable. Le trafic principal a recommencé à circuler normalement autour de 14h30 UTC, et tous les services avaient retrouvé un fonctionnement complet vers la fin de l’après midi. Dans son mea-culpa, Matthew Prince, cofondateur et CEO de Cloudflare, estime que « toute interruption de nos systèmes est inacceptable » compte tenu de l’importance de Cloudflare dans l’Internet mondial. Pour prévenir un nouvel incident, l’entreprise prévoit désormais plusieurs mesures, soit renforcer la validation des fichiers de configuration, ajouter des “kill switches” globaux, et revoir les modes d’échec de ses modules clés.
Cette panne rappelle en tout cas la fragilité des infrastructures critiques sur lesquelles repose une large partie du Web, et soulève une question un peu plus embarrassante : comment rendre plus sûr un Internet qui dépend de quelques acteurs centraux ?
