De l'app générée par l'IA au produit qui tient

Tu as décrit ton idée à Lovable ou Bolt, et une après-midi plus tard, tu avais une app qui marche, déployée, cliquable. C'est un vrai exploit — le démarrage à froid, la partie qui décourage le plus de gens, est derrière toi. Reste une question honnête : entre cette démo qui tourne et un produit qui tient dans le temps, qu'est-ce qui manque, et comment le combler ?

D'abord, créditons ce qui marche

Ne boudons pas la magie : ces générateurs résolvent le problème le plus ingrat, celui de la page blanche. Échafaudage, écrans connectés, une base de données branchée, un déploiement en ligne — tout ça en quelques prompts. Pour valider une idée, montrer une maquette vivante, sentir si le truc a du sens, c'est imbattable, et c'est exactement comme ça qu'il faut commencer.

Le piège n'est pas l'outil. C'est de confondre « ça marche dans la démo » avec « c'est prêt pour de vrais utilisateurs ». Ce sont deux étapes différentes, et la seconde est tout à fait à ta portée.

Le fossé en une image : le chemin heureux

Un générateur t'offre le chemin heureux : un utilisateur, des données propres, tout le monde clique au bon endroit, rien ne casse. La démo prouve que ça peut marcher une fois.

Un produit, lui, doit survivre à tout le reste : le deuxième utilisateur qui voit les données du premier, le formulaire rempli n'importe comment, la panne à 3 h du matin, le schéma de base qu'il faudra changer dans six mois. Le fossé entre proto et produit, c'est précisément l'ensemble de ces chemins malheureux.

La bonne nouvelle : ils sont connus. On ne les découvre pas un par un dans la douleur, on les adresse méthodiquement. Voici les principaux.

L'authentification : « connecté » n'est pas « autorisé »

Le générateur câble un « login » qui fonctionne, et on croit le sujet réglé. Mais s'authentifier (prouver qui tu es) et être autorisé (avoir le droit de toucher cette donnée) sont deux choses distinctes — et c'est la seconde qui fait défaut le plus souvent.

La question que je me pose systématiquement : est-ce que l'utilisateur A peut lire ou modifier les données de l'utilisateur B ? Dans une app adossée à Supabase, ça se joue sur les politiques de sécurité au niveau des lignes (Row Level Security). Souvent, le proto fait confiance au navigateur — il cache un bouton côté client et croit le tour joué. Or un contrôle qui vit dans le navigateur n'en est pas un.

Le réflexe de pro : chaque accès aux données est revérifié côté serveur, « cet utilisateur a-t-il le droit ? », à la source. Ça ne se voit pas dans la démo, et c'est pourtant la première chose que je solidifie.

La base de données : ça tourne, mais est-ce solide ?

La base existe, les écrans la lisent, donc on passe. Sauf qu'elle a souvent grossi par à-coups : une table ajoutée par-ci au gré des fonctionnalités, sans historique clair.

Trois choses séparent une base de démo d'une base de produit :

• Les migrations. Une base sérieuse versionne ses changements de schéma, comme du code. Sans ça, tu ne peux ni reproduire ta base ailleurs, ni la faire évoluer sans stress.
• Les garde-fous. Clés étrangères, contraintes, index sur les colonnes qu'on interroge : c'est ce qui empêche les données incohérentes et les requêtes qui rampent.
• Les sauvegardes. As-tu un moyen de restaurer si quelque chose tourne mal ? Pas besoin d'usine à gaz, juste un plan.

Rien de tout ça n'est insurmontable ; c'est juste invisible tant que tout va bien.

Déploiement, environnements et le reste de l'invisible

Le générateur héberge ton app chez lui — parfait pour une démo. Pour un produit, deux ou trois habitudes changent la donne :

• Séparer les environnements. Tu ne testes pas en production. Un environnement de préproduction, une vraie base distincte, et tes secrets rangés par environnement.
• Posséder ton déploiement. Pouvoir exporter le code, le mettre sous Git, le redéployer toi-même : c'est ta porte de sortie le jour où l'outil ne suffit plus.
• Quelques tests et un œil sur la prod. Pas une couverture à 100 % — juste de quoi protéger les chemins critiques (connexion, paiement, le flux central) et un outil qui te prévient quand ça casse, avant tes utilisateurs.

Et la montée en charge ? Honnêtement, c'est rarement ton premier problème — optimiser pour des millions d'utilisateurs que tu n'as pas est un piège classique. Le vrai goulot précoce est presque toujours la base : une requête qui en déclenche cent, un index oublié. Règle ça, et tu tiendras bien plus loin que tu ne crois.

Comment franchir le pas, sans tout réécrire

Bonne nouvelle : on ne repart pas de zéro. On greffe les pratiques de produit sur le proto, couche par couche, tant qu'il est encore petit.

1. Sors le code et mets-le sous Git. À partir de là, il est à toi : historique, branches, relecture.
2. Lis-le et cartographie-le. Passe une heure à comprendre la structure — et sers-toi de l'IA pour te l'expliquer, pas seulement pour la générer. On ne maintient pas un code qu'on ne comprend pas.
3. Solidifie les frontières d'abord : l'autorisation et l'accès aux données. C'est là que démo et produit divergent le plus.
4. Ajoute migrations et préproduction. Arrête d'éditer la prod.
5. Écris une poignée de tests sur ce qui ferait mal en cassant, puis branche un suivi des erreurs.

Chaque étape rend la suivante plus facile, et à aucun moment tu n'es bloqué.

En résumé

Le générateur ne t'a pas vendu un mensonge : il t'a offert un vrai départ, et c'était le plus dur. La suite — autorisation, base propre, environnements, tests — n'est ni magique ni réservée aux initiés ; c'est un chemin balisé que tu peux parcourir à ton rythme, en gardant la main. Prototyper vite puis solidifier posément : c'est exactement ça, vibecoder comme un pro.