Déployer une app Bolt/Lovable en production : la checklist complète
14/07/2026
Votre application créée avec Bolt ou Lovable tourne sur l'URL fournie par l'outil, et vous vous apprêtez à la partager au monde. Attention : cette URL de preview n'est pas une vraie mise en production. La confondre avec un lancement réel expose à des coupures, des pertes de données et des failles, au pire moment, celui où les premiers utilisateurs arrivent.
Déployer une application en production, c'est lui donner un socle fiable pour accueillir du trafic réel sans casser. Cet article vous donne la checklist complète pour passer de la preview à la production, les pièges spécifiques aux applications vibe-codées, et les choix d'hébergement selon votre situation. De quoi lancer sereinement, plutôt que dans l'urgence.
Preview, staging, production : quelle différence ?
Trois environnements jalonnent la vie d'une application. La preview est l'aperçu généré par l'outil de vibe coding pour tester pendant la création. Le staging est une copie de production servant à valider les changements avant de les diffuser. La production est l'environnement réel, accessible à vos utilisateurs, où la fiabilité, la sécurité et les sauvegardes deviennent non négociables.
L'erreur fréquente consiste à traiter l'URL de preview de Bolt ou Lovable comme une production. Cette URL est pensée pour le développement, pas pour servir du trafic réel : elle ne garantit ni la disponibilité, ni un nom de domaine professionnel, ni les sauvegardes, ni la séparation des données de test et des vraies données. La mettre en avant pour un lancement, c'est bâtir sur du sable. Une vraie mise en production demande de cocher une série de points précis, listés ci-dessous.
La checklist de mise en production
Ces neuf étapes sont à valider avant d'ouvrir votre application au public. Suivez-les dans l'ordre, chacune posant une brique du socle.
- Brancher un nom de domaine et activer le HTTPS. Votre application doit vivre sur votre propre domaine, servi en HTTPS (le cadenas), pas sur une URL temporaire d'outil. C'est la base de la crédibilité et de la sécurité des échanges.
- Sortir les secrets du code et configurer les variables d'environnement. Clés d'API et mots de passe doivent vivre dans des variables d'environnement côté serveur, séparées du code, et différer entre staging et production. Ce point critique est détaillé dans notre guide pour sécuriser une application créée avec l'IA.
- Mettre en place une vraie base de données de production. Les données réelles ont besoin d'une base fiable, sauvegardée et distincte de vos données de test, comme expliqué dans l'article sur l'ajout d'un backend à un prototype IA.
- Activer une authentification réelle. Les comptes utilisateurs doivent être vérifiés côté serveur, avec des mots de passe protégés. Une authentification de façade ne tient pas en production.
- Mettre en place la gestion d'erreurs et les journaux. L'application doit gérer proprement les erreurs au lieu de planter, et consigner ce qui se passe dans des journaux (logs). Sans cela, le moindre incident reste invisible et inexplicable.
- Installer le monitoring et les alertes. Un outil de supervision surveille la disponibilité et les performances, et vous alerte quand quelque chose se dégrade. Vous devez être prévenu d'une panne avant vos utilisateurs.
- Mettre en place une CI/CD. L'intégration et le déploiement continus (CI/CD) automatisent les tests et la mise en ligne à chaque modification, ce qui évite les déploiements manuels risqués et les régressions.
- Configurer les sauvegardes et un plan de restauration. Sauvegardez la base régulièrement et testez la restauration. Une sauvegarde qu'on n'a jamais essayé de restaurer ne vaut rien le jour où elle compte.
- Optimiser les performances et servir les fichiers via un CDN. Pour que l'application tienne la charge et charge vite partout, les performances et la distribution des fichiers doivent être réglées, un sujet traité dans l'article sur pourquoi une app vibe-codée ne scale pas.
Chaque point validé rapproche votre application d'une production digne de ce nom. Les ignorer, c'est repousser le problème au lancement, là où il coûte le plus cher.
Les pièges spécifiques aux apps vibe-codées
Les applications générées par IA présentent au déploiement des défauts récurrents, qu'il vaut mieux connaître avant qu'ils ne se manifestent.
- Les secrets en dur dans le code. L'IA laisse souvent les clés directement dans le code envoyé au navigateur, ce qui les expose dès le déploiement. À traiter en priorité absolue.
- L'absence de séparation entre test et production. Le prototype mélange souvent données de test et configuration réelle, au risque de polluer ou d'effacer de vraies données.
- L'impossibilité de revenir en arrière. Sans gestion des versions ni rollback, une mauvaise mise en ligne ne peut pas être annulée proprement, et un bug part directement chez les utilisateurs.
- Les dépendances non figées. Quand les versions des bibliothèques ne sont pas verrouillées, l'application peut se comporter différemment d'un déploiement à l'autre, ou casser sans prévenir.
Ces pièges expliquent pourquoi un déploiement improvisé tourne mal. Ils font partie des limites du vibe coding au passage en production qu'un accompagnement technique permet de lever.
Un scénario revient souvent. Un fondateur annonce son lancement, partage l'URL de preview de son application, et l'affluence fait apparaître les angles morts en cascade : une clé d'API exposée se fait exploiter, un bug n'a aucun moyen d'être annulé faute de rollback, et personne ne reçoit d'alerte quand l'application tombe, si bien que la panne dure des heures avant d'être remarquée. Aucun de ces incidents n'était une fatalité. Chacun correspond à un point de la checklist qui n'avait pas été coché. Le déploiement n'est pas l'étape qu'on bâcle à la fin, c'est celle qui décide si votre lancement tient ou s'effondre.
Où héberger votre application ?
Le choix de l'hébergement dépend de votre niveau d'exigence. Le tableau suivant résume les deux grandes options.
| Critère | Vercel / Netlify | Infrastructure propre (cloud dédié) |
|---|---|---|
| Mise en place | Rapide, quasi automatique | Plus longue, à configurer |
| Contrôle | Cadré par la plateforme | Total |
| Conformité (données sensibles) | Limitée | Maîtrisée (hébergement choisi) |
| Idéal pour | La plupart des projets web | Exigences fortes, santé, finance |
Pour la grande majorité des applications, une plateforme comme Vercel ou Netlify offre un déploiement simple, rapide et fiable, parfaitement adapté à une application React ou Next.js issue du vibe coding. L'infrastructure propre devient pertinente quand vous manipulez des données sensibles soumises à des obligations réglementaires, ou quand vous avez besoin d'un contrôle total sur l'environnement. Le bon choix dépend de votre contexte, pas d'une mode.
Qui gère la production après le lancement ?
Mettre en production n'est pas la fin du travail, c'est le début de la vie de l'application. Une fois en ligne, il faut surveiller la disponibilité, appliquer les mises à jour de sécurité, corriger les bugs qui remontent et répondre aux incidents. Ces tâches ne disparaissent pas une fois le lancement passé.
Trois options s'offrent à vous. Internaliser, si vous avez ou recrutez la compétence technique. Déléguer à un prestataire qui assure la maintenance et, selon les besoins, une astreinte. Ou un modèle mixte, où vous gérez le quotidien et faites appel à un expert pour les sujets pointus. Quelle que soit l'option, anticipez-la avant le lancement, pour ne pas découvrir le jour d'une panne que personne n'est en charge de la résoudre.
Prévoyez aussi un budget pour cette phase. Une application en production a un coût de fonctionnement récurrent : hébergement, services tiers, temps de maintenance. Le négliger conduit à des produits laissés à l'abandon quelques mois après le lancement, faute d'avoir anticipé qui paierait et gérerait la suite. C'est l'un des points que nous cadrons lors de l'audit d'un projet à finaliser, pour que la mise en production s'inscrive dans la durée et pas seulement le jour J.
Questions fréquentes
L'URL de preview de Lovable ou Bolt suffit-elle pour lancer ?
Non. L'URL de preview sert au développement, pas à servir du trafic réel. Elle ne garantit ni la disponibilité, ni les sauvegardes, ni un nom de domaine professionnel, ni la séparation des données. Un vrai lancement passe par une mise en production complète.
Faut-il un nom de domaine pour mettre une application en production ?
Oui. Un nom de domaine servi en HTTPS est la base d'une application professionnelle. Il inspire confiance, sécurise les échanges et vous rend indépendant de l'URL temporaire de l'outil de vibe coding.
Comment gérer les secrets en production ?
Les secrets (clés d'API, mots de passe) doivent vivre dans des variables d'environnement côté serveur, séparées du code, et différentes entre staging et production. Ils ne doivent jamais apparaître dans le code envoyé au navigateur.
Qu'est-ce que la CI/CD et est-elle indispensable ?
La CI/CD automatise les tests et la mise en ligne à chaque modification du code. Elle n'est pas strictement obligatoire pour un tout petit projet, mais elle devient vite indispensable pour déployer sans risque et éviter les régressions à mesure que l'application évolue.
Qui s'occupe de l'application une fois en production ?
Vous, un prestataire, ou un modèle mixte. La production demande surveillance, mises à jour et corrections en continu. Le mieux est de décider qui en a la charge avant le lancement, plutôt que de l'improviser lors du premier incident.
Conclusion
Déployer une application Bolt ou Lovable en production ne se résume pas à partager une URL. Retenez l'essentiel : l'aperçu de l'outil n'est pas une production, une vraie mise en ligne suppose de cocher neuf points (domaine, secrets, base, authentification, erreurs, monitoring, CI/CD, sauvegardes, performances), et les applications vibe-codées cachent des pièges précis qu'il faut traiter avant de lancer.
Si vous voulez lancer sans laisser de trou dans le filet, faites auditer gratuitement votre projet : on vérifie votre checklist de mise en production et on vous accompagne jusqu'au lancement.
Lectures complémentaires :