Accueil Câbles Emplacements Santé Recherches Guide
← Tous les articles
Câble

Quand le typhon Sinlaku a envoyé un câble de 200 km faire un détour de 12 000 km : anatomie d'un déroutage BGP pendant une tempête Cat 5

Peu après l'aube UTC le 14 avril 2026, notre supervision a détecté quelque chose qui ressemblait, à première vue, à une panne de câble sous-marin. Le temps aller-retour entre Saipan et Guam — deux îles séparées par environ 200 kilomètres d'eau pacifique — est passé de 8,35 ms à 109,98 ms. Un pic de latence d'un facteur 13 sur un câble dont le plancher physique n'est que de 2,6 ms, et cela au moment exact où le supertyphon Sinlaku de catégorie 5 traversait directement les îles Mariannes du Nord. L'hypothèse évidente était l'hypothèse évidente : la tempête avait rompu le câble.

Ce n'était pas le cas. Le câble allait très bien. Ce qui s'était cassé était plus subtil — et, d'une certaine manière, plus intéressant.

Le détour de 12 000 km

Le câble Mariana-Guam, mis en service en 1997 et exploité par PTI Pacifica, est le seul câble sous-marin qui relie le Commonwealth des Mariannes du Nord au reste du monde. Ses 268 kilomètres de fibre décrivent un arc court depuis Tanguisson Point, sur la côte nord-ouest de Guam, en passant par Rota, Tinian et Saipan, transportant chaque octet d'internet non satellitaire pour environ 55 500 personnes.

Notre sonde à Saipan — l'ancre RIPE Atlas 6923, hébergée chez l'opérateur de transit pacifique OneQode (AS140627) — mesurait le temps aller-retour toutes les trente minutes vers un point d'extrémité chez Guam Exchange (AS152735, préfixe 103.142.152.0/24). Voici la trace avant le basculement, capturée le 13 avril :

SautIPRéseauRTT
1192.168.1.1passerelle locale
210.170.7.1CGNAT
3–4103.57.234.xAS7131 PTI Pacifica (Guam)8,3 ms
5–710.25.37.22 / 202.88.72.119AS7131 PTI Pacifica8,3 ms
8103.142.152.109AS152735 Guam Exchange (cible)8,35 ms

Huit sauts. Six d'entre eux à l'intérieur du réseau de PTI Pacifica. De bout en bout : 8,35 millisecondes. C'est à peu près la physique de la lumière traversant deux fois 835 km de fibre optique — la signature attendue d'un trajet direct Saipan → Tanguisson → cible.

Voici la même mesure quatorze heures plus tard, après le passage de Sinlaku :

SautIPRéseauRTT
1103.151.64.30AS140627 OneQode (Guam)0,4 ms
2103.151.64.29AS140627 OneQode (Los Angeles)109,3 ms
3–662.115.x.xAS1299 Arelion (Los Angeles)109,5–110,0 ms
7–8103.57.233.22, 202.88.72.119AS7131 PTI Pacifica (Guam)110,0 ms
9103.142.152.109AS152735 Guam Exchange (cible)110,2 ms

Un saut supplémentaire. Mais un seul segment — de Guam à Los Angeles et retour dans le cœur de réseau d'OneQode — avait ajouté 109 millisecondes. Le paquet ne restait plus sur l'île. Il traversait le Pacifique, entrait dans le transit américain, passait à Arelion (AS1299), était ramené à travers le Pacifique, atterrissait de nouveau à Guam et ne remettait qu'ensuite le cap, via PTI, sur le câble Mariana-Guam pour la dernière étape vers la cible. Distance totale aller-retour, en termes de fibre : environ 12 000 kilomètres, pour ce qui aurait dû être un trajet de 200 km.

La révélation par l'asymétrie

Si le câble s'était rompu, les deux directions se seraient dégradées. Nous avons mesuré l'inverse — de Tanguisson Point à Guam vers Saipan — et la réponse a été sans ambiguïté :

DirectionSautsRTTChemin
Saipan → Tanguisson Point9110,2 msvia Los Angeles
Tanguisson Point → Saipan91,38 msdirect, sur l'arc insulaire

Guam-vers-Saipan empruntait le câble Mariana-Guam directement, exactement comme la veille. Le câble fonctionnait exactement comme prévu. L'anomalie n'existait que dans une seule direction, et seulement pour les clients d'un seul FAI. Ce n'était pas un dommage physique, c'était un changement de routage.

Ce que le typhon a vraiment fait

Le typhon Sinlaku a atteint l'intensité de catégorie 5 le 12 avril 2026 : le Joint Typhoon Warning Center a enregistré des vents soutenus d'environ 300 km/h (moyenne sur une minute) et l'Agence météorologique japonaise une pression centrale de 897 hPa. Par plusieurs métriques, c'était le cyclone tropical le plus puissant jamais enregistré aussi tôt dans l'année. Vers 14 h 30 UTC le 14 avril, son œil est passé directement au-dessus de Tinian et de Saipan.

Le vent à l'atterrissage avait faibli à environ 230 km/h — toujours catégorie 4. Saipan a enregistré des rafales soutenues de 209 km/h et 135 mm de précipitations en une journée. Environ 43 000 personnes dans le Commonwealth des Mariannes du Nord ont perdu l'électricité. Chaque élément d'infrastructure de télécommunications en surface — antennes cellulaires, liaisons micro-ondes, centrales électriques des stations d'atterrissage, équipements de peering dans les racks des FAI — a subi la même violence que les bâtiments qui les abritaient.

Voici maintenant ce que nos mesures montrent que le typhon n'a pas fait. Ce sont les cinq autres grands câbles sous-marins pacifiques que notre infrastructure surveille via des sondes ayant une visibilité sur la zone touchée :

CâbleRTT moyen avantRTT moyen aprèsRatio maxAlerte ?
SEA-US208,65 ms200,99 ms0,95Non
Pacific Crossing-1 (PC-1)125,55 ms134,12 ms1,00Non
Apricot90,93 ms101,31 ms1,01Non
FEA170,62 ms172,58 msNon
JUPITER259,50 ms189,64 ms0,96Non
Mariana-Guam Cable8,35 ms110,00 ms12,65Oui

Tous les autres câbles pacifiques dans la région touchée ont continué à fonctionner dans leur variance habituelle. Sinlaku, une tempête assez puissante pour faire tomber une part significative du bâti sur deux îles, n'a produit aucune dégradation mesurable dans cinq des six câbles visibles par nos sondes. L'ingénierie structurelle des stations d'atterrissage modernes — chambres de plage enterrées, bâtiments de front de mer renforcés, routes sous-marines profondes bien à l'abri des effets de tempête — a fonctionné comme prévu.

La synchronicité

Ce qui a cédé était hors de l'eau, et l'ordre chronologique compte. Trois observations RIPE Atlas fixent la chronologie :

Heure (UTC)Événement
2026-04-12 15:00Sinlaku atteint le pic cat. 5 (≈300 km/h, 897 hPa)
2026-04-13 15:00:12La sonde RIPE Atlas 65653 (Saipan, AS7131 PTI Pacifica, préfixe 8.3.112.0/20) passe hors ligne
2026-04-14 04:01:39Notre ancre 6923 (Saipan, AS140627 OneQode) enregistre sa première mesure à 110 ms — le chemin passe désormais par Los Angeles
2026-04-14 ≈14:30L'œil de la tempête passe directement sur Tinian et Saipan

La propre sonde de PTI Pacifica sur l'île a quitté le maillage RIPE Atlas 13 heures avant le basculement du chemin d'OneQode — premier signal de problème du côté de l'infrastructure de PTI à Saipan. Quand le forwarding d'OneQode a changé, PTI était déjà partiellement injoignable depuis le réseau Atlas depuis une demi-journée. L'œil de la tempête n'est arrivé que dix heures après le reroutage : les dégâts BGP ont précédé les vents les plus violents. Ce qui a provoqué les défaillances le 13 avril, ce sont les bandes périphériques du cyclone, le temps précurseur, et vraisemblablement la perte d'alimentation secteur pour tout équipement non adossé à un UPS robuste.

Ce que montre la table BGP publique

Nous avons consulté l'archive du RIPE Routing Information Service pour les deux préfixes concernés. Le RIS stocke les mises à jour BGP vues par un maillage mondial de collecteurs, et son enregistrement pour cette fenêtre est instructif :

PréfixeDétenteurMises à jour (13–15 avr)RetraitsAS d'origine
103.142.152.0/24Guam Exchange5243 le 13 avrilAS152735 (stable)
103.151.64.0/24OneQode2055 entre le 13 et le 15 avrilAS140627 (stable)

Aucun des deux préfixes n'a perdu son origine durant la fenêtre. Tous deux ont continué à être annoncés au reste d'internet normalement. Ce que le RIS a capté est bien plus modeste : de courts sursauts d'agitation des chemins intermédiaires et une poignée de brefs retraits venant de quelques pairs — la signature typique de sessions de peering isolées qui oscillent. Un lecteur non averti de la table BGP publique pour le 13–15 avril n'aurait rien vu d'inquiétant. Les deux réseaux, vus de l'extérieur, sont restés accessibles.

Et c'est précisément là le point. Le reroutage n'était pas un événement BGP mondial. C'en était un local — qui se jouait à la frontière entre deux FAI sur une seule île, invisible à la table de routage publique. OneQode avait perdu sa session de peering direct avec PTI Pacifica à Saipan. La route locale disparue, les routeurs d'OneQode se sont repliés sur leur deuxième meilleur chemin vers l'espace d'adresses de Guam : la route par défaut via leur transitaire Arelion, à Los Angeles. Les paquets arrivaient toujours à destination. Ils traversaient simplement le Pacifique deux fois pour y parvenir.

La topologie n'est pas la géographie

C'est une leçon que la plupart des ingénieurs réseau connaissent déjà, mais que chaque tempête remet au programme : la topologie d'internet est un graphe économique posé sur un graphe physique, et les deux n'ont pas à se ressembler. Un paquet allant de Saipan à Guam ne prend pas « le chemin le plus court » au sens métrique ; il prend le chemin que préfèrent à cet instant les politiques BGP des réseaux qu'il traverse. Ces politiques reflètent des contrats de peering, des factures de transit, des préférences de route et des centaines de petites décisions d'ingénierie prises il y a des années dans des salles silencieuses ailleurs. La plupart du temps, ces décisions se trouvent coïncider avec la géographie, parce que le peering le moins cher est en général le plus proche. Quand le peering le moins cher tombe, le second prend le relais, et parfois le second vit à 11 000 kilomètres.

Le Pacifique rend cela particulièrement net. L'internet d'une île n'est robuste qu'à la hauteur du nombre de relations de peering locales distinctes qu'entretiennent ses FAI. S'il n'existe qu'un seul peering entre les deux opérateurs principaux, passant par un seul équipement dans un seul bâtiment, alors n'importe quelle défaillance à ce niveau — un toit arraché, un générateur éteint, une liaison coupée — force un trombone transocéanique. Le câble sous-marin n'a jamais été le maillon faible. C'est même la partie de l'infrastructure la plus conçue pour supporter précisément le genre de tempête qu'a apporté Sinlaku.

L'alerte bloquée 33 heures

L'alerte 2026041403 de notre système s'est déclenchée à 05:01:55 UTC le 14 avril et est restée à l'état active/critical pendant 33 heures. Ce fut un vrai moment « bateau dans la bouteille » : l'événement pour lequel nous avions construit l'outil, capturé, et puis l'alerte bloquée. Nous avons déboguer le cycle de vie en direct et livré deux correctifs sur notre détecteur d'anomalies pendant que la tempête soufflait encore.

Le premier correctif visait une condition de gate subtile : notre logique de résolution automatique exigeait un aller-retour ping réussi pour sortir une alerte de l'état actif. Pour les cibles ICMP-bloquées — où la trace fonctionne mais le ping non — cette condition était inatteignable, et l'alerte ne se fermait jamais. Nous l'avons remplacée par COALESCE(ping_rtt_ms, trace_rtt_ms) : les preuves purement traces comptent désormais. Une alerte bloquée sans rapport (Batam–Sarawak) s'est auto-résolue à la passe suivante.

Le second correctif était spécifique à la signature Sinlaku. L'alerte capture le RTT de référence au moment de la détection et compare les mesures courantes à ce nombre figé. La ligne de base glissante, dans la table des health-check, s'adapte aux changements persistants en environ quinze heures : quinze heures après le basculement, elle était passée de 25 ms à 100 ms. Mais la ligne de base figée de l'alerte (25,57 ms) n'avait pas bougé. Le ratio courant / figé affichait toujours +330 % — sans moyen évident d'auto-clôture — alors même que, dans le nouveau régime, tout était parfaitement stable. Nous avons ajouté un contrôle de bascule de baseline : si l'alerte a plus de 24 heures, que la mesure courante est à moins de 20 % de la ligne glissante, et que cette ligne glissante est elle-même à au moins 1,5× la figée, nous rétrogradons de critical à monitoring et journalisons le ratio de dérive. L'alerte 74 a été rétrogradée proprement, dérive 3,95.

La leçon de fond : la détection d'anomalies doit distinguer deux modes de défaillance différents — un câble se rompt et la latence reste élevée jusqu'à la réparation physique ; ou un déplacement topologique établit une nouvelle norme que la supervision doit reconnaître. Nous écrivions du code en supposant qu'il n'existait que le premier mode. Sinlaku nous a fourni le second.

Ce qu'enseignent les îles

Dans les jours qui ont suivi la tempête, à chaque demi-heure pour laquelle notre infrastructure a des données, la nouvelle norme de 110 ms pour Saipan → Guam tient bon. La sonde de PTI Pacifica reste hors ligne. OneQode continue de router par Los Angeles. Savoir si cela redeviendra un peering local la semaine prochaine, le mois prochain, ou jamais, dépend de la rapidité avec laquelle l'infrastructure au sol d'une petite île du Pacifique pourra être reconstruite — et de savoir si quelqu'un, parmi les acteurs concernés, décidera que la topologie à peering unique était elle-même le problème à corriger.

Le câble est toujours là. Son aller-retour le plus rapide reste 8,35 ms. Dans le sens où Guam émet vers Saipan, c'est toujours ce que voient nos mesures. Dans le sens où Saipan émet vers Guam, chez un FAI précis, le chiffre est pour l'instant 110 ms. Deux îles, à 200 kilomètres l'une de l'autre, un câble sous-marin entre elles — et, pour quelques millions de paquets par seconde, dans une seule direction, un détour de 12 000 kilomètres auquel aucun d'eux ne s'était inscrit.

Nos sondes continuent de regarder.


Les données de cet article viennent de nos propres mesures RIPE Atlas (ancre 6923 et sonde 65653 à Saipan), des observations cable_health_checks de nos sondes à Minsk, Tbilissi, Jérusalem, Sébastopol et Almaty, et de l'archive publique RIPE Routing Information Service pour les mises à jour BGP des préfixes 103.142.152.0/24 et 103.151.64.0/24. Les chiffres de trajectoire du cyclone proviennent des bulletins JTWC et JMA. Consultez le dossier sur le câble Mariana-Guam ou ouvrez le calculateur de route pour voir la latence en direct entre deux villes.

Evgeny K.
Auteur
Evgeny K.
Ingénieur infrastructure · Fondateur de GeoCables
A créé GeoCables pour surveiller les câbles sous-marins en temps réel. Exploite un réseau privé de 4 serveurs de mesure avec des sondes RIPE Atlas à Minsk, Almaty, Tbilissi et Jérusalem.

🌐 Log In

Access your routes, favorites, and API key

Create account Forgot password?