Telstra : une horloge GPS qui a cru être en 2006 a paralysé tout le réseau
En bref
- En juillet 2026, un récepteur GPS en maintenance redémarrage a cru que l'année était 2006, propageant cette fausse heure à tout le réseau mobile australien.
- Le bug vient d'un débordement du compteur de semaines GPS (cycle de 1024 semaines), qui n'avait pas de mécanisme de secours fiable.
- Le réseau Telstra s'est alors auto-jammerisé : les cellules TDD ne pouvaient plus se synchroniser correctement, paralysant les appels, SMS, trains, terminaux de paiement et bornes de recharge.
- Le rapport d'audit révèle une architecture de temps fragile : une seule horloge de référence est devenue critique après des années de simplifications locales successives.
Ce que dit la source
Telstra a subi une panne majeure le 8 juillet 2026 affectant voix, SMS, appels d'urgence et systèmes connexes (transports, paiements, recharge électrique). Un récepteur GPS en Melbourne, revenu de maintenance, s'est figé à l'année 2006 et a convaincu le reste du réseau que c'était la vraie heure. Aucune attaque, aucune rupture physique : juste une erreur de configuration de référence temporelle qui a propagé une cascade de défaillances.
- Les réseaux 5G modernes utilisent TDD (Time Division Duplex) : un seul bloc de spectre alterne entre émission et réception, exigeant une synchronisation précise entre cellules. Sans elle, chaque cellule transmet dans la fenêtre de réception voisine, le réseau s'auto-jamme.
- Le compteur de semaines GPS utilise seulement 1024 semaines (19,6 ans environ), et redémarrage après maintenance ne déclenche pas une recalibration fiable auprès d'autres sources si le firmware utilise une date codée en dur comme référence.
- L'architecture Telstra (design 2010) avait NMI comme stratum 1 externe, deux serveurs stratum 2 (Sydney, Melbourne), trois stratum 3 (Sydney, Melbourne, Perth), puis les milliers de nœuds clients. Après des années de dépannage local, une seule horloge GPS est devenue le point d'appui critique, sans redondance réelle.
- NTP dispose de deux défenses contre les mauvaises sources : le poids du stratum (plus bas gagne) et la comparaison multi-source (une source isolée aberrante est écartée). Toutes deux ont échoué ici : la source défaillante s'est présentée avec assez d'autorité et d'autres n'ont pas pu la surcharger assez vite.
- L'audit TAP qualifie l'architecte originelle de 2010 de 'fit for purpose', mais les modifications successives ont érodé cette redondance sans révision globale.
Dans les commentaires
Débat plutôt technique et factuel, sans consensus fort. Plusieurs commentateurs soulignent le flou dans la rédaction (confusion stratum/hiérarchie), d'autres cherchent le rapport complet. Un point récurrent : l'ironie qu'un problème d'architecture critique soit résolu avec une seule horloge GPS supplémentaire au lieu d'une véritable redondance.
- Plusieurs commentateurs critiquent la clarté : confusion entre stratum haut/bas comme hiérarchie, et absence de lien explicite vers le rapport d'audit TAP complet (fourni en lien en commentaires).
- Un commentateur conteste que le TDD en réseaux cellulaires dépend vraiment de NTP : la synchronisation fine entre cellules (quelques millionths de seconde) ne s'aligne pas sur la précision réaliste de NTP sur un réseau large, ce qui suggère une sous-couche propriétaire ou plus proche de la physique radio.
- Anecdote : un sysadmin partage une histoire similaire sur timezone (CDT au lieu d'UTC), montrant que les erreurs de temps ne sont pas isolées à Telstra, mais révèlent plutôt une absence de test/validation lors des changements. Le fil reste court et léger sur les implications : peu de creusement sur la résilience des autres critères d'infrastructure (trains, paiements).
Notre lecture
La panne Telstra illustre un paradoxe récurrent en infrastruture critique : une défense bien pensée (NTP avec redondance NMI) se dégrade progressivement en solution du jour, jusqu'à ne plus en être une. Le bug GPS lui-même (débordement semaine + refonte firmware) est connu, mais c'est surtout l'absence de test de ce scénario spécifique et l'érosion de la redondance qui créent la vulnérabilité. Pour les équipes de réseau ou infra cloud : intéressant à surveiller. Les points clés à retenir ne sont pas révolutionnaires (redondance géographique, test des changements de configuration critiques, validation multi-source de la référence), mais la panne montre combien souvent ils sont ignorés en pratique. Pas d'action immédiate requise si vos systèmes critiques ont déjà plusieurs sources de temps indépendantes ; à examiner si vous reposez sur une seule horloge ou un seul fournisseur.