Au début, LowFlow était encore simple.
Il fallait surtout réussir une chose : transformer l'idée du journal en quelque chose d'assez pratique pour être utilisé réellement. Pas une maquette. Pas une démonstration. Un outil dans lequel on pouvait entrer une journée de trading, revenir dessus et commencer à apprendre de ses propres données.
Le premier objectif : arrêter de perdre le contexte
Un trade, pris tout seul, ne raconte presque rien. Une entrée. Une sortie. Un profit ou une perte. Mais autour de ce trade, il y a beaucoup plus. Le plan avant la séance. La raison de l'entrée. Le setup. L'état d'esprit. La qualité de l'exécution. La capture du graphique. Les notes prises après le trade. Et parfois, plusieurs jours plus tard, le trader veut comprendre pourquoi cette décision semblait bonne à ce moment-là.
Le prototype a donc commencé à accumuler ces morceaux. Trades. Notes. Plans. Statistiques. Captures. Analyses. Replay. À chaque nouvelle fonction, le journal devenait un peu moins un simple registre et un peu plus un environnement de travail.
Le journal devait raconter la journée
Une des idées importantes était de pouvoir revoir une séance comme un ensemble. Pas seulement une suite de transactions. Dans LowFlow, le trader peut préparer son pre-market plan, puis retrouver ce plan directement dans sa journée de trading. À côté, il voit ensuite ce qui s'est réellement produit : son P&L, son win rate, son profit factor, son expectancy, son drawdown, ses trades, ses setups, ses notes.
Le plan ne disparaît donc pas une fois le marché ouvert. Il reste attaché à la journée. Le trader peut comparer ce qu'il avait prévu avec ce qu'il a réellement exécuté. C'est là que le journal commence à devenir utile.
Les captures deviennent une partie de l'analyse
Les images ont rapidement pris une place importante. Le trader peut déposer une capture par drag and drop ou l'importer directement dans le journal. Mais je ne voulais pas qu'elle reste une simple pièce jointe. Il peut ensuite la modifier, ajouter du texte, marquer ce qu'il regardait, documenter une entrée ou une sortie et conserver cette image avec le reste du contexte du trade.
Une capture devient donc une partie de la mémoire du trade. Quelques semaines plus tard, il ne voit pas seulement un résultat. Il peut revoir ce qu'il voyait réellement sur le marché.
Les statistiques, mais pas imposées
Un autre choix est apparu très tôt. Beaucoup de systèmes calculent tout sur l'ensemble des comptes. Je ne voulais pas ça. Le trader devait pouvoir décider quels comptes entraient dans ses calculs.
Le panneau de gauche est donc devenu beaucoup plus qu'un menu. Il contrôle le contexte actif du journal. Le trader sélectionne les comptes qu'il veut analyser et les statistiques se construisent autour de cette sélection. S'il veut seulement regarder deux comptes funded, il peut. S'il veut comparer un groupe précis, il peut. S'il veut tout inclure, il peut aussi.
Encore une fois : Trader Choisit.
Un peu de personnalité aussi
Je ne voulais pas construire uniquement des tableaux gris remplis de chiffres. Le journal devait avoir une identité. C'est là qu'ont commencé à apparaître les petits détails visuels : les statistiques qui défilent, les vues plus graphiques, les panneaux qui peuvent disparaître pour libérer l'espace et le mode privé avec son écran animé.
Ce ne sont pas les fonctions les plus importantes techniquement. Mais elles participent à une chose essentielle : donner envie d'utiliser le journal. Un outil qu'on utilise tous les jours doit être agréable à ouvrir.
Puis le prototype a commencé à devenir trop sérieux
C'est probablement le moment où le projet a changé de nature. Au début, ajouter une fonction signifiait simplement modifier le journal. Puis les fonctions ont commencé à dépendre les unes des autres. Les captures prenaient de la place. Les données s'accumulaient. Le replay demandait davantage d'historique. Les comptes devaient être organisés. Les paramètres commençaient à devenir importants. Et le journal devait conserver tout cela sans devenir lourd ou instable.
Le prototype fonctionnait. Mais il commençait à dépasser ce qu'un simple projet HTML pouvait gérer confortablement. Il fallait maintenant lui donner une vraie structure d'application. C'est là que Tauri est entré dans l'histoire.
Et c'est là aussi que j'ai découvert qu'un logiciel léger pouvait devenir très lourd très rapidement si on ne décidait pas correctement où vivent ses données. Cette partie m'a coûté beaucoup plus de temps que prévu. Elle fera l'objet du prochain épisode.