Ce qui marche en dev mais pas en prod

Ton projet tourne nickel en local. npm run dev, tout s'affiche, les données remontent, les formulaires fonctionnent.

Tu déploies. Et là, rien ne marche.

Bienvenue dans l'étape la plus traître du vibecoding.

Pourquoi c'est l'étape la plus dangereuse

En dev, l'IA est dans son élément. Elle voit les erreurs dans le terminal, elle lit les logs, elle corrige en temps réel.

En prod, elle est aveugle.

Pas d'accès aux logs serveur. Pas de console browser. Elle debug "à l'aveugle", et toi aussi.

C'est là où il y a le plus d'erreurs. Et c'est souvent des erreurs qu'on met des heures à identifier.

Mon exemple le plus douloureux

Mon site pro (pro.matthieucousin.com). Tout marchait en dev. En prod : impossible d'accéder à la base de données.

Le problème ? Supabase était sur le même VPS que mon app. Les deux conteneurs n'arrivaient pas à communiquer. Le message ne "sortait" jamais du serveur.

J'ai dû configurer manuellement les réseaux Docker, passer d'un Dockerfile à un Docker Compose pour fixer le réseau. Et même maintenant c'est fragile : si je redémarre Supabase, je dois remodifier la config.

Ce genre de problème, l'IA ne peut pas le voir. Elle n'a pas accès à ton VPS.

Les erreurs les plus fréquentes

1. Les variables d'environnement

C'est LE piège classique.

• Tu as mis localhost:3000 quelque part → ça marche en dev, ça casse en prod
• L'IA ne peut pas copier tes env vars dans Coolify → tu le fais à la main → tu en oublies
• Ta DB est sur le même VPS → l'IP "externe" ne marche pas, il faut l'IP interne du réseau Docker

Le pire : ces variables sont éparpillées. Dans .env, dans le code parfois, dans la config Supabase... Quand ça casse, tu sais même plus où chercher.

2. Les RLS Supabase

Row Level Security. C'est une bonne pratique de sécurité : ça empêche les utilisateurs d'accéder aux données des autres.

Le problème : en dev, tu l'as peut-être désactivé pour aller plus vite. En prod, c'est activé par défaut.

Résultat : tes requêtes renvoient rien. Pas d'erreur. Juste... rien.

C'est un des bugs les plus longs à identifier parce que ça ressemble pas à un bug.

3. La méthode de build

Coolify te propose plusieurs options : Nixpack, Dockerfile, Docker Compose.

Nixpack c'est "automagique". Ça marche souvent. Mais quand ça marche pas, t'as aucune idée de pourquoi.

Ma recommandation : utilise un Dockerfile. C'est plus explicite, tu contrôles ce qui se passe, et quand ça casse, tu sais où regarder.

Docker Compose si tu as plusieurs services qui doivent communiquer (comme mon cas avec Supabase sur le même VPS).

La stratégie : déployer tôt, déployer souvent

Si tu n'as pas encore de serveur, le guide pour en monter un tient en trente minutes.

La plupart des débutants font ça :

1. Coder tout le projet en local
2. Déployer à la fin
3. Passer 2 jours à debug

Mauvaise stratégie.

Ce que j'enseigne dans mon accompagnement :

Déploie dès le début. Avant même d'avoir des features.

1. Tu crées ton projet
2. Tu setup le déploiement (Coolify, CI/CD)
3. Tu push → ça déploie
4. Tu vérifies que ça marche en prod
5. ENSUITE tu codes tes features

Comme ça, chaque push déclenche un déploiement. Tu détectes les problèmes au fur et à mesure, pas à la fin quand t'as 50 fichiers modifiés et aucune idée de ce qui a cassé.

Checklist avant déploiement

Les 6 points à vérifier avant chaque mise en prod :

1. Variables d'environnement

• ☐ Toutes les vars sont copiées dans Coolify
• ☐ Les URLs localhost sont remplacées par l'URL finale
• ☐ Les IPs de base de données sont correctes (interne si même VPS)
• ☐ Si le service tourne via un docker-compose, c'est lui qui gagne sur l'interface Coolify (le cas qui m'a coûté une soirée)

2. Supabase

• ☐ Les RLS sont configurées correctement
• ☐ L'URL du site est mise à jour dans Authentication > URL Configuration
• ☐ Les redirect URLs OAuth incluent l'URL de prod

3. Build

• ☐ Le build passe en local (npm run build)
• ☐ Tu utilises un Dockerfile (pas Nixpack)

4. Réseau (si self-hosted)

• ☐ Les conteneurs peuvent communiquer entre eux
• ☐ Le réseau Docker est configuré dans docker-compose

5. Test manuel

• ☐ Tu as testé les fonctionnalités critiques en prod (pas juste en dev)

6. Logs

• ☐ Tu sais où regarder les logs si ça casse (Coolify > Deployments > Logs)

La suite

Le déploiement, c'est un skill à part entière. L'IA peut coder ton app, mais elle peut pas configurer ton serveur.

C'est pour ça que je montre ça dès le premier jour à ceux que j'accompagne. Mais tu peux commencer sans moi : sur ton prochain projet, déploie avant d'écrire la première feature. Tu verras la différence au premier bug.