Les bonnes pratiques de vibe coding quand tu ne sais pas (encore) coder

Série — Vibe coding pour non-dev 1. Cursor et le terminal · 2. React + Vite · 3. Next.js · 4. Bonnes pratiques

Introduction

Tu as un projet qui tourne en local — React + Vite ou Next.js, peu importe. Tu as ouvert Cursor, tu as tapé quelques commandes, tu vois quelque chose dans ton navigateur.

Maintenant, la vraie question : comment parler à Cursor pour qu'il t'aide vraiment, sans transformer ton projet en Frankenstein ?

Vibe coder, ce n'est pas "balancer des prompts magiques" et espérer que ça marche. C'est apprendre à guider l'IA comme tu guiderais un dev junior : clair, précis, et avec un cadre.

Si tu n'as pas encore initialisé ton projet, commence par Cursor et le terminal, puis React + Vite ou Next.js.

---

1. Parler de ton projet comme d'un produit, pas comme d'un exercice

La plupart des prompts "foireux" ressemblent à :

"Fais-moi un site incroyable en Next.js."

Tu peux faire mieux avec une seule phrase structurée :

• ce que tu construis : "site vitrine pour [ton activité]" ou "petit outil interne pour [ton besoin]" ;
• qui l'utilise : clients, équipe interne, toi seul ;
• ce que tu veux voir concrètement sur la page : sections, blocs, actions possibles.

Exemple d'intention claire pour Cursor :

"On travaille sur un site vitrine pour mon entreprise de terrassement. Le projet est un Next.js créé avec create-next-app. Je veux une page d'accueil avec : un hero simple, une section services, une section témoignages vide (placeholder), et un footer minimal."

Même si tu ne sais pas coder, tu donnes du contexte. Cursor peut alors adapter le code sans partir dans tous les sens.

---

2. Modifier plutôt que réinventer

Une bonne pratique de vibe coding, surtout quand tu débutes :

• ne pars pas d'un fichier vide si tu peux l'éviter ;
• demande à Cursor de modifier ce qui existe déjà.

Par exemple :

• "Prends la page d'accueil actuelle et réorganise-la en trois sections : hero / services / contact."
• "Garde la structure du composant, mais simplifie le contenu et enlève tout ce qui est inutile pour un site vitrine basique."

Ça te protège de deux choses :

• des projets où chaque fichier est entièrement réécrit à chaque prompt ;
• des bugs qui apparaissent juste parce que la structure standard (scripts npm, routes, etc.) a été cassée en route.

---

3. Découper par pages, composants et fonctionnalités

Une erreur classique quand on débute avec Cursor : tout demander en une fois.

Au lieu d'un énorme prompt du genre :

"Crée-moi une app complète de gestion de projets avec authentification, dashboard, calendrier, notifications et système de facturation."

Tu peux découper :

• d'abord : "Crée une page d'accueil simple avec [tels blocs]" ;
• ensuite : "Ajoute une page /dashboard qui affiche juste du texte pour l'instant" ;
• puis : "Ajoute un composant de carte projet sur cette page /dashboard."

Tu raisonnes par pages et composants, pas par "site entier en une demande". Cursor s'en sort beaucoup mieux, et toi tu contrôles ce qui change.

---

4. Documenter un minimum tes intentions… même sans cursorrules

Tu n'as pas besoin d'être déjà dans un délire avancé de "cursorrules" pour cadrer un peu ton projet. Tu peux commencer avec un simple fichier NOTES.md ou README.md à la racine où tu écris, noir sur blanc :

• ce qu'est le projet ;
• le type d'utilisateur ;
• le ton et le style général (sobre, corporate, friendly, etc.) ;
• les grosses contraintes (par exemple : "garder Tailwind", "ne pas changer tel dossier").

Ensuite, tu peux dire à Cursor :

"Lis le fichier NOTES.md et respecte ces contraintes quand tu modifies le projet."

C'est déjà une première étape vers un vibe coding plus "industrialisé".

---

5. Accepter de ne pas tout comprendre, mais garder un réflexe : poser des questions

Tu ne sauras pas tout lire dans le code, et ce n'est pas le but. Par contre, tu peux garder un réflexe simple : demander des explications à Cursor quand tu bloques.

Quelques prompts utiles :

• "Explique ce fichier comme si j'étais un débutant qui comprend juste la logique de base, pas tous les détails techniques."
• "Résume-moi en 5 bullet points ce que fait cette page."
• "Montre-moi où je dois modifier le texte si je veux changer le titre de la page d'accueil."

Tu n'essaies pas de devenir dev du jour au lendemain. Tu veux juste assez de compréhension pour ne plus avoir peur de toucher au projet.

---

Et après ?

Tu as franchi le mur qui bloque la plupart des non-dev : terminal, init projet, dialogue avec Cursor. Les prochaines marches viendront dans de futurs articles — mais tu peux déjà les anticiper.

Brancher une base SQL

Pour l'instant, ton contenu est souvent "en dur" dans le code. La prochaine étape logique : connecter ton projet à une vraie base SQL pour stocker des articles, des fiches produits, ou des données métier — et les lire depuis ton app ou ton site.

Passer de "vibe coding" à "vibe system"

À un moment, tu vas vouloir que Cursor respecte toujours ton style de code, sans que tu répètes les mêmes consignes à chaque prompt. C'est le terrain des cursorrules et des skills — une couche au-dessus du prompting au cas par cas.

Ajouter un design crédible

Quand l'UI par défaut ne suffit plus, tu peux t'appuyer sur des bibliothèques de composants comme shadcn : boutons, formulaires, cartes déjà cohérents, sans passer trois semaines sur Figma.

---

Fermer la boucle

Tu sais maintenant :

• choisir une stack adaptée à ton besoin (app vs site vitrine) ;
• initialiser un projet moderne sans comprendre tout le code ;
• lancer un serveur local et voir ton travail dans le navigateur ;
• utiliser Cursor sans tout lui déléguer, en gardant le contrôle sur la structure.

Si tu arrives à ouvrir un terminal dans Cursor, lancer npm create vite@latest ou npx create-next-app@latest, démarrer npm run dev et commencer à dialoguer avec l'IA, tu as franchi le mur qui bloque 90 % des non-dev.

Le reste, on le construira étape par étape.