Panne Cloudflare du 18 novembre : un fichier trop gros a mis des sites à terre
Un mois après AWS, Cloudflare a rendu inaccessibles une partie des sites du monde pendant des heures. La cause, les leçons, et ce que vous pouvez y faire.
Mardi 18 novembre 2025, en fin de matinée heure française, une grande partie du web a commencé à afficher des pages d'erreur. Réseaux sociaux, outils professionnels, sites de commerce : tous ceux qui passent par Cloudflare étaient touchés. Moins d'un mois après la panne géante d'AWS, c'est un autre maillon central d'internet qui a cédé. Cloudflare a publié le soir même une explication détaillée, remarquablement transparente. Voici ce qui s'est passé, et pourquoi ça vous concerne même si vous n'avez jamais entendu parler de Cloudflare.
Cloudflare, c'est quoi ?
Cloudflare est une entreprise qui se place entre les visiteurs et les sites web. Une part très importante des sites du monde passe par elle, pour trois raisons principales : accélérer l'affichage en gardant des copies des pages au plus près des visiteurs, protéger contre les attaques (notamment les attaques par saturation et les robots malveillants), et fournir divers services de sécurité. Quand Cloudflare tombe, les sites qui l'utilisent deviennent inaccessibles, même si leurs propres serveurs fonctionnent parfaitement.
Ce qui s'est passé
Selon le compte rendu publié par Cloudflare :
- les problèmes ont commencé à 11 h 20 UTC (12 h 20 à Paris) ;
- le trafic principal a été largement rétabli vers 14 h 30 UTC, et tous les systèmes sont revenus à la normale à 17 h 06 UTC ;
- la cause n'était pas une cyberattaque, même si les équipes l'ont d'abord soupçonnée.
L'enchaînement est un cas d'école. Une modification de permissions sur une base de données interne a changé le résultat d'une requête. Cette requête sert à produire un fichier de configuration utilisé par le système de détection des robots. Le fichier s'est retrouvé avec des lignes en double, et sa taille a doublé. Or le logiciel qui le lit avait une limite fixe sur le nombre d'éléments qu'il accepte. Dépassement de la limite, plantage, et des erreurs renvoyées pour une grande partie du trafic.
Pour compliquer le diagnostic, le fichier était régénéré toutes les quelques minutes, tantôt correct, tantôt défectueux : le réseau tombait, revenait, retombait. Les équipes ont fini par bloquer la production du fichier et redéployer une version saine.
D'autres services de Cloudflare ont été touchés par ricochet, dont Turnstile, son outil anti-robots utilisé dans de nombreux formulaires, et l'accès au tableau de bord des clients. Le compte rendu se conclut par des excuses sans détour : « We know we let you down today ».
Les leçons techniques, utiles bien au-delà de Cloudflare
Cloudflare annonce plusieurs mesures, qui sont autant de bonnes pratiques pour n'importe quel logiciel :
- Traiter ses propres fichiers de configuration avec la même méfiance que les données venant de l'extérieur. Le fichier était produit en interne, donc supposé fiable. Il ne l'était pas.
- Ajouter des interrupteurs d'urgence pour couper une fonction défaillante sans arrêter tout le reste.
- Éviter que les rapports d'erreur saturent les machines au moment où tout va mal.
- Revoir la façon dont chaque module réagit à une erreur : un module de détection des robots qui plante ne devrait pas emporter tout le trafic avec lui.
Ce que ça change pour une PME
Deux pannes majeures en un mois, chez deux acteurs différents, posent la même question : de quoi dépend votre activité en ligne ? Nous écrivions après la panne d'AWS que les dépendances sont souvent invisibles. Celle de Cloudflare le confirme : beaucoup d'entreprises ne savaient même pas que leur site, leur outil de réservation ou leur formulaire de contact passaient par ce service.
Il ne faut pas en conclure qu'il faut se passer de ces services. Ils protègent efficacement contre des attaques quotidiennes qu'une PME ne saurait pas arrêter seule. Mais il faut :
- savoir qu'on en dépend, et ce qui s'arrête quand ils tombent ;
- prévoir un plan B pour les fonctions critiques : un numéro de téléphone visible, une prise de commande possible autrement, une communication prête pour vos clients ;
- vérifier que vos propres logiciels échouent proprement : quand un service tiers ne répond pas, l'application doit afficher un message clair et proposer une alternative, plutôt qu'une page blanche.
Ce dernier point est celui sur lequel nous travaillons le plus dans nos projets. Un formulaire de réservation qui ne peut plus joindre son service doit dire au visiteur d'appeler, pas planter en silence.
Les questions à vous poser
- Votre site et vos outils en ligne passent-ils par Cloudflare, ou par un service équivalent ?
- Qu'est-ce qui s'est arrêté chez vous le 18 novembre, ou le 20 octobre ?
- Vos clients ont-ils un autre moyen de vous joindre quand le site ne répond plus ?
- Vos logiciels affichent-ils un message utile quand un service extérieur est en panne ?
Pour relire l'analyse de la panne précédente, voir notre article sur la panne d'AWS. Et si vous voulez des outils qui dépendent du moins de services extérieurs possible, hébergés en France et conçus pour échouer proprement, c'est ainsi que nous construisons nos logiciels. Pour faire le point, prenez un rendez-vous de 30 minutes.