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 encore des portails d'entreprise. L'incident, qui a duré plusieurs heures, n'était cependant pas le résultat d'une attaque mais d'une panne 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'un « erreur douloureuse » à partir d'une mise à jour logicielle. Une modification des autorisations dans une base de données ClickHouse a généré des lignes en double dans un fichier de configuration utilisé par son système de gestion de robots. Résultat : ce « feature file » a doublé de taille, dépassant les limites prévues et provoquant des dysfonctionnements dans l'acheminement du trafic.
Des symptômes erratiques et une première hypothèse de cyberattaque
Cloudflare affirme avoir initialement pensé qu'il s'agissait d'une attaque massive, car le réseau tombait en panne toutes les cinq minutes au cours d'un cycle de récupération et de panne à nouveau. Cette oscillation provenait en réalité 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 une mauvaise ou une bonne configuration. »
Rechargement et correctifs entrepris
Pour résoudre la crise, Cloudflare a arrêté la propagation du fichier défectueux et a restauré une version stable. Le trafic principal a recommencé à circuler normalement vers 14h30 UTC, et tous les services étaient redevenus pleinement opérationnels en fin d'après-midi. Dans son mea-culpa, Matthew Prince, co-fondateur et PDG de Cloudflare, estime que « toute perturbation de nos systèmes est inacceptable » compte tenu de l'importance de Cloudflare dans l'Internet mondial. Pour éviter un nouvel incident, l'entreprise prévoit désormais plusieurs mesures, à savoir renforcer la validation des fichiers de configuration, ajouter des « kill switch » globaux et revoir les modes de défaillance de ses modules clés.
Cette panne rappelle en tout cas la fragilité des infrastructures critiques sur lesquelles repose une grande partie du Web, et soulève une question un peu plus embarrassante : comment sécuriser davantage un Internet qui dépend de quelques acteurs centraux ?
