Construire l'application était une chose.
La faire fonctionner chez moi en était une autre.
Mais maintenant, je voulais qu'une personne que je ne connais pas puisse acheter LowFlow, recevoir son accès, installer l'application et commencer à l'utiliser.
Et là, je me suis rendu compte d'une chose : je ne construisais plus seulement un logiciel. Je construisais un système capable de livrer un logiciel.
Le client ne devait pas avoir à m'écrire
Je voulais éviter le scénario classique. Un client achète. Il m'envoie un courriel. Je lui réponds. Je lui envoie un fichier. Je lui explique comment l'installer. Puis il revient parce qu'il a changé d'ordinateur. Puis encore parce qu'il veut une mise à jour. Et ainsi de suite.
Si je voulais avoir plusieurs dizaines, puis plusieurs centaines de clients, ce modèle ne pouvait pas fonctionner. Il fallait automatiser le maximum. Le client devait pouvoir faire son achat et recevoir ce dont il avait besoin sans que je sois obligé d'intervenir manuellement à chaque étape.
Le compte client
Il fallait donc commencer par le commencement. Un compte. Le client devait pouvoir être identifié dans mon système. Son achat devait être associé à son compte. Son accès devait être associé à son produit. Et son application devait pouvoir communiquer avec cette information.
Ça paraît simple quand on le regarde de l'extérieur. Mais derrière une petite fenêtre de connexion, il y a beaucoup de choses qui doivent être cohérentes — le bon client, le bon produit, la bonne licence, la bonne version, et le bon appareil.
La licence
Ensuite est arrivée la question de la licence. Je ne voulais pas simplement envoyer un fichier exécutable en disant : « Voilà, amuse-toi. »
Il fallait que LowFlow sache si la personne qui l'utilise possède réellement un accès valide. La licence est donc devenue une pièce centrale du système. Elle permet de relier le client au produit qu'il a acheté et de gérer son accès dans le temps.
Mais encore une fois, je voulais conserver la même philosophie. Le journal reste local. La licence, elle, est vérifiée à distance.
Et l'installation?
Puis il fallait distribuer l'application. Je voulais éviter de mettre publiquement mes fichiers de production à la disposition de n'importe qui. Il fallait donc créer un système où le client pouvait récupérer la bonne version de LowFlow sans que toute mon infrastructure de développement soit exposée.
C'est là que mon Control Panel a commencé à prendre encore plus d'importance. Il devenait le centre de gestion de tout ce qui devait être distribué.
Une version n'est pas simplement un fichier
Au début, on pourrait croire qu'une mise à jour consiste simplement à remplacer un ancien fichier par un nouveau. En réalité, ce n'est pas aussi simple.
Il faut savoir quelle version le client utilise. Il faut savoir quelle version est disponible. Il faut pouvoir vérifier que le fichier reçu correspond bien à ce qui doit être installé. Et il faut éviter qu'un client télécharge n'importe quoi.
Je commençais donc à construire une chaîne beaucoup plus structurée : une version, un contrôle, une distribution, une installation, puis une nouvelle version lorsque nécessaire.
Je voulais que ça fonctionne sans moi
C'était probablement le point le plus important. Je ne voulais pas créer une entreprise où chaque nouveau client me donnait une nouvelle tâche manuelle. Je voulais construire le système une fois. Puis laisser le système faire le travail.
Le client achète. Son accès est créé. Il récupère son application. L'application communique avec l'infrastructure. La licence est vérifiée. Et LowFlow démarre.
Tout ce qui peut être automatisé doit l'être. Parce que mon objectif n'est pas de passer mes journées à envoyer des fichiers et à activer des licences. Je veux développer LowFlow.
Et les mises à jour?
Une fois la distribution réglée, une autre question est devenue évidente. Que se passe-t-il lorsque LowFlow évolue? Parce que LowFlow évolue constamment. Une correction aujourd'hui. Une nouvelle fonction demain. Une optimisation la semaine prochaine.
Je ne pouvais pas demander à chaque client de télécharger manuellement une nouvelle version à chaque changement. Il fallait donc penser dès maintenant à la mise à jour. L'application devait pouvoir savoir si une nouvelle version était disponible et récupérer la bonne version lorsque nécessaire.
Encore une fois, le but était le même : le moins d'intervention possible.
Le système commençait à prendre forme
À ce stade, LowFlow avait maintenant plusieurs pièces qui devaient fonctionner ensemble : l'application locale, les données du trader, le compte client, les licences, le Control Panel, la distribution, les mises à jour, et l'infrastructure qui permettait à tout ça de communiquer.
Et pourtant, le cœur de LowFlow n'avait pas changé. Le trader continuait de travailler avec ses propres données, sur sa propre machine. Je n'avais pas transformé le journal en SaaS. J'avais simplement construit autour de l'application locale ce dont j'avais besoin pour pouvoir la commercialiser correctement.
Mais une nouvelle question est apparue
Plus je construisais le système, plus une autre réalité devenait évidente. Si je voulais vraiment distribuer LowFlow à des clients, je devais protéger tout ce que je venais de construire.
Pas seulement l'application. La licence. Les mises à jour. La distribution. L'infrastructure.
Et surtout, je devais m'assurer que le système puisse faire la différence entre une installation légitime et quelque chose qui ne devrait pas avoir accès au produit.
Je venais donc de terminer une étape. Et je découvrais que la suivante allait être beaucoup plus sérieuse. La protection de LowFlow.