Méthode de travail avec Claude
Le moyen le plus simple de perdre le fil d’un projet de vibe coding est de demander une application entière d’un coup. Commencez par un seul écran ou comportement, indiquez à Claude ce qui doit rester inchangé et demandez comment tester le résultat. Vibe Code vous aide à transformer cette idée en une première consigne ciblée.
Une demande vague peut produire un aperçu convaincant sans le comportement dont vous avez besoin. Ces trois points de départ montrent quand une demande plus précise à Claude est utile et quand une autre méthode peut mieux convenir.
Vous savez décrire une liste de tâches, mais pas encore comment demander à Claude de gérer l’état, les écrans vides ou la persistance des données. Commencez par une seule interaction fonctionnelle et demandez une explication simple de chaque fichier avant d’ajouter des fonctionnalités.
Si vous préférez recevoir des suggestions à côté du code que vous modifiez déjà, le guide Copilot présente cette approche centrée sur l’éditeur.
Votre maquette semble correcte, mais un écran statique ne montre pas ce qui se passe lorsqu’un champ est vide ou qu’une action échoue. Demandez à Claude d’implémenter l’interaction et de répertorier les états à vérifier.
Si vous souhaitez comparer avec un autre modèle conversationnel pendant la phase de conception, le guide Gemini présente cette possibilité.
Vous avez déjà des fichiers et souhaitez ajouter un filtre sans réécrire l’application. Fournissez uniquement les composants concernés, décrivez le comportement actuel et demandez à Claude d’identifier les fichiers touchés avant de proposer des modifications.
Si votre priorité est d’apporter des modifications dans votre éditeur, le guide Copilot explique comment vous appuyer sur les fichiers actuels.
La colonne de gauche présente une demande insuffisamment précise. Celle de droite donne à Claude une tâche délimitée et un résultat observable. Chaque méthode comprend une demande de création et une vérification de suivi.
| Demande sans périmètre défini | Flux de travail Claude à portée définie | |
|---|---|---|
| Nouvel écran · création | « Crée-moi une application de productivité. » Le public cible, l’écran et les actions essentielles ne sont pas définis. | « Crée un seul écran de liste de tâches permettant d’ajouter, de terminer et de supprimer des tâches. L’interface doit rester utilisable sur un téléphone étroit. » |
| Nouvel écran · vérification | Accepter une capture d’écran comme preuve que les commandes fonctionnent. | Demander des tests manuels couvrant une liste vide, une tâche terminée et une suppression après actualisation. |
| Application existante · modification | « Améliore mon application. » Claude ne sait pas ce qu’il peut remplacer. | Fournir les fichiers pertinents et demander un filtre par statut tout en conservant le stockage actuel des tâches et la mise en page. |
| Application existante · vérification | Appliquer une réécriture majeure sans examiner les différences. | Demander un récapitulatif des modifications fichier par fichier, puis tester le comportement existant et le nouveau filtre. |
| Correction de bug · investigation | « Ça ne marche pas. » Aucun échec reproductible ne permet d’établir un diagnostic. | Fournir le texte de l’erreur, les étapes pour la reproduire, le comportement attendu et le plus petit extrait de code pertinent. |
| Correction de bug · vérification | Supposer qu’une explication plausible signifie que le bug est corrigé. | Demander à Claude la cause présumée, un correctif minimal et un test de non-régression que vous pouvez exécuter. |
Voici ce qu’une réponse utile à une demande de liste de tâches pourrait contenir. Ces exemples de texte sont donnés à titre d’illustration : ils ne signifient pas qu’une invite a été exécutée ni que son code a été vérifié.
Première ébauche
Exemple de réponse : « Je vais créer un seul écran de liste de tâches permettant d’ajouter, de terminer et de supprimer des tâches. Les tâches seront conservées dans le stockage local. Je n’ajouterai ni comptes, ni partage, ni serveur. J’expliquerai la logique de gestion de l’état et du stockage après l’implémentation. » Ce périmètre rend le premier résultat de vibe coding plus facile à examiner qu’une proposition d’application tentaculaire.
Révision
Exemple de demande de suivi : « Après un rafraîchissement, les tâches terminées apparaissent comme non cochées. Conserve la mise en page actuelle et corrige uniquement la persistance. Dis-moi quelle valeur enregistrée manquait et comment vérifier la correction. » Cela indique à Claude un problème précis et limite la modification. Lorsque vous pratiquez le vibe coding par itérations, décrivez ce que vous avez observé plutôt que de demander une amélioration générale.
Transmission
Exemple de transmission : « La liste de tâches permet d’ajouter, de terminer et de supprimer des tâches. Lancez le projet à l’aide de la commande locale indiquée dans sa documentation, puis testez une saisie vide, une tâche terminée après un rafraîchissement et la suppression d’une tâche. La persistance repose sur le stockage du navigateur ; les données ne suivront pas l’utilisateur dans un autre navigateur. » Une bonne transmission en vibe coding énonce une limite aussi clairement qu’une fonctionnalité.
Claude peut proposer du code, mais une explication claire ne prouve pas que ce code est sûr ou correct. Ne collez pas dans une requête des secrets, des dossiers clients confidentiels ou du code que vous n’êtes pas autorisé à partager. Vérifiez les dépendances et les licences, examinez le traitement des entrées et testez le comportement réel avant toute publication. Pour des données sensibles ou une application accessible au public, faites réaliser un audit de sécurité par une personne qualifiée. Utilisez Vibe Code pour commencer par une demande au périmètre défini, puis veillez à ce qu’une personne reste responsable du résultat.
Demandez un seul écran ou un seul comportement assorti d’un critère de réussite observable, par exemple une liste de tâches qui conserve ses éléments après un rafraîchissement. Précisez ce qui est hors périmètre, puis demandez à Claude d’expliquer l’implémentation et de suggérer des tests manuels. Une première demande limitée facilite l’évaluation d’un résultat de vibe coding.
Vous pouvez commencer par décrire l’interface et son comportement en langage courant. Vous devrez tout de même exécuter le résultat, repérer les erreurs et poser des questions sur le code que vous ne comprenez pas. Si d’autres personnes doivent pouvoir compter sur le résultat, faites vérifier l’implémentation plutôt que de supposer qu’un aperçu fonctionnel suffit.
Indiquez précisément à Claude ce que vous avez fait, ce qui s’est passé et ce que vous attendiez à la place. Ajoutez le message d’erreur ou le fichier concerné si vous l’avez, et demandez une modification minimale qui préserve ce qui fonctionne déjà. Relancez le test qui a échoué ainsi qu’un test du comportement qui fonctionnait déjà.
Il peut produire une première version substantielle, mais une seule consigne ne permet pas de vérifier que toutes les interactions, dépendances et situations particulières fonctionnent. Divisez l’application en éléments testables et examinez chaque ajout. Vous saurez ainsi plus facilement ce qui ne va pas lorsqu’une itération de vibe coding échoue.
Exécutez-le vous-même, examinez les fichiers et les dépendances modifiés, puis testez la gestion des entrées, le stockage et les situations d’échec. Supprimez les secrets et les exemples de données privées du projet comme de l’historique des consignes. Si le projet traite des informations sensibles, faites réaliser une vérification de sécurité adaptée avant sa publication.