Au départ, je voulais quelque chose de simple.
Une application locale.
Le trader installe LowFlow sur son ordinateur, ses données restent chez lui et l'application fait son travail sans avoir besoin d'envoyer toute sa vie de trading quelque part dans le cloud.
C'était toujours la philosophie. Et ça l'est encore aujourd'hui.
Mais plus LowFlow avançait, plus le projet devenait sérieux. Et un problème auquel je n'avais pas vraiment pensé au début a fini par apparaître.
Comment faire fonctionner une application locale comme un véritable produit commercial?
Je voulais rester local
Je n'avais aucune envie de transformer LowFlow en SaaS.
Je ne voulais pas que les trades du client doivent être envoyés sur mes serveurs pour que son journal fonctionne. Je ne voulais pas non plus que ses photos, ses historiques ou les données nécessaires à son replay dépendent d'un cloud.
Le principe était simple : le trader garde ses données. Ses trades restent sur sa machine. Ses captures restent sur sa machine. Ses historiques restent sur sa machine. Ses données de replay restent sur sa machine. Même ses sauvegardes peuvent rester sous son contrôle.
C'était une décision importante. Et je ne voulais pas la changer simplement parce que LowFlow devenait commercial.
Mais le projet avait changé
Le problème venait d'ailleurs.
Une application que je développe pour moi-même peut fonctionner d'une certaine façon. Une application que je veux distribuer à des clients doit gérer beaucoup plus de choses.
Il faut pouvoir identifier une installation. Gérer les licences. Savoir quelle version du logiciel est utilisée. Permettre les mises à jour. Gérer les comptes. Contrôler les accès. Distribuer les nouvelles versions.
Et surtout, je voulais pouvoir faire tout ça sans transformer LowFlow en une application qui dépend entièrement d'un serveur.
C'est là que j'ai commencé à comprendre qu'il me fallait une autre couche. Pas pour les données du trader. Pour tout ce qui entoure l'application.
L'application reste chez le trader
C'est probablement la partie la plus importante à comprendre.
LowFlow est installé localement. L'application est sur l'ordinateur du trader. Ses données sont locales. Mais l'application doit maintenant pouvoir communiquer avec mon infrastructure pour certaines fonctions.
C'est un peu comme un téléphone cellulaire. Le téléphone est dans votre main. Vos applications sont installées sur votre appareil. Certaines données peuvent être conservées directement sur celui-ci. Mais pour certains services, le téléphone doit communiquer avec le réseau.
LowFlow fonctionne avec une logique similaire. Local ne veut pas nécessairement dire hors ligne.
L'application reste locale. Mais elle a besoin d'une connexion Internet pour communiquer avec l'infrastructure LowFlow et vérifier certains éléments nécessaires à son fonctionnement.
Et le Control Panel est apparu
À partir de là, le projet a encore changé.
Je n'avais plus seulement une application. J'avais maintenant besoin d'un endroit où je pouvais gérer ce qui se passe autour de l'application.
Le Control Panel est devenu cette pièce centrale. C'est là que je peux gérer les éléments nécessaires au fonctionnement commercial de LowFlow — les comptes, les licences, les versions, la distribution, les contrôles nécessaires entre l'application et mon infrastructure.
Et ça m'a permis de garder une séparation claire. Le trader garde ses données. Moi, je gère le produit.
Une connexion obligatoire, mais pas un journal dans le cloud
C'est là que la différence devient importante.
Si la connexion Internet n'est pas disponible, LowFlow ne peut pas simplement continuer comme si rien ne s'était passé. L'application doit pouvoir vérifier les éléments nécessaires auprès de mon infrastructure. Sans cette connexion, elle reste à l'écran des réglages.
Mais les données du trader ne disparaissent pas — ses trades, ses photos, ses historiques et ses données de replay sont toujours là. L'application n'est simplement pas autorisée à continuer son fonctionnement normal tant que la connexion nécessaire n'a pas été établie.
C'était le compromis que je cherchais. Les données restent locales. Le contrôle du produit reste centralisé.
Je n'avais pas prévu tout ça au départ
Et c'est probablement une des choses les plus intéressantes dans toute cette aventure.
Je n'avais pas commencé LowFlow avec un grand plan d'architecture commerciale. Je construisais un outil dont j'avais besoin.
Puis l'outil a grossi. Le journal a grossi. Les fonctionnalités ont augmenté. Les addons sont arrivés. L'application est devenue un vrai produit — avec une application locale, des données locales, des addons, des clients potentiels, des licences, un Control Panel, une infrastructure, et tout un système qui devait fonctionner ensemble.
Et finalement, en août, j'ai dû me rendre à l'évidence. Je pouvais garder LowFlow local. Mais je ne pouvais plus gérer tout ce qui entourait LowFlow uniquement depuis l'ordinateur du client.
Il me fallait une infrastructure. Pas pour prendre ses données. Pas pour héberger son journal. Mais pour pouvoir faire fonctionner correctement un produit que je voulais maintenant distribuer à d'autres traders.
Une nouvelle étape
C'est à ce moment-là que LowFlow a commencé à ressembler beaucoup moins à un simple logiciel que je construisais pour moi-même.
Et une nouvelle question est apparue.
Comment faire pour que tout ça puisse être distribué automatiquement au client?
Parce qu'une chose est de construire un logiciel. Une autre est de construire un système capable de le livrer proprement à quelqu'un que je ne connais même pas.
Et c'est là que la prochaine étape de LowFlow allait commencer.