Au début d'un journal, quelques dizaines de trades ne posent aucun problème. On peut presque tout regarder manuellement.
Puis les semaines passent. Les mois. Les comptes s'ajoutent. Les captures s'accumulent. Les imports deviennent plus nombreux. Et soudain, ce qui fonctionnait parfaitement avec 50 trades doit fonctionner avec 5 000.
C'est là qu'un autre type de problème apparaît.
Construire pour aujourd'hui est facile
Construire pour l'historique est différent. Un journal peut sembler rapide et propre lorsqu'il contient peu de données. Mais ce n'est pas une vraie preuve.
Le vrai test arrive quand on commence à demander : affiche-moi seulement ce compte; seulement cette période; seulement ce setup; compare ces mois; retrouve ce trade; charge les images; recalcule les statistiques. Et fais-le sans ralentir tout le reste.
Les données doivent pouvoir grandir sans devenir un désordre
C'est aussi là que les décisions de structure deviennent importantes. Un trade doit avoir une identité claire. Un compte doit avoir une identité claire. Une capture doit pouvoir être rattachée au bon trade. Une donnée importée ne doit pas créer une deuxième copie d'un trade qui existe déjà.
Chaque détail paraît petit lorsqu'on le construit. Mais quand l'historique grossit, les petites ambiguïtés deviennent de gros problèmes.
J'ai justement rencontré ce problème avec les doublons
Quand plusieurs sources peuvent alimenter le journal, deux fichiers différents peuvent parfois représenter le même événement réel d'une façon différente. Un add-on peut écrire un trade. Un CSV peut contenir les exécutions qui composent ce même trade. Si le journal traite les deux comme deux opérations différentes, les résultats deviennent faux.
Alors j'ai dû travailler sur une logique beaucoup plus prudente. Détecter ce qui semble être un doublon. Comparer les informations. Mais surtout : ne jamais supprimer automatiquement quelque chose simplement parce que le système pense que c'est identique. Le trader doit pouvoir vérifier.
Cette philosophie apparaît même dans le code : la détection reste volontairement conservatrice et retourne les groupes pour revue humaine plutôt que de décider seule quoi supprimer.
Parce qu'une donnée fausse peut être pire qu'une donnée manquante
Si un journal affiche deux fois le même trade, toutes les statistiques après deviennent contaminées. P&L. Win rate. Nombre de trades. Moyennes. Séries. Tout.
Alors la qualité de l'historique est devenue aussi importante que son volume.
Et c'est là que je me suis rendu compte d'une chose
Faire fonctionner un journal pour une semaine est une étape. Le faire fonctionner pour plusieurs années en est une autre.
Je ne voulais pas que LowFlow devienne moins utile à mesure que le trader accumule de l'expérience. Ça devrait être exactement l'inverse. Plus l'historique grandit, plus il devrait devenir intéressant.