Apprenez à exporter proprement le code source d'une plateforme vibe‑coding et à en prendre la main : lancez en local, configurez la CI, gérez les secrets et préparez un dépôt prêt à la remise.
Posséder le code, ce n'est pas seulement recevoir un zip d'une plateforme. C'est pouvoir builder, exécuter, modifier et livrer l'app sans dépendre de l'espace de travail original, de boutons spéciaux ou de réglages cachés. Un projet que vous possédez vraiment se comporte comme un dépôt normal : un nouveau coéquipier peut le cloner, le lancer sur son laptop et le déployer via un pipeline standard.
La plupart des inquiétudes liées au lock‑in viennent de quelques manques récurrents :
Autre surprise fréquente : l'app fonctionne sur la version hébergée mais échoue en local parce que les variables d'environnement, la configuration de la base ou les secrets n'ont jamais été explicités.
Un export propre depuis une plateforme vibe‑coding doit aboutir à quatre résultats :
Cela importe même si vous n'envisagez jamais de quitter la plateforme. Une posture de propriété solide est une assurance : elle réduit le risque, facilite les audits et simplifie les négociations si vous engagez une agence, levez des fonds ou changez d'équipe.
Si vous avez utilisé Koder.ai, votre export peut inclure des stacks courants comme une app web React, un backend Go, PostgreSQL ou une app mobile Flutter. La stack importe moins que le principe : tout ce qui est nécessaire pour exécuter doit être visible dans le dépôt, pas enfermé dans un environnement hébergé.
Imaginez un fondateur confiant une app à un prestataire. « Voici le repo » devrait suffire. Le prestataire ne devrait pas avoir besoin d'accéder au projet original sur la plateforme pour trouver l'URL de l'API, créer le schéma de la base ou apprendre à builder le frontend.
Après export, vous devriez avoir un dépôt normal que vous pouvez ouvrir dans un éditeur, lancer sur votre laptop et transmettre à une autre équipe sans dépendre de la plateforme d'origine.
Avec les projets Koder.ai, les exports correspondent souvent à des structures familières : une app web React, un backend Go et (si vous en avez construit une) une app mobile Flutter. Les noms de dossiers varient, mais le dépôt devrait indiquer clairement où vit chaque partie et comment elles se connectent.
Commencez par localiser les points d'entrée et le workflow attendu. Vous voulez le premier fichier qui démarre chaque app, ainsi que les scripts qui montrent comment développer et lancer.
Signes typiques :
package.json plus un dossier src/ (souvent avec main.tsx ou similaire)go.mod et un dossier cmd/ ou main.gopubspec.yaml de Flutter et lib/main.dartREADME ou Makefile à la racine qui décrit comment lancer le toutdocker-compose.yml si l'export est destiné à s'exécuter comme un ensemble de servicesLes dépendances doivent être verrouillées. Pour JavaScript, cela signifie un lockfile (package-lock.json, yarn.lock ou pnpm-lock.yaml). Pour Go, il s'agit de go.mod et go.sum. L'absence de verrous n'empêche pas d'exécuter le projet, mais rend les builds reproductibles plus difficiles.
La configuration doit être séparée du code. Cherchez des exemples comme .env.example ou config.example.yaml. Vous ne devriez pas voir de vrais secrets (clés API, mots de passe de production) committés dans l'export. Si c'est le cas, traitez‑les comme une fuite et révoquez‑les.
Pour la partie base de données, trouvez un dossier de migrations (migrations/, db/migrations/) ou des fichiers SQL horodatés. Dans une app Go + PostgreSQL, vous pouvez aussi voir un petit runner de migrations ou un script qui applique les migrations.
Un contrôle rapide : localisez d'abord les commandes de build et d'exécution (npm run dev, go run, make, etc.). Si un script dépend d'une commande spécifique à la plateforme, remplacez‑la par des outils standard avant de rendre le dépôt indépendant.
Traitez l'export comme un artefact de release. Avant d'exécuter quoi que ce soit, faites une passe rapide « est‑ce que tout est là ? ». Les éléments manquants sont plus faciles à repérer maintenant que lorsque vous commencez à modifier le code.
Une vérification pratique de complétude consiste à chercher les « racines » de chaque partie : un package.json pour une app React, un go.mod pour un backend Go, et des fichiers de migration/seed pour PostgreSQL.
Créez un dépôt Git frais depuis le dossier exporté, puis commitez exactement ce que vous avez reçu avant de corriger quoi que ce soit. Cela vous donne une baseline propre et rend les changements ultérieurs faciles à relire.
git init
# Optional: set default branch name
# git branch -M main
git add -A
git commit -m "Initial export"
Ensuite, lancez en local par petites étapes vérifiables. Installez les dépendances, créez la configuration locale, démarrez la base de données d'abord, puis le backend, puis le frontend. Pendant que vous le faites, notez chaque commande réellement utilisée. Ces notes deviendront votre README.
Voici une séquence simple à adapter à votre structure exportée :
# Frontend
cd web
npm install
npm run dev
# Backend
cd ../server
go mod download
go run ./cmd/server
Un serveur peut démarrer alors que l'app est cassée. Vérifiez qu'il peut lire et écrire des données.
Choisissez des vérifications rapides adaptées au produit :
Une fois que vous avez un lancement local fonctionnel, transformez votre brouillon en un vrai README.md avec des étapes copiable/collable : où lancer les commandes, l'ordre de démarrage des services et quelles variables d'environnement sont requises.
Un export peut fonctionner, mais sembler "généré" plutôt que possédé. Un dépôt prêt pour le handoff explique clairement où vivent les choses, comment lancer le projet et comment le maintenir cohérent.
Commencez par une mise en page claire au niveau racine. Les noms importent moins que la cohérence.
apps/ pour les frontends visibles par l'utilisateur (web, mobile)services/ pour les APIs backend, workers et jobsshared/ pour types et utilitaires partagésinfra/ pour templates de déploiement, scripts et exemples d'envdocs/ pour notes d'architecture et runbooksAjoutez ensuite un petit ensemble de fichiers qui réduisent les conjectures :
README.md avec prérequis et commandes exactesCONTRIBUTING.md avec quelques règles (branches, PRs, pas de secrets).gitignore pour éviter de committer des fichiers d'env locaux et des sorties de buildGardez le README pratique. Si le dépôt contient plusieurs parties (frontend React, API Go, PostgreSQL), indiquez l'ordre de démarrage et où se trouve la configuration (par ex. "copiez .env.example en .env").
Faites un test sur une machine propre : clonez dans un dossier neuf et suivez votre propre README. Si vous avez exporté depuis Koder.ai, traitez l'export comme le premier commit d'un nouveau projet indépendant, puis seulement après invitez d'autres personnes.
Une bonne configuration locale répond rapidement à une question : une nouvelle personne peut‑elle lancer l'app en moins de 15 minutes sans deviner ?
Choisissez une approche locale par défaut et soyez explicite. Les installations natives sont rapides pour ceux qui ont déjà les bons outils. Les conteneurs sont plus cohérents entre machines mais ajoutent de la complexité. Si vous supportez les deux, indiquez l'une comme défaut et l'autre comme optionnelle.
Un schéma simple qui fonctionne bien : une page README, un fichier d'exemple d'env et une commande de bootstrap.
Commettez un fichier d'exemple avec des valeurs factices pour que les gens sachent quoi renseigner sans exposer de secrets.
# .env.example (valeurs d'exemple seulement)
APP_ENV=local
PORT=8080
DATABASE_URL=postgres://app_user:app_pass@localhost:5432/app_db?sslmode=disable
JWT_SECRET=change-me
API_BASE_URL=http://localhost:8080
Dans le README, expliquez où vit le fichier réel (par exemple, "copiez en .env") et quelles variables sont obligatoires ou optionnelles.
Ajoutez un petit script qui exécute les étapes ennuyeuses dans le bon ordre. Gardez‑le lisible.
#!/usr/bin/env bash
set -euo pipefail
cp -n .env.example .env || true
# Backend deps
cd backend
go mod download
# Database: create, migrate, seed
./scripts/db_create.sh
./scripts/db_migrate.sh
./scripts/db_seed.sh
# Frontend deps
cd ../web
npm install
Pour le plan base de données, documentez trois choses : comment créer la BDD, comment les migrations sont appliquées et comment obtenir des données de seed réalistes pour un premier lancement.
Enfin, ajoutez un petit health check pour confirmer que l'app fonctionne avant de cliquer partout. Un endpoint minimal comme GET /health retournant "ok" (et vérifiant la connectivité à la BDD) suffit souvent.
Quand vous exportez un projet, le code peut vous appartenir, mais les secrets doivent rester privés. Considérez que le dépôt sera partagé avec de nouveaux coéquipiers.
Commencez par lister ce dont l'app a besoin pour tourner. Ne devinez pas. Parcourez le code pour repérer les lectures de configuration (variables d'environnement, fichiers de config) et vérifiez les intégrations activées.
Un inventaire basique des secrets inclut généralement les identifiants de base de données, les clés d'API tierces, les réglages d'auth (OAuth ou JWT), les identifiants de stockage et les secrets propres à l'app comme les clés de chiffrement ou de signature de webhooks.
Décidez où se trouve chaque secret par environnement. Une bonne règle par défaut :
.env géré par le développeur (non committé)Si vous avez exporté depuis une plateforme vibe‑coding comme Koder.ai, supposez que tout ce qui a été affiché en chat, logs ou panneaux de réglages a pu être copié. Sortez les secrets du dépôt immédiatement.
Approche pratique : commettez un template sûr (comme .env.example), gardez les vraies valeurs hors de Git (ajoutez .env à .gitignore) et injectez les secrets de production au moment du déploiement.
S'il y a un risque que des secrets aient fuité lors de l'export, révoquez‑les. Priorisez les mots de passe de base, les secrets clients OAuth et les clés de signature de webhooks.
Ajoutez quelques garde‑fous pour éviter que ça ne se reproduise : un pre‑commit qui cherche les patterns évidents de secrets, un scan de secrets en CI, un chargement de config strict qui échoue rapidement si une variable requise manque, et des identifiants séparés par environnement.
Un court SECRETS.md aide pour les handoffs. Restez simple : variables requises, où elles sont stockées par environnement et qui peut les révoquer.
Considérez la prise de propriété comme de l'indépendance : vous pouvez builder, exécuter, modifier et déployer l'application depuis un dépôt classique sans avoir besoin du projet original sur la plateforme, de réglages UI spéciaux ou d'étapes de build cachées.
Un bon test : un nouveau membre de l'équipe peut-il cloner le dépôt et le lancer en se servant seulement du README ?
Commencez par une vérification rapide de complétude :
package.json, go.mod, pubspec.yaml).package-lock.json, yarn.lock, pnpm-lock.yaml, go.sum).migrations/ ou équivalent).Makefile, scripts ou docker-compose.yml).Si quelque chose nécessaire au démarrage n'existe qu'en UI ou en chat, notez-le et déplacez-le dans le dépôt.
Procédez par petites étapes vérifiables :
.env.example → .env.Parce que l'environnement hébergé fournit souvent des éléments que vous n'avez pas rendus explicites :
Rendez la configuration visible : .env.example, scripts de migration et un README avec commandes exactes.
Un démarrage de serveur ne suffit pas : vérifiez le flux de données réel :
Si vous ne pouvez pas reproduire des changements de données localement, la configuration ou les migrations sont incomplètes.
Approche par défaut :
.env.example avec des valeurs factices..env à .gitignore.Si vous trouvez des clés réelles dans le dépôt, considérez‑les comme compromises et révoquez-les immédiatement. Priorisez les mots de passe DB, les secrets OAuth et les clés de signature de webhooks.
Gardez le premier CI simple et compatible avec les commandes locales :
go test ./... et builder le backend.Faites en sorte que CI appelle les mêmes scripts que les développeurs utilisent (par ex. make test ou ) pour réduire les différences entre local et CI.
Oui—si vous voulez un handoff prévisible. Bonnes pratiques :
README.md racine avec des commandes copiables..env.example indiquant variables requises vs optionnelles.Visez à ce qu'un nouveau développeur puisse lancer l'app en 15–30 minutes sans deviner.
Structure courante :
apps/ pour les frontends (web, mobile).services/ pour les APIs et workers.shared/ pour les types/utilitaires partagés.infra/ pour modèles de déploiement et exemples d'environnement.Le nom exact importe moins que la clarté sur ce qui tourne où et comment les pièces communiquent.
Séquence pratique :
Une fois stable, considérez Git comme source de vérité et utilisez les futurs exports de la plateforme comme checkpoints, pas comme l'historique principal.
Ne refactorez pas immédiatement : prouvez d'abord que tout fonctionne tel quel, puis améliorez en commits séparés.
npm run build