Vibe coding : mettre ton app en production

Ton app marche en local. Et maintenant ?

Tu as construit ton app en vibe coding. Le prototype tourne sur ton ordinateur. Tu l'as montré à quelques personnes, les retours sont bons.

Sauf que "ça marche sur ma machine" et "c'est en ligne, les gens peuvent s'inscrire et payer", c'est deux choses très différentes. Entre les deux, il y a la mise en production. Et c'est là que beaucoup de projets vibe-codés restent bloqués.

Ce guide te donne un chemin concret, étape par étape. Pas de théorie abstraite — des outils, des choix, et des décisions à prendre. Si tu as déjà parcouru la checklist avant lancement, ce guide est la suite logique : comment mettre en place ce que la checklist vérifie.

1. Choisis ton hébergement

C'est la première décision, et elle conditionne beaucoup de choses. Bonne nouvelle : en 2026, les options sont simples et abordables.

Si ton app est un site ou une app Next.js / React

Vercel est le choix évident. C'est les créateurs de Next.js, donc l'intégration est parfaite. Tu connectes ton dépôt GitHub, et chaque fois que tu pousses du code, ton app est mise à jour automatiquement. Le plan gratuit suffit pour démarrer. Quand tu grandis, les prix suivent.

Netlify fait la même chose, avec un peu plus de flexibilité si tu n'utilises pas Next.js.

Si ton app a un backend plus complexe

Tu as une API, un serveur, des tâches en arrière-plan ? Il te faut quelque chose de plus flexible.

• Railway : tu décris ce que tu veux (une app Node, une base PostgreSQL, un cache Redis) et Railway le déploie. L'interface est claire, les prix sont transparents. C'est le meilleur rapport simplicité/puissance en 2026.
• Fly.io : un peu plus technique, mais tes apps tournent au plus près de tes utilisateurs. Idéal si tu as des utilisateurs partout dans le monde.
• Render : une alternative solide à Railway, avec un plan gratuit généreux.
• Heroku : un ancien acteur du PaaS qui a perdu du terrain depuis la suppression de son plan gratuit. Railway et Render l'ont largement remplacé.

Ce qu'il faut éviter

Ne gère pas ton propre serveur si tu n'es pas un expert technique. Pas de VPS brut, pas d'installation manuelle d'un serveur web. C'est de la maintenance permanente, et ce n'est pas là que tu crées de la valeur. Si tu es à l'aise avec l'administration système, un VPS (Hetzner, OVH, Scaleway) permet de réduire drastiquement les coûts — mais tu devras gérer toi-même les mises à jour, le SSL, les backups et la sécurité.

Le choix rapide : si tu débutes et que ton app est en Next.js, prends Vercel. Si tu as besoin d'un backend, prends Railway. Tu pourras toujours migrer plus tard.

Mon retour d'expérience. En pratique, sur certains petits projets non critiques, je fais des configurations manuelles sur des VPS pour réduire drastiquement mes coûts d'infrastructure. Mais c'est un choix que je fais en connaissance de cause — si tu n'es pas à l'aise avec l'administration serveur, reste sur un PaaS.

2. Mets en place ta base de données

Si ton app stocke des données (et c'est probablement le cas), tu as besoin d'une base de données en production. Pas celle qui tourne sur ton ordinateur — une vraie, hébergée, sauvegardée.

La base de données est l'asset le plus critique de ta chaîne technique. Ton code, tu peux le redéployer. Ton infrastructure, tu peux la recréer. Tes données utilisateurs, si tu les perds, c'est fini. C'est sur cette partie que les sauvegardes sont les plus importantes.

Utiliser une instance managée (Supabase, Railway, Neon, etc.) coûte un peu plus cher qu'une base auto-hébergée, mais ça te garantit que la base sera maintenue, mise à jour et sauvegardée dans le temps. C'est souvent le bon choix.

Sauf en phase de test de marché ou de POC, il est très important que des backups automatisés soient en place, voire une redondance de la base de données. Ne repousse pas ça à "plus tard" — plus tard, c'est quand tu auras des utilisateurs et que le risque sera réel.

Quel type de base choisir ?

• PostgreSQL : le choix par défaut. Fiable, puissant, gratuit. Si tu ne sais pas quoi choisir, choisis PostgreSQL.
• SQLite (via Turso ou LiteFS) : parfait pour les petites apps. Plus simple, moins de configuration. Mais attention aux limites si tu grandis vite.
• Supabase : PostgreSQL + une interface web + de l'authentification + du stockage de fichiers. C'est un peu le couteau suisse. Très populaire dans la communauté vibe coding.

Les migrations : le truc que l'IA oublie souvent

Ta base de données va évoluer. Tu vas ajouter des colonnes, des tables, changer des types. Les migrations, c'est le mécanisme qui permet de faire ça proprement, sans perdre de données.

L'IA génère rarement des migrations correctes du premier coup. Vérifie toujours :

• Que la migration peut être annulée (rollback)
• Que les données existantes ne sont pas écrasées
• Que tu testes la migration sur une copie de tes données avant de la lancer en production

Outils : Prisma (le plus populaire), Drizzle (le plus léger), ou les migrations intégrées de Supabase.

Ce que l'IA fait souvent mal ici : elle génère une migration qui supprime une colonne et en recrée une nouvelle au lieu de la renommer. Résultat : toutes les données de cette colonne sont perdues. Sur ta machine de dev, tu ne vois rien — ta base est vide. En production, c'est une catastrophe silencieuse. Le genre de truc qu'un ALTER TABLE RENAME COLUMN aurait réglé, mais que l'IA ne fait presque jamais du premier coup.

3. Gère l'authentification

L'authentification, c'est le truc le plus chiant à coder soi-même. C'est aussi le premier truc qui te coûtera des utilisateurs si c'est mal fait. Alors ne le code pas toi-même.

Les solutions clé en main

• Clerk : inscription, connexion, gestion des sessions, tout est inclus. L'intégration avec Next.js est excellente. Plan gratuit jusqu'à 10 000 utilisateurs.
• Auth.js (anciennement NextAuth) : open-source, flexible, tu gardes le contrôle. Un peu plus de configuration, mais pas de dépendance à un service payant.
• Supabase Auth : si tu utilises déjà Supabase pour ta base, autant utiliser leur auth. C'est cohérent et ça évite de multiplier les services.
• Auth0 : une solution plus orientée entreprise, robuste et très complète. La configuration est un peu plus lourde, mais c'est un choix solide si tu vises une app avec des besoins avancés (SSO, gestion de rôles, multi-tenant).

Ce que tu dois vérifier

Quel que soit ton choix, assure-toi que :

• Les sessions expirent (un utilisateur ne reste pas connecté éternellement)
• Le "mot de passe oublié" fonctionne de bout en bout
• Les pages protégées sont vraiment protégées (teste en navigation privée)
• Tu gères les rôles si ton app en a besoin (admin vs utilisateur normal)

Ce que l'IA fait souvent mal ici : elle protège les pages côté client (avec un if (!user) redirect), mais oublie de protéger les routes API derrière. Résultat : n'importe qui peut appeler /api/admin/users directement depuis son navigateur et accéder à des données sensibles. L'interface a l'air sécurisée. Le backend ne l'est pas du tout.

4. Automatise tes déploiements avec le CI/CD

Le CI/CD, c'est juste un nom technique pour dire : "quand je pousse du code, mon app se met à jour toute seule, et si quelque chose ne va pas, ça s'arrête avant de casser quoi que ce soit."

GitHub Actions : le choix simple

Si ton code est sur GitHub (et il devrait l'être), GitHub Actions est le choix naturel. C'est gratuit pour les projets publics et très abordable pour les projets privés.

Un pipeline de base fait trois choses :

1. Vérifie que ton code compile sans erreur
2. Teste que tes tests passent
3. Déploie si tout est vert

Si tu utilises Vercel ou Railway, le déploiement automatique est déjà inclus quand tu connectes ton dépôt. Le CI/CD ajoute la couche de vérification avant le déploiement.

Si ton code est sur GitLab, GitLab CI/CD fait exactement la même chose, le principe est identique, seule la syntaxe de configuration change.

Le minimum à mettre en place

• Un check qui lance tes tests à chaque push
• Un déploiement automatique sur ta branche principale
• Un environnement de prévisualisation pour les branches secondaires (Vercel le fait automatiquement)

Au tout début, déployer à la main peut être acceptable — tu es seul, tu connais ton code, les risques sont faibles. Mais dès que le projet prend de l'ampleur (premiers utilisateurs, plusieurs branches, un collègue qui contribue), un CI/CD devient indispensable. Sans ça, le jour où tu casses quelque chose en production un vendredi soir, tu regrettes.

5. Mets en place le monitoring

Tu ne peux pas réparer ce que tu ne vois pas. En production, tu as besoin de savoir quand quelque chose ne va pas — idéalement avant tes utilisateurs.

Les erreurs : Sentry

Sentry capture chaque erreur qui se produit dans ton app, avec le contexte complet : quelle page, quel utilisateur, quel navigateur, quelle action a déclenché le problème. Le plan gratuit suffit largement pour commencer.

L'intégration prend 10 minutes. C'est probablement les 10 minutes les plus rentables de ta mise en production.

Ce que l'IA fait souvent mal ici : elle installe Sentry, mais envoie l'intégralité des erreurs sans filtrer. Résultat : tu reçois 200 alertes par jour pour des erreurs inoffensives (un utilisateur qui perd sa connexion WiFi, un bot qui scanne ton site). Au bout de 48h, tu désactives les notifications. Et le jour où une vraie erreur arrive, tu ne la vois pas. Configurer Sentry, c'est facile. Configurer Sentry pour qu'il soit utile, c'est un autre sujet.

Les performances : ton hébergeur

Vercel, Railway et les autres fournissent des métriques de base : temps de réponse, usage mémoire, nombre de requêtes. Commence par regarder ce qu'ils offrent avant d'ajouter un outil supplémentaire.

Les alertes : ne sois pas dans le noir

Configure au minimum :

• Une alerte email quand ton app plante (Sentry le fait)
• Une alerte quand ton app est hors ligne (UptimeRobot, gratuit)
• Un coup d'œil hebdomadaire sur tes métriques d'hébergement

6. Sécurise les bases

La checklist de lancement couvre la sécurité en détail. Ici, on se concentre sur les actions concrètes côté infrastructure.

Gestion des secrets

Tes clés API, mots de passe de base de données, tokens de services tiers — tout ça doit être dans des variables d'environnement, jamais dans ton code.

• Chaque hébergeur (Vercel, Railway, Render) a une interface pour gérer les variables d'environnement
• Ne committe jamais de fichier .env dans ton dépôt Git
• Utilise des valeurs différentes en développement et en production

Ce que l'IA fait souvent mal ici : elle met des valeurs par défaut "de secours" dans le code — du type const dbUrl = process.env.DATABASE_URL || "postgres://localhost:5432/myapp". En dev, ça marche. En production, si ta variable d'environnement est mal configurée, ton app se connecte silencieusement à une base qui n'existe pas, ou pire, à la mauvaise base. Pas d'erreur visible. Juste des données qui disparaissent.

HTTPS partout

Si tu utilises Vercel, Railway ou Netlify, c'est automatique. Vérifie juste que ton domaine personnalisé a bien le petit cadenas dans la barre d'adresse. Sans HTTPS, les navigateurs affichent un avertissement et tes utilisateurs partent.

Headers de sécurité

Ajoute ces en-têtes HTTP dans la configuration de ton app :

• X-Content-Type-Options: nosniff
• X-Frame-Options: DENY
• Strict-Transport-Security (force HTTPS)

Sur Next.js, ça se configure dans next.config.js en quelques lignes. Demande à l'IA de te les ajouter.

7. Sauvegarde et plan B

Sauvegardes automatiques

Ta base de données doit être sauvegardée automatiquement. La plupart des services le font par défaut, mais vérifie :

• Que les sauvegardes sont activées (certains plans gratuits ne les incluent pas)
• Que tu peux restaurer une sauvegarde (teste-le une fois, pour de vrai)
• Que les sauvegardes sont conservées assez longtemps (au moins 7 jours)

Revenir en arrière

Si un déploiement casse quelque chose, tu dois pouvoir revenir à la version précédente en 2 minutes. C'est ce qu'on appelle un rollback.

• Vercel : un clic dans le dashboard pour revenir au déploiement précédent
• Railway : même chose, tu peux redéployer n'importe quelle version passée
• GitHub : git revert + push, et ton CI/CD fait le reste

Le test : fais un rollback maintenant, sur un environnement de test. Le jour où tu en auras besoin pour de vrai, tu ne veux pas chercher comment faire.

8. Les outils open-source qui changent la donne

Un des avantages du vibe coding, c'est que la communauté open-source est énorme. Voici les outils gratuits qui peuvent remplacer des services payants — ou les compléter.

L'open-source, c'est gratuit en argent mais pas en temps. Si tu gères toi-même un outil, c'est toi qui le mets à jour, toi qui le répares s'il plante. Pour un fondateur qui se lance, les services managés sont souvent le meilleur investissement. Tu paies quelques euros par mois pour ne pas y penser.

9. La checklist "go live"

Avant d'envoyer le lien à tes premiers utilisateurs, passe cette liste :

• Mon app est déployée sur un hébergement de production (pas en local)
• Mon domaine personnalisé est configuré avec HTTPS
• Ma base de données est hébergée et sauvegardée automatiquement
• L'authentification fonctionne de bout en bout (inscription, connexion, mot de passe oublié)
• Mes secrets sont dans des variables d'environnement, pas dans le code
• J'ai un outil de monitoring des erreurs (Sentry ou équivalent)
• J'ai testé un rollback (retour à la version précédente)
• J'ai testé mon app sur mobile
• Mes déploiements sont automatiques (CI/CD ou déploiement auto de l'hébergeur)
• J'ai parcouru la checklist de sécurité

Chaque point non coché est un risque. Certains sont acceptables au lancement (tu peux vivre sans CI/CD sophistiqué au début). D'autres ne le sont pas (pas de sauvegarde = pas de filet de sécurité).

Tu n'as pas besoin de tout faire seul

Ce guide couvre beaucoup de terrain. Si tu débutes, ça peut sembler écrasant. Voici la bonne nouvelle : la plupart de ces étapes se mettent en place en quelques heures, pas en quelques semaines.

Et si tu veux que quelqu'un le fasse avec toi — ou pour toi — c'est exactement ce que couvre notre offre Pro Stack. On prend ton prototype vibe-codé, on le passe en production avec toutes les fondations solides, et tu repars avec une app prête à accueillir de vrais utilisateurs.

Le vibe coding, c'est incroyable pour construire vite. Mais pour durer, il faut des fondations. Ce guide te donne la carte. À toi de choisir si tu fais la route seul ou accompagné.