Je vais tout vous révéler tout de suite, alors si vous êtes pressé, vous pouvez vous épargner la suite : hier, le 18 novembre 2025, une panne chez Cloudflare a mis hors service 20 % d’Internet pendant trois heures. La cause ? Un fichier de configuration du système de gestion des bots dont la taille a doublé, dépassant les limites de mémoire pré-allouées. Le logiciel de routage a paniqué, générant des erreurs HTTP 500 sur des milliers de sites : X, ChatGPT, Canva, PayPal, League of Legends. Aucune cyberattaque. Aucune attaque DDoS. Et surtout… Aucune intelligence artificielle n'a tenté de « prendre le contrôle d'Internet ». Alors qu'un individu déséquilibré s'emballe sur les réseaux sociaux, il s'agit simplement d'une erreur de requête de base de données ayant renvoyé des lignes dupliquées lors d'une mise à jour des autorisations.
Matthew PrinceLe PDG de Cloudflare a qualifié l'incident de « pire panne depuis 2019 ». Le réseau a été rétabli à 17h06 UTC après une restauration manuelle du fichier de configuration. Mais sur X et Reddit, certains ont déjà évoqué Skynet. Voici l'histoire complète.
Le bot qui n'était pas une IA rebelle
Commençons par les faits. Cloudflare utilise un système appelé Gestion des robots Ce système permet d'identifier et de bloquer le trafic automatisé malveillant. Il repose sur un modèle d'apprentissage automatique qui analyse chaque requête HTTP transitant sur le réseau. Pour fonctionner, le modèle lit un « fichier de caractéristiques » : un fichier de configuration contenant les caractéristiques utilisées pour classifier un bot et déterminer s'il est « ami » ou « ennemi », et donc s'il mérite d'être bloqué.
Ce fichier est mis à jour toutes les cinq minutes et distribué à tous les serveurs Cloudflare dans le monde. Le 18 novembre, à 11 h 05 UTC, une personne a modifié les autorisations d'un groupe de bases de données ClickHouse. Ce changement visait à améliorer la gestion des autorisations, rendant explicite l'accès aux données sous-jacentes. Mais la commande utilisée pour générer le fichier de configuration était incorrecte. Résultat : a renvoyé des lignes en double, doublant ainsi la taille du fichier.
Le fichier a été validé. d'environ 60 fonctionnalités à plus de 200Le logiciel avait une limite fixe : exactement 200 fonctionnalités, pré-allouées en mémoire pour optimiser les performances. Lorsque le fichier dépassait cette limite, le système passait en mode… paniqueEt tout s'est arrêté, entraînant la chute de Cloudflare et d'une très grande partie du web.
Aucune IA qui devient folle. Aucun bot qui prend conscience. Juste (désolé si ça sonne arabe, je vais utiliser des termes techniques) une Résultat::déballer() appelé à un Err Dans Rust. C'est un peu comme essayer de faire entrer 11 personnes dans une voiture de 10 places et que le système vous dise : « Non, ce n'est pas possible. » Sauf qu'ici, le système a dit « non », provoquant la panne de la moitié d'Internet.
Cloudflare en panne : pourquoi cette confusion avec l'IA ?
L'expression « gestion des bots » n'arrange rien. Pour les non-initiés, le terme « bot » évoque immédiatement l'intelligence artificielle autonome. Ajoutez à cela le fait que le système utilise l'apprentissage automatique, et le scénario se déroule presque tout seul : « L'IA de Cloudflare a pris le contrôle. » Pendant les minutes de la panne, des discussions délirantes ont fleuri sur X : « Ça a commencé », « Skynet s'est réveillé », « L'IA a trouvé le moyen de couper Internet. » Certains ont même avancé que la page d'état de la panne de Cloudflare était également hors ligne comme « preuve » d'une attaque coordonnée.
La page d'état est en réalité hébergée sur une infrastructure externe, sans aucune dépendance à Cloudflare. C'était une coïncidence. Mais lorsque la connexion internet est coupée et que votre source d'informations sur l'état du service est également inaccessible, L'équipe interne a un instant pensé qu'il pouvait s'agir d'une attaque DDoS.Ils ont alors compris : il s'agissait simplement du chaos parfait d'une erreur insignifiante amplifiée à l'échelle mondiale.
Un mois de pannes : AWS, Azure, Cloudflare
L'indisponibilité de Cloudflare n'est pas un incident isolé. Il s'agit du troisième épisode en un mois. Le 20 October 2025, AWS a été hors service pendant des heures., emmenant avec lui Snapchat, Roblox, Fortnite, Duolingo, Ring, Coinbase. Comme nous l'avons indiqué ici sur Futuro ProssimoLe problème a pris naissance dans des centres de données situés en Virginie, dans la région. nous-est-1DynamoDB et EC2, les deux piliers de l'infrastructure AWS, véritables cœurs battants du cloud computing mondial, ont subi une augmentation de leurs taux d'erreur. Autrement dit : ils se sont effondrés.
Le 28 Octobre c'était à AzureLe cloud de Microsoft. Une fois de plus, les services répartis dans le monde entier sont paralysés en raison de problèmes localisés sur quelques nœuds critiques. Et maintenant, c'est au tour de Cloudflare. Trois pannes en un mois. Trois géants. Trois infrastructures qui, à elles seules, supportent une part considérable d'Internet.
Selon les estimations, 34 millions de sites Web Ils utilisent Cloudflare. AWS contrôle 30 % du marché du cloud, Azure 24 %. Au total, ces trois services prennent en charge les trois quarts d'Internet.Et lorsque l'un d'eux s'effondre, l'effet domino est immédiat et mondial.
La contradiction est flagrante. Nous concevons des architectures « distribuées » et « résilientes », mais nous centralisons ensuite tout dans le même centre de données par commodité, rapidité et rentabilité. Jusqu'à ce que ce ne soit plus le casUne enquête menée par PagerDuty auprès de 1 000 dirigeants informatiques a révélé que 88 % s'attendent à une nouvelle panne d'électricité mondiale dans les 12 prochains mois.À ce stade, je dirais que le « pessimisme », compte tenu des statistiques récentes, est au moins légitime.
La fragilité d'un web centralisé
Le vrai problème n'est pas que Cloudflare soit tombé en panne. C'est que quand Si Cloudflare tombe en panne, tout le reste s'effondre. Le web est né distribué. L'idée originale d'Internet était celle d'un réseau décentraliséDans ce système, chaque nœud pouvait communiquer avec n'importe quel autre sans passer par un point central. En cas de défaillance d'un élément, le trafic empruntait un autre chemin.
Aujourd'hui, internet fonctionne à l'inverse. Nous avons concentré les infrastructures critiques entre les mains de trois ou quatre entreprises : AWS, Azure, Google Cloud (sera-t-il le prochain à s’effondrer ?) et Cloudflare. Si l’une d’entre elles rencontre un problème technique, des millions de services cessent simultanément de fonctionner. Non pas parce qu’ils sont logiquement connectés, mais parce qu’ils partagent la même infrastructure physique.
C'est comme si toutes les rues d'une ville passaient par un seul et même pont. Quand le pont s'effondre, peu importe la qualité des routes : personne ne peut passer. Et quand Ce pont s'appelle Cloudflare et il achemine 78 millions de requêtes HTTP par seconde.L'effondrement se fait sentir partout.
Cloudflare est hors service, Skynet n'y est pour rien. Mais ne vous inquiétez pas : c'est pire.
Les catastrophistes évoquent toujours Skynet, l'intelligence artificielle de Terminator qui prend conscience de la situation et décide d'exterminer l'humanité. C'est un fantasme commode. Il nous donne l'impression que le danger est toujours étranger et hostile. Mais la réalité est tout autre. Le plus grand danger ne venait pas d'une rébellion de l'IA, mais des choix que nous faisions chaque jour quant à la manière de construire l'infrastructure numérique.
Cloudflare n'est pas tombé en panne suite à une attaque d'IA. La panne est due à une modification des permissions de la base de données et à une requête SQL ayant renvoyé des lignes dupliquées. De même, AWS n'est pas tombé en panne à cause d'une cyberattaque, mais en raison d'un problème technique rencontré par DynamoDB dans la région. nous-est-1Azure n'est pas tombé en panne à cause d'un complot. La panne est due à une erreur de configuration.
Ce sont des erreurs humaines. Banales. Mais amplifiées à l'échelle mondiale parce que nous avons choisi de tout centraliser. Au lieu de fantasmer sur le moment où l'IA prendra le pouvoir, demandons-nous plutôt combien de temps encore nous voulons dépendre de trois ou quatre entreprises pour faire fonctionner Internet.
Cloudflare a déjà annoncé des contre-mesures : des contrôles plus stricts des fichiers de configuration, des mécanismes d’arrêt d’urgence globaux pour désactiver les fonctionnalités problématiques et une révision des limites de mémoire. C’est bien beau. Mais cela ne résout pas le problème de fond. Je le répète, au risque de paraître lassant : tant que 20 % du web dépend d’un seul opérateur, une erreur anodine peut mettre des millions de services hors service.
Aucune IA ne prendra le contrôle. Mais la réalité pourrait être pire que la fiction si nous ne corrigeons pas nos choix. Car Skynet a au moins le mérite d'être prévisible : on sait qu'elle veut nous anéantir. Un fichier de configuration de 200 lignes, en revanche, nous prend au dépourvu.
Et cela nous rappelle que l'internet, aussi indestructible qu'il puisse paraître, Elle repose sur des fondements bien plus fragiles que nous ne voudrions le croire..
