Application Bolt.new : à corriger avant le lancement

Bolt.new est un moyen rapide d'obtenir une application web fonctionnelle : vous décrivez ce que vous voulez, et il génère dans le navigateur un projet full-stack, avec aperçu en direct et publication en un clic. Pour une démo, c'est remarquable. Pour de vrais clients, l'écart se situe rarement dans les écrans. Il tient à tout ce qui les entoure : où se trouve le code, comment il est déployé, à qui appartient la base de données et ce qui se passe quand quelque chose tombe en panne la nuit.

Ce guide porte sur le passage d'un « projet dans un onglet de navigateur » à une véritable chaîne de livraison : mettre en production une application Bolt.new relève donc autant de l'exploitation que du code. Si vous voulez d'abord un premier indicateur, lancez notre AI App Health Check gratuit. Pour une vision plus large du lancement, consultez notre checklist de préparation à la production en 20 points ; ici, nous entrons dans le détail de la façon de mettre en production une application Bolt.

Les plateformes évoluent rapidement. Les fonctionnalités, options d'export et intégrations décrites ci-dessous sont des schémas généraux ; vérifiez les paramètres de votre projet et la documentation actuelle de Bolt avant de vous fier à un détail.

Pourquoi un projet Bolt a besoin d'une vraie chaîne de livraison

Un constructeur dans le navigateur optimise la rapidité de la première version. Un système de production optimise la répétabilité : n'importe qui dans l'équipe peut le construire, le déployer, revenir en arrière et comprendre ce qui a changé. Si votre seule copie de l'application vit dans le constructeur, vous avez un point de défaillance unique et aucun historique des décisions.

L'objectif des étapes ci-dessous est simple : votre code dans un dépôt dont vous êtes propriétaire, construit par un processus automatisé, exécuté dans des environnements que vous contrôlez, avec des données que vous pouvez sauvegarder et restaurer.

Étape 1 : prendre la propriété du code et du dépôt

Avant toute chose, placez le projet dans un dépôt Git rattaché à un compte ou à une organisation que votre entreprise contrôle, et non à l'identifiant personnel d'un freelance ou d'un ancien collègue. Les projets Bolt peuvent généralement être exportés ou connectés à GitHub ; consultez les paramètres de votre projet pour connaître les options actuelles.

• Validez l'état actuel comme référence et posez-y une étiquette. C'est votre point de départ connu.
• Ajoutez un .gitignore correct afin que les fichiers d'environnement, les artefacts de build et les caches locaux n'atteignent jamais le dépôt.
• Vérifiez l'historique à la recherche de secrets. Si une clé a un jour été validée dans le dépôt, la renouveler compte davantage que supprimer le fichier.
• Protégez la branche principale et exigez une pull request, même si le seul relecteur est un second regard.
• Rédigez un court README expliquant comment installer, exécuter, construire et déployer. Si vous n'y parvenez pas, cette lacune est votre premier constat.

Étape 2 : hébergement et environnements

Une publication en un clic est pratique, mais la production exige plus de maîtrise : votre propre domaine, HTTPS, retours arrière prévisibles et environnements séparés. Il vous en faut au minimum trois.

Local, préproduction et production

Le local est l'endroit où travaillent les ingénieurs. La préproduction est une copie de la production avec de fausses données, utilisée pour tester chaque modification avant sa mise en ligne. La production est le seul endroit où existent de vrais clients et de vraies données. Chacun doit avoir sa propre base de données, ses propres clés et son propre domaine ou sous-domaine. Si les tests se font sur la base de données réelle, les clients finissent par recevoir des e-mails de test et des enregistrements de test.

Choisir un hébergeur

La plupart des applications Bolt centrées sur le frontend peuvent s'exécuter sur un hébergeur statique ou serverless géré. Les applications dotées de code serveur de longue durée, de tâches en arrière-plan ou de websockets ont besoin d'un hébergeur conçu pour cela. Le bon choix dépend de ce que fait réellement l'application ; décidez-le donc après avoir lu le code, et non avant. Quel que soit votre choix, les déploiements doivent partir du dépôt, et non d'un téléversement manuel.

Étape 3 : variables d'environnement et secrets

C'est là que les applications générées fuient le plus souvent. Tout ce qui est intégré au code du navigateur est public, quel que soit son nom. Passez en revue les points suivants.

• Séparez le public du privé. Les valeurs sans danger dans le navigateur (par exemple une clé publiable ou une URL d'API publique) sont différentes des clés secrètes, qui ne doivent exister que sur un serveur.
• Recherchez dans le code compilé. Ouvrez votre bundle JavaScript de production et cherchez des préfixes de clés et des noms de services. Si un secret s'y trouve, considérez-le comme compromis et renouvelez-le.
• Utilisez le coffre de secrets de l'hébergeur pour les valeurs de production et un fichier d'exemple documenté pour la configuration locale. Ne partagez jamais de secrets dans des messages de discussion ou des tickets.
• Utilisez des clés différentes selon l'environnement, avec le principe du moindre privilège et des plafonds de dépense, surtout pour toute clé d'API de modèle de langage appelée par votre application.
• Déplacez côté serveur les appels qui nécessitent des secrets. Si le navigateur appelle aujourd'hui directement une API tierce payante avec une clé, ajoutez un point d'accès backend léger qui détient la clé et applique des limites par utilisateur.

Étape 4 : backend, base de données et migrations

Les applications Bolt associent généralement un frontend à une base de données hébergée et à un service d'authentification, et parfois à des fonctions serverless. La question, pour la production, n'est pas « lequel » mais « qui le contrôle, et peut-on le reconstruire ».

Rendre le schéma reproductible

Si les tables n'existent que parce qu'un prompt les a créées, vous ne pouvez pas les recréer de façon fiable. Exportez le schéma dans des fichiers de migration versionnés, appliquez-les à une base de données neuve et vérifiez que l'application fonctionne. Ensuite, les changements futurs passent par des migrations, relues comme du code, et jamais par des modifications manuelles dans un tableau de bord.

Règles d'accès, sauvegardes et restaurations

Vérifiez que chaque table contenant des données d'utilisateurs dispose de règles d'accès, et prouvez l'isolation entre locataires avec deux comptes de test. Si vous utilisez Supabase, notre guide sur les erreurs de Row Level Security dans les applications créées par IA couvre les pièges habituels. Activez les sauvegardes, puis testez une restauration dans une base de données jetable. Une sauvegarde que vous n'avez jamais restaurée est un espoir, pas un plan.

Étape 5 : renforcer l'authentification et les paiements

L'authentification générée fonctionne généralement pour le cas nominal. La production a besoin des cas défavorables.

• Une autorisation appliquée côté serveur, et pas seulement en masquant des boutons.
• Des rôles stockés à un endroit que les utilisateurs ne peuvent pas modifier.
• La vérification de l'e-mail, la réinitialisation du mot de passe par des liens à usage unique et à durée limitée, et des limites de débit sur la connexion et l'inscription.
• L'authentification multifacteur pour les comptes administrateurs.

Pour les paiements, la page de succès n'est qu'une redirection du navigateur. L'accès payant doit découler d'événements de webhook vérifiés et idempotents, avec des modes test et production totalement séparés. Nous détaillons les cas d'échec dans les webhooks et abonnements Stripe dans les applications créées par IA. Vérifiez les renouvellements, les paiements échoués, les résiliations et les remboursements avant le lancement, et non après le premier e-mail furieux.

Étape 6 : CI et hygiène des dépendances

L'intégration continue (CI) est une tâche automatisée qui s'exécute à chaque modification. Même une petite chaîne s'amortit.

1. Installez depuis le fichier de verrouillage pour que les builds soient reproductibles.
2. Exécutez le lint, les vérifications de types et le build sur chaque pull request.
3. Ajoutez quelques tests autour de l'argent et des accès : inscription, connexion, une action payante et une tentative d'accès entre comptes qui doit échouer.
4. Déployez automatiquement en préproduction, puis en production après validation.

Concernant les dépendances, les projets générés intègrent souvent des paquets pratiques pour un prompt et devenus inutiles. Supprimez ceux qui ne servent plus, mettez à jour les paquets visés par des avis de sécurité connus et figez les versions. Moins de dépendances, c'est une surface de maintenance plus réduite.

Étape 7 : performance et supervision

Une démo avec dix lignes de données paraît rapide. La production, non. Vérifiez les bases :

• Pages lourdes. Examinez la taille du bundle, les images non optimisées et les données récupérées à chaque rendu.
• Requêtes de base de données. Repérez les listes qui chargent tout d'un coup, et ajoutez des index sur les colonnes que vous filtrez et triez.
• Supervision des erreurs et alertes de disponibilité qui atteignent une personne prête à agir. Si vous apprenez une panne par un client, c'est que la supervision manque.
• Des journaux sans secrets ni données personnelles, conservés assez longtemps pour enquêter sur un incident.

Corriger ou reconstruire ? Décidez section par section

La question est rarement de « reconstruire toute l'application ». Jugez chaque domaine séparément.

Ce qu'il vaut généralement mieux corriger

Les écrans et parcours que les utilisateurs comprennent, les intégrations qui fonctionnent et un modèle de données qui correspond à votre activité. Ils concentrent de vraies décisions produit, et les réécrire revient à jeter ce que vous avez appris.

Ce qu'il vaut souvent mieux reconstruire

Une authentification et une autorisation ajoutées par couches successives, une logique de paiement éparpillée dans le frontend et une conception de base de données qui s'oppose à chaque nouvelle fonctionnalité. Pour ces éléments, une implémentation propre et testée coûte souvent moins cher que des couches de correctifs. Notre article quand arrêter les prompts et faire appel à un ingénieur énumère les signes indiquant que vous en êtes là.

Un parcours de remise en état, dans l'ordre

1. Geler les fonctionnalités. Cessez d'ajouter des éléments pendant la stabilisation.
2. Prendre la propriété. Déplacez le code vers votre dépôt et consignez qui a accès à l'hébergement, à la base de données, au domaine et aux paiements.
3. Établir une base de référence et un inventaire. Listez chaque service, clé et environnement. Lancez l'AI App Health Check gratuit pour repérer les lacunes évidentes.
4. Renouveler les secrets exposés et déplacer les appels privés côté serveur.
5. Rendre la base de données reproductible, activer les sauvegardes et tester une restauration.
6. Renforcer les accès et les paiements, en le prouvant avec deux comptes et des paiements de test.
7. Ajouter la CI et un environnement de préproduction.
8. Ajouter la supervision et un plan de retour arrière avec un responsable désigné.
9. Lancer d'abord auprès d'un petit groupe, puis élargir.

Comment UnlockLive intervient

Si vous préférez ne pas faire cela seul, nos deux services suivent le même parcours. L'AI App Technical Audit examine le code, les données, l'authentification, les paiements, l'infrastructure et les risques, et vous remet une liste priorisée de ce qu'il faut corriger et dans quel ordre. Le service AI App Repair and Launch met ensuite en œuvre les corrections et construit la chaîne de déploiement, de sorte que l'application soit mise en ligne sur une infrastructure dont vous êtes propriétaire. Nos ingénieurs travaillent depuis Toronto et depuis notre centre d'ingénierie de Dhaka, la gestion de projet étant assurée côté Toronto.

Prêt à mettre votre application Bolt en production ?

Commencez par l'AI App Health Check gratuit pour savoir où en est votre application, puis décidez si vous avez besoin d'un audit, d'une réparation ou simplement de quelques après-midi de travail ciblé. L'essentiel de ce qui sépare un prototype Bolt d'un produit fiable peut être corrigé sans repartir de zéro, à condition de le trouver avant vos clients.