Avis sur Bolt.new (Vérifié en août 2026)

Bolt.new débute à $25/mois. Découvrez notre avis sur Bolt.new, ses limites de base de données et de tokens, face à Lovable, Replit ou Cursor.

Thursday, September 3, 2026Omid Saffari
Avis sur Bolt.new (Vérifié en août 2026)

Bolt.new vaut ses $25 par mois pour un créateur solo qui doit transformer une idée d'application web bien délimitée en un prototype hébergé et prêt à être inspecté au niveau du code. Évitez-le pour un système en production mature, un workflow purement visuel pour profils non techniques, ou tout projet dont vous ne pouvez pas vous permettre de restaurer la base de données manuellement : le retour en arrière de projet de Bolt ne restaure toujours pas la base de données.

Bolt.new en un coup d'œil : de quoi s'agit-il ?

Bolt.new est un constructeur d'applications dans le navigateur qui transforme un brief rédigé en code applicatif modifiable, exécute ce code dans un environnement de développement en ligne, et peut intégrer une base de données, l'authentification et l'hébergement sans vous obliger à assembler ces briques au préalable. Il se positionne entre un outil no-code et un éditeur de code assisté par IA : vous travaillez via des conversations, mais le résultat produit reste une base de code prête à être exportée vers GitHub. Cela en fait une solution idéale pour les prototypes, les outils internes et les produits web aux contours stricts, et non pour déléguer chaque décision d'ingénierie à un prompt.

Page d'accueil de Bolt.new avec son générateur prompt-to-app et ses options d'importation
Page d'accueil de Bolt.new

Le produit actuel a nettement évolué par rapport à celui utilisé lors de ses débuts. Les notes de version de Bolt indiquent que le v1 Agent et le Discussion Mode ont été retirés le August 3, 2026. Les projets restants ont migré vers le Bolt Agent tout en conservant les fichiers et l'historique des chats, et le Plan Mode est devenu l'espace dédié à la conception d'une architecture sans modifier immédiatement le code. La dictée vocale est également active, transcrivant la voix en un prompt modifiable avant son envoi.

Notre avis sur Bolt.new face aux alternatives

Bolt.new s'impose lorsque vous souhaitez réunir le prompt, le code, la base de données et le premier déploiement au sein d'un seul workflow dans le navigateur. Lovable l'emporte lorsque la finition visuelle et la collaboration fluide priment sur le contrôle direct du code. Replit offre un espace de travail de développement dans le navigateur plus généraliste. Cursor est bien plus pertinent lorsqu'un développeur expérimenté dispose déjà d'un dépôt Git et recherche un éditeur de code pensé pour l'IA plutôt qu'un générateur d'applications tout-en-un.

OutilIdéal pourPrix de départ payantDifférence décisive
Bolt.newPrototypes full-stack cadrés et outils internesPro à $25/moisBase de données, hébergement et code portable dans un flux piloté par prompt
LovableFondateurs axés design et équipes aux compétences variéesPro à $25/moisUtilisateurs illimités partageant un espace de travail et un pool de crédits
ReplitDéveloppement cloud étendu et agents parallèlesCore à $20/mois, ou $18/mois facturé annuellementDeux agents en parallèle, base de données intégrée et espace de développement complet
CursorDéveloppeurs faisant évoluer une base de code existanteIndividual Pro à $20/moisÉdition directe du code avec modèles de pointe, MCPs, skills, hooks et agents cloud

Ce tableau masque une nuance essentielle. Bolt.new, Lovable et Replit peuvent tous amorcer une application, tandis que Cursor présuppose que vous êtes à l'aise au milieu des lignes de code. Se limiter au prix de l'abonnement fait oublier le coût de la transition technique. Un fondateur non technique paiera les mêmes $25 pour Lovable Pro et s'évitera des heures de revue de code. Un développeur paiera $20 pour Cursor et évitera de payer un constructeur de prompts pour relire un projet grandissant à chaque message.

C'est la règle d'or de cette analyse : choisissez l'environnement qui garde visible la complexité majeure de votre projet. Bolt garde l'infrastructure suffisamment visible pour migrer vers GitHub. Lovable met en avant le design et la collaboration. Replit privilégie l'espace de développement étendu. Cursor met l'accent sur le code lui-même.

À qui s'adresse Bolt.new, et qui devrait l'éviter

Bolt.new s'adresse aux bâtisseurs qui recherchent une première version fonctionnelle rapide sans la confondre avec une architecture définitive. Le profil idéal gère un workflow restreint, sait décrire les données et les permissions, et analysera le code généré ou fera appel à quelqu'un capable de le faire. Le profil inadapté arrive avec une idée de produit massive, sans critères d'acceptation, avec des données sensibles et l'illusion que multiplier les prompts résoudra chaque défi d'architecture.

Profil adapté : le fondateur solo validant un workflow unique

Bolt.new est idéal pour un créateur solo voulant valider un workflow précis avant d'embaucher une équipe de développement. Prenons l'exemple d'un outil de réservation pour professeurs indépendants. Une première version utile nécessite des profils d'enseignants, des créneaux disponibles, un formulaire de réservation, un e-mail de confirmation et une interface d'administration basique. Ces éléments s'articulent parfaitement avec une base de données, un module d'authentification et une interface hébergée.

Le fondateur peut décrire les rôles des utilisateurs, demander à Bolt de générer les tables et la logique de connexion, publier un aperçu privé ou public, puis exporter le code sur GitHub avant d'inviter ses premiers utilisateurs. Le produit nécessitera encore des tests, des arbitrages sur la confidentialité des données et de la maintenance, mais Bolt réduit considérablement l'écart entre un cahier des charges textuel et une interface cliquable.

Cette logique ne fonctionne plus si le fondateur ne sait pas si un contrôle de permissions relève de l'interface ou de la base de données. Un bouton masqué pour le mauvais utilisateur ne garantit en rien une stratégie de sécurité au niveau des lignes (RLS). Bolt peut générer les deux, mais quelqu'un doit impérativement auditer l'ensemble.

Profil adapté : le product manager validant un flux avant le dev

Bolt.new convient également à un product manager cherchant un prototype interactif alimenté par de vraies données, plutôt qu'une énième maquette statique. Un outil d'approbation de retours produits, par exemple, peut inclure une file d'attente, une fiche client, des motifs de retour et des actions spécifiques selon les rôles. Les parties prenantes peuvent manipuler le flux et détecter les cas limites avant même le lancement du sprint de développement.

Le PM doit considérer l'application générée comme une phase de discovery exécutable. L'intérêt n'est pas de pousser ce prototype tel quel en production, mais de valider la pertinence du workflow tant que les modifications restent peu coûteuses. La synchronisation avec GitHub fournit un livrable technique concret à inspecter pour un ingénieur, sans pour autant transformer ce prototype en architecture validée.

Profil adapté : la petite agence avec une stratégie de transfert claire

Bolt.new permet à une petite agence de créer rapidement des calculateurs, portails, outils de campagne ou prototypes, à condition d'appliquer une règle de transfert stricte à chaque projet. Dès le cadrage, l'agence doit définir si le livrable reste sur l'hébergement de Bolt, bascule sur un dépôt client ou fait l'objet d'un développement sur mesure. Ce choix détermine la gestion des domaines, des secrets d'API, des sauvegardes de bases de données et des évolutions futures.

Les fonctionnalités Teams facilitent la gestion des accès, le partage d'organisation et l'intégration de design systems, mais la tarification par utilisateur doit être prise en compte. Chaque membre payant bénéficie de son propre quota de tokens, sans mise en commun possible. Une agence comptant un développeur actif et plusieurs relecteurs risque de payer pour de la capacité inutilisée alors que le bâtisseur principal arrive à court de tokens.

Pour une équipe non technique axée sur le design : préférez Lovable

Lovable est la meilleure solution de repli si votre équipe privilégie une interface soignée, un pool de crédits partagé et un minimum d'arbitrages techniques sur le code. Lovable Pro est proposé à $25 par mois pour 100 crédits mensuels, un nombre illimité d'utilisateurs, le report des crédits, des recharges, des domaines personnalisés, la gestion des rôles, des plafonds par utilisateur, le support par e-mail et l'intégration de design systems.

Page de tarification de Lovable affichant les forfaits Free, Pro, Business et Enterprise
Tarifs Lovable

Ce modèle d'utilisateurs illimités tranche nettement avec le forfait Bolt Teams à $30 par membre et par mois. Les crédits partagés de Lovable ne sont pas nécessairement plus généreux, et leur métrique ne correspond pas directement aux tokens de Bolt. L'avantage est avant tout organisationnel : un fondateur, un designer et un marketeur peuvent collaborer sur un unique espace Pro sans multiplier l'abonnement par le nombre de sièges.

Choisissez Lovable si votre priorité est : « L'équipe entière peut-elle ajuster l'interface ? ». Choisissez Bolt si votre priorité est : « Pouvons-nous générer une base de code fonctionnelle, une infrastructure et un export GitHub depuis un seul onglet ? ». Si personne dans votre équipe n'est prêt à relire du code, le contrôle offert par Bolt représente une complexité superflue.

Pour un environnement de développement cloud plus large : préférez Replit

Replit représente une excellente alternative si vous recherchez un environnement de développement complet dans le navigateur, l'exécution d'agents en parallèle et un pont direct entre l'expérimentation rapide et un espace développeur managé. Replit Core coûte $20 par mois ou $18 par mois avec engagement annuel, incluant deux agents simultanés, des espaces de travail illimités et $20 de crédits sur ses modèles les plus performants.

Page de tarification de Replit présentant les forfaits Starter, Core, Pro et Enterprise
Tarifs Replit

L'écart est encore plus visible sur le haut de gamme. Replit Pro coûte $100 par mois ou $90 par mois facturé annuellement, et intègre dix agents parallèles, jusqu'à quinze collaborateurs, jusqu'à cinquante observateurs et un rollback de la base de données jusqu'à vingt-huit jours. À l'inverse, l'historique de versions natif de Bolt ne permet aucune restauration de base de données.

Cela ne rend pas Replit supérieur par défaut. En revanche, un utilisateur pour qui l'exécution concurrente d'agents ou la restauration documentée de données est critique doit faire passer ces besoins avant le tarif d'entrée plus accessible de Bolt à $25. Choisissez Bolt pour créer une application à partir d'un prompt ciblé. Choisissez Replit lorsque c'est l'environnement de développement complet que vous achetez.

Pour une base de code existante : préférez Cursor

Cursor est la meilleure option pour un développeur chevronné dont le projet existe déjà. Cursor Individual Pro coûte $20 par mois et augmente les quotas de son mode Agent tout en donnant accès aux modèles de pointe, aux MCPs, aux skills, aux hooks et aux agents cloud.

Page de tarification de Cursor affichant les forfaits Hobby, Individual, Teams et Enterprise
Tarifs Cursor

Cursor ne vous dispense pas de configurer l'hébergement, l'authentification ou la base de données — et c'est précisément ce qui en fait l'outil idéal une fois ces briques architecturales posées. Le développeur intervient directement sur le dépôt Git au lieu de demander à un générateur d'applications de resynchroniser et réinterpréter constamment le projet global.

Passez à Cursor lorsque votre mission n'est plus de « définir les contours d'un produit », mais de « modifier une base de code identifiée selon des règles d'architecture et de revue établies ». Notre comparatif détaillé Codex, Claude Code et Cursor sera votre meilleure lecture dès lors que la maîtrise directe du code redevient votre priorité.

Fonctionnalité 1 : prototypes full-stack avec base de données et hébergement

L'atout majeur de Bolt.new ne réside pas dans la génération d'une page isolée. Sa force est d'articuler l'interface, la base de données, l'authentification et le premier déploiement pour permettre à une seule personne de modéliser un workflow de bout en bout. C'est pourquoi Bolt s'avère bien plus pertinent pour concevoir un portail client ou un module de réservation que pour fabriquer de simples maquettes marketing.

Documentation de Bolt Database détaillant les paramètres d'authentification, de stockage, de logs et de sécurité
Bolt Database

Imaginons une entreprise locale de services à domicile remplaçant un traitement manuel par e-mail et tableur. L'outil nécessite un formulaire client, l'enregistrement des demandes, une vue de répartition, l'assignation aux techniciens et un suivi d'états. Un workflow efficace sur Bolt commence par définir formellement ces entités et permissions, plutôt qu'en réclamant une « application moderne de services ».

  1. Définir le workflow et les rôles

    Décrivez précisément les rôles client, répartiteur et technicien. Spécifiez les différents statuts d'une demande, ce que chaque rôle peut visualiser, et quelles actions font progresser le statut. Cela fournit à Bolt un modèle logique plutôt qu'une vague intention visuelle.

  2. Expliciter le modèle de données

    Demandez explicitement la création de tables pour les clients, les demandes d'intervention, les assignations et l'historique des statuts. Bolt peut générer une base de données de manière autonome, mais un modèle clair facilite l'audit et évite que des états critiques ne restent confinés au code de l'interface.

  3. Spécifier l'authentification et les autorisations

    Détaillez l'inscription par e-mail, la connexion, la réinitialisation de mot de passe et le contrôle d'accès basé sur les rôles. La documentation de Bolt précise que l'authentification peut ne pas être activée automatiquement, même lorsqu'une base de données est créée. Vérifiez les URLs de redirection et les règles d'accès avant tout partage public.

  4. Déployer un aperçu jetable

    Les forfaits Free et Pro permettent de publier sur une adresse en .bolt.host. Travaillez d'abord sur un jeu de données temporaire. Invitez un utilisateur métier à tester la création, l'assignation et la clôture d'un ticket pour consigner chaque état manquant.

  5. Exporter le code avant d'intégrer des données réelles

    Liez votre dépôt GitHub dès que le premier workflow est stabilisé. N'attendez pas d'avoir des données clients réelles pour découvrir comment isoler proprement le projet, la base de données et le déploiement.

Bolt Database simplifie la configuration initiale. Le service peut provisionner une base de données selon les besoins de l'application, gère les paramètres d'authentification, donne accès aux logs et aux variables secrètes, et vous permet d'opter pour Supabase lors de l'initialisation. La protection contre les fuites de mots de passe est activée par défaut lors de la création via Bolt. En revanche, si la base est liée ou revendiquée via Supabase, cette protection dépend de votre forfait Supabase et reste désactivée sur leur offre Free.

Il est primordial de distinguer une fonctionnalité générée d'un comportement rigoureusement vérifié. Une page de connexion peut sembler fonctionnelle alors que les redirections de mot de passe oublié renvoient vers une URL incorrecte. Une vue de répartition peut masquer les données d'un autre client sur l'interface alors que les politiques d'accès de la base de données continuent de les exposer. Bolt permet de configurer les URLs de redirection, les listes d'URIs autorisées, les fournisseurs et les templates, mais une vérification humaine reste indispensable.

L'hébergement proposé est tout aussi pratique mais présente des limites strictes. L'offre Free comprend une adresse en .bolt.host, 10GB de bande passante et 333,333 requêtes par mois pour l'ensemble du compte. Le forfait Pro étend cette limite à 30GB et 1 million de requêtes mensuelles, autorise les noms de domaine personnalisés et permet la facturation du trafic excédentaire. Ces volumes suffisent pour tester de petits projets, mais ils s'appliquent au compte entier : vos différentes applications se partagent donc ce quota unique.

Le véritable écueil concerne la restauration. L'historique de versions (Version History) de Bolt ne prend absolument pas en charge la base de données. Revenir à la version de votre code d'hier laisse intacte votre base de données d'aujourd'hui. Ce décalage peut être plus préjudiciable que l'absence totale de rollback, car il induit en erreur en laissant penser que le code et les données sont versionnés conjointement.

Dans notre exemple d'entreprise de services, imaginez restaurer le code applicatif antérieur au renommage d'un statut alors que la base de données utilise déjà le nouveau schéma. L'interface et les données ne correspondront plus. Avant qu'un projet ne devienne stratégique, prévoyez des sauvegardes de bases de données, gérez les migrations de schéma et validez une procédure de restauration complète en dehors de Bolt.

Fonctionnalité 2 : propriété du code grâce à GitHub

Bolt.new se démarque des outils no-code fermés car l'application peut être hébergée sur GitHub, puis transférée vers un autre hébergeur ou environnement de développement. Cette portabilité n'est utile que si vous l'activez immédiatement. L'argument « le code est exportable » ne constitue pas un plan de secours si votre dépôt n'a jamais été synchronisé et que nul ne sait quel commit correspond à la base de données en production.

Documentation de l'intégration GitHub de Bolt couvrant les dépôts, les branches et la synchronisation
Intégration GitHub sur Bolt

La documentation GitHub de Bolt précise qu'un dépôt créé depuis Bolt démarre en mode privé sur la branche main. Bolt commite automatiquement les modifications tant qu'elles ne cassent pas le projet, vérifie GitHub toutes les trente secondes pour détecter les changements externes, et permet de créer ou changer de branche.

Voici un workflow de transfert recommandé :

  1. Connecter le dépôt dès la première version stable

    Générez le dépôt pendant que le projet est encore en phase exploratoire. Vérifiez la présence des fichiers attendus, des exemples de variables d'environnement et des fichiers de dépendances. Vos clés secrètes ne doivent jamais être commitées.

  2. Créer une branche pour chaque évolution majeure

    Isolez chaque flux de paiement, changement de droits ou refonte d'interface sur une branche distincte. Bolt sépare le contexte de chaque branche, évitant ainsi la pollution accidentelle de votre branche principale par du code non finalisé.

  3. Relire et fusionner sur GitHub

    Bolt permet de créer et changer de branche, mais ne gère pas les fusions (merges) dans son interface. Ouvrez votre pull request et effectuez le merge sur GitHub, là où un développeur peut inspecter les commits et où l'historique reste documenté.

  4. Synchroniser avant de relancer des prompts

    Attendez que l'état fusionné soit répercuté dans Bolt, ouvrez la branche souhaitée et contrôlez l'aperçu. Bolt scrute GitHub toutes les trente secondes, mais cette synchronisation automatique ne remplace pas la vérification manuelle de la branche avant d'engager de nouveaux prompts.

Ce workflow positionne Bolt comme un tremplin plutôt qu'un écosystème fermé. Un développeur peut quitter Bolt, travailler directement sur le dépôt, déployer sur un autre cloud, puis revenir ponctuellement sur l'outil. Une souplesse appréciable lorsque le prototype nécessite d'intégrer des tests unitaires, de la surveillance applicative, un audit de sécurité ou un nouveau backend.

Deux limites techniques doivent être clairement anticipées. D'abord, le merge s'effectue exclusivement hors de Bolt : une équipe non technique doit donc maîtriser les pull requests ou s'appuyer sur une ressource technique. Ensuite, l'éditeur documente un cas de concurrence rare : si Bolt et GitHub sont mis à jour quasi simultanément, Bolt conserve ses propres modifications et écrase celles de GitHub.

La parade repose sur de bonnes pratiques : ne modifiez jamais la même branche simultanément sur Bolt et en local. Travaillez avec des branches, fusionnez via GitHub et faites du dépôt Git votre source de vérité absolue. Dès lors que plusieurs développeurs travaillent en continu sur le projet, Bolt doit être traité comme un contributeur d'appoint, et non comme le gestionnaire central.

Fonctionnalité 3 : applications mobiles avec Expo

Bolt.new peut amorcer une application mobile multiplateforme via Expo, mais le tout premier prompt détermine le succès de l'opération. Le guide Expo de Bolt indique qu'un projet initié pour le web ne bascule pas facilement sur le mobile. Demander « rends cette application mobile » représente un changement d'architecture profond, pas un simple ajustement d'affichage.

Documentation de l'intégration Expo de Bolt pour les applications mobiles et la publication sur les stores
Bolt avec Expo

Prenons l'exemple d'une application de planification de repas. Votre premier prompt doit explicitement mentionner qu'il s'agit d'une application mobile pour iOS et Android, lister les données de recettes et de gestion du foyer, et spécifier les interactions tactiles clés. Bolt s'appuie alors sur Expo, un framework permettant à une même base de code de cibler à la fois les plateformes mobiles et le web.

La prévisualisation est très accessible. Lancez votre projet mobile, cliquez sur Device Preview, flashez le QR code avec l'application Expo Go et testez directement le rendu sur votre smartphone. Vous identifierez immédiatement les bugs de mise en page, d'ouverture de clavier, de navigation tactile et de gestes que l'écran d'un ordinateur masque souvent.

En revanche, le processus de déploiement final ne se déroule pas dans Bolt. Pour publier sur l'App Store ou Google Play, vous devrez télécharger le code, l'ouvrir dans un éditeur dédié sur une machine équipée de Node.js LTS et Git, paramétrer Expo Application Services (EAS), et détenir des comptes développeurs actifs chez Apple ou Google. La compilation peut également buter sur des certificats de signature, des dépendances natives ou les règles de validation des stores.

Cette frontière technique clarifie les responsabilités au sein de l'équipe. Un porteur de projet peut concevoir un prototype mobile sans maîtriser Swift ou Kotlin. En revanche, il devra s'associer à un profil technique capable de gérer la signature des builds, les fiches sur les stores, les politiques de confidentialité, l'analyse des crashs et les processus de validation d'Apple et Google. Expo simplifie le développement multiplateforme ; il ne supprime pas les exigences opérationnelles des stores.

Appliquez cette feuille de route :

  1. Déclarer l'environnement mobile dès le premier prompt

    Spécifiez d'emblée iOS et Android, l'expérience tactile principale, les contraintes de fonctionnement hors-ligne et l'usage éventuel de la caméra, des notifications ou de la géolocalisation avant toute génération de code.

  2. Tester immédiatement sur un smartphone réel

    Utilisez Expo Go sans attendre. Validez le parcours de base : sélection d'un menu, ajout d'ingrédients et persistance de la liste après fermeture complète de l'application.

  3. Exporter le code avant la configuration des stores

    Basculez le code sur GitHub et configurez un environnement local avant d'intégrer vos identifiants de stores. Le dépôt audité doit servir de base à votre chaîne de déploiement.

  4. Identifier un responsable de publication

    Désignez clairement la personne en charge des certificats, des phases de test sur TestFlight ou Google Play, des notes de version et du suivi des crashs. Sans responsable désigné, votre livrable reste un prototype, pas une application prête pour le lancement.

Optez pour Bolt sur mobile afin de lever les incertitudes sur les parcours utilisateurs. Délaissez-le en tant qu'environnement unique si vos défis portent déjà sur des composants natifs profonds, des services d'arrière-plan complexes ou la mise en place d'un pipeline de publication d'applications exigeant.

Fonctionnalité 4 : intégration de design systems pour les équipes

La prise en charge des design systems dans Bolt.new s'adresse aux équipes disposant déjà de bibliothèques de composants, de chartes de spacing et de documentations de marque établies. Elle ne transformera pas par magie un guide de style informel en composants de production réutilisables. La qualité de vos sources détermine si Bolt exploitera une véritable librairie ou se contentera d'imiter vos polices et couleurs.

Documentation de Bolt pour ajouter un design system d'équipe à partir de sources de code et de documentation
Design systems sur Bolt

L'intégration de design systems personnalisés nécessite le forfait Teams payant. L'équipe peut connecter Bolt à un dépôt GitHub, un paquet NPM, un Storybook, un site documentaire ou des fichiers locaux. Bolt analyse ces éléments et génère un Storybook interne permettant d'explorer directement les composants reconnus.

Le cas d'usage idéal concerne une entreprise SaaS B2B publiant déjà ses boutons, formulaires, barres de navigation et tableaux sous forme de package NPM. L'équipe importe le paquet, connecte le Storybook associé et fournit des instructions précises à l'agent, comme l'exclusion de composants dépréciés ou l'application d'un thème spécifique. Un product manager peut ainsi concevoir des prototypes alignés sur la charte de l'entreprise dès le premier écran.

La documentation de Bolt souligne l'importance des sources fournies. Les dépôts GitHub et les paquets NPM offrent de bien meilleurs résultats qu'un simple site documentaire. Un site illustré de captures d'écran et de descriptions textuelles transmet l'esprit visuel, alors qu'un package de code apporte à l'IA l'implémentation exacte qu'elle peut injecter et réutiliser.

Certaines contraintes d'utilisation s'appliquent. Une équipe peut ajouter ou synchroniser un maximum de dix design systems par semaine. L'import de fichiers locaux est limité à dix documents (PDFs, images ou autres). L'accumulation de frameworks contradictoires ou de librairies obsolètes dégrade les résultats : ajouter trop de sources hétérogènes est souvent contre-productif.

  1. Sélectionner la source de référence

    Basez-vous sur le dépôt ou le paquet NPM que votre équipe technique utilise activement en production. Ne mélangez pas des versions obsolètes et actuelles dans vos imports.

  2. Fournir de la documentation fonctionnelle

    Intégrez des directives expliquant les cas d'usage des composants, les règles d'accessibilité et les contraintes de thèmes. Des maquettes visuelles seules ne suffisent pas à dicter le comportement d'un composant interactif.

  3. Définir des consignes strictes pour l'agent

    Indiquez clairement à Bolt le framework, le thème et la version du paquet à respecter, ainsi que les composants à proscrire. Une règle d'exclusion évite bien des dérives de génération.

  4. Générer un premier parcours représentatif

    Créez un formulaire type incluant des messages de validation, un état vide et une vue de résultats. Validez la conformité du code et du comportement avec votre design system avant de déployer l'outil à l'échelle de l'équipe.

Cette fonctionnalité justifie l'abonnement Bolt Teams lorsque la création de maquettes respectant la charte évite des allers-retours de développement et que l'entreprise dispose déjà de composants structurés. En revanche, elle ne justifie pas un coût de $30 par membre pour un créateur indépendant ne disposant que d'un logo et de deux polices. Lovable Pro intègre les design systems dès $25 avec des utilisateurs illimités ; le surcoût de Bolt n'est pertinent que si le contrôle du code source et son environnement full-stack sont indispensables à votre flux de travail.

Tarifs de Bolt.new : grilles tarifaires et coût par résultat

La tarification mensuelle publique de Bolt.new est lisible : $0 en Free, $25 en Pro, $30 par membre pour Teams et un tarif sur devis pour Enterprise. La difficulté consiste à anticiper comment la consommation de tokens, les plafonds d'hébergement mutualisés et le nombre de sièges impactent le coût réel par prototype livré.

Page de tarification de Bolt.new présentant les forfaits Free, Pro, Teams et Enterprise
Tarifs de Bolt.new

Les tarifs et plafonds ci-dessous ont été vérifiés sur la page officielle des tarifs de Bolt le August 27, 2026. Le site met en avant une économie pouvant atteindre 28% sur la facturation annuelle. La mention « jusqu'à » n'équivalant pas à une réduction uniforme, la comparaison ci-dessous s'appuie sur la tarification mensuelle exacte, le récapitulatif de paiement faisant foi pour l'annuel.

ForfaitTarif mensuel actuelInclusions principalesIdéal pour
Free$01M de tokens/mois, 300K/jour, uploads 10MB, 10GB de bande passante, 333,333 requêtes, badge BoltDécouvrir le workflow et créer des aperçus jetables
Pro$25À partir de 10M de tokens, pas de limite journalière, uploads 100MB, 30GB de bande passante, 1M de requêtes, domaine personnalisé, report de tokensBâtisseurs solo travaillant sur un prototype sérieux
Teams$30 par membreFonctionnalités Pro, facturation centralisée, droits admin, partage d'organisation, registres NPM privés et design systemsÉquipes nécessitant des accès centralisés et des standards communs
EnterpriseSur mesureSécurité avancée, SSO, logs d'audit, support conformité, SLAs dédiés, gouvernance, onboarding et support prioritaire 24/7Grandes organisations avec contraintes d'audit et de sécurité négociées

L'offre Free : un essai complet avec hébergement bridé

L'offre Free permet de concevoir des projets publics ou privés, inclut des bases de données illimitées, le déploiement sur .bolt.host, 1 million de tokens mensuels et un plafond journalier de 300,000 tokens. Cela suffit pour appréhender le fonctionnement des prompts et de la génération. Toutefois, vous ne pourrez pas finaliser d'application complexe, car le plafond quotidien peut bloquer votre progression bien avant d'avoir consommé votre réserve mensuelle.

L'hébergement impose une coupure stricte : l'offre Free inclut 10GB de bande passante et 333,333 requêtes par mois pour tout le compte. Dès que ce plafond est atteint, vos sites cessent de répondre jusqu'à la réinitialisation mensuelle. Ce fonctionnement est acceptable pour un prototype interne, mais exclu pour un projet devant rester accessible en continu.

L'offre Pro : le choix standard pour un créateur solo

Facturé $25 par mois, le forfait Pro débute avec 10 millions de tokens mensuels sans aucune restriction quotidienne. Il supprime le badge Bolt, autorise l'envoi de fichiers jusqu'à 100MB, intègre le partage privé, les domaines personnalisés, la fonction SEO Boost, le choix du fournisseur de base de données et la retouche d'images par IA. L'hébergement inclus s'élève à 30GB de bande passante et 1 million de requêtes par mois pour l'ensemble du compte.

Les tokens payants non utilisés sont reportés sur le mois suivant et restent utilisables jusqu'à deux mois tant que votre abonnement demeure actif. Cela corrige une idée reçue répandue affirmant que les tokens de Bolt sont systématiquement perdus. Les tokens du forfait Free ne sont pas reportables.

Les utilisateurs Pro peuvent maintenir leurs sites en ligne au-delà des quotas inclus grâce à un système de facturation à l'usage avec plafond de dépenses paramétrable. La page publique d'hébergement ne précisant pas le coût unitaire du trafic supplémentaire, vous pouvez plafonner votre risque financier, mais vous ne pouvez pas modéliser précisément votre facture en cas de pic de trafic avant souscription.

Les recharges de tokens obéissent également à des conditions particulières : Bolt indique que l'achat de recharges est réservé au forfait Pro mensuel au palier le plus élevé ou à l'ensemble des forfaits Pro annuels. Le tarif de ces recharges variant selon le plan et n'étant accessible qu'après connexion, les $25 de base ne représentent pas un budget global garanti pour un usage intensif.

L'offre Teams : une tarification par utilisateur sans mutualisation

Le plan Teams est fixé à $30 par membre et par mois. Chaque utilisateur dispose de son propre quota de tokens, strictement rattaché à son profil et non mutualisé au niveau de l'équipe. Centraliser la facturation ne signifie pas mutualiser les ressources.

Cette formule est pertinente si chaque membre développe activement. Elle devient désavantageuse si une seule personne construit l'application pendant que les autres se contentent de relire ou tester. Une équipe de quatre personnes paiera $120 par mois, soit $1,440 par an, hors options de trafic, packs de tokens ou services tiers.

À titre de comparaison, Lovable Pro propose des utilisateurs illimités pour $25 par mois (soit $300 par an), contre $1,440 par an pour quatre collaborateurs sur Bolt. L'écart est de $95 par mois, soit $1,140 par an. Certes, les métriques d'usage diffèrent — les utilisateurs de Lovable partagent 100 crédits tandis que les membres de Bolt disposent de quotas individuels et d'un environnement d'infrastructure dédié. Cependant, cet arbitrage financier est clair : ne payez le surcoût par utilisateur que si plusieurs collaborateurs rédigent activement du code dans Bolt, ou si l'intégration de vos design systems compense largement ce différentiel tarifaire.

L'offre Enterprise : pour les besoins stricts de gouvernance

Le forfait Enterprise fait l'objet d'un devis personnalisé. Il intègre des options de sécurité poussées, le SSO, les logs d'audit, l'accompagnement à la conformité, des flux de travail et SLAs sur mesure, des politiques de conservation des données, un onboarding dédié et un support prioritaire disponible 24/7.

Si votre organisation impose ces garde-fous, ne planifiez pas votre budget sur la base des $30 du forfait Teams en pensant ajouter ces options plus tard. Sollicitez un devis Enterprise en amont pour vous assurer que vos exigences de conformité seront effectivement couvertes.

Le calcul du coût par résultat

Pour calculer le coût réel d'un prototype fonctionnel, divisez le montant de l'abonnement par le nombre de projets validés selon des critères de test prédéfinis. Compter les prompts mesure votre volume d'activité, pas vos résultats concrets.

Pour un utilisateur solo sur le forfait Pro, l'abonnement revient à $300 par an. Si vous validez quatre prototypes dans le mois, le coût d'accès est de $6.25 par prototype finalisé. Si vous n'en validez qu'un seul, ce même prototype vous coûte $25 d'abonnement. Bien que ce calcul exclue la consommation de bande passante, la base de données et le temps de travail, il met en lumière la métrique fondamentale : votre taux d'aboutissement technique.

Pour un espace Teams de quatre collaborateurs facturé $120 par mois : valider huit prototypes abaisse la part d'abonnement à $15 par projet. N'en valider que deux la fait grimper à $60 chacun. L'outil n'est pas devenu plus onéreux en soi ; c'est le processus qui a généré moins de résultats opérationnels.

Les limites techniques à connaître avant de payer

Les limites de Bolt.new ne sont pas anecdotiques. Elles surviennent généralement au moment où le projet gagne en importance : lorsque plusieurs personnes interviennent, que les données deviennent critiques et que la maîtrise budgétaire devient essentielle. C'est précisément à ce stade qu'acheter des packs de tokens supplémentaires risque de masquer un problème d'architecture derrière une simple question de volume.

1. La consommation de tokens s'envole avec la taille du projet

Bolt indique que l'essentiel de la consommation de tokens provient de la lecture et de la synchronisation des fichiers du projet. Plus votre application s'étoffe, plus chaque nouveau message consomme de tokens. Une instruction identique coûtera donc beaucoup plus cher en fin de développement qu'au tout premier prompt.

Il devient dès lors difficile d'anticiper sa consommation en se basant sur le simple volume de prompts. Une modification de style mineure peut exiger le rechargement d'un contexte étendu. Une demande floue peut pousser l'agent à planifier, modifier et corriger de multiples fichiers en chaîne. Le report des tokens payants compense un mois d'inactivité, mais ne résout pas la hausse des coûts sur un projet volumineux.

Pour y remédier, segmentez vos requêtes, gardez un code modulaire et basculez les modifications simples sur un éditeur classique dès lors que formuler le prompt prend plus de temps et de ressources que de faire l'édition à la main. Augmenter son forfait de tokens est judicieux pour des fonctionnalités bien circonscrites ; cela devient un gaspillage si l'agent perd la cohérence architecturale ou régénère continuellement du code inchangé.

2. Le rollback du projet ne restaure pas la base de données

L'historique de versions (Version History) de Bolt restaure uniquement les fichiers du code, jamais la base de données. Rétablir une version antérieure de votre application n'aura aucun impact sur l'état de votre base actuelle. Il s'agit du piège majeur pour quiconque interprète « outil full-stack » comme « restauration full-stack ».

Le code applicatif et les schémas de base de données évoluent ensemble. Si une modification générée par l'IA renomme une colonne, adapte une règle de sécurité ou migre des tables, restaurer uniquement le code génère une incohérence immédiate. Un workflow orienté production exige des sauvegardes de données externes, un suivi rigoureux des migrations et un plan de restauration testé sur les deux volets.

Une subtilité technique est également à prévoir durant la phase de développement : une base de données non publiée et peu sollicitée peut être suspendue après six jours d'inactivité, nécessitant quelques minutes pour se réactiver. Les bases de données publiées ne sont pas concernées. Cette veille automatique optimise les serveurs, mais peut réserver de mauvaises surprises lors d'une démonstration client imprévue.

3. L'intégration GitHub n'est pas un flux Git complet

Bolt permet de générer des branches et de basculer de l'une à l'autre, mais ne permet pas de réaliser de merge dans son interface. La fusion s'opère obligatoirement sur GitHub. C'est une excellente pratique pour auditer les changements dans le dépôt, mais cela vient contredire l'idée qu'un utilisateur non technique puisse tout piloter depuis l'interface de Bolt.

Le comportement en cas de conflit de synchronisation simultané est encore plus strict : bien que Bolt interroge GitHub toutes les trente secondes, si une modification intervient en même temps sur les deux plateformes, Bolt donne la priorité à sa version et écrase les commits externes sur GitHub. Vos équipes ne doivent donc jamais éditer la même branche en parallèle depuis deux environnements différents. Utilisez des branches dédiées, désignez une source de vérité unique et confiez la validation des merges à un relecteur précis.

4. Le mobile démarre facilement mais exige une chaîne d'outils locale

Bolt configure un projet sous Expo dès lors que votre premier prompt spécifie une application mobile, et Expo Go offre une prévisualisation mobile immédiate. Toutefois, un projet initialement pensé pour le web ne se convertit pas en mobile d'un simple clic. Cette décision d'architecture doit être actée dès la première seconde.

De plus, la publication sur les stores vous fait sortir de la simplicité du navigateur. Vous devrez télécharger le code et utiliser Node.js LTS, Git, la suite d'outils Expo, ainsi que des comptes développeurs payants avec gestion de certificats et validation d'applications. Cela reste bien plus simple que de maintenir deux bases de code natives en parallèle, mais cela n'a rien d'un déploiement mobile automatisé.

5. L'hébergement peut être interrompu ou difficile à chiffrer

Les sites hébergés sur l'offre Free sont immédiatement coupés dès que le quota mensuel mutualisé est consommé. Le forfait Pro autorise le dépassement facturé à l'usage avec un plafond de sécurité, mais la grille publique ne détaille pas le coût unitaire de la bande passante excédentaire. Un créateur peut sécuriser son risque financier dans ses réglages, mais ne peut pas calculer son coût exact en amont.

Rappelons aussi que ces limites s'appliquent à l'échelle du compte. Déployer plusieurs démonstrations clients ou applications de test signifie qu'un projet drainant du trafic réduira les ressources disponibles pour tous les autres. Les agences ont tout intérêt à isoler les projets sur des comptes clients distincts plutôt que de mutualiser tous les livrables sous un compte unique.

6. Le support technique est réservé aux jours ouvrés hors Enterprise

Bolt oriente les utilisateurs du plan Free vers sa communauté Discord. Les clients payants disposent d'un support par e-mail accessible du lundi au vendredi sur les heures ouvrées. L'offre Enterprise est la seule à garantir une assistance prioritaire 24/7 avec un interlocuteur dédié.

Ce découpage est classique dans l'univers du logiciel, mais pèse lourd dans votre analyse des risques. Une application en production nécessitant une astreinte de nuit ou le week-end ne peut pas s'appuyer sur le forfait Pro à $25 ou Teams à $30. Ces exigences de disponibilité vous orientent d'office vers un forfait Enterprise négocié ou vers une infrastructure hébergée sous votre propre responsabilité.

Centre d'aide de Bolt regroupant la documentation et les options de support technique
Centre d'aide de Bolt

7. Gouvernance d'entreprise et rentabilité d'équipe sont dissociées

L'offre Teams apporte des contrôles utiles, la prise en charge des design systems et une facturation mutualisée. Cependant, les fonctionnalités critiques de sécurité d'entreprise listées sur la grille tarifaire sont réservées au forfait Enterprise : SSO, logs d'audit, support à la conformité, gouvernance des données et SLAs personnalisés. Une entreprise peut donc avoir besoin des fonctions Enterprise bien avant d'avoir l'équipe de développeurs justifiant la rentabilité du plan Teams.

L'attribution individuelle des tokens accentue ce décalage. Les utilisateurs passifs ne peuvent pas céder leurs tokens non consommés aux développeurs actifs. Avant de souscrire, évaluez précisément vos profils créateurs réels, définissez les rôles de simple consultation, et comparez ce budget avec une solution à crédits mutualisés.

Les atouts
Ce qu'il fait bien
5 points

  • Le forfait Pro à $25 réunit la génération par prompt, la base de données, l'authentification, l'hébergement et l'export GitHub au même endroit.
  • Le code source reste exploitable hors de Bolt, offrant une transition saine vers un développeur ou un hébergeur tiers.
  • Bolt Database et les déploiements en .bolt.host permettent de concevoir un prototype fonctionnel complet sans souscrire à de multiples services externes.
  • Expo offre une passerelle directe vers le développement mobile cross-platform, et le plan Teams intègre de véritables briques de design systems issues de code existant.
  • Les tokens payants non utilisés sont désormais reportés sur un mois, levant une crainte tarifaire récurrente.
Les limites
Là où il pèche
6 points

  • La consommation de tokens s'accélère avec la volumétrie du projet, empêchant toute prévisibilité budgétaire sur une application complexe.
  • L'historique de versions du projet ne restaure pas les données de la base.
  • Les merges GitHub s'effectuent obligatoirement hors de l'interface, et un conflit de synchronisation simultané donne la priorité à la version de Bolt.
  • Le déploiement d'une application sur les stores mobiles impose des outils de compilation locaux et des comptes développeurs externes.
  • Les tarifs de l'hébergement payant à l'usage ne sont pas publiés en clair sur la page des prix.
  • L'assistance sur le plan Free se limite à Discord ; le support e-mail payant n'intervient qu'en semaine, l'astreinte 24/7 étant réservée aux contrats Enterprise.

Verdict : notre avis final sur Bolt.new et son rôle idéal

Bolt.new mérite son investissement dès lors qu'un profil solo doit convertir un besoin clairement délimité en une base de code hébergée et auditable, avec la perspective d'un transfert rapide vers GitHub. Le forfait Pro à $25 constitue le choix naturel pour démarrer, car le plafond journalier de l'offre Free et l'arrêt brutal de son hébergement sont incompatibles avec un développement sérieux.

En revanche, l'équation change radicalement si votre projet intègre déjà une architecture technique complexe, mobilise plusieurs développeurs en parallèle, gère des données stratégiques ou nécessite un contrat d'exploitation strict. Cursor reste bien plus adapté pour intervenir sur un dépôt existant. Replit surpasse Bolt pour qui recherche un environnement cloud polyvalent avec des agents concurrents ou la restauration native de base de données. Lovable s'impose si la collaboration d'équipe centrée sur le design et le partage d'utilisateurs illimités priment sur le contrôle poussé de l'infrastructure.

La règle d'arrêt est tout aussi déterminante. Ne tentez pas de compenser des blocages d'architecture réguliers, des manques de synchronisation de base de données ou des conflits de versions en achetant simplement plus de tokens. Dès lors que votre projet exige des revues de code manuelles récurrentes, des fusions complexes, des migrations sous contrôle et une exploitation continue, déplacez votre environnement de travail vers un flux Git standard. Bolt pourra toujours intervenir pour générer un composant ou tester une branche, mais il ne doit plus être le gestionnaire central de votre application.

Le plan d'action sur cinq jours

Consacrez une semaine de travail pour tester la solution sur un projet jetable, et non sur votre base de données réelle.

  1. Lundi : définir un cas d'usage précis

    Déterminez le profil utilisateur, l'état initial, l'état final attendu, les données nécessaires et les restrictions d'accès. Délimitez un flux suffisamment concis pour être finalisé de bout en bout par une seule personne.

  2. Mardi : configurer l'infrastructure par prompt

    Exigez expressément la création de la base de données, la logique d'authentification, les rôles et la procédure de mot de passe oublié. Utilisez l'offre Free tant que les données sont fictives, et repérez les prompts générant des régressions.

  3. Mercredi : connecter le dépôt GitHub

    Créez votre dépôt privé, isolez une fonctionnalité sur une branche dédiée et effectuez le merge via GitHub. Assurez-vous que l'aperçu dans Bolt et votre dépôt distant restent parfaitement synchronisés après la fusion.

  4. Jeudi : tester les cas d'erreur

    Simulez l'accès avec un profil non autorisé, une session expirée, une redirection erronée, une modification de schéma et la reprise après mise en veille de la base. Consignez toutes les interventions ayant nécessité une action manuelle hors de l'interface.

  5. Vendredi : appliquer la règle de décision

    Ne passez au forfait Pro que si votre prototype a validé tous ses tests, que le responsable technique valide la qualité du code produit et que le rythme de consommation des tokens reste économiquement cohérent. Dans le cas contraire, basculez vers l'alternative adaptée à votre point de blocage principal.

Pour élargir vos options, consultez notre sélection des meilleurs outils de vibe-coding. Si Replit retient votre attention mais que sa tarification ne convient pas à votre structure, notre panorama des alternatives gratuites à Replit pour créer des applications avec l'IA vous aidera à trancher.

Questions fréquentes

Le site Bolt New est-il fiable et légitime ?

Oui. Bolt.new est un produit développé et maintenu par StackBlitz, doté d'une tarification officielle, d'une documentation complète, de notes de version transparentes et de canaux de support identifiés. Ces éléments attestent du sérieux de l'entreprise, mais ne garantissent pas que le code généré soit adapté sans contrôle à n'importe quel usage critique. Connectez systématiquement GitHub, auditez les permissions et prévoyez une procédure de sauvegarde de votre base de données avant d'y injecter des données sensibles.

Bolt New fonctionne-t-il réellement ?

Bolt documente des parcours complets et fonctionnels pour le web, les bases de données, l'authentification, l'hébergement, la synchronisation GitHub et les projets mobiles Expo. Il génère de véritables applications et non de simples maquettes. Notre avis repose sur l'analyse technique des spécifications et non sur un banc d'essai exhaustif : nous ne formulons donc pas de promesse de réussite universelle ni ne garantissons qu'une architecture complexe soit prête pour la production sans l'audit d'un développeur.

Bolt new est-il meilleur que Cursor ?

Bolt est supérieur pour transformer un brief rédigé en une première application hébergée intégrant sa propre infrastructure au sein du navigateur. Cursor est bien plus efficace pour un développeur aguerri travaillant directement sur un dépôt de code existant. Optez pour Bolt tant que l'architecture globale reste à définir, et choisissez Cursor dès lors que l'écriture fine du code et l'organisation du dépôt redeviennent le cœur de votre quotidien.

Bolt New est-il sécurisé ?

Bolt intègre des contrôles d'authentification, des listes blanches d'URIs, la détection des mots de passe compromis, des paramètres de sécurité et des fonctionnalités de gouvernance sur son offre Enterprise. La sécurité finale dépend toutefois des politiques de contrôle d'accès (RLS) du code généré, de la gestion de vos clés API, du modèle de données et de vos procédures d'exploitation. L'absence de restauration de la base de données dans l'historique des versions impose de gérer vos sauvegardes de façon autonome.

Bolt New est-il totalement gratuit ?

Bolt met à disposition une offre Free à $0 intégrant des projets publics et privés, 1 million de tokens mensuels avec un plafond journalier de 300,000 tokens, des bases de données illimitées et l'hébergement. Le forfait applique un badge Bolt sur les projets, limite les uploads à 10MB et suspend vos sites dès que le quota mutualisé de 10GB de bande passante ou de 333,333 requêtes mensuelles est atteint.

Bolt.new est-il gratuit pendant 1 an ?

La grille tarifaire officielle actuelle présente une offre Free permanente à $0 et ne mentionne aucune promotion offrant un an d'abonnement payant gratuit. Les accès gratuits restent soumis aux restrictions de tokens, de taille d'upload, de marquage visuel et de volume de trafic. Pour débloquer les limites professionnelles, le premier palier payant reste l'offre Pro à $25 par mois en facturation mensuelle.

Quels sont les tarifs de Bolt new ?

Bolt propose actuellement l'offre Free à $0, le forfait Pro à $25 par mois, le forfait Teams à $30 par membre et par mois, et un contrat Enterprise sur devis. Une remise pouvant atteindre 28% est proposée pour un engagement annuel. L'abonnement Pro démarre à 10 millions de tokens par mois ; les tokens payants non utilisés sont reportables sur le mois suivant tant que l'abonnement reste actif.

Que choisir entre Bolt new et Lovable ?

Préférez Bolt pour un workflow orienté code avec base de données intégrée, hébergement direct et volonté d'exporter rapidement vers GitHub. Privilégiez Lovable si vous recherchez avant tout une finition visuelle poussée et un espace collaboratif fluide : son forfait Pro à $25 permet d'inviter un nombre illimité d'utilisateurs partageant un pool de crédits. Pour une équipe de créateurs, le modèle de Bolt à $30 par siège peut alourdir la facture globale même si les tarifs individuels de base sont identiques.

Téléchargez la Checklist d'Audit des Workflows IA

Notre Checklist d'Audit des Workflows IA gratuite vous guide pour cibler le bon processus métier, évaluer l'impact des données et les risques d'échec, désigner un responsable technique et fixer des critères d'arrêt stricts avant de souscrire à un nouvel outil de génération. Inscrivez-vous pour recevoir notre prochaine analyse vérifiée.

Dernière mise à jour

3 sept. 2026

CatégorieBuild

Préférez ce site dans Google

Ajouter omidsaffari.com comme source préférée dans la recherche Google

Marquez omidsaffari.com comme source préférée et Google le met en avant pour vous dans Top Stories, AI Overviews et AI Mode.

Newsletter

Une lettre, chaque dimanche. Des systèmes qui tournent, pas des hot takes.

Build logs, systèmes en production et notes de terrain d'un portefeuille de ventures IA.

Hebdomadaire. Pas de spam. Désabonnement à tout moment.