Vous avez adopté vos outils et vous savez quand utiliser chacun. Ce qui compte ensuite, c'est « comment demander à l'IA ». Avec le même Claude Code, la qualité du résultat peut varier du simple au multiple selon la manière de formuler l'instruction. Ce chapitre vous apprend l'art de « bien demander » autour des deux grands styles de travail avec l'IA : le vibe coding, qui consiste à construire en conversant librement, et le développement piloté par les spécifications, qui consiste à définir d'abord le cahier des charges pour faire produire un résultat précis. C'est là que se joue l'essentiel du coding avec l'IA.
Le mot d'ordre : « petit et exploratoire, c'est vibe ; grand et précis, c'est spec »
La qualité de l'instruction détermine le résultat
En coding avec l'IA, le premier obstacle n'est généralement pas « la manipulation de l'outil » mais « la manière de demander ». L'IA ne peut pas lire dans vos pensées. Si vous lui lancez une phrase vague, elle comblera les manques à sa guise, en devinant, et vous renverra un code qui a l'air de fonctionner mais s'écarte de votre intention. À l'inverse, si vous savez transmettre avec justesse quoi, pourquoi et comment vous voulez que ce soit fait, elle produira un résultat d'une précision surprenante. « La qualité de l'instruction » devient directement « la qualité du résultat » — c'est le message central qui traverse tout ce chapitre. Et cette façon de demander se décline en deux grands styles.
Vibe coding — construire en conversant
Le vibe coding est un style qui consiste à ne pas figer la conception en détail à l'avance, mais à construire par tâtonnements en conversant avec l'IA. Vous exprimez grossièrement « je veux quelque chose dans ce genre », vous regardez ce qui sort, puis vous enchaînez les échanges — « un peu plus comme ça », « corrige ici » — en vous laissant porter par le ressenti (vibe) jusqu'à donner forme au résultat. Son plus grand attrait : c'est léger, exploratoire, et cela permet de matérialiser une idée d'un seul élan.
🎨 L'image : comme chercher une forme en malaxant de l'argile, sans dessiner de plan. Puisqu'on « réfléchit en faisant », même une idée encore floue dans votre tête peut être vérifiée en mettant tout de suite les mains à la pâte.
Alignons les situations où il convient et les pièges auxquels prêter attention.
- Petites choses : script ponctuel, outil simple, application d'un seul écran.
- Prototype, essai : quand on veut juger sur pièce. Une expérimentation faite pour être jetée.
- Apprentissage, entraînement : quand on veut prendre en main une nouvelle technologie et se faire une idée.
- La conception d'ensemble dérive : la direction fluctue à chaque échange, la cohérence se perd facilement.
- Ça s'effondre quand ça grossit : plus les fichiers se multiplient, moins l'IA comme l'humain parviennent à saisir l'ensemble.
- Le contenu devient une boîte noire : s'accumule du code qui fonctionne mais dont on ne sait pas expliquer pourquoi.
💡 En un mot : le vibe coding est imbattable pour « tester vite », mais il ne convient pas pour « faire grandir et maintenir longtemps ». Petit, jetable, exploratoire — gardez ces trois mots comme repère et vous vous tromperez rarement.
Développement piloté par les spécifications — définir d'abord, construire avec précision
Le développement piloté par les spécifications (spec-driven development) est un style à l'opposé du vibe coding. Avant de commencer à écrire du code, on consigne dans un document « quoi construire et comment », puis on confie ce cahier des charges à l'IA pour qu'elle implémente avec précision. Plutôt que de converser à l'aveuglette, on fait travailler l'IA en suivant un plan de conception convenu.
La façon de faire est simple. On rédige d'abord la spécification en concertation avec l'IA, on la place (le plus souvent sous forme de fichier) dans le projet, puis on avance l'implémentation en s'y référant.
Mettre par écrit objectif, fonctions, entrées/sorties et contraintes. C'est plus rapide de faire produire un brouillon par l'IA puis de le corriger.
Avant l'implémentation, lire soi-même la spécification et éliminer manques et contradictions. C'est ici que se joue la qualité.
Donner l'instruction « implémente en suivant cette spécification ». En cas d'écart, revenir à la spécification pour corriger.
- Choses un peu plus grandes : développement s'étendant sur plusieurs fonctions et plusieurs fichiers.
- Priorité à la qualité : ce qui poserait problème si cela cassait plus tard, ce qui doit être maintenu longtemps.
- Lu par une équipe ou par d'autres : la spécification devient un point de repère partagé.
- Ne pas viser la perfection d'emblée : commencer aussi par une petite spécification et la faire grandir.
- La spécification, vous devez impérativement la lire. Une spécification laissée à l'IA a tendance à être pleine de trous.
- Si l'implémentation dérive, ne pas rafistoler au fil de la conversation : corriger la spécification puis recommencer.
📐 Pourquoi ça marche : l'IA ne voit que « cette conversation-ci, maintenant ». En posant d'abord une spécification comme référence vers laquelle on peut toujours revenir, la direction ne dérive pas même si la conversation s'allonge, et les oublis d'implémentation comme les reprises diminuent. Au fond, il s'agit simplement de « donner un plan à l'IA avant de la faire construire », mais l'effet est considérable.
Bien choisir — petit et exploratoire, ou grand et précis
Il ne s'agit pas de dire lequel est supérieur. La bonne approche est de choisir selon « l'ampleur » et « l'objectif » de ce que vous construisez. Opposons les deux styles selon plusieurs axes.
| Ampleur | Petite |
| Objectif | Prototype · exploration · apprentissage |
| Démarche | Tâtonner en conversant |
| Vitesse | Très rapide |
| Faiblesse | S'effondre en grandissant |
| Ampleur | Moyenne à grande |
| Objectif | Qualité · maintenance · production |
| Démarche | Spécification → implémentation |
| Vitesse | Démarrage lent |
| Faiblesse | Lourd pour les petits travaux |
✅ En pratique, on « fait des allers-retours ». Nul besoin de se figer dans un choix binaire. Prototyper d'abord vite en vibe coding, puis, une fois qu'on sent que ça tient la route, coucher le tout en spécification et passer à l'implémentation réelle — ce flux est le plus puissant sur le terrain. Petite exploration : vibe ; phase de croissance : spec. Alternez les styles au sein d'un même projet.
Les 5 clés d'une bonne instruction
Quel que soit le style, si l'instruction (le prompt) que vous donnez à l'IA est bonne, le résultat s'améliore. Retenons, sous forme de cartes, 5 clés de base utilisables dès aujourd'hui. Pour aller plus loin, rendez-vous sur le guide pratique du prompt engineering.
Non pas « fais que ce soit bien », mais précisément quoi faire et comment. Plus vous explicitez chiffres, conditions et cibles, plus la précision augmente.
Transmettre le langage, le framework, les fichiers liés et les contraintes utilisés. Plus l'IA connaît le contexte, plus elle vise juste.
Ne pas tout demander en même temps. En découpant petit et en demandant une chose à la fois, la vérification comme la correction deviennent plus faciles.
Montrer d'abord la forme voulue (nom de fonction, valeur de retour, exemple de sortie, format). Partager l'objectif réduit les écarts.
Ne pas viser la perfection du premier coup. Regarder la sortie et enchaîner des corrections concrètes « ici, comme ça » est plus rapide.
Les mots seuls étant difficiles à saisir, mettons côte à côte une même demande en « mauvaise instruction » et « bonne instruction ».
« Fais une fonctionnalité de connexion. »
Ni le langage, ni l'endroit de stockage, ni le comportement en cas de succès ou d'échec ne sont précisés. L'IA comble tout en devinant et renvoie un code en décalage avec ce que vous imaginiez. Source de reprises.
« Ajoute à un projet Laravel une fonctionnalité de connexion par e-mail et mot de passe. Utilise la table users existante. En cas d'authentification réussie, rediriger vers /dashboard ; en cas d'échec, afficher un message d'erreur. Pour le mot de passe, aligne-toi sur la méthode de hachage existante. Propose d'abord uniquement les routes et le Controller, l'implémentation viendra après ma validation. »
Objectif, contexte, conditions de succès, périmètre de sortie et démarche sont tous explicités. Les 5 clés y figurent toutes.
🧩 Un cran plus loin : l'approche qui consiste, au-delà de « quoi transmettre » à l'IA, à concevoir quelles informations livrer et comment à l'échelle de tout le projet s'appelle l'ingénierie du contexte ; celle qui consiste à aménager tout l'environnement où l'IA travaille (outils, permissions, fichiers d'instructions) s'appelle l'ingénierie du harnais. Si l'envie de progresser vous prend, allez y jeter un œil.
Quand l'IA ignore les règles
Claude Code dispose d'un mécanisme permettant de regrouper les instructions propres à chaque projet dans un fichier comme CLAUDE.md et de les faire respecter en permanence par l'IA. Mais à l'usage, on se retrouve face à des situations où « l'IA ignore une règle pourtant écrite ». Les causes sont multiples.
Quand les règles sont pléthoriques, les importantes se noient. Réduire leur nombre et clarifier les priorités.
Une marge d'interprétation et la règle n'est pas suivie. Adopter une rédaction concrète et vérifiable.
Quand les échanges s'éternisent, les premières instructions s'estompent. Les rappeler aux moments clés est efficace.
💡 L'essentiel de la parade : rédigez les règles « courtes, concrètes et hiérarchisées ». Et les règles importantes, rappelez-les une nouvelle fois dans la conversation au moment voulu. Le diagnostic détaillé des causes et les remèdes concrets sont expliqués dans Pourquoi l'IA ignore les règles de CLAUDE.md, et comment y remédier.
- La qualité de l'instruction fait la qualité du résultat. L'IA comble les manques en devinant : plus vous demandez avec justesse, plus le résultat est précis.
- Vibe coding = tâtonner en conversant. Fort pour le petit, le jetable, l'exploratoire. S'effondre quand ça grossit.
- Développement piloté par les spécifications = définir d'abord la spécification et implémenter avec précision. Fort pour le moyen à grand et la priorité à la qualité.
- Le bon dosage : « petit et exploratoire, c'est vibe ; grand et précis, c'est spec ». En pratique, on fait des allers-retours.
- Les clés d'une bonne instruction sont au nombre de 5 : concrétiser, contexte, une tâche à la fois, exemple de sortie, itérer.
- Si l'IA ignore les règles, c'est parce que les instructions sont longues, ambiguës ou la conversation trop longue. Courtes et concrètes, avec des rappels.
Une fois la façon de demander maîtrisée, le coding avec l'IA gagne d'un coup en stabilité. Il n'empêche que, dès que vous mettrez les mains à la pâte, vous rencontrerez forcément des erreurs et des impasses. Dans le prochain chapitre 5, « Se sortir des blocages », passons en revue de façon systématique les causes des erreurs courantes et les moyens de s'en dégager.