📍 Article principal de la série : Vibe coding 2026 : du tweet de Karpathy aux outils dominants
Cet article fait partie de la série « vibe coding ». Pour la vue d’ensemble du concept, des plateformes concurrentes et de la méthodologie disciplinée, lire d’abord le guide principal.

Pourquoi Cursor en mode vibe coding et pour qui

Vous êtes développeur Next.js à Abidjan, vous travaillez déjà dans Cursor depuis des mois, et vous lisez consciencieusement chaque diff que l’agent vous propose. C’est du AI coding professionnel, et c’est très bien. Mais il existe un autre mode d’usage de Cursor — le mode vibe coding strict — qui consiste à demander une fonctionnalité complète, à laisser Composer 2.0 modifier dix ou vingt fichiers, et à valider le résultat sur ce que l’application fait à l’écran sans relire chaque ligne. C’est précisément ce que désignait Karpathy dans son tweet original : « Cursor Composer w Sonnet ». Le mode existe, il est productif sur les bons sujets, et il demande une discipline particulière qu’on confond souvent avec une absence de discipline.

Ce tutoriel suit l’usage de Cursor en mode vibe coding pour les tâches où le mode est légitime — prototypage, exploration, scaffolding accéléré — et précise les zones où il faut basculer vers un usage discipliné. La distinction n’est pas dans l’outil mais dans la posture, et savoir alterner entre les deux modes est ce qui fait un développeur efficace en 2026. Le guide principal AI coding développeur 2026 traite l’usage discipliné de Cursor en profondeur ; ce tutoriel couvre spécifiquement le mode vibe.

Prérequis

Cursor installé en version récente (2026.x avec Composer 2.0)
Compte Cursor Pro à 20 USD par mois (environ 12 000 FCFA) ou Pro+ à 60 USD si usage intensif
Familiarité de base avec un IDE et le terminal
Un projet existant ou la volonté d’en démarrer un
Connaissance du framework cible (React, Vue, Django, etc.) suffisante pour évaluer le résultat à l’écran
Temps estimé : 30 à 45 minutes pour produire une fonctionnalité complète en mode vibe

Étape 1 — Décider que la tâche est éligible au mode vibe

Le mode vibe coding n’est pas un défaut acceptable pour toutes les tâches. Avant de basculer, posez-vous trois questions. Est-ce un prototype qu’on jettera ou réécrira après validation ? Est-ce une zone non sensible du code (interface, mise en page, composant visuel, page marketing) plutôt qu’une zone critique (paiement, authentification, autorisation, requêtes base) ? Est-ce un contexte où les conséquences d’une erreur sont limitées (projet personnel, démo investisseur, brouillon de fonctionnalité) ?

Trois oui : le mode vibe est légitime. Un seul non : restez en mode discipliné. Cette grille de décision, posée explicitement avant chaque session, évite la dérive insidieuse où l’on commence par vibe-coder une page d’accueil et où l’on finit par vibe-coder le système de paiement parce que l’élan est pris.

Étape 2 — Préparer le contexte du projet pour Composer

Pour que Composer 2.0 produise un résultat aligné sur vos conventions, alimentez-le en contexte. Cursor lit deux sources principales : le dossier .cursor/rules/ à la racine du projet et le fichier CLAUDE.md ou équivalent si présent. Créez le dossier de règles s’il n’existe pas et ajoutez une règle générale qui s’applique partout :

--- mkdir -p .cursor/rules ---

# Fichier .cursor/rules/general.mdc
---
description: Conventions globales du projet
alwaysApply: true
---
- Utilise TypeScript strict, jamais 'any'.
- Imports nommés, jamais default exports sauf pour les pages Next.js.
- Tests Vitest pour la logique métier, Playwright pour les flux end-to-end.
- Commentaires uniquement quand la raison n'est pas évidente.
- Devises : tous les montants en FCFA, format 'XX XXX FCFA' avec espace fine.
- Téléphones sénégalais : validation +221 puis 9 chiffres.

Ce fichier est lu automatiquement par Composer à chaque requête. Pour des règles spécifiques à un sous-dossier (par exemple les routes API qui doivent toutes valider l’authentification), créez une règle complémentaire avec un globs qui cible le chemin concerné. C’est la fondation qui permet au mode vibe coding de rester cohérent avec la codebase au lieu de produire un code qui dérive.

Étape 3 — Lancer Composer en mode vibe

Ouvrez Composer (raccourci Cmd+I sur macOS ou Ctrl+I sur Windows et Linux). Une fenêtre s’ouvre avec un champ de prompt et un mode par défaut. Pour le vibe coding, sélectionnez le mode « Agent » dans le menu déroulant — c’est ce qui permet à Composer d’écrire et modifier plusieurs fichiers sans valider ligne par ligne.

Formulez une requête ample : « Ajoute une page complète /pricing qui présente trois plans (Particulier 0 FCFA, Pro 15 000 FCFA/mois, Entreprise sur devis). Pour chaque plan, liste cinq fonctionnalités. Bouton CTA différent par plan. Section FAQ en bas avec cinq questions sur la facturation et les conditions d’annulation. Mobile-first, palette du projet, conforme aux règles existantes. Inclus la route Next.js, les composants nécessaires, et les tests Vitest qui vérifient que les trois plans s’affichent. »

Composer interprète, identifie les fichiers à créer ou modifier, lance la production. Vous voyez en temps réel les fichiers se créer dans la barre latérale, le code s’écrire, les tests se lancer si vous avez configuré une commande de test. La session prend généralement de deux à dix minutes selon la complexité.

Étape 4 — Valider à l’écran (et seulement à l’écran)

Le mode vibe coding consiste à juger sur le rendu, pas sur le code. Une fois Composer terminé, lancez le serveur de développement (npm run dev), ouvrez la page concernée dans le navigateur, et testez visuellement :

La page s’affiche-t-elle correctement en desktop, tablette, mobile ?
Les trois plans sont-ils présents avec les bonnes informations ?
Les CTA fonctionnent-ils (renvoient vers la bonne page ou ouvrent le bon flux) ?
La FAQ se déplie-t-elle correctement ?
Les tests Vitest passent-ils en lançant npm test ?

Si tout est satisfaisant, vous acceptez la totalité des modifications via la commande de validation. Si quelque chose cloche, vous formulez la correction au niveau du comportement attendu : « La FAQ ne se déplie pas sur mobile ; le CTA Entreprise renvoie vers une page 404 ; le tarif Pro doit afficher ‘15 000 FCFA / mois’ avec espace fine. » Composer applique les corrections et le cycle reprend.

Étape 5 — Repérer les zones où basculer hors du mode vibe

Le piège du mode vibe est qu’il fonctionne tellement bien sur les zones légères qu’on est tenté de l’étendre aux zones critiques. Trois signaux d’alerte doivent vous faire basculer immédiatement vers un usage discipliné où vous lisez chaque ligne avant validation :

Composer touche à un fichier d’authentification, de session, ou de gestion d’autorisation. Une régression silencieuse ici peut exposer des données. Lisez le diff avant validation.
Composer modifie une route de paiement ou un appel à un service de facturation. L’erreur peut coûter de l’argent réel. Lisez et testez explicitement.
Composer génère ou modifie une migration de base de données. Une mauvaise migration peut détruire des données en production. Lisez la migration ligne par ligne, simulez en local sur une copie, validez sur staging avant production.

Cette discipline est exactement la critique d’Andrew Ng résumée en pratique : le vibe coding est un mode légitime sur les zones légères, pas une posture universelle. Cursor permet le passage entre les deux modes en quelques clics — c’est l’une de ses forces par rapport aux plateformes 100 % vibe.

Étape 6 — Garder l’historique des sessions vibe

Une bonne pratique consiste à tracer chaque session vibe coding significative dans un fichier PROMPTS.md à la racine du projet. Pour chaque session, notez la date, l’objectif, le prompt principal, les fichiers touchés, et un commentaire court sur le résultat. Cela documente l’histoire du projet et facilite la reprise par un autre développeur.

# PROMPTS.md

## 2026-04-30 — Page de tarification
Prompt : « Ajoute une page complète /pricing... »
Fichiers : app/pricing/page.tsx, components/pricing-card.tsx, tests/pricing.test.ts
Résultat : OK après deux itérations (FAQ mobile, format prix)

Ce fichier prend trente secondes à entretenir et change radicalement la maintenabilité d’un projet vibe-codé. Sans cette trace, un projet qui passe de main en main devient archéologique.

Étape 7 — Quand revenir au mode discipliné

Le mode vibe coding est un sprint, pas un marathon. Pour les phases de stabilisation — quand le projet sort du prototype et entre en production — basculez explicitement en mode discipliné : lecture systématique des diffs, tests obligatoires avant chaque merge, code reviews internes si vous êtes en équipe. Cursor reste votre IDE, vous changez juste la façon dont vous interagissez avec Composer (mode chat plutôt qu’agent, demandes ciblées plutôt qu’amples, validation ligne par ligne).

Le marqueur opérationnel pour basculer : dès que le projet a un utilisateur réel qui dépend de son bon fonctionnement, vous êtes sorti de la zone vibe coding. À partir de ce point, chaque modification mérite la même rigueur qu’avant l’ère des agents — l’outil change, l’exigence reste.

Erreurs fréquentes

Erreur	Cause	Solution
Composer dérive et touche des fichiers hors du périmètre demandé	Pas de scope explicite dans le prompt	Préciser dans le prompt : « Modifie uniquement les fichiers dans `app/pricing/` et `components/pricing-*` »
Le code généré utilise des conventions différentes du reste du projet	Règles `.cursor/rules/` absentes ou trop vagues	Étoffer le fichier de règles avec des exemples concrets de patterns à suivre
Composer génère des tests qui passent mais qui ne testent rien	Test bidon (par exemple `expect(true).toBe(true)`)	Lire les tests générés ; demander explicitement « les tests doivent vérifier le rendu, le clic CTA, et la validation du formulaire »
Le mode agent boucle sans terminer	Tâche trop ample ou conflits de dépendances	Découper la tâche en sous-tâches plus petites, lancer une seule à la fois
Le coût mensuel grimpe inopinément	Sessions Composer multiples non fermées, modèle Opus utilisé partout	Surveiller l’usage dans le dashboard Cursor, basculer sur Sonnet pour les tâches simples, Opus uniquement pour les sujets complexes
Une régression apparaît dans une zone non touchée par la session	Composer a modifié des fichiers transversaux (config, types globaux)	Activer la confirmation des modifications hors périmètre, lire les diffs des fichiers config avant validation

Adaptation au contexte ouest-africain

Cursor est installé localement, ce qui le rend particulièrement tolérant aux conditions de connectivité. Une fois le projet ouvert, seules les requêtes vers les modèles partent sur le réseau — vous pouvez continuer à éditer manuellement même quand la connexion vacille. C’est un avantage net par rapport aux plateformes 100 % cloud comme Lovable ou Bolt.new pour les zones où la fibre n’est pas disponible.

Côté tarification, Cursor Pro à 20 USD par mois (environ 12 000 FCFA) couvre confortablement un développeur freelance en usage régulier. Pour des sessions Composer intensives, le plan Pro+ à 60 USD (environ 36 000 FCFA) ouvre des quotas étendus. Au-delà, le plan Ultra à 200 USD est rarement justifié pour un solo : si vous l’atteignez, vous pouvez probablement embaucher un développeur junior.

Côté confidentialité du code, Cursor propose un Privacy Mode qui doit être activé explicitement dans les paramètres. Sans cette activation, certaines données peuvent être utilisées pour amélioration produit. Pour un développeur qui travaille sur du code propriétaire client, l’activation du Privacy Mode est une discipline de base — vérifiez les paramètres avant la première session.

Tutoriels associés

Windsurf et son agent Cascade : flow agentique en vibe coding
Méthodologie vibe coding responsable : revue, tests, sécurité

Pour aller plus loin

🔝 Retour au guide principal : Vibe coding 2026 : du tweet de Karpathy aux outils dominants
Documentation officielle Cursor : docs.cursor.com
Pour l’usage discipliné de Cursor en production : guide principal AI coding développeur 2026 (Claude Code, Cursor, Copilot)

FAQ

Cursor en mode vibe coding fait-il un bon Lovable ?
Non. Lovable cible les non-développeurs avec une expérience guidée. Cursor reste un IDE pour développeur. Le mode vibe coding de Cursor est destiné à un développeur qui sait ce qu’il fait et qui choisit, sur certaines zones, de relâcher la lecture ligne par ligne pour gagner en vitesse.

Composer 2.0 et l’ancien Composer, quelle différence ?
Composer 2.0 (sortie 2026) est nettement plus performant en édition multi-fichiers et en compréhension du contexte projet. La différence pratique : sur une tâche complexe touchant huit ou dix fichiers, Composer 2.0 produit un résultat cohérent du premier coup là où l’ancien demandait souvent deux ou trois itérations.

Faut-il préférer Claude Sonnet ou GPT-5 dans Composer ?
Claude Sonnet 4.6 et GPT-5 sont tous deux disponibles dans Cursor 2026. Les retours de la communauté tendent à favoriser Claude pour les tâches de refactoring et de raisonnement multi-fichiers, GPT-5 pour les tâches de génération créative. Testez les deux sur vos cas d’usage et choisissez celui qui colle à votre style.

Le mode vibe coding marche-t-il sur des codebases legacy ?
Avec précaution. Sur des codebases anciennes avec peu de typage et de conventions explicites, Composer dérive souvent. Étoffez les règles .cursor/rules/, ajoutez des annotations de types là où c’est possible, et privilégiez les sessions ciblées sur des fichiers spécifiques plutôt que des demandes amples.

Cursor remplace-t-il VS Code définitivement ?
Pour qui utilise les agents IA quotidiennement, Cursor offre une expérience plus intégrée que VS Code + extension Copilot. Pour qui n’utilise les agents que ponctuellement, VS Code + Copilot ou VS Code + Continue.dev restent valides. Le test pratique : si vos sessions agent dépassent une heure par jour, Cursor amortit largement son coût.

Comment savoir si je suis sorti du mode vibe coding sans m’en rendre compte ?
Posez-vous chaque matin la question : « Sur quoi je travaille aujourd’hui ? » Si c’est un sujet sensible (paiement, données personnelles, authentification, performance critique), vous êtes en mode discipliné, point. Si c’est un sujet léger (présentation, mise en page, composant isolé), vous pouvez vibe-coder. La règle se rappelle d’elle-même quand on l’explicite.

Cursor Composer 2.0 en mode vibe coding : agent autonome multi-fichiers (2026)