Du vibe coding au produit: que faire de votre prototype généré par IA ?

Une nouvelle catégorie de clients est née en 2025 : le fondateur qui arrive avec un produit déjà construit. Pas un cahier des charges, pas une maquette : une application qui tourne, générée avec un outil d’IA, avec de vrais utilisateurs dessus. Sa question n’est plus « pouvez-vous le construire ? » mais « pouvez-vous en faire un vrai produit ? ». C’est une excellente question, et elle mérite une réponse d’ingénieur plutôt qu’un réflexe corporatiste. La voici.

Pourquoi un prototype vibe-codé n’est-il pas un produit ?

Parce qu’un prototype et un produit répondent à deux questions différentes. Le prototype répond à « est-ce que ça vaut le coup ? » : il doit être rapide, convaincant et jetable. Le produit répond à « est-ce que ça tient ? » : face à la charge, aux attaques, aux données réelles et aux années. Le vibe coding, cette pratique qui consiste à générer son application en la décrivant à une IA sans lire le code produit, excelle à la première question et n’a jamais prétendu répondre à la seconde.

Le point dur est la sécurité, et il est documenté : la presse spécialisée, relayant les études du secteur, constate que les plateformes de génération produisent régulièrement du code non sécurisé, y compris des failles classées critiques, et que le phénomène s’aggrave précisément quand la logique métier devient prépondérante (CIO Online, les bons et les mauvais points du vibe coding). Rien d’étonnant pour qui lit le code généré : l’IA optimise pour que ça marche en démo, pas pour ce qui n’apparaît dans aucune démo, le contrôle des accès, la validation des entrées, la gestion des cas d’erreur. Les fondamentaux d’hygiène qu’exige tout système en production (guide d’hygiène informatique, ANSSI) sont exactement ce que le prototype ignore par construction.

Trois vérifications donnent la température en dix minutes, avant tout audit : créez deux comptes et essayez de voir les données de l’autre ; mettez dix utilisateurs simultanés sur l’application ; cherchez des clés d’API dans le code. Le résultat surprend rarement.

Que trouve-t-on en ouvrant un prototype vibe-codé ?

Toujours les mêmes patterns, à des degrés divers, et les nommer aide à dédramatiser : aucun n’est une honte, tous sont la signature d’un outil qui optimise la vitesse de démonstration.

• Les secrets dans le code. Clés d’API, mots de passe de base de données et identifiants de services tiers écrits en clair dans les fichiers, parfois publiés dans un dépôt accessible. C’est la première chose à vérifier et la première à corriger, avant même toute décision de reprise.
• L’absence de frontière entre les utilisateurs. L’application affiche les données du compte connecté parce que l’interface le veut bien, pas parce que le serveur l’impose : changer un identifiant dans l’adresse suffit souvent à lire les données d’un autre. En démo, invisible ; avec de vrais clients, c’est une fuite de données en attente.
• La duplication massive. La même logique recopiée à chaque écran avec de légères variantes, parce que chaque génération repart de sa propre inspiration. Conséquence : corriger un comportement impose de le retrouver partout, et il manque toujours un endroit.
• Les dépendances fantômes. Des dizaines de briques installées au fil des générations, dont la moitié ne sert plus, jamais mises à jour, chacune avec sa surface d’attaque. Personne ne les a choisies : elles se sont accumulées.
• Le bonheur permanent. Aucune gestion des cas d’échec : que se passe-t-il si le paiement est refusé, si le réseau coupe au milieu d’une saisie, si deux personnes modifient la même chose ? Le prototype vit dans un monde où tout se passe bien ; la production est précisément l’endroit où tout finit par mal se passer une fois.

Cette liste explique le paradoxe apparent de ces reprises : le prototype peut être fonctionnellement excellent et techniquement irrécupérable, sans contradiction. Ce sont deux couches différentes du même objet.

Que garde-t-on, que réécrit-on ?

La valeur du prototype ne se mesure pas en lignes de code : elle est dans ce que l’usage a validé. Voici le partage tel qu’il se constate sur ces reprises :

La colonne de gauche explique pourquoi ces projets coûtent moins cher qu’ils n’en ont l’air : le prototype a déjà accompli la partie la plus incertaine et la plus coûteuse d’un projet logiciel, savoir quoi construire. Il joue exactement le rôle de spécification vivante qu’un outil no-code saturé joue pour d’autres projets, et la logique de reprise est cousine de celle que nous avons détaillée pour un logiciel resté sans développeur : diagnostiquer d’abord, décider ensuite.

Comment se déroule la reprise, concrètement ?

1. Auditez l’existant en quelques jours. Lecture du code généré, revue des accès et de l’hébergement, cartographie de ce qui existe réellement derrière les écrans. Objectif : décider en connaissance, pas au réflexe. Il arrive qu’une partie du code soit saine et se garde ; il arrive aussi que tout se réécrive, et le prototype n’en a pas moins rempli sa mission.
2. Extrayez la logique métier. Chaque règle, chaque calcul, chaque cas particulier découvert pendant la vie du prototype est documenté en français avant d’être réimplémenté. L’IA d’aujourd’hui aide d’ailleurs remarquablement à cette extraction : lire et expliquer du code est ce qu’elle fait de plus fiable.
3. Reconstruisez sur un socle éprouvé. Authentification, droits, API, base de données : ces fondations existent en standard sur notre socle open source FastEdgy, et n’ont aucune raison d’être régénérées différemment à chaque produit. Le budget se concentre sur ce qui vous différencie.
4. Testez ce qui compte. Les parcours critiques (inscription, paiement, cœur métier) se couvrent de tests automatisés : c’est ce qui permettra de faire évoluer le produit chaque semaine sans jouer sa production à chaque mise à jour.
5. Basculez proprement. Migration des données par import rejouable, période de recouvrement courte, et le prototype part en archive avec les honneurs.

Le budget suit la grille canonique d’un développement SaaS : 12 000 à 30 000 € HT pour un MVP de production en 4 à 8 semaines, la borne exacte dépendant du périmètre validé et de ce que l’audit permet de conserver. Trois facteurs tirent vers le bas de la fourchette : un périmètre resserré par l’usage réel (le prototype a déjà montré ce qui ne sert pas), des règles métier documentées plutôt qu’à redécouvrir, et l’absence de débat sur les écrans, déjà arbitrés par les utilisateurs. Trois facteurs tirent vers le haut : des paiements à reprendre proprement, un volume de données à migrer avec historique, et des utilisateurs actifs qu’il faut basculer sans interruption. La suite (hébergement, évolutions, mises à jour) relève du même régime de maintenance que tout produit vivant.

La reprise interrompt-elle le service pour vos utilisateurs ?

Non, et c’est un point que les fondateurs n’osent pas toujours demander : la reconstruction se mène en parallèle du prototype, qui continue de tourner pendant toute la durée du chantier. Vos utilisateurs ne voient rien jusqu’au jour de bascule, préparé comme toute migration sérieuse : données importées par un script rejouable, répétition à blanc, comparaison des totaux, puis bascule un soir calme avec l’ancien système gardé en secours quelques semaines.

La seule règle contraignante pendant la période de recouvrement : geler les évolutions du prototype. Continuer d’y générer des fonctionnalités pendant que la version de production se construit, c’est courir après une cible mouvante et payer deux fois chaque idée. Les nouvelles demandes s’empilent dans le backlog de la V1, où elles arrivent sur des fondations qui les porteront durablement, au rythme d’une release par semaine.

Faut-il regretter d’être passé par le vibe coding ?

Non, et il faut le dire contre une partie de notre propre corporation : le fondateur qui arrive avec un prototype vibe-codé et cinquante utilisateurs actifs a mieux travaillé que celui qui arrive avec un cahier des charges de soixante pages et zéro utilisateur. Il a validé sa demande pour quelques centaines d’euros là où d’autres brûlent 20 000 € à construire un produit dont personne ne veut. Nous utilisons ces mêmes outils quotidiennement, et l’IA a transformé notre façon de produire, nous l’avons documenté dans développer son SaaS en 2026 : le sujet n’a jamais été l’outil, c’est de savoir ce qu’on lui confie.

Et pour la suite, rien n’oblige à choisir entre générer et construire sérieusement : notre propre pratique combine les deux, l’IA produit, des seniors relisent, testent et assument chaque ligne en production. La différence entre le vibe coding et le développement assisté n’est pas l’outil, c’est la présence d’un regard d’ingénieur entre la génération et vos clients. Un fondateur peut parfaitement continuer à prototyper ses idées en génération libre, sur un environnement séparé, pendant que son produit de production avance sous revue : les deux vitesses coexistent très bien quand elles ne partagent pas le même code.

Le seul vrai piège est le déni de bascule : continuer d’empiler des fonctionnalités générées sur un socle que personne ne comprend, avec de vrais clients et de vraies données dessus. Chaque semaine dans cet état augmente à la fois la surface de risque et le coût de la reprise, exactement comme une dette technique qu’on laisse composer. Les signaux qu’il est temps : des paiements réels, des données personnelles en volume, un premier client B2B qui envoie un questionnaire de sécurité, ou cette sensation que plus personne n’ose toucher à rien. Un quatrième signal mérite d’être ajouté depuis peu : l’assureur ou le client grand compte qui demande qui a écrit le code et qui en répond, question à laquelle « une IA, et personne » est une réponse commercialement mortelle. Si vous hésitez entre continuer seul et passer la main, la carte complète des options est dans créer un SaaS sans être développeur.

Le diagnostic, lui, ne coûte rien : 30 minutes en visio avec un fondateur, l’accès à votre prototype, et vous saurez ce qui se garde, ce qui se réécrit, en combien de semaines et pour quel budget. Montrez-nous ce que vous avez construit : l’avoir construit est déjà la meilleure preuve que votre projet en vaut la peine.