Jusqu'ici, LowFlow pouvait fonctionner.
Le site existait. Le système de comptes existait. Stripe pouvait recevoir un paiement. Le serveur pouvait gérer les licences. L'application pouvait s'installer. Le Control Panel pouvait gérer les clients.
Tous les morceaux étaient là.
Mais avoir tous les morceaux ne veut pas dire que le client peut réellement passer de l'un à l'autre.
Et c'est probablement l'une des leçons les plus importantes de toute cette construction.
Un client ne voit pas l'architecture
Pour moi, LowFlow était devenu un ensemble assez complexe.
Il y avait le site. Le serveur. Stripe. Les comptes. Les courriels de vérification. Les identifiants LowFlow. Les téléchargements. Les licences. Les activations. Les contrôles de sécurité.
Mais le client ne doit jamais avoir à comprendre tout ça.
Pour lui, le parcours devrait être beaucoup plus simple.
Il découvre LowFlow. Il choisit une formule. Il crée son compte ou se connecte. Il paie. Il télécharge. Il installe. Il ouvre LowFlow. Et il commence à travailler.
Tout ce qu'il y a entre ces étapes doit rester derrière l'écran.
Le vrai défi était de relier les morceaux
C'est là que j'ai compris une différence importante.
Construire une fonction est une chose. Construire un parcours complet en est une autre.
Un paiement Stripe peut parfaitement fonctionner, mais si le client reste sur une page de confirmation sans savoir quoi faire ensuite, le parcours est cassé.
Un téléchargement peut être protégé, mais si le lien n'arrive jamais jusqu'au client, le parcours est cassé.
Chaque morceau peut fonctionner individuellement. Et malgré tout, l'ensemble peut ne pas fonctionner.
Le paiement ne devait pas être la fin
Au début, j'avais surtout vu Stripe comme le système qui recevrait le paiement.
Mais dans un vrai produit, le paiement n'est pas la fin. C'est une transition.
Une fois le paiement confirmé, LowFlow doit savoir ce qui vient de se passer.
Le compte doit être reconnu. Le droit doit être accordé. Le client doit revenir sur le site. Il doit voir clairement que son paiement est confirmé. Il doit pouvoir télécharger l'application. Puis l'application doit reprendre le relais.
Le paiement devient donc le point où le site, Stripe, le serveur et l'application commencent réellement à travailler ensemble.
Le client qui revient compte autant que le nouveau
Un autre détail paraît évident après coup.
Un client ne visite pas le site une seule fois dans sa vie.
Il peut revenir. Il peut oublier son identifiant LowFlow. Il peut changer d'ordinateur. Il peut vouloir télécharger l'application de nouveau. Il peut vouloir gérer son abonnement. Il peut simplement vouloir consulter son compte.
Il fallait donc arrêter de penser uniquement au parcours « créer un compte → acheter » et aussi construire « se connecter → retrouver son compte → continuer ».
Le courriel et le mot de passe doivent suffire pour retrouver le compte. L'identifiant LowFlow reste important, mais il ne doit pas devenir une information que le client doit mémoriser pour avoir accès à ce qu'il a acheté.
Une seule étape oubliée suffit
C'est probablement ce qui m'a le plus surpris.
Il suffit d'une seule étape manquante pour donner l'impression que tout le système ne fonctionne pas.
Le paiement peut être réussi. Le serveur peut recevoir l'événement. La transaction peut apparaître chez Stripe.
Mais si le client ne revient pas automatiquement vers LowFlow, il ne voit rien de tout ça.
Pour lui, il vient simplement de payer. Et ensuite… plus rien.
C'est exactement le genre de problème qu'on ne voit pas forcément lorsqu'on teste chaque fonction séparément.
La maquette avait déjà la réponse
Ce qui est presque amusant, c'est que j'avais déjà dessiné ce parcours.
Dans ma maquette locale, les étapes étaient simples : compte créé, courriel vérifié, identifiant LowFlow, paiement confirmé, téléchargement, ordinateur activé.
Tout était déjà là.
Le travail n'était donc pas d'inventer un nouveau processus. Il fallait prendre ce parcours et s'assurer que le vrai site, le vrai serveur, Stripe et la vraie application le respectaient réellement.
Le parcours devient une fonction du produit
À partir de ce moment, j'ai cessé de voir le site comme une simple vitrine.
Le parcours client fait maintenant partie de LowFlow.
La connexion fait partie du produit. Le retour après paiement fait partie du produit. Le téléchargement fait partie du produit. L'activation fait partie du produit.
Même les courriels envoyés lorsqu'un paiement échoue ou lorsqu'une carte expire font partie de l'expérience.
LowFlow ne commence plus uniquement lorsque l'application s'ouvre. Il commence au moment où quelqu'un décide de l'utiliser.
La complexité doit disparaître
Derrière ce parcours, il y a énormément de choses.
Des vérifications. Des automatismes. Des échanges constants entre le site, le serveur et l'application.
Mais si le système est bien construit, le client ne devrait presque jamais voir cette complexité.
Il devrait simplement avancer. Une étape après l'autre.
Et si quelque chose demande son attention, le système doit lui dire clairement quoi faire.
C'est là que j'ai compris qu'une bonne automatisation n'est pas simplement quelque chose qui travaille sans intervention. C'est quelque chose qui fait disparaître la mécanique.
La prochaine étape : arrêter de tester comme le développeur
Une fois le parcours construit, une question restait.
Est-ce qu'il fonctionnait réellement ?
Pas lorsque je connaissais déjà tous les boutons. Pas lorsque je pouvais regarder les logs. Pas lorsque je pouvais ouvrir le serveur et corriger une donnée à la main.
Mais lorsqu'une autre personne arrivait sur le site sans connaître tout ce qui se passait derrière.
C'est là que le prochain test devenait évident.
Il fallait arrêter de tester LowFlow comme celui qui l'avait construit. Et commencer à le tester comme quelqu'un qui venait simplement de l'acheter.