Comment héberger vous-même une application Lovable ou Bolt

Lovable et Bolt permettent de créer une app et de la mettre en ligne sans penser aux serveurs. C'est leur force. Mais quand l'app devient importante pour votre activité, vous pouvez vouloir qu'elle vive dans des comptes à vous, et non dans l'outil qui l'a générée. Les deux outils le permettent. Ce guide explique pourquoi des fondateurs le font, les étapes dans l'ordre, et les problèmes à prévoir.

Pourquoi passer à votre propre hébergement ?

• La propriété. Le code, la base de données et le domaine se trouvent dans des comptes à votre nom. Si un outil change ses règles, ou si vous arrêtez de l'utiliser, votre app reste en ligne.
• La maîtrise des coûts. Vous payez l'hébergeur et la base de données pour ce que l'app consomme. Vous voyez chaque facture et pouvez changer de fournisseur si l'un devient trop cher.
• La liberté de choisir qui vous aide. Un freelance ou un studio peut travailler sur un projet standard dans GitHub avec ses outils habituels. Il n'a pas besoin de travailler dans votre compte Lovable ou Bolt.

Vous n'êtes pas obligé de quitter l'outil pour cela. Beaucoup de fondateurs continuent à construire dans Lovable ou Bolt pendant que le code vit aussi dans leur compte GitHub.

Que déplacez-vous exactement ?

Une app n'est pas un seul bloc. Elle a quatre parties, et chacune se déplace d'une façon différente :

• Le code. Les fichiers qui font les écrans et la logique.
• Le backend. La partie cachée : la base de données, les connexions et les fichiers stockés.
• Les secrets. Les clés et mots de passe que l'app utilise pour parler à la base de données, au service de paiement et aux autres services.
• Le domaine. L'adresse que les gens tapent pour ouvrir l'app.

Il y a donc deux niveaux de déménagement. Le premier ne déplace que le code et l'hébergement, et l'app continue à parler au même backend. Le second déplace aussi le backend vers un compte à vous. Le premier est rapide. Le second demande plus de soin, car il touche à vos utilisateurs et à leurs données.

Les six étapes, en mots simples

• 1. Placez le code dans votre propre compte GitHub. GitHub est le service où l'on stocke le code. Lovable et Bolt peuvent tous deux relier un projet à GitHub. Créez le compte vous-même, avec votre propre adresse e-mail, et reliez-le depuis l'outil. Ne laissez pas le code vivre uniquement dans le compte d'un freelance.
• 2. Soyez propriétaire du compte de la base de données. Si votre app utilise déjà un projet Supabase que vous avez créé, il est déjà à vous. Si elle utilise le backend intégré à l'outil, consultez la documentation à jour : Lovable décrit comment passer un projet sur votre propre compte Supabase, et Bolt permet de récupérer sa base de données dans Supabase.
• 3. Réglez les secrets. Les secrets ne sont jamais stockés avec le code, et c'est une bonne chose. Chez le nouvel hébergeur, vous les ajoutez un par un comme variables d'environnement (des réglages que l'hébergeur garde privés et donne à l'app quand elle tourne).
• 4. Déployez chez un hébergeur. Créez un compte chez un hébergeur comme Vercel ou Netlify, reliez votre projet GitHub et lancez le premier déploiement (l'étape qui construit l'app et la met en ligne). Vous obtenez une adresse provisoire pour tester.
• 5. Reliez votre domaine. Achetez le domaine à votre nom si ce n'est pas déjà fait. Ajoutez-le chez l'hébergeur, puis modifiez les enregistrements DNS (les réglages qui disent à Internet où pointe votre domaine) comme l'hébergeur le demande.
• 6. Testez tout. Inscrivez-vous avec une nouvelle adresse, connectez-vous, réinitialisez un mot de passe, envoyez un fichier, faites un paiement de test. Faites-le aussi sur un téléphone. Gardez l'ancienne version en ligne tant que la nouvelle n'a pas réussi tous les tests.

Déplacer le code prend un après-midi. Déplacer les données et les connexions sans perdre un seul utilisateur demande un plan.

Qu'est-ce qui pose souvent problème ?

• Un secret manquant. L'app se construit, mais la page est blanche ou personne ne peut se connecter. Dans la plupart des cas, une variable d'environnement manque ou porte un mauvais nom.
• Des connexions qui renvoient vers l'ancienne adresse. La connexion avec Google et les e-mails de confirmation renvoient l'utilisateur vers une adresse réglée plus tôt. Après le déménagement, la nouvelle adresse doit être ajoutée dans les réglages de connexion.
• Des données qui ne suivent pas. Quand vous changez de backend, la structure de la base peut être recréée, mais le contenu et les fichiers envoyés doivent être exportés puis importés. Comparez les chiffres avant et après.
• Des utilisateurs qui doivent se reconnecter. Après un changement de backend, les sessions ouvertes ne sont pas conservées. Prévenez vos utilisateurs avant.
• Des messages de paiement envoyés au mauvais endroit. Votre service de paiement envoie des messages à votre app (appelés webhooks) pour dire qu'un paiement a réussi. S'ils partent encore vers l'ancienne adresse, des gens paient sans obtenir d'accès.
• Des fonctions qui passaient par l'outil. Certaines fonctions d'IA ou certaines connexions à d'autres services passent par l'outil lui-même. Si vous quittez son backend, vous devez les remplacer par votre propre compte chez un autre fournisseur.

Le déménagement rend-il l'app prête pour de vrais utilisateurs ?

Non, et c'est important. Un déménagement change l'endroit où vit l'app. Il ne change pas la façon dont elle est écrite. Si un utilisateur peut voir les données d'un autre avant, c'est encore vrai après. L'hébergement et la sécurité sont deux chantiers séparés.

La bonne nouvelle, c'est que le déménagement est le moment idéal pour vérifier le reste. Notre guide pour lancer une application Lovable auprès de vrais utilisateurs donne les huit points à contrôler, et le test de lancement gratuit vous situe en deux minutes.

Quand demander de l'aide ?

• De vrais utilisateurs sont déjà dans l'app. Une erreur pendant le déménagement peut leur bloquer l'accès ou faire perdre des données.
• Vous encaissez des paiements. Les réglages de paiement doivent basculer exactement au même moment que l'app.
• Vous devez déplacer le backend, pas seulement l'hébergement. C'est la partie qui compte le plus d'étapes et le plus de pièges.
• Quelqu'un d'autre détient vos comptes. Il faut d'abord récupérer le code, le domaine et l'hébergement à votre nom.
• Le premier déploiement échoue et vous ne comprenez pas l'erreur. Redemander sans fin une correction à la conversation rend souvent le code plus difficile à lire.

Chez Swipe Up, nous le faisons dans le cadre de notre offre pour finir les applications créées avec l'IA. Quand c'est pertinent, nous déplaçons l'app vers un hébergement et une base de données qui vous appartiennent, pour que vous ne dépendiez plus de l'outil qui l'a générée. Tout commence par un audit à prix fixe, et tout reste à votre nom. Si vous hésitez entre déplacer l'app telle quelle et en refaire une partie, lisez d'abord reconstruire ou réparer son application.

En résumé

Héberger vous-même une app Lovable ou Bolt est possible, et les deux outils le prévoient. Commencez par le niveau facile : le code dans votre compte GitHub, déployé chez un hébergeur que vous payez vous-même, sur votre propre domaine. Ne déplacez le backend que si vous avez une raison et un plan. Et gardez en tête qu'une nouvelle adresse ne répare pas l'app. Vérifiez la sécurité et les paiements au même moment, pendant que tout est ouvert devant vous.