Accueil › Bolt.new › Prompts

Bolt.new Prompts : Comment Écrire des Prompts qui Économisent vos Tokens

Un prompt efficace sur Bolt.new est spécifique (framework, style, fonctionnalités), découpe le projet en étapes progressives, et utilise les outils intégrés (Enhance Prompt, Target File, File Lock, mode Discuss) pour minimiser la consommation de tokens. La différence entre un prompt vague et un prompt structuré peut représenter des millions de tokens économisés.

Pourquoi le prompting est encore plus critique sur Bolt

Sur Bolt.new, la consommation de tokens est proportionnelle à la taille de votre projet. Chaque message synchronise l’ensemble du codebase avec l’IA. Un prompt inefficace sur un gros projet peut brûler 500K à 1M+ tokens en une seule interaction. Sur un plan Pro à 10M tokens/mois, c’est 5 à 10 % de votre allocation mensuelle pour un seul message.

Les cycles de debug sont le principal piège. Un prompt vague qui produit un résultat approximatif déclenche une cascade de corrections qui consomment bien plus de tokens que le prompt initial. La documentation officielle de Bolt le dit clairement : la meilleure façon d’économiser des tokens est d’écrire des prompts précis dès le départ. Pour comprendre le système de facturation, consultez notre page Bolt Prix.

L’outil Enhance Prompt : votre premier réflexe

Avant d’envoyer n’importe quel prompt, cliquez sur l’icône « Enhance » (baguette magique) à côté du champ de saisie. L’IA enrichit automatiquement votre description avec des détails techniques : stack, structure, patterns de design, contraintes. Relisez et éditez le résultat enrichi avant de l’envoyer.

C’est gratuit (ou très peu coûteux en tokens) et améliore significativement la qualité du premier résultat. La différence est souvent spectaculaire : un prompt de deux lignes peut être transformé en une spécification technique complète de dix lignes qui produit un résultat bien plus proche de votre vision.

Les Project et System Prompts : le contexte persistant

Bolt offre deux niveaux d’instructions persistantes qui sont envoyées à l’IA à chaque interaction :

Project Prompt (par projet)

Le Project Prompt contient les instructions spécifiques à votre projet en cours. Accédez-y via l’icône engrenage > All project settings > Knowledge > Project-specific. Vous pouvez y définir la stack technique, les conventions de code, les librairies préférées, le style de design et les contraintes spécifiques.

Exemple de Project Prompt efficace tiré d’un projet Vite React :

« This is a task management SaaS built with React, Vite, Tailwind CSS, and ShadCN components. Backend: Supabase for auth, database, and Edge Functions. Design: minimal, dark theme, inter font. Always use TypeScript strict mode. Never use ‘any’. Use Zod for form validation. Use React Query for server state. »

System Prompt (global)

Le System Prompt s’applique à tous vos projets. C’est l’endroit pour définir vos préférences générales de développement : librairies favorites, conventions de nommage, style de code, comportement de l’IA (concis, technique, etc.).

Exemple : « Always use TypeScript. Prefer functional components with hooks. Use Tailwind CSS for styling. Generate responsive designs mobile-first. Keep code clean and well-commented. When debugging, explain the root cause before suggesting fixes. »

Le Project Prompt surcharge le System Prompt quand les deux sont définis. Configurez les deux dès le premier jour pour des résultats cohérents sur la durée.

Les trois modes de Bolt et quand les utiliser

Le choix du mode a un impact direct sur votre consommation de tokens :

Build Mode (défaut). L’IA génère et modifie le code. C’est le mode le plus puissant mais aussi le plus gourmand. Utilisez-le uniquement quand vous êtes prêt à implémenter, pas pour explorer ou planifier.

Plan Mode. L’IA discute de l’approche sans toucher au code. Elle peut analyser le projet, proposer une architecture, identifier les risques. Consomme moins de tokens car il n’y a pas de génération de code, même si la synchronisation du projet reste nécessaire.

Discussion Mode. Conversation pure avec moins de contexte projet. Le mode le plus économe en tokens. Idéal pour les questions conceptuelles, la planification de haut niveau, ou comprendre un concept technique sans rapport direct avec le codebase.

La stratégie optimale suit un flux en trois étapes : Discussion Mode pour conceptualiser, Plan Mode pour architecturer, Build Mode pour implémenter. Ce flux peut réduire votre consommation de tokens de 30 à 50 % par rapport à tout faire en Build Mode.

Target File et File Lock : contrôle granulaire

Target File : diriger les modifications

Au lieu de laisser Bolt décider quels fichiers modifier, faites un clic droit sur un fichier spécifique et sélectionnez « Target file ». Cela indique à l’IA de concentrer ses modifications sur ce fichier. Avantage double : le résultat est plus précis, et la consommation de tokens peut être réduite car l’IA n’a pas besoin d’analyser l’ensemble du codebase pour décider où intervenir.

Vous pouvez aussi mentionner directement des fichiers, des classes CSS, des fonctions ou des composants spécifiques dans votre prompt : « In the Dashboard.tsx component, modify the renderTaskCard function to add a priority badge. » Plus vous êtes précis sur la localisation, moins l’IA risque de toucher à du code non concerné.

File Lock : protéger le code stable

Quand un composant fonctionne correctement, verrouillez-le avec File Lock. L’IA ne pourra plus le modifier, même si elle tente de le réécrire dans le cadre d’une autre modification. C’est la meilleure protection contre les régressions involontaires, le problème le plus frustrant du développement assisté par IA.

Stratégie recommandée : après chaque fonctionnalité validée, verrouillez les fichiers concernés. Déverrouillez uniquement si vous avez besoin de modifier ce composant spécifiquement. Combinez avec l’export GitHub pour avoir un double filet de sécurité.

Ask Bolt : interroger le code existant

Sélectionnez du code dans l’éditeur et utilisez la fonctionnalité « Ask Bolt » pour demander des explications, des optimisations ou des modifications ciblées sur la sélection. C’est plus précis qu’un prompt libre car l’IA sait exactement quel code vous ciblez.

Structure de prompt optimale pour Bolt

La documentation officielle et les retours communautaires convergent sur cette structure :

Prompt initial (nouveau projet)

Commencez par spécifier la stack technique, puis les fonctionnalités principales, puis le design, puis les contraintes. Le format recommandé :

« Create a [type d’app] using [framework] with [librairies de style]. Include [fonctionnalité 1], [fonctionnalité 2], [fonctionnalité 3]. Design: [adjectifs de style]. Start with [page/composant principal] containing: [description détaillée]. »

Exemple concret : « Create a responsive landing page for a coffee shop using React, Vite, and Tailwind CSS with a dark theme. Include a hero section with a background image, a menu section with category tabs, and a contact form. Design: warm, elegant, minimal. Start with the hero section: full-viewport height, centered headline ‘Artisan Coffee Since 1985’, subtitle, and a ‘View Our Menu’ CTA button. »

Prompts d’itération (modifications)

Soyez explicite sur trois points : ce qui doit changer, ce qui ne doit pas changer, et où se trouve le changement.

Mauvais : « Make it look better. »

Bon : « In the hero section only, increase padding to 24px, add a subtle drop shadow to the CTA button, and change the headline font to Playfair Display. Do not modify any other sections. »

Regrouper les modifications simples

Les modifications visuelles simples peuvent être regroupées dans un seul message pour économiser des tokens. L’IA traite toutes les instructions d’un coup au lieu de synchroniser le codebase à chaque message séparé.

Exemple de regroupement efficace : « Apply these changes across the entire site: 1) Change primary color to #1E40AF, 2) Add 8px border-radius to all cards, 3) Make the navigation bar sticky on scroll, 4) Add hover scale effect (1.02) on all clickable cards, 5) Ensure all text has sufficient contrast on dark backgrounds. »

Prompts de debug efficaces

Le debug est le gouffre à tokens le plus fréquent sur Bolt. Voici les techniques qui fonctionnent :

Fournir l’erreur exacte. Copiez le message d’erreur complet et collez-le avec le contexte : « I’m getting this error in the Dashboard component: [message d’erreur]. Expected behavior: [description]. Actual behavior: [description]. »

Utiliser Plan Mode d’abord. Avant de demander une correction en Build Mode, passez en Plan Mode et demandez : « I have this error. What do you think is the root cause, and what’s the best approach to fix it? » Cela vous permet de valider l’approche avant de consommer des tokens de génération.

Limiter le scope de la correction. « Fix the authentication redirect issue in the AuthCallback.tsx file only. Do not modify any other files. » Plus le scope est restreint, moins l’IA risque de créer des régressions.

Ouvrir la preview dans un nouvel onglet. Certaines erreurs (OAuth, Stripe, embeds YouTube) apparaissent uniquement parce que la preview tourne dans un iframe. Ouvrez-la dans un onglet séparé avant de reporter un bug qui n’en est peut-être pas un.

Ne pas boucler. Si « Attempt Fix » échoue trois fois, arrêtez. Passez en Plan Mode, demandez une analyse de la cause profonde, ou exportez le code vers GitHub et corrigez manuellement dans un éditeur externe comme Cursor.

Exemples de prompts par cas d’usage

Erreurs de prompting les plus courantes

Ne pas spécifier la stack. Sans mention de framework, Bolt choisit par défaut. Si vous voulez Next.js et que Bolt génère du Vite, vous perdez des tokens à reconstruire. Spécifiez toujours le framework dans le premier prompt.

Tout demander d’un coup. Un prompt massif qui décrit 10 fonctionnalités produit un résultat fragile. Si une seule partie pose problème, il est difficile d’identifier laquelle sans tout recommencer. Découpez en étapes : structure de base, puis fonctionnalités une par une.

Ignorer les modes Plan et Discussion. Tout faire en Build Mode multiplie la consommation de tokens par 2 ou 3. Planifiez d’abord, implémentez ensuite.

Ne pas verrouiller les fichiers stables. Sans File Lock, l’IA peut réécrire un composant validé en tentant de modifier un autre fichier. Verrouillez systématiquement après chaque validation.

Des prompts de debug trop vagues. « It doesn’t work » ne donne aucune piste à l’IA. Fournissez toujours le message d’erreur exact, le comportement attendu, le comportement réel, et le fichier concerné.

Ne pas configurer le Project Prompt. Sans contexte persistant, chaque session repart de zéro et l’IA prend des décisions architecturales potentiellement différentes à chaque fois.

Notre verdict

Le prompting sur Bolt est à la fois plus technique et plus impactant que sur Lovable. Plus technique parce que Bolt est un IDE complet qui offre des outils de contrôle granulaire (Target File, File Lock, modes multiples, éditeur de code) que vous devez apprendre à utiliser. Plus impactant parce que la consommation de tokens est proportionnelle à la taille du projet, ce qui rend chaque prompt inefficace exponentiellement plus coûteux à mesure que le projet grandit.

Les trois habitudes les plus rentables : utilisez Enhance Prompt systématiquement avant chaque envoi, passez par Plan Mode avant Build Mode pour toute fonctionnalité non triviale, et verrouillez les fichiers validés avec File Lock. Ces trois réflexes peuvent diviser votre consommation de tokens par deux sur un projet de taille moyenne.