Votre prototype Lovable tourne. Vous avez une URL, quelques écrans propres et un parcours qui fonctionne assez bien pour être montré à quelqu'un.

La tentation est forte : ajouter les derniers détails, connecter un paiement, puis envoyer le lien aux premiers clients.

Mais une démo qui fonctionne ne répond qu'à une question : est-ce que le parcours principal fonctionne dans le cas prévu ? La production pose des questions moins flatteuses. Que se passe-t-il quand deux personnes utilisent l'app en même temps ? Quand un paiement échoue ? Quand un utilisateur tente d'accéder à une donnée qui ne lui appartient pas ? Quand personne ne sait pourquoi l'écran est vide ?

La bonne question n'est donc pas « est-ce que Lovable peut produire une app ? ». C'est : qu'est-ce que votre prototype a déjà validé, et qu'est-ce qu'il reste à vérifier avant de lui confier de vraies personnes ?

Ce que le prototype a déjà validé

Un prototype reste très utile. Il peut vous aider à tester un parcours, montrer une idée à un prospect, obtenir des retours et repérer les parties du produit qui ne tiennent pas debout.

Lovable présente d'ailleurs le prototypage comme une étape de validation avant le passage au code de production et aux équipes d'ingénierie. La documentation de Lovable décrit ce passage comme un transfert après validation des parcours et des hypothèses.

C'est une bonne séquence. Le prototype réduit l'incertitude produit avant que vous dépensiez davantage en développement.

En revanche, il ne prouve pas automatiquement que :

chaque utilisateur ne voit que ses propres données ;
les permissions sont vérifiées côté serveur ;
les données peuvent être restaurées après une erreur ;
le déploiement peut être reproduit sans manipulations manuelles ;
un paiement ou un webhook ne sera pas traité deux fois ;
quelqu'un pourra corriger un bug dans trois mois sans tout casser.

Ces sujets ne sont pas des détails à ajouter à la fin. Ils déterminent si votre app peut supporter une utilisation réelle.

Les signes que le prototype approche de sa limite

Il n'y a pas de nombre magique d'utilisateurs à partir duquel un prototype devient dangereux. Le moment dépend surtout de ce que votre app fait et des conséquences d'une erreur.

Vous êtes probablement arrivé à cette frontière si plusieurs situations suivantes vous parlent :

De vraies personnes vont l'utiliser

Tant que vous êtes le seul utilisateur, vous pouvez corriger à la main et surveiller ce qui se passe. Dès qu'un client dépend du produit, une panne devient un problème commercial.

L'app manipule des données sensibles ou payantes

Une adresse email n'a pas le même niveau de risque qu'un dossier médical, un historique de paiement ou des informations propres à une entreprise. Plus les données comptent, moins vous pouvez vous contenter de vérifier que l'interface a l'air correcte.

Chaque correction en casse une autre

C'est souvent le premier signal visible. Vous demandez une modification ciblée et l'outil modifie plusieurs endroits du projet. Le résultat fonctionne parfois, mais vous ne savez plus quelle partie dépend de quelle autre.

Vous ne savez pas expliquer où sont les règles importantes

Qui peut créer une facture ? Qui peut modifier une commande ? Où l'application vérifie-t-elle les droits ? Si la réponse est « je pense que c'est dans ce composant », il manque probablement une vue d'ensemble.

Une échéance ne vous laisse plus le temps d'apprendre en production

Un premier pilote, une démo investisseur ou une ouverture commerciale peuvent justifier un audit même si l'app n'a pas encore beaucoup d'utilisateurs. Le risque vient parfois du calendrier, pas du trafic.

Les sept vérifications à faire avant d'ouvrir l'accès

Vous n'avez pas besoin de connaître tous les détails techniques pour commencer. Il faut surtout savoir quelles questions poser et obtenir des réponses vérifiables.

1. Authentification et permissions

Un utilisateur connecté ne doit pas seulement accéder à l'application. Il doit accéder aux bonnes données et aux bonnes actions.

Testez les cas suivants :

un utilisateur tente d'ouvrir l'URL d'une autre personne ;
un utilisateur modifie une requête depuis le navigateur ;
un compte standard appelle une action réservée à un administrateur ;
une session expirée tente encore d'utiliser l'API.

Le fait de cacher un bouton dans l'interface ne constitue pas une permission. La règle doit être vérifiée au moment où le serveur reçoit la demande.

2. Données et migrations

Demandez-vous ce qui se passe si un champ change, si une ligne est supprimée par erreur ou si vous devez importer un historique existant.

Une base qui fonctionne avec dix lignes de test peut devenir difficile à maintenir dès que les données ont une valeur réelle. Il faut connaître les relations importantes, les contraintes, les sauvegardes et la procédure de restauration.

3. Gestion des erreurs

Une production ne se déroule jamais uniquement dans le cas nominal. Un service tiers tombe, le réseau coupe, un email n'arrive pas ou une requête prend trop longtemps.

L'utilisateur doit recevoir un message compréhensible. De votre côté, vous devez pouvoir retrouver ce qui s'est passé. Une page blanche ou un simple « une erreur est survenue » ne permet ni de rassurer le client ni de corriger rapidement.

4. Déploiement et secrets

Pouvez-vous redéployer l'application sans vous souvenir de commandes particulières ? Les environnements de test et de production sont-ils séparés ? Les clés privées sont-elles stockées dans des variables d'environnement plutôt que dans le dépôt Git ?

Si le déploiement dépend d'une seule machine ou d'une suite de manipulations impossible à documenter, vous avez un risque opérationnel avant même d'avoir un problème de code.

5. Paiements et traitements asynchrones

Un paiement ne se résume pas à afficher une page de confirmation. Il faut gérer les abandons, les erreurs, les remboursements et les notifications envoyées par le prestataire de paiement.

Le même événement peut parfois être reçu plusieurs fois. Votre application doit éviter de créer deux commandes ou de créditer deux fois un compte pour une seule transaction.

6. Tests sur les parcours importants

Vous n'avez pas besoin de tester chaque pixel. Commencez par les parcours qui peuvent coûter quelque chose : inscription, connexion, création de données, paiement, invitation d'un autre utilisateur et action administrateur.

Un test qui échoue avant chaque mise en ligne vous donne une information utile. Une vérification manuelle faite une fois, puis oubliée, ne joue pas le même rôle.

7. Reprise par quelqu'un d'autre

Essayez de répondre à cette question : si vous êtes indisponible pendant un mois, qui peut corriger le projet ?

Le code n'a pas besoin d'être parfait. Il doit être compréhensible, déployable et accompagné des informations qui ne peuvent pas être devinées. C'est aussi la meilleure manière de ne pas rester prisonnier de l'outil qui a servi à créer le prototype.

Faut-il garder le code ou repartir de zéro ?

Dans la plupart des cas, la réponse n'est pas binaire.

On peut généralement garder une partie du prototype quand les parcours sont clairs, que le modèle de données est récupérable, que les règles métier sont identifiables et que le déploiement peut être stabilisé sans tout déplacer.

Une reprise ciblée devient nécessaire quand le problème se concentre sur quelques zones : permissions, paiements, modèle de données, gestion des erreurs ou déploiement. Refaire ces fondations peut coûter moins cher que de continuer à empiler des corrections imprévisibles.

Un rebuild complet se justifie lorsque les règles de sécurité sont impossibles à vérifier, que les données sont déjà incohérentes ou que chaque modification entraîne des régressions difficiles à isoler. Ce n'est pas le scénario à choisir par défaut. C'est le verdict que l'audit doit pouvoir poser, avec des raisons précises.

Quand l'audit n'est pas encore nécessaire

Si vous n'avez pas encore de prototype, ne commencez pas par payer une reprise. Construisez une première version et mettez-la devant quelques utilisateurs.

Si vous avez un prototype mais ni utilisateurs réels, ni paiement, ni données personnelles, et que vous êtes encore en phase d'apprentissage produit, continuez à itérer. C'est probablement le meilleur usage de votre temps et de votre argent.

L'audit devient pertinent quand une erreur pourrait coûter un client, exposer une donnée, bloquer un paiement ou vous faire rater une échéance. Avant cela, le prototype a encore un rôle à jouer.

Ce que l'audit doit vous apporter

Un audit utile ne se résume pas à une liste de problèmes techniques. Il doit vous aider à décider.

À la fin, vous devriez savoir :

ce qui peut rester en l'état ;
ce qui doit être corrigé avant l'ouverture ;
ce qui peut attendre une prochaine version ;
ce qu'il faut reprendre ou réécrire ;
combien de temps et de budget prévoir pour la suite.

Chez TechSprint, l'audit prend une semaine et coûte 2k€. Le livrable contient un état des lieux du code, de la sécurité et de l'hébergement, une liste priorisée des risques, un verdict garder / reprendre / refaire et un chiffrage de la suite.

Le rapport vous appartient. Vous pouvez continuer avec moi, le transmettre à un développeur de votre équipe ou demander un autre avis. Son intérêt ne dépend pas de la réalisation des travaux qui suivent.

Si votre app vient de Lovable et que les premiers clients approchent, la page reprise prototype Lovable détaille le format de reprise quand le code est récupérable.

La prochaine question à vous poser

Ne demandez pas seulement : « Est-ce que mon app fonctionne ? »

Demandez plutôt : « Qu'est-ce qui se passe quand elle ne fonctionne pas, et qui saura le corriger ? »

Si vous pouvez répondre clairement, vous êtes peut-être déjà bien avancé. Si vous devez deviner, l'app mérite probablement un regard extérieur avant les premiers vrais utilisateurs.

Envoyez-moi le lien de votre prototype et le contexte : qui va l'utiliser, avec quelles données, et à quelle date. En 30 minutes, on peut déjà déterminer si vous devez continuer à prototyper, faire un audit ou passer directement à une reprise ciblée.

Réserver un appel de 30 minutes

Vous pouvez aussi lire où l'IA aide vraiment dans le développement et ce qu'un sprint rapide permet réellement.

Fabrice Payet — fondateur de TechSprint, La Réunion.