Prototype Lovable, Bolt ou v0 : le passer en production

Vous avez construit un prototype avec Lovable, Bolt, v0 ou Cursor. Il tourne, vous l’avez montré, et les retours sont bons. Peut-être même que des premiers utilisateurs attendent déjà un accès. La question n’est plus « est-ce que l’idée tient ? » mais « comment je mets ça entre les mains de vrais gens sans que ça s’écroule ? ».

C’est une excellente question à se poser maintenant, avant le lancement plutôt qu’après le premier incident. Voici ce qui change réellement entre un prototype et une application en production, et les chantiers à mener, dans l’ordre.

Prototype et production : ce qui change vraiment

Un prototype répond à une seule question : « est-ce que ça marche quand je clique ? ». Une application en production doit répondre à beaucoup d’autres, que personne ne pose pendant la démo :

• Des utilisateurs que vous ne connaissez pas font des choses que vous n’avez pas prévues : double clic sur « Payer », retour arrière en plein formulaire, champ rempli avec un emoji.
• Des données que vous ne pouvez plus perdre : en prototype, on vide la base sans état d’âme. En production, chaque ligne est un client, une commande, un historique.
• Des erreurs qui arrivent pendant que vous dormez, et dont il faut être prévenu autrement que par un client mécontent.
• Des évolutions à livrer sans rien casser, alors que des gens utilisent l’outil au même moment.

Rien de tout cela ne se voit à l’écran. C’est pour ça que l’écart est si souvent sous-estimé : le prototype a l’air fini, alors qu’il en est à peu près à la moitié du chemin.

Avant de commencer : garder, exporter ou reconstruire ?

Première décision, et elle conditionne tout le reste. Il y a trois options, et aucune n’est honteuse.

Rester sur la plateforme

Pour un outil interne utilisé par quelques personnes, sans paiement ni données sensibles, rester sur l’hébergement de Lovable ou Bolt est souvent le bon choix. Il faudra quand même sécuriser l’accès aux données, mais inutile de sortir l’artillerie lourde.

Exporter le code et le reprendre

C’est le cas le plus fréquent dès qu’il y a des clients, de l’argent ou des données personnelles. On récupère le code (la plupart des outils synchronisent avec GitHub), on le fait tourner dans un environnement que vous maîtrisez, et on le consolide. On garde l’interface et la logique qui fonctionnent, on reprend ce qui est fragile.

Reconstruire une partie

Parfois, une brique précise (souvent la base de données ou la gestion des comptes) est trop bancale pour être réparée. On la reconstruit proprement, en gardant tout le reste. Repartir entièrement de zéro est rarement justifié : votre prototype a au moins le mérite d’avoir validé ce qu’il faut construire.

Les 7 chantiers du passage en production

1. Reprendre la maîtrise du code

Le code doit vivre dans un dépôt versionné (GitHub, GitLab) qui vous appartient, avec un historique lisible. C’est ce qui permet de revenir en arrière en deux minutes quand une modification tourne mal, et de confier le projet à quelqu’un d’autre sans dépendre d’un compte ou d’une plateforme.

2. Séparer le test de la production

Dans un prototype, on teste directement sur la seule version qui existe. En production, il en faut au moins deux : une version de test, avec ses propres données, et la version en ligne. Chaque modification passe d’abord par la première. Sans cette séparation, chaque essai se fait sur le dos de vos utilisateurs.

3. Fermer les portes ouvertes

Clés d’API visibles dans le navigateur, base de données lisible par n’importe qui, routes d’administration non protégées : ce sont les failles les plus courantes des projets générés par IA. Je les détaille une par une dans la checklist sécurité avant la mise en ligne. C’est le chantier à ne pas reporter.

4. Protéger les données

Un schéma de base cohérent (pas trois champs qui veulent dire la même chose), des modifications de structure faites proprement plutôt qu’à la main, et surtout des sauvegardes automatiques. Pas seulement activées : testées.

5. Voir les erreurs avant vos utilisateurs

En production, une erreur silencieuse est la pire des erreurs. Un outil de suivi (Sentry ou équivalent) vous prévient quand quelque chose plante, avec le contexte pour comprendre pourquoi. Ajoutez des messages clairs côté utilisateur : « Le paiement n’a pas abouti, votre carte n’a pas été débitée » rassure, une page blanche fait fuir.

6. Fiabiliser paiements et emails

Deux zones où les prototypes sont presque toujours trop optimistes. Côté paiement, il faut gérer les confirmations envoyées par Stripe (les « webhooks ») de façon à ce qu’un même paiement ne soit jamais compté deux fois, ni perdu si votre serveur ne répond pas à cet instant précis. Côté emails, sans configuration du domaine (SPF, DKIM), vos emails de confirmation finissent en spam, et vos utilisateurs pensent que l’inscription n’a pas marché.

7. Soigner la mise en ligne

Nom de domaine, HTTPS, temps de chargement correct sur mobile, mentions légales et politique de confidentialité à jour. Ce sont des détails pris un par un, mais ce sont aussi les premiers signaux de sérieux que perçoit un nouvel utilisateur (et un moteur de recherche).

Ce que vous pouvez faire seul, et ce qui mérite un regard extérieur

Soyons honnêtes : une bonne partie de cette liste est à votre portée, surtout si vous êtes à l’aise avec vos outils.

• Faisable seul : connecter GitHub, activer les sauvegardes, installer un outil de suivi d’erreurs, configurer le domaine et les emails, rédiger les pages légales.
• Plus délicat : les règles d’accès aux données, la logique des paiements, la structure de la base, et tout ce qui touche aux autorisations (« qui a le droit de voir quoi »).

La différence entre les deux ? Dans la seconde catégorie, une erreur ne se voit pas. Tout semble fonctionner, jusqu’au jour où un client voit les commandes d’un autre, ou où un paiement disparaît. L’IA peut vous aider sur ces sujets, mais elle vous répondra avec assurance même quand elle se trompe. C’est là qu’un second regard rapporte le plus.

Combien de temps faut-il prévoir ?

Tout dépend de ce que fait l’application. Pour un outil interne simple, quelques jours suffisent souvent à le rendre solide. Pour une application avec comptes utilisateurs, paiements et données clients, comptez plutôt quelques semaines. Le bon réflexe : commencer par un état des lieux, qui dit précisément où en est le projet et ce qui est prioritaire, pour ne pas payer (en temps ou en argent) des chantiers inutiles.

Et si vous vous demandez s’il faudra tout refaire, la réponse est presque toujours non. Je l’explique plus en détail dans le guide pour fiabiliser un site ou une application créé avec l’IA, avec un exemple d’outil en production.