Guide Complet du Vibe Coding : Techniques et Meilleures Pratiques avec Cursor et Windsurf

Guide Complet du Vibe Coding : Techniques et Meilleures Pratiques avec Cursor et Windsurf

Ces derniers temps, je me suis plongé intensément dans le « Vibe Coding », une approche qui consiste essentiellement à utiliser un agent IA pour coder à ma place, avec très peu (voire pas du tout) d’écriture manuelle de code. Je vais partager toutes les leçons que j’ai apprises pour en tirer le meilleur parti. Commençons sans plus attendre.

Qu’est-ce que le Vibe Coding ?

Pour clarifier rapidement, le Vibe Coding (ou codage agentique) ne consiste pas simplement à appuyer sur Tab pour que l’IA complète une ligne de code. Il s’agit plutôt de demander à l’IA d’écrire l’application entière, de A à Z. Dans les outils comme Cursor ou Windsurf, on utilise les fonctionnalités « Agent Ask and Edit ». Cette approche est plus complexe et présente certaines limitations qu’il faut connaître.

Ma Configuration

J’utilise principalement Cursor ou Windsurf avec les modèles Claude 3.7, en me concentrant sur la version « Thinking ». Actuellement, j’utilise Claude 3.7 Sonnet Thinking dans Cursor.

Dans Cursor et Windsurf, vous pouvez configurer n’importe quel modèle selon vos préférences :

  1. Accédez aux paramètres de Cursor
  2. Choisissez parmi la liste prédéfinie de modèles fournis directement par Cursor/Windsurf
  3. Vous pouvez également ajouter vos propres modèles

Pour ajouter des modèles personnalisés, il faut utiliser la clé API OpenAI. Activez-la, ajoutez votre clé et vous pouvez remplacer l’URL de base. Vous ne pouvez le faire qu’une seule fois, ce qui signifie que vous ne pouvez avoir qu’un seul service API non-OpenAI, mais c’est suffisant. Personnellement, j’utilise Groq en y ajoutant ma clé Groq, qui est formatée selon la norme API d’OpenAI.

Quel que soit le modèle choisi, assurez-vous qu’il prend en charge le comportement agentique et les appels de fonctions et d’outils. La plupart des modèles n’y parviennent pas bien, mais Claude 3.7 Thinking le fait.

Commencer par une Spécification Détaillée

Je recommande de commencer par rédiger une spécification très détaillée de ce que vous souhaitez construire. Par exemple, j’ai utilisé Groq 3 pour écrire une spécification pour un clone de Twitter :

Écrire une spécification pour une application qui sera un clone de Twitter. Soyez aussi précis que possible. Nous utiliserons Python pour le backend.

L’IA va alors générer une spécification complète, incluant non seulement les détails techniques, mais aussi le fonctionnement de l’application, le schéma de la base de données, les points d’API, etc.

Une fois cette spécification terminée, copiez-la et collez-la dans Cursor.

L’Importance des Règles

Une découverte majeure pour moi a été l’utilisation des « règles » dans Cursor ou Windsurf. Ces règles permettent d’indiquer à l’agent comment vous souhaitez coder, quelles technologies utiliser et quels workflows suivre.

Cela s’est avéré crucial, car souvent l’IA essayait d’utiliser des technologies qui n’étaient pas dans ma spécification, ce qui causait des problèmes. Par exemple, je voulais utiliser une base de données SQL pour tout, mais à chaque problème rencontré, l’agent essayait de passer au stockage JSON dans un fichier, ce qui était très frustrant.

Configuration des Règles

Dans Cursor, allez dans Settings > Rules. Vous pouvez avoir des règles spécifiques à l’utilisateur (pour tous les projets) ou des règles de projet. J’ajoute généralement des règles de projet en créant un nouveau fichier dans le dossier « cursor/rules ».

Mes Préférences de Codage

Voici quelques règles que j’ai établies et pourquoi :

  1. Préférer les solutions simples – Évident mais important
  2. Éviter la duplication de code – L’IA a tendance à dupliquer du code plutôt que de vérifier s’il existe déjà
  3. Séparer les environnements Dev/Test/Prod – Crucial pour éviter les confusions
  4. Ne faire que les changements demandés – L’IA modifiait souvent d’autres parties du code non concernées
  5. Ne pas introduire de nouveaux modèles ou technologies – Sauf en dernier recours
  6. Maintenir le code propre et organisé – Éviter les fichiers de plus de 200-300 lignes
  7. Éviter d’utiliser des données fictives – Sauf dans les environnements de test
  8. Ne pas modifier les fichiers .env – Pour éviter de perdre les clés API

Ma Stack Technique

J’ai également défini ma stack technique dans les règles :
– Python pour le backend
– HTML/JS pour le frontend
– Base de données SQL (jamais de stockage JSON dans des fichiers)
– Bases de données séparées pour Dev/Test/Prod
– Elasticsearch pour la recherche (version hébergée uniquement)

Utilisation de l’Agent

Une fois que vous avez défini vos règles et votre spécification, vous pouvez commencer à travailler avec l’agent :

  1. Ouvrez une nouvelle fenêtre Cursor
  2. Cliquez en haut à droite pour ouvrir le panneau IA
  3. Assurez-vous que l’agent est activé par défaut (avec Claude 3.7 Sonnet Thinking comme modèle)
  4. Collez votre spécification et demandez à l’agent de construire l’application

Gestion du Contexte

Un élément important à surveiller est le panneau de contexte. Il montre tout ce que vous donnez à l’IA. À un certain point, le contexte devient trop volumineux et les performances se dégradent. Cursor vous indiquera « Start a new chat for better results » (Démarrer une nouvelle conversation pour de meilleurs résultats).

C’est un équilibre à trouver : vous voulez donner suffisamment de contexte sans en donner trop. Si vous commencez une nouvelle conversation, vous perdez du contexte, mais vous pouvez en transférer une partie.

Lorsque vous démarrez une nouvelle conversation, assurez-vous d’inclure vos règles à nouveau. Cliquez sur « My Stack » et « Coding Preferences » pour ajouter ce contexte.

Conseils Pratiques

Restez Précis dans vos Demandes

Faites des demandes spécifiques et limitées. Corrigez de petits problèmes, ajoutez de petites fonctionnalités et testez autant que possible.

Tests

Les tests de bout en bout (end-to-end) fonctionnent mieux que les tests unitaires. Ils simulent ce qu’un utilisateur ferait réellement. Demandez à l’agent d’écrire des tests pour chaque fonctionnalité et vérifiez qu’ils passent.

Si les tests échouent, demandez à l’agent de les corriger, mais surveillez attentivement les corrections pour vous assurer qu’elles n’affectent pas la production de manière inattendue.

Utilisez une Stack Populaire

L’IA fonctionne mieux avec des technologies populaires car elle a été exposée à plus de code et de documentation dans ces langages. Choisissez des stacks courantes comme Python, HTML/JavaScript et SQL.

Exemple de Conversation avec l’Agent

Voici à quoi ressemble une conversation typique :

Moi : Imposer une longueur maximale de tag de 20 caractères. Vérifier que nous n'avons pas déjà de code pour cela. Écrire des tests après l'implémentation.

[L'agent commence à réfléchir, utilise ses outils pour explorer le code existant, lit les fichiers pertinents...]

Agent : Basé sur mon analyse du code, voici ce que j'ai trouvé... [Détails de l'analyse]

[L'agent fait des changements, exécute les tests, corrige les erreurs si nécessaire...]

Agent : Tous les tests sont passés. Voici un résumé des changements effectués...

Modes d’Exécution

Il existe trois modes pour exécuter les commandes de l’agent :

  1. Manuel – Vous devez approuver chaque action
  2. YOLO – Exécution automatique de tout (risqué pour le code en production)
  3. Auto – L’agent décide quelles commandes exécuter automatiquement et lesquelles vous demander d’approuver

Pour le Vibe Coding à partir de zéro, le mode YOLO fonctionne bien, mais soyez prudent car il peut pousser vers GitHub ou déployer en production.

Limitations et Considérations

Temps de Réponse

Le processus peut être lent. Chaque commande peut prendre entre 2 et 15 minutes pour être complétée, car l’agent doit tester, corriger et vérifier. Une solution potentielle est d’ouvrir plusieurs fenêtres Cursor et de travailler sur différentes branches simultanément.

Modèles

J’alterne entre Claude 3.7 Thinking et Claude 3.7 standard. La version Thinking fonctionne généralement mieux, mais elle est un peu plus lente.

Refactoring

Demandez occasionnellement à l’agent de refactoriser le code pour le rendre plus propre et mieux organisé, mais spécifiez qu’il doit s’agir d’un refactoring à faible risque pour éviter de casser trop de choses.

Limitations de Complexité

À un certain point, il devient difficile d’apporter des modifications. Une simple modification peut nécessiter de nombreuses itérations pour être correctement implémentée. Connaître toutes ces bonnes pratiques dès le départ vous permettra d’aller beaucoup plus loin.

Conseils Finaux

Commits Fréquents

Commitez souvent ! Je ne peux pas assez insister sur ce point. Assurez-vous de commiter chaque changement pour pouvoir revenir en arrière si nécessaire.

Utiliser l’Historique des Conversations

Vous pouvez voir l’historique des conversations et restaurer des points de contrôle. Par exemple, si vous avez ajouté un mode sombre, vous pouvez faire défiler jusqu’en haut et cliquer sur « Restore checkpoint » pour revenir à cet état du code.

Vous disposez donc non seulement de Git pour la gestion des versions, mais aussi de cette fonctionnalité intégrée à Cursor/Windsurf.

Conclusion

Voilà toutes les meilleures pratiques que j’ai apprises après environ 100 à 150 heures de Vibe Coding sur différentes applications. C’est très amusant et je suis impatient de voir ces outils s’améliorer encore. C’est le pire qu’ils seront jamais, et tous les problèmes actuels deviendront plus faciles à gérer à l’avenir.

Profitez du Vibe Coding ! Vous n’avez besoin que de très peu de connaissances en programmation pour construire quelque chose d’incroyable. Je vous encourage à vous lancer dans la création.