AltiTrak
l'analytique du trail, avec le dénivelé en premier

Un monorepo avec un front React et un back FastAPI en quatre couches, où le domaine est fait de fonctions pures sans aucun import externe : indicateurs de qualité des données, segmentation des montées, vitesse verticale en montée et en descente, temps par 100 m, part course/marche, un indice de « descente destructrice ». Les points de trace vivent dans une hypertable TimescaleDB avec une colonne géométrique PostGIS, une seule instance pour les séries temporelles et la géographie, décision consignée dans un ADR, préférée à une seconde base.

Par-dessus : une charge d'entraînement qui pondère chaque séance par son dénivelé (D+ et D− ne comptent pas pareil), un double graphique de gestion de la performance (global avec le vélo en entraînement croisé, trail seul sans), des alertes hebdomadaires, et le score « toi vs la course » : distance et dénivelé d'une course face aux quatre dernières semaines de volume, de grimpe, de sorties longues et d'exposition à la descente, rendus en préparation de 0 à 100 avec trois forces, trois manques et trois actions. Un serveur MCP tourne dans le même processus pour qu'un assistant interroge les données. La CI enchaîne lint, audits, tests unitaires et environ deux cents tests Playwright de bout en bout, smoke à chaque déploiement et suite complète chaque nuit.

Que la première version du modèle de charge surestimait la fatigue de deux à quatre fois (fenêtre de chauffe absente, facteur terrain appliqué à la mauvaise entrée), et que se comparer à un outil établi est la façon de s'en apercevoir. Qu'une application doit fonctionner avec seulement un type, une date et une durée, et considérer tout le reste comme optionnel. Et qu'un monolithe aux fonctions de domaine pures est un bon endroit où être ; la réécriture en microservices qui a suivi m'a appris le prix de l'alternative.