Globe Satellites

Le projet

Plusieurs milliers de satellites actifs tournent au-dessus de nos têtes, et leurs orbites sont publiques. Celestrak diffuse les éléments orbitaux au format TLE (Two-Line Element), qui suffisent à calculer la position de n'importe quel objet à n'importe quel instant.

Globe Satellites affiche ce ballet sur un globe 3D, actualisé toutes les soixante secondes.

Fonctionnalités

• Filtrage par catégorie — starlink, oneweb, communication, navigation, station, météo, observation terrestre, science, autres — cliquables dans le HUD, avec boutons « Tout afficher » / « Tout cacher »
• Tooltip au survol — nom, altitude et catégorie de chaque satellite
• Échelle radiale logarithmique — sépare visiblement les orbites basses, moyennes et géostationnaires plutôt que de les superposer
• Reconnexion automatique du WebSocket (backoff exponentiel), avec un watchdog qui détecte une connexion figée sans fermeture TCP propre

Calcul côté serveur

Le choix structurant est de calculer côté serveur. La propagation orbitale SGP4 pour plusieurs milliers d'objets, une fois par minute, n'est pas un travail pour le navigateur — d'autant que tous les clients connectés partagent exactement le même résultat. Le serveur calcule une fois (SatrecArray + NumPy, un seul appel vectorisé plutôt qu'une boucle Python — environ 24x plus rapide), diffuse à tout le monde par WebSocket en parallèle, et le client ne fait que du rendu.

Résilience réseau

Les TLE se dégradent en précision au fil des jours — une propagation sur des éléments vieux d'une semaine dérive sensiblement — d'où un rafraîchissement automatique toutes les deux heures. Le chargement suit une chaîne à trois niveaux : le groupe complet Celestrak en premier, un repli sur 37 groupes téléchargés en parallèle si celui-ci échoue ou renvoie un 403, puis un proxy de secours si les deux échouent — signe d'un blocage réseau plutôt que d'un incident isolé. Le retour au direct se fait seul, sans action manuelle. L'état de fraîcheur des données est exposé par un endpoint /health, qui pousse une supervision Vigie best-effort sur le cycle de rafraîchissement.

Contrainte matérielle

Le projet est pensé pour un Raspberry Pi 4 en ARM64. Cette contrainte a orienté plusieurs décisions : image Docker multi-architecture, calculs vectorisés avec NumPy plutôt qu'en boucle Python, un unique InstancedMesh Three.js plutôt qu'un objet par satellite, et diffusion d'un état partagé unique plutôt que d'un calcul par client connecté.