Panne Cloudflare du 20 février : six heures pour rappeler qu'un prestataire peut tomber
Une tâche automatique boguée a retiré d'internet des milliers d'adresses de clients Cloudflare pendant plus de six heures. Ce qu'une PME doit en tirer.
Vendredi 20 février, une partie des clients de Cloudflare, l'un des principaux intermédiaires techniques d'internet, sont devenus injoignables pendant plus de six heures. Pas d'attaque : une tâche de nettoyage automatique, mal écrite, a supprimé des configurations qu'elle n'aurait jamais dû toucher. Cloudflare a publié une analyse détaillée et transparente. Elle rappelle une vérité simple : vos services dépendent de prestataires qui, eux aussi, peuvent tomber, et la question est de savoir ce qui se passe chez vous ce jour-là.
Ce qui s'est passé
Cloudflare se place entre les visiteurs et des millions de sites et d'applications : il accélère l'affichage, filtre les attaques et répartit le trafic. Certains grands clients lui confient même leurs propres plages d'adresses IP (un service appelé BYOIP, pour Bring Your Own IP), que Cloudflare annonce au reste d'internet.
D'après le rapport d'incident de Cloudflare, une sous-tâche automatique chargée de supprimer les plages d'adresses en attente de suppression envoyait une requête mal formée. L'interface interne a interprété cette requête comme « toutes les plages », et la tâche a commencé à les retirer une par une. Environ 1 100 plages ont disparu d'internet, soit à peu près un quart des 4 306 plages BYOIP. Les services de ces clients (sites, protection, transit réseau) ont cessé de répondre.
Le retour à la normale a pris un peu plus de six heures, jusqu'à 23 h 03 UTC. Certains clients ont pu rétablir leur service eux-mêmes depuis leur tableau de bord. Pour environ 300 plages, un second bug avait effacé la configuration : il a fallu que des ingénieurs la restaurent à la main. Le résolveur DNS public 1.1.1.1 a continué de fonctionner.
Ce que Cloudflare a promis de changer
- Des paramètres d'interface typés et validés, pour qu'une requête mal formée soit refusée au lieu d'être mal comprise.
- Une séparation entre l'état de fonctionnement interne et la configuration des clients.
- Un disjoncteur qui arrête un déploiement dès que des suppressions se produisent trop vite ou trop largement.
- La surveillance de la santé des services clients comme signal d'arrêt.
Ce sont des principes valables pour n'importe quel logiciel : valider les entrées, déployer par petites étapes, prévoir un arrêt d'urgence automatique. Ce n'est pas la première panne majeure de Cloudflare en quelques mois, et l'entreprise mène un chantier interne pour que chaque changement de configuration soit progressif et contrôlé.
Ce que ça change pour une PME
Vous n'utilisez peut-être pas Cloudflare directement. Mais votre hébergeur, votre outil de facturation, votre boutique en ligne ou votre messagerie s'appuient sur des prestataires comparables. Une panne chez l'un d'eux se traduit chez vous par un site injoignable, une boutique fermée, des commandes perdues ou une équipe à l'arrêt.
La concentration est un risque
Une grande partie d'internet repose sur une poignée d'acteurs. C'est efficace, et c'est aussi une fragilité. Quand l'un d'eux trébuche, des milliers d'entreprises sont touchées en même temps, et personne ne peut vous dépanner plus vite.
La vraie question : que se passe-t-il chez vous ?
Pour chaque service important, il y a trois questions : combien de temps pouvez-vous vous en passer ? Que faites-vous pendant ce temps ? Comment prévenez-vous vos clients ?
Six heures, c'est long et c'est court
Pour un site vitrine, six heures d'indisponibilité un vendredi soir passent presque inaperçues. Pour une boutique en ligne en pleine opération commerciale, un service de réservation ou un logiciel utilisé par vos équipes de terrain, c'est une journée de travail perdue. La même panne n'a pas le même coût selon l'activité, et c'est ce qui doit guider vos choix : inutile de payer une architecture redondante pour un site qui peut attendre, indispensable d'y réfléchir pour un service dont dépend votre chiffre d'affaires du jour.
Ce qu'on conseille de faire
- Lister vos services critiques : site, boutique, logiciel métier, messagerie, téléphonie. Pour chacun, noter le prestataire et ses propres dépendances connues.
- Fixer une durée acceptable d'interruption pour chacun. Une heure pour la boutique, une journée pour le site vitrine ? C'est une décision de dirigeant, pas une question technique.
- Prévoir un mode dégradé : une page d'information hébergée ailleurs, une procédure papier pour prendre les commandes, un message prêt pour vos clients.
- Exiger des sauvegardes que vous pouvez récupérer, chez un autre prestataire que l'hébergeur principal.
- Lire les rapports d'incident de vos prestataires. Un prestataire qui publie une analyse honnête, comme Cloudflare ici, est souvent plus fiable qu'un prestataire qui n'en publie jamais.
Les logiciels que nous livrons sont hébergés en France ou chez le client, avec une maintenance qui répond sous 24 heures ouvrées, et leur code source vous est remis : si un prestataire vous lâche, vous pouvez partir. C'est vrai pour un logiciel métier comme pour une boutique en ligne. Pour faire le point, prenez rendez-vous.
À relire sur le même sujet : Panne Cloudflare du 18 novembre : un fichier trop gros a mis des sites à terre.