Mets ton app en ligne

La mission est découpée en étapes progressives :

1. 1
   Étape 1 — Choisis l'hébergeur selon ta stack. Tu ne choisis pas au hasard, tu choisis selon ce que tu as construit. La carte de référence :

1. 1
   Étape 2 — Mets ton code sur Git si ce n'est pas déjà fait. La plupart des hébergeurs déploient depuis un repo. Vérifie d'abord que tes secrets ne partent pas avec.

# Est-ce que .env est bien ignoré ?
git check-ignore .env
# Doit afficher ".env". Si la commande ne renvoie RIEN, .env n'est pas ignoré : danger.

Si .env n'est pas ignoré, ajoute-le à .gitignore avant le moindre commit. Un secret poussé sur GitHub est un secret cramé, même si tu le supprimes après : il reste dans l'historique du repo, accessible à qui sait remonter les commits.

git status            # vérifie que .env n'apparaît PAS dans les fichiers à committer
git add .
git commit -m "Prêt pour le déploiement"
git push

1. 1
   Étape 3 — Inventaire avant d'agir : liste tes variables d'environnement. Avant de déployer, ouvre ton .env local et fais l'inventaire. Le .env ne monte jamais tel quel en prod. Il est dans ton .gitignore (et il DOIT l'être), donc il ne part pas avec ton code. Tu vas reporter chaque variable à la main dans le dashboard de l'hébergeur. Prompt à donner à Claude Code :

Lis mon fichier .env et liste toutes les variables d'environnement que mon app utilise réellement (cherche les os.getenv / process.env dans le code, pas juste le contenu du .env). Pour chacune, dis-moi : son rôle, si c'est un secret (clé API, token, mot de passe) ou une config publique, et ce qui se passe si elle manque. Sors un tableau prêt à recopier dans un dashboard d'hébergeur. Ne modifie aucun fichier.

Note bien la frontière : un secret (token Notion, clé APIAPI : ouvre la porte aux fonctionnalités logicielles., mot de passe base) ne doit JAMAIS finir côté client, c'est-à-dire dans une variable exposée au navigateur. Sur Next.js, tout ce qui commence par NEXT_PUBLIC_ est visible par tout le monde dans les DevTools. Concrètement : NEXT_PUBLIC_API_URL (une URL publique) → ok ; NEXT_PUBLIC_STRIPE_SECRET (un secret) → catastrophe, tu viens d'afficher ta clé à la terre entière. Côté Vite, c'est le préfixe VITE_ qui joue ce même rôle d'exposition publique.

1. 1
   Étape 4 — Vérifie que le build passe en local d'abord. Avant d'envoyer en prod, lance le build de production sur ta machine. Le serveur de dev est permissif ; le build, lui, est strict. La majorité des erreurs « KO en prod » se voient déjà ici, et c'est dix fois plus rapide à corriger en local qu'en attendant un déploiement à distance.

# App Next.js / JS
npm run build

# App Docker (simule exactement ce que fera l'hébergeur)
docker build -t mon-app .

Si ça casse en local, ça cassera en prod. Corrige ici. Demande à Claude Code de lire la sortie d'erreur en entier (elle nomme le fichier et la ligne), puis applique un seul changement à la fois et relance le build jusqu'à ce qu'il passe vert.

1. 1
   Étape 5 — Déploie.

Cas Vercel (app web JS / Next / Vite). Le plus court chemin : connecte ton repo GitHub sur vercel.com, Vercel détecte le framework tout seul. Ou en ligne de commande :

npm i -g vercel
vercel
# suis les questions (projet, dossier, framework détecté), puis pour la mise en prod :
vercel --prod

Avant ou juste après, ajoute tes variables (Settings → Environment Variables dans le dashboard, ou en CLI) :

vercel env add NOM_DE_LA_VARIABLE production

Cas Railway / Render (app Python / Docker). Connecte ton repo, l'hébergeur lit ton Dockerfile (ou détecte ton requirements.txt), lance le build, te donne une URL. Ici l'ordre compte : reporte tes variables dans l'onglet Variables / Environment du dashboard AVANT que le service démarre, sinon il crashe au premier lancement faute de trouver sa config. Prompt à donner à Claude Code pour préparer le terrain :

Mon app doit se déployer sur [Vercel | Railway | Render]. Vérifie que tout ce qu'il faut est présent et correct : le build command, le start command, le port lu depuis une variable d'environnement (process.env.PORT / os.getenv("PORT")) et PAS codé en dur, le host d'écoute en 0.0.0.0 et pas 127.0.0.1, et un Dockerfile propre si Docker. Liste-moi ce qui manque ou ce qui risque de casser en prod, sans rien modifier encore. Ensuite on corrigera un changement à la fois.

1. 1
   Étape 6 — Prouve depuis un autre appareil. Une fois l'URL obtenue, ne la teste pas seulement dans ton navigateur. Sors-la de chez toi : ouvre-la sur ton téléphone en 4G, WiFi coupé. Si ça répond, c'est vraiment en ligne. Si ça ne répond que sur ta machine ou que sur ton WiFi maison, c'est encore du local déguisé. C'est cette ouverture-là, depuis un réseau qui n'est pas le tien, qui fait la preuve. Si ça coince, ouvre les logs runtime de l'hébergeur (pas seulement les logs de build) : ils te disent ce que l'app crie au démarrage, et neuf fois sur dix la cause est dans la liste de la correction plus bas.