La réponse courte
Oui, une application vibe-codée peut être reprise.
Le code produit avec Lovable, Bolt, v0, Cursor ou Claude Code n'est pas automatiquement jetable. La bonne question n'est pas « qui a écrit le code ? », mais « peut-on expliquer, tester, sécuriser et exploiter ce produit sans dépendre d'un prompt chanceux ? »
Votre prototype fonctionne. Les utilisateurs comprennent la promesse. Peut-être avez-vous même déjà des inscriptions, des données ou des paiements. Puis les changements deviennent plus risqués : une correction casse un autre écran, les règles d'accès à la base sont difficiles à expliquer et personne ne sait vraiment si l'application peut accueillir cent utilisateurs — encore moins dix mille.
C'est généralement à ce moment qu'une reprise technique devient utile. Elle ne consiste pas à mépriser le travail réalisé avec l'IA, ni à tout réécrire par réflexe. Elle consiste à établir ce qui est fiable, ce qui doit être consolidé et ce qui engage réellement votre entreprise.
Le principal risque n'est pas que l'IA ait écrit une partie du code. C'est qu'aucune personne n'en assume encore la cohérence technique.
Dossier de reprise · 01
Six preuves à réunir avant de parler de production
Une démo convaincante prouve que l'idée peut fonctionner. Ces six points indiquent si le produit peut fonctionner durablement.
- 01À vérifier
Code sous contrôle
Dépôt Git accessible, historique exploitable, dépendances identifiées et procédure de démarrage reproductible.
- 02Critique
Données protégées
Règles d'accès vérifiées côté serveur, secrets hors du navigateur, sauvegardes testées et données sensibles localisées.
- 03Critique
Identités maîtrisées
Inscription, récupération de compte, rôles, permissions et suppression des données suivent des règles explicites.
- 04À vérifier
Parcours testables
Les flux qui créent de la valeur — paiement, réservation, partage, synchronisation — disposent de contrôles reproductibles.
- 05Critique
Exploitation prévue
Staging, déploiement, monitoring, alertes, restauration et responsabilité en cas d'incident sont définis.
- 06À vérifier
Distribution conforme
Confidentialité, consentements, SDK tiers, permissions et exigences Apple/Google sont traités avant la soumission.
Un point rouge n'impose pas une réécriture complète. Il indique simplement où l'incertitude doit être remplacée par une preuve.
Dossier de reprise · 02
Quatre issues possibles — dont une seule consiste à tout refaire
L'objectif d'un audit n'est pas de vendre la solution la plus lourde. Il doit permettre une décision proportionnée au produit, aux données et au prochain jalon business.
Quand
Architecture lisible, risques limités, parcours critiques stables.
Décision
Fermer les derniers écarts, documenter et préparer le lancement.
Quand
Produit utile, mais tests, sécurité ou exploitation restent incomplets.
Décision
Corriger les risques prioritaires sans toucher à ce qui fonctionne.
Quand
L'interface tient, mais la donnée, l'authentification ou le backend sont fragiles.
Décision
Conserver l'expérience validée et remplacer uniquement la fondation concernée.
Quand
Le modèle de données, les flux métier et l'interface se contredisent profondément.
Décision
Capitaliser sur les apprentissages du prototype, pas nécessairement sur son code.
Dossier de reprise · 03
Comment reprendre une app sans casser ce qu'elle a déjà validé
La reprise doit réduire l'incertitude dans un ordre précis. Commencer par refactorer des composants visuels est rarement le meilleur usage du budget.
- 01
Figer une version de référence
On sauvegarde le dépôt, les environnements et les données, puis on documente les parcours qui fonctionnent aujourd'hui.
Livrable
Baseline reproductible
- 02
Auditer par risque
On examine d'abord les accès aux données, les secrets, les paiements, l'authentification et les dépendances critiques.
Livrable
Matrice de criticité
- 03
Choisir ce que l'on conserve
Chaque couche reçoit une décision explicite : garder, corriger, isoler ou remplacer. Le raisonnement est documenté.
Livrable
Plan de reprise chiffré
- 04
Prouver avant de lancer
Tests ciblés, environnement de staging, monitoring et répétition du déploiement remplacent le « ça marche chez moi ».
Livrable
Go / no-go de lancement
Cas particulier · Mobile
Un déploiement web n'est pas encore une app publiable
Une interface générée pour le web peut servir de base produit, mais la publication sur l'App Store et Google Play ajoute des responsabilités que la prévisualisation ne montre pas.
- Comportements natifs, navigation, clavier, gestes et fonctionnement sur de vrais appareils
- Permissions, notifications, deep links, achats intégrés et gestion des comptes
- Déclarations de confidentialité, collecte de données et responsabilité des SDK tiers
- Builds signés, certificats, fiches store, captures, review et stratégie de mises à jour
Le code est souvent récupérable. La responsabilité ne s'exporte pas en un clic.
Lovable et Bolt permettent de synchroniser ou d'exporter le code, tandis que v0 s'intègre à un projet Vercel. C'est une excellente base pour commencer une reprise. Cela ne remplace toutefois ni la revue du produit, ni les décisions de sécurité, ni la préparation des stores.
Lovable → GitHub
Synchronisation du code pour sauvegarde, collaboration et travail local.
Bolt → GitHub
Historique Git et possibilité de poursuivre le travail hors de Bolt.
v0 → Vercel
Projet Vercel associé pour le déploiement et les ressources d'exécution.
Expo → Stores
Builds et soumissions iOS/Android avec les prérequis propres à chaque store.
Apple et Google rendent le développeur responsable du comportement de l'app, de ses SDK et de ses déclarations de confidentialité. L'export du code n'est donc que le début de la reprise.
Questions fréquentes
Faut-il forcément réécrire une application créée avec Lovable ou Bolt ?
Non. Les interfaces, les parcours et une partie de la logique peuvent souvent être conservés. La décision doit être prise couche par couche après examen du code, des données et des risques métier.
Une app vibe-codée est-elle sécurisée ?
Impossible de le conclure depuis une démonstration. Il faut vérifier notamment les règles d'accès à la base, les secrets, les rôles, les dépendances, les fichiers envoyés et les données exposées au navigateur.
Peut-on reprendre le code d'un projet Lovable ?
Oui. Lovable permet de synchroniser un projet avec GitHub. Le dépôt peut ensuite être audité et développé avec un workflow d'ingénierie classique.
Peut-on transformer une web app vibe-codée en application mobile ?
Oui, mais ce n'est pas un simple emballage. Il faut adapter l'expérience aux usages mobiles, choisir une architecture comme Expo et React Native, puis traiter les permissions, les builds, la confidentialité et les règles des stores.
Combien de temps prend un audit de reprise ?
Cela dépend du périmètre et de la qualité du dépôt. Un audit utile doit au minimum couvrir l'architecture, la sécurité, les données, les parcours critiques, l'exploitation et produire un plan priorisé plutôt qu'une liste générique de remarques.
Quelle est la première chose à faire avant de confier l'app à une équipe ?
Créer une version de référence : dépôt Git sauvegardé, accès documentés, variables d'environnement inventoriées, copie des données et liste des parcours qui fonctionnent. Cette baseline évite de perdre les acquis pendant la reprise.
Votre prochain jalon
Savoir ce qui mérite d'être gardé avant d'investir davantage.
Appik Studio audite et reprend des applications web et mobiles depuis Lausanne. Vous recevez une lecture claire des risques, des éléments réutilisables et du chemin réaliste vers le lancement.
Demander un diagnostic de reprise
Swiss Made Software
