Bolt.new : 5 vérifications avant mise en production

Bolt.new fait un truc impressionnant : en 10 minutes, il génère une app qui marche. Le problème, c'est tout ce qu'il ne fait pas.

Le mois dernier, un fondateur m'a envoyé son app Bolt pour audit. Interface propre, navigation fluide, le formulaire de paiement fonctionnait. Sauf qu'en regardant le code, j'ai trouvé 40 fichiers, zéro test, et 3 clés API visibles par n'importe qui avec un clic droit dans le navigateur. L'app marchait parfaitement. Elle était juste ouverte à tous les vents.

Ce que Bolt.new fait bien — et pourquoi c'est trompeur

Je ne vais pas cracher sur Bolt. L'outil est bluffant. Vous décrivez ce que vous voulez, il génère une app React complète avec une interface soignée, du routing, et un déploiement en un clic sur Netlify. Pour valider une idée, c'est exactement ce qu'il faut.

Le piège, c'est que le résultat ressemble à un produit fini. L'interface est propre. Les boutons fonctionnent. Le formulaire envoie les données. Alors on se dit : "c'est bon, je peux lancer."

Sauf que le code généré par Bolt.new n'est pas mauvais — il est incomplet. La distinction compte. Un dev qui vous dit "c'est du code pourri, il faut tout refaire" se trompe. Le code fait ce qu'on lui a demandé de faire. Il manque tout ce qu'on ne lui a pas demandé : la sécurité, la gestion d'erreurs, les tests, la validation côté serveur.

C'est comme un appartement témoin : tout est beau, tout fonctionne en apparence. Mais il n'y a ni serrure à la porte, ni alarme incendie, ni compteur électrique.

Ce que j'ai trouvé en auditant une vraie app Bolt

Le fondateur avait construit une app e-commerce avec Bolt. Catalogue produits, panier, paiement Stripe. Visuellement, rien à redire.

Dans le code, c'était une autre histoire.

3 clés API en clair dans le code frontend — Stripe, SendGrid, un service de géolocalisation. N'importe qui en ouvrant les outils développeur du navigateur pouvait les copier. La clé Stripe permettait d'émettre des remboursements. Temps de correction : 2 heures.

Zéro test. Pas un seul fichier de test dans le projet. Aucun moyen de savoir si une modification du code allait casser le paiement, l'inscription ou n'importe quel autre parcours critique. Le fondateur l'a appris quand une mise à jour a silencieusement cassé le formulaire de commande pendant 4 jours. Personne ne s'en est aperçu.

Le fichier .env commité sur GitHub. Le dépôt était public. Les identifiants de la base de données — login, mot de passe, URL du serveur — étaient accessibles à quiconque les cherchait. Le fondateur ne savait même pas ce qu'était un fichier .env.

Pas de validation côté serveur. Les prix des produits n'étaient vérifiés que dans le navigateur. Un utilisateur un peu malin pouvait modifier le montant dans la requête réseau et payer ce qu'il voulait. Le fondateur l'a découvert quand un client a commandé pour 2 000 € de marchandise en payant 20 €.

Le vrai problème : tout est côté client

Bolt génère du code frontend-first. Toute la logique tourne dans le navigateur du visiteur : la validation des formulaires, la vérification des prix, parfois même l'accès aux données.

Pour un dirigeant, voici ce que ça signifie concrètement : imaginez un coffre-fort dont le code est écrit sur la porte. Le coffre ferme bien. Mais n'importe qui peut lire le code et l'ouvrir.

Quand la logique est côté client, l'utilisateur peut la modifier. Changer un prix. Contourner une vérification d'accès. Voir les données d'un autre utilisateur en modifiant une URL. Ce n'est pas de la science-fiction — c'est ce que je retrouve dans la majorité de mes audits de code généré par IA.

Bolt ne fait pas ça par négligence. Il fait ce qu'on lui demande : générer une interface qui fonctionne. La sécurité côté serveur, la protection des données, le cloisonnement entre utilisateurs — ce sont des choses qu'il faut lui demander explicitement, avec des prompts précis. Et même là, le résultat demande une vérification humaine.

Non, il ne faut pas tout recoder

C'est le réflexe que je vois chez beaucoup de fondateurs après une mauvaise surprise : appeler une agence pour "refaire proprement". Un de mes clients a payé 8 000 € pour une refonte complète de son app Bolt. L'agence a tout réécrit de zéro — nouveau framework, nouvelle base de données, nouvelle architecture.

En réalité, il suffisait de sécuriser 4 points : déplacer les clés API côté serveur, ajouter une validation serveur sur les prix, configurer les autorisations CORS, mettre un rate limiting sur les endpoints sensibles. Coût estimé : environ 1 500 €. Cinq fois moins.

Sur mes derniers audits de code IA, la grande majorité nécessitait moins de 2 000 € de corrections. Pas une refonte. Des corrections ciblées sur les failles de sécurité et les manques critiques.

J'ai aussi vu la situation inverse. Un fondateur convaincu qu'il devait tout jeter est venu me voir la boule au ventre. Son app Bolt était en fait propre côté interface et structure de composants. Le problème se limitait à la sécurité et la gestion d'erreurs. On a corrigé en 2 jours, il a gardé 90 % du code. Son soulagement était palpable — il s'attendait à un devis de refonte à 10 000 €.

Le code Bolt est un brouillon avancé. Pas un produit fini. Et un brouillon, on le corrige — on ne le réécrit pas.

Les 5 vérifications post-Bolt avant mise en production

Avant de mettre votre app Bolt.new en production — ou si elle est déjà en ligne — voici les 5 points à vérifier. Vous pouvez transmettre cette liste à un développeur, il saura exactement quoi faire.

1. Les clés API et secrets sont-ils protégés ? Vérifiez qu'aucune clé API (Stripe, base de données, services tiers) n'apparaît dans le code frontend. Elles doivent être côté serveur, dans des variables d'environnement non accessibles au navigateur, et absentes de tout dépôt Git. Si votre dépôt GitHub est public, c'est la première chose à vérifier — aujourd'hui.

2. La validation se fait-elle côté serveur ? Tout ce qui concerne l'argent, les droits d'accès ou les données sensibles doit être vérifié par le serveur, pas par le navigateur. Si les prix, les remises ou les rôles utilisateurs ne sont contrôlés que côté client, n'importe qui peut les contourner.

3. L'authentification protège-t-elle vraiment les données ? Vérifiez que les pages protégées le sont côté serveur — pas uniquement par un if dans le code frontend qui masque un bouton. Un utilisateur ne doit pas pouvoir accéder aux données d'un autre en modifiant l'URL ou en interceptant les requêtes réseau.

4. Les erreurs sont-elles gérées proprement ? Quand quelque chose plante, l'utilisateur ne doit pas voir un message technique avec des détails sur votre infrastructure (nom de la base de données, chemin du serveur, stack trace). Et surtout, chaque erreur doit être enregistrée quelque part pour que vous puissiez la détecter et la corriger.

5. Les flux critiques ont-ils été testés ? Paiement, inscription, modification de mot de passe, suppression de compte : faites passer ces scénarios par un développeur qui essaie activement de les casser. Pas besoin de 200 tests automatisés pour commencer. Testez manuellement les 3 ou 4 parcours où l'argent ou les données personnelles circulent.

Bolt pour le prototype, un audit avant la prod

Bolt.new est un excellent outil de prototypage. Il fait gagner des semaines sur la construction d'un MVP et permet de valider une idée avec de vrais utilisateurs avant d'investir lourdement. Le problème n'est pas Bolt. C'est de confondre un prototype fonctionnel avec un produit sécurisé.

La stratégie qui fonctionne : utilisez Bolt pour construire et valider votre idée — c'est fait pour ça. Avant de passer en production avec de vrais utilisateurs et de vraies transactions, faites vérifier les 5 points ci-dessus. Si un dev vous dit "il faut tout refaire", demandez-lui d'abord de lister précisément ce qui est critique. Dans la plupart des cas, 80 % du code est récupérable.

Un audit de code prend quelques jours et coûte une fraction du prix d'une refonte. C'est la différence entre une app qui tient la route et une app qui attend son premier incident pour révéler ce que Bolt n'a pas fait.