Du prototype Lovable, Bolt ou Cursor au SaaS en production : ce qu'il faut reconstruire

Un prototype généré avec Lovable, Bolt, v0, Cursor ou Claude Code est un excellent point de départ, mais rarement un produit prêt à encaisser des clients. Ce qu'il faut presque toujours reprendre : les règles d'accès aux données, le modèle de données, l'intégration des paiements, la gestion des erreurs et la capacité à faire évoluer le code sans tout casser. Ce qu'il faut garder : les parcours validés par les utilisateurs, qui sont la vraie valeur du prototype.

Ce que le prototype a prouvé (et c'est beaucoup)

Avoir un prototype qui fonctionne, c'est avoir répondu à des questions que beaucoup de fondateurs se posent encore au moment de signer un devis : à quoi ressemble le produit, quels écrans comptent, ce que les premiers utilisateurs comprennent et ce qu'ils ignorent. Un prototype testé vaut un cahier des charges, en mieux. Le bon réflexe n'est pas de le jeter : c'est de le traiter comme une spécification vivante.

Ce qui pose problème, presque à chaque fois

1. L'accès aux données

C'est le point le plus critique. Les prototypes s'appuient souvent sur un back-end managé comme Supabase ou Firebase, interrogé directement depuis le navigateur. Cette architecture est sûre si les règles d'accès — les politiques RLS de Supabase, les règles de sécurité de Firebase — sont correctement écrites pour chaque table. Dans un prototype généré rapidement, elles sont souvent absentes, trop permissives ou contournables. Résultat : un utilisateur un peu curieux peut lire, voire modifier, les données des autres.

2. Les secrets exposés

Clés d'API d'un fournisseur de modèle ou de paiement placées dans le code envoyé au navigateur : n'importe qui peut les récupérer et les utiliser à vos frais. Tout appel à un service payant doit passer par un serveur.

3. Le modèle de données

Les tables ont été créées au fil des demandes, sans vision d'ensemble : données dupliquées, absence de notion d'organisation pour un produit B2B, champs texte là où il faudrait des relations. Ce qui fonctionne avec dix utilisateurs de test devient ingérable avec des clients payants, et chaque migration ultérieure coûte plus cher.

4. Les paiements

Un bouton qui ouvre une page de paiement n'est pas une intégration. Un SaaS doit gérer les renouvellements, les échecs de paiement, les changements d'offre, les annulations, les factures et la synchronisation de l'état de l'abonnement via les webhooks de Stripe. C'est rarement présent dans un prototype.

5. La maintenabilité

Le code généré par itérations successives accumule les incohérences : trois façons différentes de faire la même chose, des composants dupliqués, aucun test. Chaque nouvelle demande à l'outil de génération risque de casser une fonctionnalité existante sans que personne ne s'en aperçoive.

Notre méthode de reprise

1. 01Audit : sécurité des accès, secrets, modèle de données, dépendances, qualité du code. Nous livrons une liste priorisée, avec ce qui bloque un lancement et ce qui peut attendre.
2. 02Décision : consolider l'existant ou reconstruire sur une base saine. Quand le prototype est petit, reconstruire en reprenant ses écrans et ses parcours est souvent plus rapide que corriger.
3. 03Socle : authentification, organisations, règles d'accès, paiements, administration, mesure d'usage.
4. 04Migration : reprise des données et des comptes des premiers utilisateurs, sans perte.
5. 05Tests sur les parcours critiques, pour que les évolutions futures ne cassent pas ce qui fonctionne.

Faut-il arrêter d'utiliser ces outils ?

Non. Nous les utilisons nous-mêmes : les assistants de code font gagner un temps considérable à un développeur qui sait relire ce qu'ils produisent. La différence entre un prototype et un produit n'est pas l'outil utilisé, c'est la personne qui en assume les choix d'architecture et de sécurité. Continuez à prototyper vite ; faites relire avant d'encaisser le premier euro.

Combien coûte la reprise ?

Elle s'inscrit dans nos offres habituelles : à partir de 8 000 € HT pour le MVP Traction et 12 000 € HT pour le MVP Scalable, après un cadrage technique à 990 € HT (déduit ensuite du prix) qui, dans ce cas, inclut l'audit du prototype. Un prototype existant raccourcit le cadrage : les parcours sont déjà là. Les fondations à reconstruire sont détaillées dans l'architecture d'un SaaS, et notre approche sur la page développement SaaS.