Exporter proprement le code source depuis une plateforme vibe‑coding

Ce que signifie prendre la propriété après export

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 :

• De la configuration qui n'existe que dans l'UI de la plateforme
• Des étapes de build qui se passent "ailleurs"
• Des dépendances supposées mais non documentées

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 :

• Vous pouvez lancer l'app exportée en local avec des étapes prévisibles.
• Vous pouvez la déployer depuis votre propre dépôt via CI, sans clics manuels.
• Les secrets sont gérés en sécurité (pas de clés dans Git, pas de supposition).
• Le dépôt est prêt pour un handoff : une nouvelle personne peut monter en compétence rapidement et faire confiance à ce qu'elle voit.

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.

Ce à quoi vous devez vous attendre dans un projet exporté

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.

La forme du projet : dossiers, points d'entrée et qui lance quoi

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 :

• Web : un package.json plus un dossier src/ (souvent avec main.tsx ou similaire)
• Backend : go.mod et un dossier cmd/ ou main.go
• Mobile : pubspec.yaml de Flutter et lib/main.dart
• Un README ou Makefile à la racine qui décrit comment lancer le tout
• Un docker-compose.yml si l'export est destiné à s'exécuter comme un ensemble de services

Dépendances, configuration et éléments de base de données

Les 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.

Étape par étape : exporter, committer et lancer en local

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.

Un premier commit propre (pour que l'historique commence lisible)

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

Confirmez que la base de données fonctionne vraiment (pas seulement « le serveur a démarré »)

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 :

• Ouvrez une page qui dépend clairement de données (une liste, un profil, un tableau de bord).
• Créez un enregistrement (inscription, création d'élément, ajout d'une note), actualisez et confirmez qu'il est persisté.
• Lancez une mise à jour et une suppression si l'UI le permet.
• Surveillez les logs pour des erreurs de migration ou « relation does not exist ».

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.

Transformer l'export en un dépôt prêt pour le handoff

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 jobs
• shared/ pour types et utilitaires partagés
• infra/ pour templates de déploiement, scripts et exemples d'env
• docs/ pour notes d'architecture et runbooks

Ajoutez ensuite un petit ensemble de fichiers qui réduisent les conjectures :

• README.md avec prérequis et commandes exactes
• CONTRIBUTING.md avec quelques règles (branches, PRs, pas de secrets)
• .gitignore pour éviter de committer des fichiers d'env locaux et des sorties de build

Gardez 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.

Configuration du développement local que les nouveaux peuvent suivre

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.

Une configuration d'env minimale et sûre

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.

Une commande pour tout initialiser

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.

Secrets et configuration sans rien divulguer

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 :

• Local : .env géré par le développeur (non committé)
• CI : le coffre de secrets du fournisseur CI
• Production : un gestionnaire de secrets dédié ou des variables d'environnement de l'hébergeur

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.