F1 Pitwall transforme une course en interface d’analyse.

Comprendre une course demande de relier des informations qui évoluent à des rythmes différents : position en piste, écarts, arrêts, pneus, météo, incidents, messages de direction de course et télémétrie. Une donnée isolée explique rarement une décision. C’est leur alignement temporel qui permet de reconstruire le contexte.

F1 Pitwall part donc d’un problème produit réel : permettre à une personne de naviguer dans une session comme dans un outil d’analyste, sans ouvrir plusieurs sources ni perdre le moment exact auquel un événement s’est produit.

Le timing tower constitue le point d’entrée. Il affiche le classement, les écarts et les composés, puis ouvre une vue pilote plus détaillée. Le replay fait avancer les données selon une horloge commune ; la carte, la météo, les messages et les graphiques doivent rester synchronisés lorsque l’utilisateur met en pause ou change de position.

L’application comporte aussi des vues consacrées à la stratégie pneus, à la comparaison de télémétrie et à l’analyse après course. Les radios peuvent être transcrites localement afin d’explorer leur contenu sans envoyer l’audio à un service distant.

Le backend Python prépare les sessions et expose les données à l’interface React. Les données historiques peuvent venir de FastF1 et certaines informations temps réel ou événementielles d’OpenF1. Chaque source possède sa propre granularité et ses propres limites ; l’application doit donc conserver la provenance et gérer explicitement les informations absentes.

Le replay repose sur des événements ordonnés et un état dérivé. Cette architecture ressemble à celle d’un outil opérationnel : plusieurs systèmes alimentent un même dossier, l’interface doit rester réactive, et une erreur d’une source ne doit pas rendre toute l’expérience inutilisable.

Le résultat observable est une application fonctionnelle capable de charger une session, de la rejouer et de mettre en relation des vues fortement dépendantes du temps. La capture présentée sur cette page vient du produit exécuté localement, pas d’une maquette.

Ce projet n’apporte pas une preuve de gain financier chez un client. Il apporte une preuve technique et produit : je peux transformer des données complexes en outil de décision, construire un backend d’ingestion, orchestrer du temps réel et concevoir une interface dense sans sacrifier la hiérarchie de l’information.

Dans une entreprise, les flux peuvent être des commandes, interventions, dossiers, capteurs ou événements logistiques plutôt que des tours de piste. Le même besoin demeure : consolider, historiser, détecter les écarts et donner à l’utilisateur la prochaine information utile.

La valeur du projet réside donc moins dans son thème que dans son architecture : une source de vérité, des événements synchronisés, des vues spécialisées et la possibilité d’expliquer comment un état a été obtenu.