Une panne de fournisseur de transit dégrade Cloudflare pendant près de trois heures en Amérique du Nord
Le 23 octobre 2026, de 15 h 47 à 18 h 43 UTC, une panne chez un fournisseur de connectivité a saturé les liens entre les centres de données Cloudflare d’Ashburn et d’Atlanta, dégradant des services sans lien direct avec ce fournisseur. Pour qui dépend d’un CDN ou d’un cloud, la leçon est nette : la redondance se vérifie, elle ne se suppose pas.
23 octobre 2026. Cloudflare commence à investiguer une dégradation de performance sur le trafic entre ses centres de données d’Ashburn et d’Atlanta. 16 h 07 UTC. L’équipe identifie une panne chez un fournisseur de connectivité et commence à rerouter le trafic loin des chemins touchés. 18 h 43 UTC. L’incident est déclaré résolu, après deux heures et cinquante-six minutes. Le point qui compte : un seul fournisseur de transit, jamais nommé, a suffi à dégrader des services qui n’avaient pourtant aucun lien direct avec lui — et la panne a récidivé après un premier correctif.
Ce qui s’est passé, minute par minute
La chronologie, telle que Cloudflare l’a publiée sur sa page de statut, tient en huit mises à jour. À 15 h 47 UTC, l’équipe ouvre l’incident : dégradation du trafic entre Ashburn et Atlanta, avec de la latence, des pertes de paquets et des erreurs intermittentes sur Workers et d’autres services dans l’est des États-Unis. À 16 h 07 UTC, le diagnostic tombe : panne chez un fournisseur de connectivité, qui provoque une congestion réseau. Le reroutage commence.
À 16 h 27 UTC, un correctif est appliqué et l’équipe passe en observation. À 17 h 03 UTC, la panne du fournisseur récidive, et Cloudflare reprend la gestion du trafic pour contourner les liens défaillants. À 18 h 18 UTC, le trafic est rerouté autour des chemins touchés et les pertes de paquets cessent ; le fournisseur annonce son service rétabli, mais certains liens reviennent encore, alors Cloudflare maintient ses modifications. À 18 h 43 UTC, l’incident est clos.
Pourquoi une panne de transit touche des sites sans rapport
Cloudflare n’est pas qu’un CDN. Il s’intercale entre de très nombreux sites et leurs visiteurs, et porte aussi le trafic des applications et des API de ses clients. Quand les chemins entre deux de ses centres de données se dégradent, le trafic qui les emprunte ralentit ou échoue — même quand les serveurs d’origine du client tournent parfaitement.
C’est le mécanisme clé de l’épisode. La panne initiale est chez un fournisseur de transit, l’un de ces opérateurs de gros qui interconnectent les réseaux entre eux. Quand ses liens entre Ashburn et Atlanta se saturent, Cloudflare ne « tombe » pas : il congestionne. Les utilisateurs finaux voient alors des erreurs sur des services qui n’ont aucun contrat direct avec le fournisseur fautif — la défaillance d’un maillon invisible du réseau se traduit, à l’arrivée, en sites qui ne répondent plus.
La récidive : le signal qu’on néglige
Le détail le plus instructif n’est pas la panne, mais sa récidive. À 16 h 27 UTC, un correctif est en place ; à 17 h 03 UTC, le fournisseur retombe en panne. Une première remédiation qui ne tient pas une heure est un signal fort : le problème n’était pas un incident ponctuel, mais un état instable du fournisseur, qu’il a fallu contourner plutôt que réparer.
Pour un opérateur, c’est la différence entre « redondance » et « reroutage ». Cloudflare n’a pas basculé sur un chemin de secours en une seconde : il a mis près de trois heures à stabiliser le trafic, en gardant ses changements en place même après l’annonce du rétablissement, parce que les liens revenaient par à-coups. La leçon est crue : un chemin alternatif ne sert à rien si personne ne l’a testé, et un fournisseur instable doit être écarté du plan de production, pas « surveillé de près ».
L’opacité d’un fournisseur non nommé
Autre point notable : Cloudflare n’a jamais nommé le fournisseur de connectivité en cause, et n’a publié ni le nombre de clients touchés ni le volume de requêtes échouées. C’est une discrétion habituelle dans l’industrie du transit — les contrats entre réseaux sont rarement publics — mais elle a un coût : les clients ne peuvent pas savoir si leur propre redondance reposait, sans le savoir, sur le maillon qui vient de céder.
Le même jour, Downdetector a enregistré des pics de signalement aux États-Unis pour Canva, ChatGPT, Reddit, Zoom, Microsoft 365, Discord et Cloudflare. Ces pics ne prouvent pas une cause commune, et rien ne relie officiellement ces services à l’incident Cloudflare. Mais la coïncidence horaire illustre un phénomène structurel : quand un grand intermédiaire congestionne, la plainte remonte partout à la fois, sans qu’aucun client ne puisse établir le lien.
Des fournisseurs de transit concentrés et silencieux
Le marché du transit est l’une des couches les plus concentrées de l’internet. Une poignée d’opérateurs de gros — les Tier 1 — interconnectent l’essentiel du trafic mondial, et leurs pannes, quand elles surviennent, ne font pas la une : elles se manifestent en latence, en pertes de paquets et en erreurs intermittentes que les clients attribuent à tort à leurs propres serveurs.
Cette concentration a une conséquence directe sur la redondance. Deux chemins qui « semblent » différents passent souvent par le même AS de transit quelques sauts plus loin, parce que les accords de peering et les coûts poussent les réseaux à se raccorder aux mêmes gros maillons. Vérifier la redondance ne consiste donc pas à cocher « j’ai deux fournisseurs » : il faut tracer les chemins jusqu’au bout et s’assurer qu’ils ne convergent pas vers le même point de défaillance.
Ce que ça apprend aux équipes
La surveillance du réseau se résume trop souvent à un ping vers son propre site. L’épisode montre qu’il faut regarder les chemins, pas seulement les destinations.
# Suivre le chemin réel et la perte par saut (Linux)
mtr -rwzbc 100 1.1.1.1
# Vérifier la diversité des chemins vers un service critique
traceroute -n api.exemple.comUn mtr qui affiche une perte concentrée sur un saut intermédiaire — le AS d’un fournisseur de transit, par exemple — dit plus qu’un simple « le site répond ». Il révèle sur quel maillon repose votre trafic. La question à se poser n’est pas « mon fournisseur est-il fiable ? » mais « qu’est-ce qui casse si son lien avec mon datacenter sature ? ».
Au-delà du chemin, il faut surveiller la table BGP. Une annonce retirée, un préfixe passé par un autre AS, un pic de changements de route sont souvent les premiers signes d’un incident de transit, avant même la perte de paquets. Les outils publics — RIPE RIS, les route-views, ou Cloudflare Radar pour les anomalies de routage — permettent de voir ce qui change sur les chemins qui vous concernent, sans attendre la page de statut d’un fournisseur.
Trois heures, c’est long à l’échelle d’un incident Cloudflare, et c’est précisément la durée qu’il a fallu pour contourner un maillon externe. Le chiffre rappelle une vérité d’ingénierie réseau : on ne « répare » pas un fournisseur tiers, on le contourne — et le contournement se prépare à froid, pas pendant l’incident.
Verdict
Si votre service dépend d’un CDN ou d’un cloud qui concentre votre trafic, ne confondez pas la disponibilité annoncée avec la redondance réelle : la panne du 23 octobre n’a pas coupé Cloudflare, elle l’a congestionné, et des sites parfaitement sains ont renvoyé des erreurs pendant près de trois heures. Si vous avez un plan de continuité, testez-le — un reroutage qui n’a jamais été exercé est un vœu, pas un plan. Et si votre redondance repose sur deux chemins qui traversent le même fournisseur de transit, vous n’avez pas de redondance : vous avez deux fois le même point de défaillance. Le réseau est plus centralisé qu’il n’y paraît, et la prochaine panne de transit ne préviendra pas non plus.