À ce stade, LowFlow avait énormément changé depuis ses débuts.
Ce qui était au départ un journal que je construisais pour mes propres besoins était devenu une véritable application.
Il y avait maintenant une infrastructure.
Des licences.
Des mises à jour automatiques.
Un Control Panel.
Des contrôles de sécurité.
Et tout ça devait fonctionner ensemble.
Mais une nouvelle question devenait de plus en plus importante.
Est-ce que j'allais devoir gérer tout ça manuellement ?
La réponse était non.
Je ne voulais pas créer un deuxième emploi
Je connais déjà la réponse si je dois faire chaque opération moi-même.
Un client achète.
Je vérifie son paiement.
Je crée son accès.
Je prépare sa licence.
Je lui donne la bonne version.
Je vérifie son installation.
Une nouvelle version sort.
Je recommence.
Un client change d'ordinateur.
Je dois intervenir.
Un problème arrive.
Je dois intervenir.
Et pendant ce temps-là, je ne développe plus LowFlow.
Ce n'était pas le but.
Je voulais construire un produit.
Pas me créer un poste d'administrateur à temps plein.
Alors j'ai commencé à automatiser
Chaque fois que je faisais quelque chose manuellement, je me posais la même question :
« Est-ce que l'ordinateur peut le faire à ma place ? »
Si la réponse était oui, je cherchais une façon de l'automatiser.
Le paiement peut déclencher une action, le compte client peut être créé automatiquement, la licence peut être générée, et l'application peut vérifier son accès elle-même.
La disponibilité d'une nouvelle version peut être vérifiée.
La mise à jour peut être distribuée.
Les informations importantes peuvent être enregistrées.
Et lorsqu'un problème inhabituel apparaît, le système peut me prévenir.
Petit à petit, le processus commençait à se construire tout seul.
Le Control Panel devient le centre
Mon Control Panel est devenu particulièrement important à ce moment-là.
Je ne voulais pas avoir dix endroits différents où aller chercher l'information.
Je voulais avoir une vue d'ensemble — les clients, les licences, les versions, les téléchargements, les contrôles, les événements importants, tout regroupé au même endroit.
Et surtout, je voulais pouvoir intervenir lorsque c'était nécessaire sans devoir toucher directement aux serveurs ou à l'application du client.
Le Control Panel devenait donc une sorte de poste de pilotage.
Mais automatiser ne veut pas dire tout laisser faire
C'est une chose que j'ai rapidement comprise.
Une automatisation qui fait n'importe quoi très rapidement est beaucoup plus dangereuse qu'une opération manuelle.
Il fallait donc mettre des vérifications.
Une action devait avoir une condition.
Une version devait être identifiée.
Une licence devait être valide.
Un téléchargement devait correspondre au bon produit.
Un comportement inhabituel devait pouvoir être repéré.
L'automatisation devait donc être accompagnée de contrôles.
Faire moins de travail manuel ne signifie pas enlever les règles.
Au contraire.
Il faut de bonnes règles pour pouvoir automatiser.
Les alertes
Une autre partie importante a commencé à apparaître.
Je ne peux pas surveiller LowFlow vingt-quatre heures sur vingt-quatre.
Et je ne veux pas le faire.
Alors, plutôt que de regarder constamment ce qui se passe, je préfère que le système me prévienne lorsqu'il y a quelque chose d'anormal.
C'est une différence énorme.
Avant, je devais chercher le problème.
Maintenant, le système peut attirer mon attention dessus.
Ça me permet de consacrer mon temps à ce qui demande réellement une intervention humaine.
L'objectif de 90 à 95 %
Je ne cherche même pas à automatiser absolument tout.
Il y aura toujours des situations particulières.
Un client qui perd son accès.
Un changement exceptionnel.
Une situation qui nécessite une décision.
Mais si 90 à 95 % du processus peut fonctionner automatiquement, c'est déjà énorme.
Le système fait le travail répétitif.
Moi, je m'occupe des décisions et du développement.
C'est exactement la séparation que je voulais.
Et ça change complètement la façon de penser une entreprise
À ce moment-là, j'ai commencé à comprendre quelque chose que je n'avais pas réalisé au début.
Construire un logiciel et construire une entreprise autour d'un logiciel sont deux choses complètement différentes.
Le logiciel doit fonctionner.
Mais le système autour du logiciel doit lui aussi fonctionner — le paiement, la livraison, la licence, les mises à jour, le support, les contrôles, les alertes, les sauvegardes.
Tout cela fait partie du produit, même si le client ne voit presque rien de tout ça.
Le trader, lui, ne devrait presque rien voir
Et finalement, c'est peut-être le meilleur signe que le système fonctionne.
Le client achète LowFlow.
Il reçoit son accès.
Il installe l'application.
Il travaille.
Ses données restent chez lui.
Les mises à jour arrivent.
La licence est vérifiée.
Et tout le reste se fait en arrière-plan.
Le trader ne devrait pas avoir besoin de connaître toute la mécanique qui existe derrière.
Il doit simplement pouvoir ouvrir son journal et trader.
La complexité doit être derrière l'écran.
Je commençais enfin à voir le produit complet
À force de régler les problèmes un par un, quelque chose que je n'avais jamais vraiment planifié au départ était en train d'apparaître.
LowFlow n'était plus seulement un journal.
C'était devenu un écosystème — une application locale, des outils de trading, une infrastructure, un système de licences, une distribution automatisée, des mises à jour, un Control Panel.
Et surtout, un système qui pouvait fonctionner avec beaucoup moins d'intervention manuelle.
Mais il restait une dernière étape.
J'avais construit le logiciel.
J'avais construit l'infrastructure.
J'avais automatisé une grande partie du fonctionnement.
Maintenant, il fallait faire quelque chose que je n'avais jamais eu besoin de faire avec mes projets personnels.
Mettre tout ça entre les mains de vrais clients.
Et c'est là que LowFlow allait passer du projet que je construisais…
au produit que je pouvais réellement lancer.