CLOUDFLARE

Le choix automatique et la liste des algorithmes autorisés relèvent désormais de commandes distinctes. Les procédures de retour arrière doivent suivre cette séparation.

Cloudflare indique que certains clients ont pu rencontrer des erreurs 5xx et des délais d’attente entre des serveurs d’origine en Amérique du Nord et son centre de données de Singapour, de 01 h 06 à 01 h 54 UTC le 23 août. L’incident est clos, mais le récit public précis a été publié après la fin de cette plage.

Cloudflare a annoncé un correctif huit minutes et 36 secondes après l'ouverture d'un incident de performance réseau en Asie-Pacifique. Mais l'avis est resté en surveillance, sans ville, produit, symptôme ni population affectée : l'étiquette régionale ne peut donc pas servir de dénominateur.

Deux incidents Workers, clos le 4 août, ont rompu deux promesses différentes. Dans le moteur d’exécution, un objet `Temporal` apparu sans être prévu donnait l’heure du 1er janvier 1970. Dans le plan de déploiement, une assertion refusait une combinaison récente de date de compatibilité et de drapeau `nodejs_compat`. Cloudflare n’a pas relié les causes. Leur proximité montre néanmoins qu’une plateforme doit vérifier la sémantique qu’elle expose aussi rigoureusement que les configurations qu’elle accepte.

Le 3 août, Cloudflare a suivi pendant une heure et 51 minutes un incident touchant Workers Builds. Sa chronologie évite un raccourci fréquent : à 15 h 38 UTC, les builds ne se terminaient plus en échec, mais des retards pouvaient encore affecter les utilisateurs. La disparition d’une erreur n’est donc pas la preuve que la file d’attente a retrouvé son débit normal. Faute de cause, de volumes et de mesure de l’exécution en production, l’événement doit être lu comme un problème circonscrit à la chaîne de changement, et non comme une panne mondiale de Workers.

Cloudflare a clos après 2 heures 17 minutes et 50 secondes un incident touchant l’accès à Internet public de clients utilisant des adresses IPv4 de sortie dédiées rattachées à Londres. Le journal public distingue cinq étapes : enquête, identification, mise en œuvre d’un correctif, surveillance, puis résolution. Cette précision rend possible une lecture rigoureuse de la reprise. Elle ne fournit toutefois ni cause, ni volume de trafic, ni nombre de clients, ni preuve que chaque parcours client a récupéré au même instant.

Le 27 juin 2024, deux événements de routage distincts ont affecté l’accès à l’adresse 1.1.1.1 de Cloudflare : l’annonce d’un préfixe très spécifique par AS267613 et la fuite séparée d’un préfixe plus large par AS262504 via AS1031. Leur analyse montre pourquoi les registres, les ROA et les collecteurs de routes sont indispensables sans suffire à protéger le trafic. La responsabilité dépend surtout des acteurs capables d’autoriser une origine, de filtrer l’export d’un client, d’accepter une route, de déclencher un blackhole, de surveiller la propagation et de vérifier le retrait effectif d’une annonce erronée.

Le 22 janvier 2026, la suppression d’une contrainte devenue obsolète a laissé subsister une règle d’acceptation plus générale dans une politique BGP générée. L’incident montre pourquoi la syntaxe valide, l’intention du code source et l’autorisation d’origine RPKI ne suffisent pas à prouver qu’une route peut légitimement être exportée à un voisin donné.

Lorsqu’un opérateur annonce l’espace d’adressage de ses clients, l’autorisation administrative ne suffit pas à établir la disponibilité réelle. L’incident BYOIP du 20 février 2026 montre pourquoi la responsabilité doit relier les droits sur les préfixes, les objets IRR, les ROA, les services associés, l’intention d’annonce, la configuration effectivement déployée et l’observation externe des routes.

La campagne de mars 2013 a montré comment la récursion DNS exposée, l’usurpation d’adresses source et les chemins d’interconnexion partagés pouvaient transformer des défauts de configuration dispersés en un coût collectif massif. La responsabilité se mesure en identifiant le contrôle détenu par chaque opérateur, les preuves disponibles et l’efficacité réelle des réparations.

Cloudflare a ouvert le 31 juillet à 11 h 51 min 07 s UTC un incident mineur touchant d’abord Analytics, le Dashboard et des API associées. Les répercussions ont ensuite été étendues aux compilations Pages et Workers. Un correctif est passé en surveillance à 12 h 43 min 57 s, avant une résolution à 13 h 01 min 59 s. Cloudflare a précisé que la distribution des fichiers en cache par son CDN et les autres fonctions de sécurité en périphérie n’étaient pas affectées. L’incident a donc touché la capacité d’administrer et de livrer des changements, pas l’ensemble du réseau.