Au début, je pensais naturellement en termes d'un trader, un compte. Puis la réalité du trading m'a rapidement rattrapé.
Beaucoup de traders n'ont pas un seul compte. Ils peuvent avoir un compte personnel. Un compte de simulation. Plusieurs comptes de prop firm. Parfois plusieurs plateformes. Et parfois les mêmes stratégies sont utilisées sur différents comptes.
À partir de là, LowFlow devait être capable de suivre tout ça sans mélanger les données.
Le compte devient une dimension importante du journal
Deux trades identiques sur le même instrument ne sont pas nécessairement le même trade. Ils peuvent appartenir à deux comptes différents. Ils peuvent avoir des tailles différentes. Des commissions différentes. Des objectifs différents.
Alors le compte doit rester attaché à chaque transaction. Et le trader doit pouvoir choisir ce qu'il veut regarder. Un seul compte. Plusieurs comptes. Ou l'ensemble.
Le danger, c'est de tout fusionner trop tôt
C'est un problème que j'ai rencontré plusieurs fois pendant le développement. Quand une donnée sert à plusieurs choses, il devient facile de lui donner trop de responsabilités. Puis un jour, une règle change et tout devient difficile à démêler.
Alors j'ai appris à garder les rôles séparés. Le compte dit à qui appartient le trade. Le trade conserve son identité. Les statistiques utilisent ensuite le filtre choisi. Mais aucune de ces couches ne doit réinventer les autres.
Comparer sans modifier les données originales
Le trader peut vouloir savoir : quel compte a été le plus actif? Comment un setup se comporte-t-il sur deux comptes? Combien de trades ont été pris au total? Ou simplement cacher un compte qui ne l'intéresse plus.
Le journal peut afficher plusieurs vues différentes sans changer ce qui a réellement été enregistré. Et ça rejoint encore le même principe : les données restent les données. La vue est un choix.
Plusieurs comptes, plusieurs plateformes, mais une seule mémoire
C'est là que la structure commence vraiment à devenir intéressante. Un trader peut utiliser NinjaTrader pour un compte. Sierra Chart pour un autre. Importer un ancien historique par CSV. Ajouter des captures.
Et malgré toutes ces sources différentes, LowFlow doit pouvoir reconstruire un historique cohérent. Pas parce que toutes les plateformes fonctionnent pareil. Mais parce qu'à la fin, le trader doit pouvoir retrouver ses propres trades, peu importe d'où ils viennent.
C'est une des différences entre un prototype et un produit
Un prototype fonctionne parfaitement dans le scénario pour lequel on l'a construit. Un produit doit continuer à fonctionner quand les utilisateurs commencent à l'utiliser d'une façon que le développeur n'avait pas imaginée au premier jour.
C'est pour ça que LowFlow est devenu progressivement plus modulaire. Pas pour ajouter de la complexité. Pour pouvoir accepter la réalité du trader sans lui demander de s'adapter au logiciel.