Reprendre un projet vibe codé et l'amener en production

Reprendre un projet vibe codé, c'est-à-dire une application construite en décrivant à une IA ce que vous vouliez jusqu'à obtenir un résultat qui fonctionne, commence par un état des lieux de l'existant, jamais par une réécriture à l'aveugle. Le scénario est devenu courant dans les PME : un dirigeant ou un collaborateur a construit en quelques soirées un outil qui tourne sur sa machine, il rend déjà service, et il reste pourtant bloqué à la porte de la vraie mise en service. Pas de comptes pour les collègues, des données d'exemple à la place des vraies, une clé copiée dans le code. Vous avez bien fait de commencer : ce guide fait le tri entre ce que votre prototype a déjà réglé, ce qui manque réellement poste par poste, et les trois issues possibles pour le finir.

Ce que votre prototype a déjà réglé

Un prototype vibe codé qui fonctionne a déjà réglé trois problèmes que beaucoup de projets logiciels classiques n'atteignent jamais. Le besoin est validé : vous utilisez l'outil, il vous fait gagner du temps, la question « est-ce que quelqu'un s'en servira » est déjà tranchée. Le périmètre est clair : l'application montre concrètement ce qui doit exister, écran par écran, là où un projet classique démarre sur des suppositions. Et surtout, votre prototype est un cahier des charges exécutable : un développeur qui le prend en main comprend en une heure ce que cent pages de spécifications n'auraient pas dit, parce qu'il peut cliquer dedans, observer les données et constater ce qui casse.

Qu'il soit sorti de Lovable, de Bolt, de Cursor ou de Claude Code, ce travail a de la valeur, et il serait absurde de le jeter par principe. Les promesses et les limites de la pratique sont posées dans le guide complet du vibe coding. Ce guide-ci démarre là où le pilier s'arrête : au moment où le prototype doit devenir un service.

Du vibe coding à la production : ce qui manque, poste par poste

Six postes séparent un prototype qui tourne sur votre machine d'un service que d'autres peuvent utiliser : les comptes, les données réelles, les erreurs, les secrets, l'hébergement et la conformité. Aucun ne relève de la génération de code, tous relèvent de l'ingénierie d'exploitation.

Les comptes et les droits d'accès

Sur votre machine, vous êtes le seul utilisateur et tous les droits vous appartiennent. En service réel, il faut des comptes individuels, une distinction entre ce que chacun peut voir et modifier, et une procédure quand quelqu'un quitte l'équipe. C'est souvent le premier mur : l'IA a généré une application mono-utilisateur parce que vous étiez seul à la tester.

Les données réelles

Votre prototype a tourné sur des données d'exemple ou sur un extrait copié à la main. Les données réelles sont plus volumineuses, plus sales et plus sensibles : doublons, champs vides, formats hérités d'un vieil export. Il faut décider où elles vivent, qui les sauvegarde, et comment on les restaure après une fausse manipulation.

Les erreurs et les pannes

Un prototype qui plante se relance à la main, et vous seul savez le faire. Un service doit encaisser les pannes sans perdre de données : le service externe qui ne répond plus, le fichier mal formé, la coupure en plein traitement. Et si votre application appelle elle-même un LLM, le grand modèle de langage qui comprend et produit du texte, ses indisponibilités et ses coûts à l'usage deviennent votre problème d'exploitation.

Les secrets et les clés

Les clés d'API, ces interfaces par lesquelles vos logiciels communiquent directement entre eux, se retrouvent fréquemment écrites en clair dans le code généré. Tant que le projet reste sur votre machine, personne ne les voit. Dès qu'il est partagé ou mis en ligne, une clé exposée permet à n'importe qui de consommer vos services payants ou de lire vos données. En production, les secrets vivent hors du code, se limitent au strict nécessaire et peuvent être révoqués.

L'hébergement

« Ça marche chez moi » n'est pas un hébergement. Il faut un serveur qui tourne quand votre ordinateur est éteint, un nom de domaine, des sauvegardes, des mises à jour de sécurité et une alerte quand le service tombe. Les plateformes de création proposent un hébergement intégré pensé pour publier vite : la vraie question est celle de la dépendance. Que se passe-t-il si l'outil change ses conditions, et comment récupérez-vous votre application pour l'héberger ailleurs ?

La conformité RGPD, si des données personnelles circulent

Dès que l'application manipule des noms, des emails ou des dossiers clients, le RGPD, le règlement européen qui encadre l'usage des données personnelles, s'applique : savoir où les données sont hébergées, qui y accède et comment les effacer. Un outil personnel passe sous le radar en pratique. Un outil utilisé par vos équipes sur de vrais clients, non.

Les trois issues honnêtes

Un projet vibe codé bloqué a trois issues : le finir vous-même, le faire reprendre par un développeur, ou le refaire sur un socle propre. La bonne dépend du risque que porte l'outil, pas du temps que vous y avez investi.

Finir seul est légitime quand le périmètre reste personnel et le risque faible : l'outil ne sert qu'à vous, aucune donnée de client n'y circule, une panne coûte du confort et non du chiffre d'affaires. Continuez avec les mêmes outils, en traitant les postes ci-dessus un par un, en commençant par les secrets.

Faire reprendre s'impose dès que des clients ou des données réelles entrent en jeu. À ce stade, une clé exposée ou une base perdue ne sont plus des incidents d'apprentissage, ce sont des dommages pour l'entreprise. Les critères pour identifier un profil sérieux sont détaillés dans le guide pour choisir un freelance IA.

Refaire sur un socle propre est parfois l'option la moins chère, et il faut le dire honnêtement. Quand le code s'est empilé au fil de demandes contradictoires, le remettre d'équerre coûte parfois plus que reconstruire les mêmes fonctions proprement. Refaire n'est pas repartir de zéro : votre prototype sert de cahier des charges exécutable, et c'est précisément ce qui rend la reconstruction rapide. Un développeur honnête tranche après l'état des lieux, jamais avant.

Comment un développeur reprend ce type de projet

Un développeur sérieux commence par un état des lieux, jamais par une réécriture. Concrètement : il fait tourner l'application, déroule les scénarios qui marchent et ceux qui cassent, lit le code généré, et passe les six postes en revue un par un. Il en sort un verdict écrit : ce qui se garde en l'état, ce qui se répare, ce qui se refait, dans quel ordre et pour quel budget. C'est exactement le périmètre d'un audit IA : un diagnostic indépendant qui aboutit à un plan d'action, que vous restez ensuite libre de confier à qui vous voulez.

Méfiez-vous du prestataire qui prononce « tout est à refaire » avant d'avoir fait tourner votre application. Ce verdict est parfois vrai, mais il ne peut pas être honnête avant l'état des lieux : personne ne peut évaluer un système sans l'avoir vu fonctionner.

La marche entre prototype et production n'a rien de théorique. Sur la plateforme conversationnelle de Labo M, qui guide les clients dans un catalogue de 72 000 références et résout 90 % des requêtes sans intervention humaine, une grande partie du travail a précisément porté sur ces postes : les pannes, les filtres de budget, la traçabilité de chaque réponse pour pouvoir auditer le système en production. Le cœur IA compte, mais c'est l'exploitation qui fait qu'un chiffre tient dans la durée.

Préparer la passation : ce qu'il faut montrer

Une passation réussie tient à quatre choses que vous êtes seul à pouvoir transmettre. D'abord le prompt d'origine, c'est-à-dire les instructions que vous avez données à l'IA, et si possible l'historique de vos conversations avec l'outil : il raconte les décisions prises en chemin, les demi-tours, les fonctions abandonnées. Ensuite la liste des scénarios qui marchent, ceux que vous utilisez réellement, dans l'ordre où vous les enchaînez. Puis la liste des cas qui cassent : chaque bug connu, même contourné depuis des semaines par une petite manipulation dont vous avez pris l'habitude, fait gagner des heures de découverte au repreneur. Enfin l'inventaire des branchements : quels services externes, quels comptes, créés avec quelle adresse email, et qui en détient les accès aujourd'hui.

Vous n'avez pas à produire de documentation technique, c'est le travail du repreneur. Votre rôle est de transmettre ce que le code ne dit pas.

Votre prototype fonctionne et la mise en service bloque ? C'est le bon moment pour un regard extérieur, pas le signe d'un échec. Le premier échange est gratuit et sert à qualifier le projet : ce qui se garde, ce qui manque, et laquelle des trois issues correspond à votre situation. Décrivez votre besoin via la page consultant IA, en amenant votre prototype tel qu'il est. Je suis Antoine Guerra, développeur IA freelance, ex-CTO, dans l'IA depuis 2018, et j'utilise quotidiennement les outils de développement assisté par IA qui ont produit votre prototype. Je réponds avec un devis sous 48 h.