Test complet Bolt.new en 2026 : 7 jours sur un vrai projet client du prompt à la mise en ligne

En septembre 2026, nous avons décidé de mettre Bolt.new à l'épreuve sur un vrai projet client. Pas un prototype jetable, pas une démo pour un meetup : un livrable payant, avec un client qui attend une application fonctionnelle. Cet article retrace chaque journée de ce test, du premier prompt jusqu'à la mise en ligne, avec un retour honnête sur les forces, les faiblesses, les coûts réels et les limites du code généré par cette plateforme qui a transformé le paysage du développement web.

Introduction : pourquoi tester Bolt.new sur un vrai projet client en 2026 ?

L'intelligence artificielle a profondément modifié la manière de créer des applications web en 2026. Les outils de génération de code par langage naturel ne sont plus des curiosités : ils sont entrés dans les workflows de production des agences, des freelances et des startups. Bolt.new, développé par StackBlitz et lancé en juillet 2023, s'est imposé comme l'un des acteurs majeurs de cet écosystème. La plateforme a atteint 40 millions de dollars de revenus annuels en seulement cinq mois, et plus d'un million de sites ont été déployés via son environnement. Elle permet de créer des applications sans compétences préalables en programmation, directement depuis un navigateur.

Le projet que nous avons choisi pour ce test est une application de gestion de réservations pour un studio de yoga à Lyon. Les besoins sont classiques pour du B2B : planning de cours, fiches professeurs, paiement en ligne via Stripe, gestion d'abonnements, espace client, back-office léger. Ce type de solution couvre les cas d'usage les plus fréquents pour les petites entreprises.

Le plan de cet article : dérouler chaque journée du 10 au 17 septembre 2026, puis analyser les coûts, la qualité du code, la maintenabilité, et donner un avis tranché sur la pertinence de Bolt.new pour livrer un vrai projet client.

Jour 1 – Cadrage du besoin client et premier prompt dans Bolt.new

Le 10 septembre 2026, kick-off avec le client. Avant de toucher à l'outil, on pose les bases fonctionnelles du projet :

• Rôles utilisateurs : administrateur du studio, professeur, client

• Pages clés : page d'accueil, planning des cours, fiche cours/prof, espace client (réservations, abonnements), back-office (gestion des cours, professeurs, réservations)

• Fonctionnalités critiques : paiement Stripe, gestion d'abonnements (mensuel, trimestriel), inscription/connexion, annulation de réservation

• Stack souhaitée : Next.js full stack, Tailwind CSS, base de données Supabase

Le prompt initial doit inclure des spécifications claires sur la logique métier et les parcours utilisateur. Nous rédigeons un prompt structuré en français - Bolt.new supporte les prompts en français pour générer du code - avec les objectifs, rôles, pages, et contraintes techniques. Concrètement :

"Je souhaite créer une application de réservation pour un studio de yoga à Lyon. Les clients peuvent s'inscrire, réserver des cours selon un planning hebdomadaire, payer via Stripe et gérer des abonnements. Le back-office permet au personnel de gérer les cours, les professeurs et de visualiser les réservations. Stack : Next.js full stack, Tailwind CSS, Supabase. Design responsive mobile-first, palette de couleurs nature/pastel."

Il est crucial de choisir le mode approprié dès le début du projet - ici, le mode "application" plutôt que "site", pensé pour des sites web, ou "prototype". Bolt.new reste un outil orienté création rapide. L'interface de Bolt.new se présente simplement : une zone de chat à gauche, un éditeur de code au centre, et une preview en temps réel à droite. On limite volontairement le périmètre du MVP pour ne pas exploser la consommation de tokens dès la première session.

Jour 2 – Génération de l'application full stack et mise en place de la base de données

Le résultat du premier prompt est impressionnant. Bolt.new génère une application full-stack complète dès la première instruction : pages Next.js (avec le dossier app/), routes API, composants React, configuration Tailwind, et un schéma de base de données initial. Le tout en moins de cinq minutes.

Le projet utilise la technologie WebContainers pour exécuter un environnement Node.js complet dans le navigateur - pas besoin de terminal local ni de configuration serveur. L'outil permet aussi d'installer des packages npm directement depuis l'interface, ce qui simplifie l'ajout de dépendances comme stripe ou @supabase/supabase-js.

Les entités générées pour la base de données :

• Utilisateurs (nom, email, rôle, mot de passe hashé)

• Cours (titre, description, professeur, horaire, capacité)

• Réservations (utilisateur, cours, statut, date)

• Abonnements (type, durée, prix, renouvellement)

• Paiements (montant, statut, référence Stripe)

Des ajustements suivent par prompts supplémentaires : ajout d'un champ "niveau du cours" (débutant, intermédiaire, avancé), "capacité max", "statut de paiement" plus détaillé. L'IA comprend la demande, mais les noms de tables restent en anglais par défaut ("bookings", "courses"). Il faut reformuler pour adapter au métier du client. Les relations entre entités sont parfois simplifiées : pas toujours de contraintes ON DELETE, jointures superficielles. On note ces points pour y revenir plus tard.

Jour 3 – Design de l'interface et "vibe coding" avec l'IA

Le vibe coding, c'est cette approche où l'on itère rapidement entre prompts conversationnels et retouches manuelles dans l'éditeur. Pas de maquette Figma en amont : on pilote le design par le dialogue avec l'agent IA.

Via des prompts successifs, on obtient une interface responsive moderne : pages mobile-first, style minimaliste avec palette végétale, composants Tailwind CSS bien structurés. L'expérience utilisateur doit être améliorée par des ajustements visuels et une ergonomie respectée - on affine les marges, les tailles de police, les contrastes.

Exemple d'itération concrète :

"Rends la page de planning plus lisible. Passe en vue calendrier semaine. Ajoute un filtre par professeur et un indicateur du nombre de places restantes."

Le code généré modifie le composant planning, ajoute un sélecteur de professeur, et intègre un compteur de places. Le résultat visuel est convaincant. Mais voici le point d'attention : Bolt a tendance à réécrire des composants complets pour une petite demande. Ce qui devrait être un ajout de 10 lignes de code se transforme en 200 lignes réécrites. Cela fonctionne, mais génère de la dette technique et complexifie la maintenance à moyen terme.

Le mélange entre no code (prompts, preview) et code généré modifiable dans l'éditeur offre un bon contrôle. On peut intervenir manuellement sur les parties sensibles tout en laissant l'IA gérer le gros du travail de création visuelle.

Jour 4 – Logique métier, intégration Stripe et gestion des réservations

Le jour 4 est le tournant du projet : on passe du front-end au back end, là où la logique métier devient critique.

L'intégration Stripe se fait via prompts : on demande la création de sessions de paiement Checkout, la mise en place de webhooks pour écouter les événements (paiement réussi, échoué, remboursement), et la liaison avec le statut de réservation en base de données. L'application doit être configurée avec des clés API pour relier des bases de données et mettre en place l'authentification - variables d'environnement dans les réglages de Bolt.

Cas concrets testés :

• Annulation tardive (moins de 24h avant le cours) : on doit définir la règle, l'IA la traduit en condition dans l'API route, mais sans prompt précis, elle ne l'invente pas. L'IA ne comprend pas toujours le contexte métier spécifique.

• Cours complet : vérification de la capacité max avant insertion d'une réservation. Bolt génère la logique, mais la validation côté serveur est parfois incomplète.

• Liste d'attente : nécessite un prompt dédié et quelques itérations pour obtenir un résultat propre.

Une vérification humaine est recommandée pour la sécurité et les permissions dans les applications générées. Les endpoints doivent être protégés par authentification, les webhooks Stripe sécurisés par vérification de signature. Bolt génère le squelette, mais la relecture humaine reste essentielle.

Jour 5 – Tests, corrections d'erreurs et optimisation du code généré

Avant la mise en ligne, la phase de tests comprend des vérifications fonctionnelles, de performance et de sécurité. C'est le moment de vérité.

Bolt.new permet de créer et de tester des applications à l'aide d'une interface d'exécution intégrée. Les WebContainers affichent les logs serveur, les erreurs de build Next.js, et les messages d'erreur directement dans le navigateur. On peut utiliser des prompts pour diagnostiquer : "Debug cette erreur 500 sur /api/bookings" - l'IA propose une correction automatique, souvent pertinente.

Les fonctionnalités doivent être testées dans différents environnements : mobile, tablette, desktop. On vérifie les parcours utilisateur complets sur chaque format. Les performances ne sont pas optimisées pour la production à ce stade - il faut ajouter pagination du planning, réduction des requêtes N+1, et début de mise en cache pour les données semi-statiques.

L'optimisation de la performance et du référencement est réalisée avant la validation finale du client. Les Skills de Bolt.new permettent d'appliquer des conventions de performance et d'audit SEO directement dans le workflow.

Attention : les crédits s'épuisent rapidement lors d'itérations. Chaque prompt de debug consomme des tokens, et relancer la génération complète d'un composant coûte cher. Il faut être stratégique.

Jour 6 – Déploiement : de Bolt.new à Netlify (ou Vercel) en quelques clics

L'objectif du jour 6 : passer de l'environnement de développement dans le navigateur à une app en ligne accessible au client.

Bolt.new permet de déployer en un clic via Netlify. Le déploiement d'une application peut prendre moins de 10 minutes une fois la configuration prête. Bolt.new génère une URL publique après déploiement, sur un sous-domaine .bolt.host par défaut. Pour un domaine personnalisé, il faut passer sur un plan Pro ou configurer manuellement le DNS chez Netlify/Vercel.

Réglages concrets effectués :

• Variables d'environnement : clés Stripe (publique et secrète), URL Supabase, secret du webhook, clé d'authentification

• Build command : npm run build

• Output directory : .next

• Domaine : sous-domaine temporaire pour la préproduction, domaine client pour la production

Les projets peuvent être exportés vers GitHub pour un suivi de version. On peut exporter le code vers un dépôt GitHub en un clic directement depuis l'interface de Bolt. Ce conseil est important : exportez vers GitHub dès le milieu du projet, pas seulement à la fin. Cela sécurise le code, facilite la collaboration en équipe, et prépare une CI/CD plus classique si nécessaire.

Jour 7 – Recette client, ajustements finaux et passage en production

Le 17 septembre 2026, recette fonctionnelle avec le client en visioconférence. Les étapes clés d'un projet client incluent le cadrage, la génération, les itérations, les tests et le déploiement - nous sommes à l'étape finale.

Scénario de test déroulé en direct :

• Création de compte client

• Connexion, visualisation du planning

• Réservation d'un cours de yoga niveau débutant

• Paiement via Stripe (mode test)

• Réception du mail de confirmation

• Annulation de la réservation

• Vérification de l'état de l'abonnement dans le profil

Le projet doit être validé avec des tests utilisateurs pour s'assurer de son ergonomie et de sa fonctionnalité. Quelques demandes de dernière minute du client : changement de wording sur la page d'accueil, ajout du champ "niveau" visible directement sur la fiche cours, ajustement des créneaux horaires pour exclure le dimanche. Ces modifications sont faites soit par prompts rapides, soit par édition directe du code dans l'éditeur.

Passage en production : configuration du domaine personnalisé du client, SSL automatique via Netlify, vérification que les variables d'environnement pointent vers Stripe en mode live. Le site est en ligne.

Gestion des tokens, coûts et limites du plan gratuit en 2026

La réalité budgétaire d'un projet sur Bolt.new mérite d'être détaillée, car c'est souvent là que les surprises arrivent.

Le plan gratuit offre 1 million de tokens par mois, avec une limite de 300 000 tokens par jour. Un projet moyen consomme entre 30 000 et 50 000 tokens par session de travail significative. Sur notre projet de 7 jours, la consommation a été bien supérieure à ce que permet le plan gratuit :

• Génération initiale du squelette full stack : ~100 000 tokens

• Itérations design/UI (jour 3) : ~80 000 tokens

• Logique métier et intégrations (jour 4) : ~120 000 tokens

• Debug et corrections (jour 5) : ~90 000 tokens

• Ajustements finaux (jour 7) : ~60 000 tokens

Le plan gratuit suffit pour des prototypes simples de 1 à 2 écrans, mais devient trop juste pour un vrai projet client avec back end, paiement et logique métier. Le plan Pro coûte environ 20 dollars par mois et inclut un rollover des tokens non utilisés, ce qui est appréciable pour lisser la consommation. Le plan Teams commence à 60 dollars par membre par mois pour les agences qui gèrent plusieurs projets.

Pour rester compétitif face à d'autres solutions d'intelligence artificielle ou de no code, passer en Pro est un investissement raisonnable dès qu'on travaille sur un livrable client.

Qualité et maintenabilité du code généré : ce que révèle un vrai projet

Après 7 jours d'utilisation intensive, voici notre analyse critique du code généré par Bolt.new pour cette application full stack.

Structure du projet :

• Dossiers app/ (pages et layouts Next.js), components/ (composants React), api/ (routes backend), lib/ (helpers, configuration Supabase, Stripe), styles/ (Tailwind)

• Fichiers de configuration standards : next.config.js, package.json, .env

Points positifs :

• Utilisation de frameworks standards (Next.js, React, Tailwind CSS) : le code est lisible par n'importe quel dev expérimenté

• Conventions reconnues, nommage cohérent, architecture par dossiers claire

• Le code en ligne est modifiable, pas une boîte noire

Faiblesses constatées :

• Logique métier parfois mélangée aux composants de présentation (validation de réservation dans le composant UI au lieu d'un service séparé)

• Composants trop lourds après plusieurs itérations de réécriture

• Quasi-absence de tests unitaires auto-générés

• Duplication de code entre pages similaires

• Le code généré peut accumuler de la dette technique, surtout après de nombreuses itérations

• Le code généré devient difficile à maintenir au-delà de 5-6 écrans

Nous recommandons une phase de refactoring post-projet de 1 à 2 jours pour solidifier l'architecture, extraire la logique métier dans des services dédiés, ajouter des tests, et uniformiser le style avant d'ajouter de nouvelles fonctionnalités.

Comparaison rapide avec un workflow "classique" de développement web

Pour mettre ce test en perspective, comparons avec un développement codé à la main par un dev expérimenté.

• Cadrage fonctionnel : temps identique (~0,5 jour). Pas de raccourci possible ici.

• Scaffolding full stack : 1 journée avec Bolt vs 3 à 5 jours en traditionnel (initialisation projet, configuration base de données, auth, premières pages, API).

• Intégrations (Stripe, Supabase) : temps comparable, car la relecture humaine du code est nécessaire dans les deux cas.

• Tests et debug : le temps "gagné" sur le scaffolding est parfois "reperdu" sur le débogage et la clarification des prompts. Un benchmark récent confirme que les outils comme Bolt accélèrent la phase initiale mais n'éliminent pas la phase de validation.

La posture de travail change fondamentalement. On pilote un agent IA plutôt que d'écrire chaque ligne de code. Cela demande des compétences en architecture et en conception plus qu'en programmation pure.

Lovable est considéré plus performant que Bolt.new sur certains cas d'usage, notamment pour les interfaces très polies. Mais Bolt reste un choix solide comme alternative grâce à son approche full stack et à son environnement de développement intégré au navigateur. Bolt.new est idéal pour des MVP et prototypes rapides, moins adapté pour des projets enterprise très complexes dès le départ.

Conseils pratiques pour réussir vos 7 premiers jours sur Bolt.new

Voici notre guide condensé après cette expérience terrain :

• Définissez l'architecture métier avant le premier prompt. Schéma de base de données, rôles utilisateurs, règles métier clés - tout cela doit être clair avant d'ouvrir Bolt. La création d'une application nécessite un prompt initial détaillé pour orienter le développement.

• Travaillez par petites étapes. Une fonctionnalité à la fois, tests immédiats, prompts précis. Évitez les gros prompts flous qui consomment des tokens pour des résultats approximatifs.

• Utilisez l'éditeur de code en parallèle des prompts. Pour les parties sensibles - sécurité, paiements, logique métier - gardez la maîtrise en intervenant directement dans le logiciel. Ne laissez pas l'IA gérer seule sans écrire une seule ligne de code de vérification.

• Exportez vers GitHub dès le milieu du projet. Bolt.new permet d'exporter le code vers GitHub en un clic. Faites-le tôt pour éviter tout verrou propriétaire et faciliter la collaboration en équipe.

• Testez sur mobile et tablette régulièrement. Pas seulement le dernier jour.

• L'IA est un accélérateur, pas un remplaçant. Elle ne remplace pas une compétence de base en développement full stack ou en architecture. Le dev humain reste essentiel pour auditer, sécuriser et optimiser.

Bolt.new, no code, low code : où se situe l'outil en 2026 ?

Bolt.new n'est pas un pur no code. On reste sur du code généré, modifiable, basé sur des frameworks open source standards. Contrairement à un builder visuel type Webflow ou Bubble, on a accès à chaque fichier, chaque ligne de code, chaque configuration. Bolt.new propose un processus structuré qui couvre les 7 jours de la conception à la mise en production d'un projet.

L'outil se positionne comme un intermédiaire entre les plateformes no code visuelles et l'IDE classique avec copilot IA. C'est un modèle hybride - du vibe coding combiné à un éditeur de code complet - qui offre plus de contrôle que du no code pur pour créer des applications métier sur mesure.

Pour les consultants en consulting tech, les agences SaaS, ou les équipes dev réduites, cette approche hybride représente un gain de productivité réel. L'utilisation des Skills de Bolt.new permet d'appliquer des conventions de qualité à tous ses projets, ce qui tend à industrialiser la génération de code.

Le futur probable : montée en puissance de la génération de code par IA, mais besoin croissant de compétences pour auditer, tester et sécuriser les applications web. Les mises à jour régulières de la plateforme (nouveaux modèles, meilleure efficacité tokens) vont dans ce sens. Le moteur d'IA derrière Bolt évolue vite, et les concepts de prompt engineering deviennent une compétence à part entière.

FAQ rapide : questions fréquentes après 7 jours sur Bolt.new

• Peut-on livrer un vrai projet client avec le plan gratuit ? Pour un prototype simple ou une démo, oui. Pour un vrai livrable avec paiement, back-office et logique métier, le plan gratuit sera insuffisant dès la 3e ou 4e journée. Le passage au plan Pro est quasiment inévitable.

• Combien de temps pour une première application full stack ? Bolt.new génère une application complète en moins de 5 minutes. Mais un MVP fonctionnel avec design, logique métier et intégrations prend 3 à 5 jours de travail réel.

• Bolt gère-t-il la base de données ou faut-il tout configurer à la main ? L'intégration d'une base de données et d'une authentification est essentielle pour de nombreux projets client. Bolt initialise une base par défaut et permet la connexion à Supabase. Les modèles sont modifiables par prompts ou manuellement.

• Le code généré est-il suffisant pour du paiement en ligne en production ? Partiellement. Le code inclut les routes API Stripe et la logique de base, mais une vérification humaine de la sécurité (webhooks, validation, conformité) reste indispensable avant la mise en production.

• Comment travailler à plusieurs sur un projet Bolt.new (GitHub, export, partage de code) ? Bolt.new permet d'exporter le code vers un dépôt GitHub. En plan Teams, on bénéficie d'un accès partagé et de droits de collaboration. Pour les projets sérieux, l'export GitHub dès le début est fortement conseillé.

• Les performances sont-elles suffisantes pour un usage réel ? Pour un usage normal (quelques dizaines d'utilisateurs simultanés), oui. Pour de la montée en charge, il faudra optimiser ou migrer certaines parties vers une solution dédiée.

• Bolt.new est-il adapté pour du SaaS ? Pour un MVP SaaS, c'est un excellent point de départ. Au-delà, il faudra refactorer, ajouter des tests, et probablement migrer vers un workflow de développement plus classique.

• L'outil fonctionne-t-il bien en français ? Oui. Les prompts en français sont supportés et le code généré répond correctement aux instructions en langue française. Nommer les variables et les champs en français est possible, même si l'IA propose souvent l'anglais par défaut.

Conclusion : notre verdict après un test complet de Bolt.new sur 7 jours

Après 7 jours sur un vrai projet client - du cadrage du besoin pour un studio de yoga lyonnais jusqu'à la mise en production d'une app de rendez-vous et de réservation - voici notre verdict.

Ce qui fonctionne remarquablement bien :

• La vitesse de prototypage est sans équivalent. Passer d'un prompt à une application full stack fonctionnelle directement dans le navigateur en quelques minutes change radicalement la donne pour les MVPs.

• L'intégration IA + WebContainers crée un environnement de développement web complet, sans installation locale, accessible à tout le monde - développeur comme non-dev.

• La grâce de pouvoir alterner entre prompts et édition manuelle donne un vrai contrôle sur le résultat final.

Ce qui reste à améliorer :

• La consommation de tokens sur un projet réel dépasse vite les limites du plan gratuit.

• Le code généré nécessite du refactoring pour être maintenable au-delà du prototype.

• La sécurité et la logique métier demandent une supervision humaine attentive - l'IA accélère, mais ne remplace pas le regard du développeur.

Notre recommandation : Bolt.new est un excellent choix pour des MVPs, des projets B2B simples, des startups en early-stage ou des outils internes. Il est moins adapté pour des applications critiques très complexes dès la première version, ou pour des sites nécessitant une architecture sur mesure dès le début.

Si vous hésitez encore, testez Bolt.new sur un petit projet réel de 3 à 7 jours. Appliquez les bonnes pratiques de prompt engineering, exportez vers GitHub dès le début, et gardez un œil critique sur le code généré. C'est la meilleure façon de vous forger votre propre avis - et probablement de livrer votre prochain MVP plus vite que prévu.