Accueil › Cursor › Prompts

Prompts Cursor : exemples concrets et bonnes pratiques par mode

Un bon prompt dans Cursor fait la différence entre un agent qui produit un code utilisable en une passe et un agent qui tourne en rond pendant 10 itérations. Cette page regroupe 30+ exemples de prompts testés, classés par mode et par cas d’usage.

Le prompt engineering dans Cursor n’a rien à voir avec le prompting d’un chatbot classique. L’agent Cursor a accès à votre codebase, à des outils de recherche, au terminal et à la documentation. Un prompt efficace ne doit pas tout expliquer : il doit donner un objectif clair, pointer vers le bon contexte et spécifier les contraintes. L’agent se charge du reste.

Cursor lui-même recommande, dans son guide officiel de bonnes pratiques, une approche contre-intuitive : « à mesure que les modèles s’améliorent, on obtient de meilleurs résultats en fournissant moins de détails en amont, ce qui facilite la capacité de l’agent à trouver le contexte pertinent par lui-même. » Autrement dit, soyez précis sur le quoi, mais laissez l’agent gérer le comment.

Les 6 principes d’un prompt Cursor efficace

Avant de plonger dans les exemples, voici les règles qui s’appliquent à tous les modes.

1. Soyez spécifique sur le résultat attendu

Comparez ces deux prompts :

Faible : « Ajoute des tests pour auth.ts »
Fort : « Écris un test pour auth.ts couvrant le edge case de logout avec token expiré, en utilisant les patterns du dossier __tests__/ et sans utiliser de mocks pour les services externes. »

Le second prompt est plus long, mais il produit un code correct en une passe. Le premier nécessite typiquement 3 à 5 allers-retours de clarification, ce qui consomme plus de tokens au total.

2. Pointez le contexte avec les symboles @

N’espérez pas que l’agent devine quels fichiers sont pertinents. Utilisez @file, @folder, @codebase et @Docs pour lui donner un contexte précis. Un prompt avec des références @ explicites augmente la précision de l’IA de 62 % à 91 % selon les mesures de la communauté.

3. Découpez les tâches larges

« Refactorise toute l’application » est un prompt voué à l’échec. Préférez des tâches ciblées : « Refactorise le middleware d’authentification dans @file:src/middleware/auth.ts pour supporter JWT et API key. » L’agent performe mieux sur des objectifs bien délimités.

4. Planifiez avant de construire

L’erreur la plus courante est de sauter directement en mode Agent pour une tâche complexe. Le workflow optimal : commencez en mode Plan (Shift+Tab) pour que l’agent explore votre code, pose des questions de clarification et produise un plan détaillé. Validez le plan, puis lancez l’exécution.

5. Donnez des objectifs vérifiables

Les agents performent significativement mieux quand ils ont un critère de succès objectif : tests qui passent, TypeScript qui compile, linter sans erreur. Ajoutez à vos prompts des instructions du type « Lance les tests après les modifications et corrige jusqu’à ce que tout passe. »

6. Codifiez vos conventions dans Cursor Rules

Tout ce que vous répétez dans vos prompts (stack technique, conventions de code, architecture) devrait être dans un fichier Cursor Rules (.cursor/rules/). L’agent les lit automatiquement à chaque requête. Vous n’avez plus besoin de préciser « utilise TypeScript » ou « pas de classes React » à chaque fois.

Prompts pour le mode Agent

Le mode Agent est le mode par défaut et le plus autonome. Utilisez-le quand la tâche touche plusieurs fichiers et que vous connaissez l’objectif.

Ajout de feature multi-fichiers

@file:src/routes/users.ts @file:src/middleware/auth.ts

Ajoute un système de rate limiting par IP sur les routes /api/users.
- Utilise un middleware Express dédié dans src/middleware/rate-limit.ts
- Fenêtre glissante de 15 minutes, max 100 requêtes par IP
- Bypass pour les routes /api/health
- Retourne un 429 avec header Retry-After
- Ajoute les tests dans src/middleware/__tests__/rate-limit.test.ts
- Lance les tests et corrige jusqu'à ce qu'ils passent

Refactoring structurel

@file:src/services/order-service.ts

Cette classe fait 800 lignes. Extrais la logique de validation
dans un module séparé src/services/order-validation.ts et la
logique de notification dans src/services/order-notifications.ts.
Garde l'interface publique identique. Mets à jour tous les imports
dans le projet. Lance tsc pour vérifier qu'il n'y a pas d'erreur
de compilation.

Migration de framework

@Docs:Next.js @folder:src/app/

Migre les Server Components de Next.js 14 vers les conventions
Next.js 15. Spécifiquement :
- Remplace les imports de next/headers par la nouvelle API
- Convertis les routes dynamiques vers le nouveau format
- Mets à jour le système de cache selon la nouvelle API
- Ne touche pas aux Client Components (fichiers avec "use client")

TDD avec l’agent

Implémente un service de panier d'achat (src/services/cart.ts).
Écris les tests d'abord dans src/services/__tests__/cart.test.ts
avec les cas suivants :
- Ajout d'un item, quantité mise à jour si déjà présent
- Suppression d'un item
- Calcul du total avec remise en pourcentage
- Panier vide retourne un total de 0

Puis écris le code, lance les tests et itère jusqu'à ce que
tous les tests passent. Utilise vitest.

Débogage par logs

Le calcul du prix total est incorrect sur les commandes avec
une remise groupée. Ajoute des console.log à chaque étape du
calcul dans @file:src/services/pricing.ts pour identifier où
la valeur diverge. Lance npm run test:pricing et analyse la
sortie pour trouver le bug. Corrige-le et retire les logs.

Intégration API externe

@Docs:Stripe @file:src/config/env.ts

Intègre Stripe Checkout pour les abonnements mensuels.
- Crée src/services/stripe.ts avec les fonctions :
  createCheckoutSession, handleWebhook, cancelSubscription
- Ajoute la route POST /api/stripe/webhook avec vérification
  de signature
- Utilise les variables d'env STRIPE_SECRET_KEY et
  STRIPE_WEBHOOK_SECRET depuis @file:src/config/env.ts
- Gère les événements : checkout.session.completed,
  customer.subscription.deleted
- Ajoute la gestion d'erreur avec des types d'erreur custom

Prompts pour le mode Plan

Le mode Plan crée un plan d’implémentation avant d’écrire du code. Utilisez-le pour les tâches complexes touchant l’architecture.

Planification architecturale

@codebase

Crée un plan pour ajouter la multi-tenancy à notre application.
Avant de proposer quoi que ce soit :
1. Analyse le système d'authentification actuel (trace le flow
   de la requête login jusqu'à l'appel API authentifié)
2. Identifie les tables qui n'ont pas de colonne tenant_id
3. Liste les services partagés ou singletons qui devront
   devenir tenant-aware
4. Vérifie quels patterns les tables multi-tenant existantes
   utilisent pour l'isolation des données

Pose-moi jusqu'à 3 questions de clarification si nécessaire.
Produis un plan avec des étapes numérotées, fichiers concernés
et estimation de complexité par étape.

Plan de migration technique

@codebase @Docs:Prisma

Crée un plan de migration de Sequelize vers Prisma ORM.
- Inventorie tous les modèles Sequelize et leurs relations
- Mappe chaque modèle vers le schéma Prisma équivalent
- Identifie les requêtes raw SQL à convertir
- Propose un ordre de migration fichier par fichier
- Prévois les risques et les points de vérification

Prompts pour le mode Ask

Le mode Ask est en lecture seule. Utilisez-le pour investiguer et comprendre avant de modifier.

Comprendre l’architecture

@codebase

Explique-moi le flux de données complet quand un utilisateur
passe une commande :
- Du formulaire frontend jusqu'à la confirmation par email
- Quels services sont impliqués ?
- Où sont les validations ?
- Comment les erreurs sont-elles propagées ?
Sois précis : cite les noms de fichiers et de fonctions.

Analyse d’impact

@file:src/models/user.ts

Si je renomme le champ 'email' en 'emailAddress' dans le
modèle User, quels fichiers seront impactés ? Liste chaque
fichier avec la ligne concernée et le type de changement
nécessaire (import, référence directe, requête DB, test).

Review de code

@git

Analyse le diff de ma branche courante. Cherche :
- Des bugs potentiels ou des edge cases non gérés
- Des problèmes de performance (requêtes N+1, boucles inutiles)
- Des violations de nos conventions (voir .cursor/rules/)
- Des imports manquants ou inutilisés
Présente les problèmes par ordre de sévérité.

Prompts pour Cmd K (édition inline)

Cmd K (⌘+K / Ctrl+K) est conçu pour les modifications ciblées dans le fichier actif. Les prompts doivent être courts et précis.

Refactoring rapide

# Sélectionnez la fonction, puis Cmd+K :

Extrais la logique de validation dans une fonction séparée
validateOrderInput(). Garde les types stricts.

Ajout de types TypeScript

# Sélectionnez un bloc JavaScript, puis Cmd+K :

Convertis en TypeScript strict. Ajoute les interfaces pour
les paramètres et les retours. Utilise les types du projet
existant quand ils sont pertinents.

Documentation de fonction

# Sélectionnez la signature de fonction, puis Cmd+K :

Ajoute une JSDoc complète avec @param, @returns, @throws
et un @example d'utilisation.

Optimisation de performance

# Sélectionnez la boucle ou la requête, puis Cmd+K :

Optimise la complexité temporelle. Remplace la boucle O(n²)
par une approche avec hash map en O(n).

Prompts pour le Debug Mode

Le Debug Mode de Cursor capture automatiquement le contexte d’erreur (message, stack trace, fichiers impliqués). Vos prompts peuvent être plus courts car le contexte est déjà fourni.

Fix automatique

# L'erreur apparaît dans le terminal. Le Debug Mode la capture.

Corrige cette erreur. Explique brièvement la cause avant de
modifier le code. Lance les tests ensuite pour vérifier que
le fix ne casse rien d'autre.

Investigation approfondie

# Après un crash intermittent en production (logs collés) :

Ce crash arrive de façon intermittente. Analyse la stack trace
et identifie les conditions de course possibles. Vérifie s'il
y a des accès concurrents non protégés dans les fichiers
mentionnés dans la trace. Propose un fix et explique pourquoi
le bug est intermittent.

Patterns de prompts avancés

Course de modèles (Background Agents)

Lancez le même prompt sur plusieurs modèles en parallèle via les Cloud Agents, puis comparez les résultats :

# Lancez en Cloud Agent avec Composer 2, Claude Opus 4.6
# et GPT-5.4 séparément :

@file:src/services/search.ts

Réécris le système de recherche full-text pour supporter
les requêtes fuzzy avec une tolérance de 2 caractères.
Utilise l'algorithme de Levenshtein. Ajoute les benchmarks
de performance dans les tests. Objectif : < 50ms pour
10 000 documents.

Comparez les trois PR et gardez l’approche la plus propre. Cette technique est particulièrement efficace pour les bugs complexes où les modèles proposent des approches radicalement différentes.

Prompts avec images

L’agent Cursor peut traiter des images directement dans les prompts. Collez un screenshot, un mockup Figma ou une capture d’erreur :

# Collez une capture d'écran du design Figma :

Implémente ce composant exactement comme sur le mockup.
Utilise Tailwind CSS et notre design system (voir
@file:src/styles/tokens.ts). Le composant doit être
responsive avec un breakpoint à 768px.

Prompts pour les Automations

Depuis mars 2026, Cursor supporte les Automations déclenchées par événements. Les instructions d’une automation sont essentiellement un prompt persistant :

# Template d'automation pour les issues GitHub "bug-minor" :

Quand une issue avec le label "bug-minor" est créée :
1. Lis la description de l'issue
2. Explore la codebase pour identifier les fichiers concernés
3. Propose un fix minimal et ciblé
4. Crée une PR avec :
   - Titre : "fix: [description courte du bug]"
   - Description : lien vers l'issue + explication du fix
   - Tests : ajoute un test de non-régression
5. Assigne la PR au reviewer par défaut

Anti-patterns : les prompts à éviter

Certains patterns de prompts produisent systématiquement de mauvais résultats. Voici ce qu’il ne faut pas faire.

Cursor Rules : le prompt permanent

Tout ce que vous répétez dans vos prompts doit migrer vers un fichier Cursor Rules. L’agent les lit automatiquement, ce qui allège vos prompts et assure la cohérence.

Exemple de fichier .cursor/rules/conventions.mdc :

---
description: Conventions de code du projet
globs: ["src/**/*.ts", "src/**/*.tsx"]
---

# Stack technique
- TypeScript strict, React 19, Next.js 15, Tailwind CSS
- ORM : Prisma avec PostgreSQL
- Tests : Vitest + Testing Library
- Linting : ESLint + Prettier

# Conventions
- Composants fonctionnels uniquement (pas de classes)
- Hooks custom dans src/hooks/ avec préfixe "use"
- État global via Zustand (pas Redux, pas Context)
- Pas de any en TypeScript (utilise unknown si nécessaire)
- Chaque service a son fichier de tests dans __tests__/

# Architecture
- src/app/ : routes Next.js (App Router)
- src/components/ : composants réutilisables
- src/services/ : logique métier
- src/lib/ : utilitaires et helpers
- src/types/ : types partagés

Avec ce fichier en place, vos prompts deviennent beaucoup plus courts. Au lieu de « Crée un composant React fonctionnel avec TypeScript strict, Tailwind CSS, et teste-le avec Vitest », vous écrivez simplement « Crée un composant UserCard qui affiche le nom, l’email et le rôle. » L’agent applique automatiquement toutes les conventions.