E. Leveque
ENThème : système
← Retour au parcours (P3 · km 58,2)

Zotracker

Le suivi GPS en direct d'une course à pied : mes proches me suivent sur une carte, sans rien installer.

Une course simulée sur le tracé officiel du Grand Trail d'Auvergne.

Le problème

Zotracker est né pour le marathon de Lille : mes parents, ma famille et mes amis voulaient me suivre en direct. Il fonctionne dans le navigateur, sans appli à installer, et je compte le réutiliser sur d'autres courses.

Les décisions

Des fichiers JSON plutôt qu'une base de données

Compromis : Aucun service à lancer ni à sauvegarder. Contrepartie : les écritures sur disque sont à ma charge. J'ai déjà ajouté un nouvel essai en cas d'échec et un refus de démarrer si le fichier est corrompu.

Un front en JavaScript natif, sans bundler

Compromis : Aucune étape de build. Contrepartie : du code dupliqué entre serveur et navigateur. Les statistiques sont calculées deux fois, et les deux résultats divergent déjà sur l'heure d'arrivée estimée avant le départ.

Distance calculée sur le tracé GPX

Compromis : La distance suit le parcours officiel, sans le zigzag du GPS. Les points à plus de 100 m sont ignorés, et un écart de plus de 150 m affiche « hors parcours ». Sans fichier GPX, le serveur retombe sur les points bruts, moins précis.

L'architecture

Architecture de ZotrackerLe GPS du téléphone du coureur, qui peut se couper quand l'écran se verrouille, envoie la position au serveur Node.js avec une clé traceur. Le serveur la projette sur le tracé GPX, calcule l'allure et les heures de passage, puis diffuse en temps réel la page publique et l'administration, déclenche les alertes par Web Push et ntfy, et enregistre l'état dans des fichiers JSON. Une simulation optionnelle réinjecte un coureur virtuel dans le même flux.GPS du téléphonenavigateur ou applicoupé si l'écranse verrouilleSimulationcoureur virtueloptionnelleServeur Node.jsprojette la positionsur le tracé GPX,calcule allure etheures de passagePage publique et adminsuivi en directAlertesWeb Push, ntfy (SOS privés)state.json, secrets.jsonstockage en fichiers JSONclé traceurtemps réel (SSE)Architecture de ZotrackerLe GPS du téléphone, qui peut se couper quand l'écran se verrouille, envoie la position au serveur Node.js, qui la projette sur le tracé GPX puis alimente la page publique et l'administration en temps réel, les alertes Web Push et ntfy, et des fichiers JSON. Une simulation optionnelle réinjecte un coureur virtuel dans le serveur.GPS du téléphonenavigateur ou applicoupé si l'écran se verrouilleclé traceurServeur Node.jsprojette sur le tracé GPX,allure et heures de passagePage publique et admintemps réel (SSE)AlertesWeb Push, ntfy (SOS privés)state.json, secrets.jsonstockage en fichiers JSONSimulationcoureur virtuel, optionnelle
Un trait plein : appel systématique. Pointillé : optionnel. Orange : le maillon fragile le jour de la course, le GPS du téléphone.

Le mur du 60e km

Le jour de la course, tout peut lâcher : le réseau se coupe, le GPS du navigateur s'éteint quand l'écran se verrouille (sur iPhone), les alertes de sécurité doivent partir quand même. Les points sont mis en attente quand le réseau tombe ; le reste de cette fiabilité est encore à construire.

Ce que j'en retire

Une appli utilisée le jour J ne se juge pas à sa démo : elle se juge au pire moment de la course. D'où le mode simulation, pour tester sans courir.