À force de construire LowFlow, je commençais à avoir quelque chose qui ressemblait vraiment à un produit.
Une application locale.
Des données qui restent chez le trader.
Un système de mises à jour automatiques.
Un Control Panel.
Des licences.
Une infrastructure capable de faire communiquer l'application avec mon système.
Tout commençait à fonctionner ensemble.
Mais une nouvelle réalité est devenue évidente.
Plus le système devenait important, plus il fallait le protéger.
Au début, je ne pensais pas autant à la sécurité
Quand je construisais LowFlow pour moi-même, la question était beaucoup plus simple.
Je voulais que le logiciel fonctionne.
Je voulais qu'il soit rapide.
Je voulais qu'il ne plante pas.
Je voulais ajouter mes fonctions.
Je voulais améliorer mon journal.
La sécurité n'était pas au centre de mes journées.
Mais dès qu'une application devient un produit commercial, la situation change.
Il ne s'agit plus seulement de protéger mes propres fichiers, mais les clients, les licences, les mises à jour, le système de distribution, et l'infrastructure qui se trouve derrière tout ça.
Une application distribuée n'est plus la même chose
Lorsque LowFlow reste sur mon ordinateur, je contrôle tout.
Mais lorsque l'application est installée sur l'ordinateur de quelqu'un d'autre, je ne contrôle plus directement cet environnement.
L'application doit donc être capable de vérifier certaines choses elle-même.
Et mon infrastructure doit pouvoir vérifier d'autres éléments à distance.
C'est là que j'ai commencé à construire plusieurs couches de protection.
Je ne voulais pas mettre toute la sécurité au même endroit.
Parce qu'une seule protection peut toujours finir par être contournée.
L'idée était donc de multiplier les contrôles.
Protéger les licences
La première chose à protéger était évidemment l'accès au produit.
Je voulais éviter qu'une licence puisse simplement être copiée d'un ordinateur à un autre sans contrôle.
LowFlow devait pouvoir reconnaître l'installation qui utilise la licence.
Et si quelque chose ne correspondait pas, le système devait pouvoir le détecter.
Cela m'a amené à travailler sur l'identification de la machine et sur la gestion des transferts.
Le but n'était pas d'empêcher le client de changer d'ordinateur.
Le but était de pouvoir gérer ce changement correctement.
Protéger les mises à jour
Puis il y avait les mises à jour.
C'était devenu l'une des pièces les plus importantes du système.
Si LowFlow pouvait récupérer automatiquement une nouvelle version, je devais être certain que cette version venait bien de moi.
Une mise à jour n'est pas un simple fichier.
C'est quelque chose qui va être exécuté directement sur l'ordinateur du client.
Je voulais donc que les versions distribuées puissent être vérifiées avant leur installation.
La distribution devait être contrôlée.
Le serveur devait aussi être protégé
J'avais maintenant un autre problème.
Je construisais une infrastructure qui devait être accessible par l'application.
Mais je ne voulais évidemment pas ouvrir toute mon infrastructure sur Internet.
Il fallait limiter ce qui était accessible.
Limiter les fonctions exposées.
Surveiller les demandes.
Et surtout, pouvoir savoir lorsqu'un comportement ne ressemblait pas à ce qui était attendu.
Je commençais donc à ajouter des contrôles à plusieurs endroits.
Pas une seule barrière.
Plusieurs.
La sécurité devient une architecture
C'est probablement là que ma façon de voir le projet a changé.
Je ne pensais plus : « Comment est-ce que je peux sécuriser LowFlow? »
Je pensais plutôt : « Comment est-ce que je peux faire en sorte qu'une seule faiblesse ne compromette pas tout le système? »
Cette différence est importante.
L'application possède ses contrôles.
Le serveur possède les siens.
Les licences possèdent leurs propres validations.
Les mises à jour ont leurs propres vérifications.
Et certaines informations peuvent être surveillées côté serveur.
Tout cela fonctionne ensemble.
Mais je ne voulais pas transformer LowFlow en prison
Il fallait aussi garder une certaine simplicité.
Je ne voulais pas que le trader ait l'impression d'utiliser un logiciel compliqué rempli de contrôles.
Il devait simplement ouvrir LowFlow et travailler.
Le système devait faire son travail en arrière-plan.
C'est probablement l'une des choses les plus difficiles à faire dans un logiciel : construire quelque chose de complexe pour que l'utilisateur n'ait pas à voir cette complexité.
Le trader n'a pas besoin de connaître les mécanismes qui protègent son installation.
Il veut simplement que LowFlow fonctionne.
Et mes données restent locales
Malgré toute cette nouvelle infrastructure, je revenais toujours au même principe.
Les données du trader ne devenaient pas soudainement les miennes — elles restent où elles ont toujours été, sur sa machine, qu'il s'agisse de ses trades, de ses photos, de ses historiques ou de ses données de replay.
La sécurité ajoutée autour de LowFlow ne change pas cette philosophie.
Elle protège surtout le produit et son fonctionnement, pas la vie de trading du client.
Une autre leçon du développement
Plus je construis LowFlow, plus je découvre que chaque nouvelle fonction entraîne plusieurs conséquences auxquelles je n'avais pas pensé au départ.
Je voulais des mises à jour automatiques.
Il a fallu créer une infrastructure.
J'ai créé une infrastructure.
Il a fallu la protéger.
J'ai ajouté des protections.
Puis il fallait maintenant penser à autre chose : comment faire fonctionner tout ce système de manière suffisamment automatique pour que je puisse réellement gérer des clients?
Parce qu'au bout du compte, mon objectif n'était pas de passer mes journées derrière le Control Panel.
Je voulais continuer à développer LowFlow.
Et pour ça, il fallait que le système puisse travailler pour moi.
La prochaine étape allait donc être celle de l'automatisation.
Construire un système capable de faire presque tout le travail tout seul.