Pendant longtemps, j'ai testé LowFlow comme quelqu'un qui connaissait le système.
Je savais où cliquer. Je savais quelles données devaient apparaître. Je savais où regarder lorsqu'une information manquait.
Je pouvais ouvrir le serveur, consulter les logs, vérifier un fichier, modifier une configuration, relancer un service.
Bref, je testais comme celui qui avait construit LowFlow.
Mais un client ne fera jamais ça.
Et c'est là qu'un autre type de test devient nécessaire.
Le test technique ne suffit plus
Un bouton peut fonctionner. Une route serveur peut répondre correctement. Stripe peut confirmer un paiement. Une licence peut être générée. Le téléchargement peut exister.
Tout ça peut être vrai séparément.
Mais le client, lui, ne teste pas les morceaux. Il teste le parcours complet.
Il arrive sur le site. Il choisit. Il crée son compte. Il confirme son courriel. Il paie. Il revient sur LowFlow. Il télécharge. Il installe. Il ouvre l'application. Il active sa machine.
Et si une seule de ces étapes est mal reliée à la suivante, son expérience s'arrête là.
Il fallait une vraie personne
Pour ce test, je ne voulais plus simuler le client moi-même.
Je pouvais toujours inconsciemment contourner un problème parce que je connaissais le système.
Il fallait quelqu'un qui utilise le parcours tel qu'il est présenté.
Un ami m'a aidé pour ça.
Une deuxième machine. Un autre ordinateur. Un vrai navigateur. Un vrai courriel. Une vraie carte.
Et surtout, quelqu'un qui ne devait jamais avoir besoin de comprendre l'architecture derrière LowFlow.
S'il fallait lui expliquer une manipulation technique pour continuer, le test avait déjà révélé un problème.
Tester avec de vrais paiements, sans payer 200 dollars à chaque fois
Je voulais aussi tester Stripe dans les vraies conditions. Pas uniquement en simulation.
Mais faire payer 199,99 $ simplement pour vérifier un parcours aurait été absurde.
J'ai donc créé trois offres temporaires de validation qui reproduisent les trois chemins commerciaux de LowFlow :
1A — paiement complet : 1,00 $
1B — plan 12 mois : 0,75 $
1C — plan 24 mois : 0,50 $
Les vraies offres restent inchangées. Le but est seulement de faire circuler un vrai petit paiement dans le vrai système.
Même site. Même Stripe. Même compte. Même serveur. Même logique d'activation.
La seule chose différente est le montant.
Et c'est là que les vrais problèmes apparaissent
Le premier enseignement a été brutalement simple.
Un paiement réussi ne veut pas dire un parcours réussi.
Stripe pouvait accepter la carte. La transaction pouvait apparaître dans le tableau de bord.
Mais si le serveur n'écoutait pas le bon événement, LowFlow ne savait pas à quel client attribuer le paiement.
Stripe avait l'argent. Le serveur avait reçu quelque chose. Mais le client n'avait aucun droit supplémentaire.
Techniquement, plusieurs systèmes avaient fonctionné. Commercialement, rien n'avait fonctionné.
Puis le client payait… et tombait dans le vide
Autre problème.
Le paiement passait. Mais après le paiement, Stripe affichait simplement sa propre confirmation.
Aucun retour clair vers LowFlow. Aucun téléchargement. Aucune prochaine étape.
Le client venait de payer et devait deviner quoi faire ensuite.
C'était exactement l'inverse de ce que j'avais voulu construire.
La maquette originale avait pourtant déjà défini le parcours : paiement confirmé, puis télécharger LowFlow, puis installer et ouvrir l'application, puis terminer l'activation.
Le vrai site devait donc respecter cette séquence.
Le retour Stripe a été relié à une page LowFlow dédiée. Le paiement n'est plus une fin. Il devient une transition vers la suite.
Le client qui revient a aussi révélé un trou
Un autre test a montré quelque chose d'encore plus évident.
Que se passe-t-il si quelqu'un possède déjà un compte ?
Il ne devrait pas avoir à recréer son compte. Il ne devrait pas avoir à se souvenir de son LF-ID par cœur. Il devrait entrer son courriel et son mot de passe, retrouver son compte, choisir son produit et continuer.
La page de connexion existait déjà. La page prix existait déjà. Mais les deux n'étaient pas suffisamment reliées.
Encore une fois, tous les morceaux existaient. Le parcours, lui, était incomplet.
Le trial a eu droit au même traitement
À un moment, j'ai eu un doute sur l'essai gratuit.
Quelque chose ne me semblait pas logique.
J'ai vérifié. Et le doute était justifié.
La validation du compte ne débloquait pas le téléchargement.
Le bouton existait. La page existait. Le système d'essai existait. Mais le client n'aurait pas pu télécharger réellement l'application.
C'est exactement pour ça que le test du parcours complet est différent. Il fait apparaître les trous situés entre deux fonctions.
Le vrai test commence après l'installation
Après le site et Stripe vient la partie que j'avais passée beaucoup de temps à construire : l'activation.
Une machine neuve ouvre LowFlow. Elle ne possède encore aucune licence.
Le client entre son courriel et son identifiant LowFlow. La machine est liée au compte. Et la licence arrive toute seule.
Le client n'a jamais eu à copier une clé de licence.
C'était exactement l'objectif.
Mais l'activation n'est pas la dernière vérification
Il restait un test important.
Une licence permanente ne doit pas devenir une permission de contourner les protections.
Le test final est volontairement simple :
La machine possède une vraie licence. Elle est activée. Puis, depuis le serveur, je lui retire l'accès.
Si LowFlow continue à fonctionner normalement, l'architecture est mauvaise. Si l'application respecte le verdict serveur, alors la séparation entre Activation et Accès fonctionne réellement.
C'est cette différence qui était importante depuis le début.
Payé ne veut pas dire immunisé. Activé ne veut pas dire incontrôlable.
Le testeur ne doit jamais devenir le développeur
Une règle est ressortie très clairement de cette journée.
Je ne veux jamais demander à un client d'ouvrir des outils techniques, de copier des messages d'erreur, ou de m'expliquer ce que le serveur répond.
Si quelque chose ne fonctionne pas, c'est à moi de regarder les logs, le code et le serveur.
Le client doit rester le client. Son seul travail est d'utiliser LowFlow normalement.
Et c'est précisément ce qui rend son test précieux.
Stripe aussi devait être testé comme un système complet
En faisant le tour du tableau de bord Stripe, j'ai découvert quelque chose de similaire.
Recevoir un paiement n'est qu'une petite partie de la configuration.
Il y a les reçus. Les notifications. Les cartes expirées. Les paiements échoués. Les confirmations supplémentaires. Le portail client. Les abonnements. Les remboursements. Les redirections. Les alertes d'erreur. Les règles antifraude.
Un seul réglage oublié peut casser une partie de l'expérience.
Encore une fois : les détails restent derrière l'écran, mais quelqu'un doit les vérifier.
Finalement, tester un produit n'est pas vérifier qu'il ouvre
Avant, je pouvais dire : LowFlow démarre. Les trades entrent. Les calculs fonctionnent. Les données restent locales. Les mises à jour fonctionnent.
Tout ça reste important. Mais ce n'est plus suffisant.
Maintenant, tester LowFlow signifie aussi :
Est-ce que quelqu'un peut le découvrir ? Créer son compte ? Revenir plus tard ? Payer ? Recevoir ce qu'il vient d'acheter ? Installer l'application ? Activer sa machine ? Gérer son abonnement ? Être aidé correctement si quelque chose échoue ?
Et est-ce que mes protections continuent à fonctionner une fois que tout le reste fonctionne ?
C'est un autre niveau de test.
Parce que LowFlow n'est plus seulement un programme. C'est maintenant un parcours complet.
Et après ?
À partir de là, les prochaines améliorations deviennent beaucoup plus faciles à identifier.
Ajouter plusieurs machines à un compte. Permettre l'achat d'un deuxième emplacement. Encadrer les migrations d'ordinateur. Améliorer encore les pages de compte. Continuer les traductions. Ajouter les prochains marchés et plateformes.
Mais cette fois, la base commerciale existe.
Quelqu'un peut arriver. Acheter. Installer. Activer. Et commencer à utiliser LowFlow.
Sans avoir besoin de connaître tout ce qui a été nécessaire pour rendre ça possible.
Et c'est probablement le meilleur signe que LowFlow commence réellement à devenir un produit.