Bien prompter son assistant de code IA : patterns qui marchent avec Claude Code et Cursor

Introduction

L'intelligence artificielle a révolutionné de nombreux domaines, et le développement logiciel n'y fait pas exception. Avec l'émergence d'assistants de code IA comme Claude Code et Cursor, la ligne entre l'écriture manuelle et la génération semi-automatisée de code s'estompe. Cependant, beaucoup de développeurs se trouvent désarmés face à la complexité de générer le code précis et de haute qualité qu'ils désirent. Combien de fois avez-vous obtenu un résultat passable, loin de vos attentes, en interagissant avec ces IA ? Souvent, la clé ne réside pas dans l'IA elle-même, mais dans la manière dont vous l'interrogez.

Chez Aetherio, nous exploitons quotidiennement ces outils dans nos projets de développement d'applications sur-mesure pour startups et PME. Notre expérience nous a montré que la qualité du code généré est directement proportionnelle à l'efficacité du prompt. Cet article est un guide pratique, né de cette expertise terrain, pour vous aider à maîtriser le prompt engineering spécifiquement pour le développement de code avec des assistants comme Claude Code et Cursor. Nous n'aborderons pas ici le développement d'applications IA ou les stratégies avancées comme le fine-tuning ou le RAG, qui sont explorées dans notre article sur le fine-tuning vs prompt engineering; notre focus est l'usage quotidien d'un outil de code par un développeur. Attendez-vous à des stratégies concrètes, des patterns éprouvés et des exemples avant/après qui feront de vous un pro du prompt pour la génération de code de qualité.

Pourquoi les prompts font toute la différence pour la qualité du code généré

Un assistant de code IA comme Claude Code ou Cursor est un outil puissant, mais sa performance est intrinsèquement liée à la qualité de l'input qu'il reçoit. Pensez-y comme à un stagiaire brillant : il peut accomplir des miracles si vous lui donnez des instructions claires, précises et contextuelles. À l'inverse, des directives vagues ou ambiguës le mèneront à des résultats décevants, voire contre-productifs. Dans l'écosystème du développement web en 2025, où l'IA et développement web sont de plus en plus imbriqués, la maîtrise du prompt engineering devient une compétence quasi indispensable.

Le défi de la compréhension contextuelle pour l'IA

Les LLM (Large Language Models) sont des machines à prédire la suite logique d'une séquence de texte. Ils ne "comprennent" pas le code comme un humain. Sans un contexte suffisant, ils s'appuient sur des généralités et des patterns statistiquement les plus probables, ce qui peut mener à du code :

• Non-optimisé : Ne tenant pas compte des spécificités de votre stack ou de vos contraintes de performance.
• Incompatible : Ne s'intégrant pas naturellement à votre base de code existante (conventions de nommage, architecture).
• Incomplet ou erroné : Manquant des cas limites ou introduisant des bugs subtils.
• Générique : Qui ne reflète pas l'intention métier unique de votre application.

Lorsque nous parlons de "bien prompter", nous abordons l'essence même du prompt engineering. C'est l'art et la science de formuler des requêtes efficaces pour obtenir les meilleurs résultats d'un modèle d'IA. Pour le code, cela signifie non seulement indiquer quoi faire, mais aussi comment le faire, où le placer, et pourquoi c'est important. C'est aussi ce qui distingue un usage maîtrisé du vibe coding, sur lequel nous revenons plus bas, d'un code généré sans contrôle.

Les patterns de prompt qui fonctionnent réellement avec Claude Code et Cursor

À force d'utiliser Claude Code et Cursor au quotidien sur nos projets (applications web & SaaS sur-mesure, refontes, etc.), nous avons identifié des patterns de prompt qui optimisent la qualité et la pertinence du code généré. Ces techniques transforment une interaction basique en une collaboration productive avec votre assistant IA.

Pattern 1 : Fournir un contexte de référentiel complet et précis

C'est la règle d'or. Un LLM n'a aucune idée de la structure de votre projet. Ne comptez pas sur sa "magie" pour deviner vos conventions de nommage, l'emplacement de vos fichiers ou l'architecture de votre application.

Comment faire concrètement :

• Copier-coller des extraits pertinents : Avant de demander du code, collez l'arborescence des fichiers, le contenu d'un fichier package.json (pour les dépendances), les tsconfig.json, ou même un exemple de composant similaire à celui que vous voulez générer.
• Décrire l'architecture : "Mon application est une PWA Vue.js 3 avec Nuxt 3, TypeScript, et Tailwind CSS. Le backend est en Node.js/Nest.js. Les composants sont organisés par fonctionnalité dans des dossiers séparés." (Ex: src/components/auth/LoginForm.vue).
• Donner des exemples de conventions : "Nous utilisons la composition API de Vue.js. Les styles Tailwind sont appliqués directement dans les templates. Les fonctions utilitaires sont dans src/utils."

Avec un agent comme Claude Code ou le mode Agent de Cursor, vous n'avez plus besoin de tout coller : l'outil lit lui-même les fichiers du projet. Votre rôle devient de lui indiquer lesquels comptent. Dans les deux outils, la syntaxe @chemin/du/fichier permet de désigner un fichier précis dans le prompt.

Rendre ce contexte permanent. Répéter l'architecture à chaque session est une perte de temps. Les deux outils chargent automatiquement un fichier d'instructions : CLAUDE.md à la racine du projet pour Claude Code (la commande /init en génère une première version en analysant le code), les règles du dossier .cursor/rules/ ou un fichier AGENTS.md pour Cursor. Ce fichier est versionné avec le code et partagé par toute l'équipe.

# CLAUDE.md

## Stack
- Nuxt 4 (Vue 3, Composition API, `<script setup lang="ts">`), Tailwind CSS
- API NestJS + Prisma + PostgreSQL, dans `apps/api`

## Commandes
- `pnpm typecheck` et `pnpm test` doivent passer avant de considérer une tâche terminée
- `pnpm test -- chemin/du/fichier.test.ts` pour lancer un seul fichier de test

## Conventions
- Composants organisés par fonctionnalité : `app/components/<feature>/`
- Aucun `any` ; les types d'API sont générés depuis le schéma OpenAPI, jamais écrits à la main
- Les erreurs métier passent par `DomainError`, pas de `throw new Error` dans les services

## À ne pas faire
- Ajouter une dépendance sans le signaler
- Modifier une migration Prisma existante : en créer une nouvelle

Gardez ce fichier court et factuel : ce sont des consignes, pas une documentation. Ce qui n'y figure pas, l'agent le devinera à partir des patterns les plus fréquents dans ses données, c'est-à-dire rarement les vôtres.

Pattern 2 : Explorer et planifier avant de coder

Pour toute tâche qui touche plusieurs fichiers, demandez d'abord un plan, relisez-le, et laissez seulement ensuite l'agent écrire du code. Claude Code et Cursor proposent tous deux un mode plan, accessible avec Shift+Tab : l'agent lit le code, pose ses questions et présente sa démarche sans rien modifier.

Ce détour paraît ralentir, il fait l'inverse. Corriger un plan de dix lignes coûte beaucoup moins cher que défaire trois cents lignes parties dans la mauvaise direction, et la relecture du plan fait souvent apparaître une ambiguïté de votre demande avant qu'elle ne se transforme en code.

Pattern 3 : Découper en tâches courtes et vérifiables

Une demande doit correspondre à un changement cohérent, qu'on peut relire en quelques minutes et committer. « Ajoute l'export CSV des factures » est une tâche. « Refais le module de facturation » en contient vingt. Plus la demande est large, plus l'agent prend de décisions à votre place, et plus la revue devient superficielle.

Committez entre chaque étape validée : si l'étape suivante part de travers, un retour en arrière suffit, sans démêler ce qui était bon de ce qui ne l'était pas.

Pattern 4 : Donner une référence dans votre propre code

La façon la plus sûre d'obtenir du code conforme à vos conventions est de montrer un exemple existant. « Crée SupplierService sur le modèle de @apps/api/src/customers/customer.service.ts » transmet d'un coup la structure, la gestion d'erreurs, le nommage et le style de tests, ce qu'aucune description abstraite ne fait aussi bien.

Pattern 5 : Définir quand la tâche est terminée

Un agent qui peut exécuter des commandes peut vérifier son propre travail, à condition de savoir comment. Terminez vos demandes par un critère explicite : « la tâche est terminée quand pnpm typecheck et pnpm test passent ».

Vous pouvez aller plus loin et faire écrire le test d'abord : décrivez le comportement attendu, demandez un test qui échoue, relisez-le, puis demandez l'implémentation. Le test devient la spécification, et l'agent dispose d'une cible objective plutôt que de sa propre interprétation.

Pattern 6 : Poser les contraintes explicitement

Ce que l'agent ne doit pas faire compte autant que ce qu'il doit faire : ne pas ajouter de dépendance, ne pas modifier la signature publique d'une fonction, ne pas toucher aux tests existants, rester dans un dossier donné. Sans contrainte, un assistant résout le problème par le chemin qui lui semble le plus court, qui passe parfois par une bibliothèque de plus ou par la réécriture d'un fichier voisin.

Exemple avant/après : paginer une liste

Voici une demande typique, telle qu'on la tape en fin de journée :

Ajoute la pagination sur la liste des factures.

L'agent va devoir tout décider seul : pagination côté client ou serveur, nom des paramètres, format de réponse, composant d'interface, éventuelle nouvelle bibliothèque. Le résultat peut fonctionner, mais il a peu de chances de ressembler au reste de l'application.

La même demande, structurée avec les patterns précédents :

Objectif : paginer la liste des factures (page /factures).

Contexte :
- API : @apps/api/src/invoices/invoices.controller.ts, endpoint GET /invoices
- Front : @app/pages/factures/index.vue
- La liste des clients est déjà paginée côté serveur : reprends exactement le même
  contrat (paramètres page et pageSize, réponse { items, total }) que
  @apps/api/src/customers/customers.controller.ts

Contraintes :
- Pagination côté serveur, pageSize par défaut 25, maximum 100
- Aucune nouvelle dépendance
- Conserver le filtre par statut existant

Terminé quand :
- un test d'intégration couvre la première page, la dernière page et un pageSize > 100
- pnpm typecheck et pnpm test passent

Commence par me proposer un plan, sans modifier de fichier.

Ce prompt prend deux minutes de plus à écrire. Il désigne les fichiers concernés, fournit une référence à imiter, fixe les limites, définit le critère de fin et impose un plan avant toute modification. La revue qui suit porte sur un code qui ressemble au vôtre, au lieu d'une solution à réaligner de bout en bout.

Les anti-patterns qui dégradent le code généré

• Le prompt fourre-tout. Trois fonctionnalités dans une même demande produisent un diff impossible à relire sérieusement. Une tâche, une demande.
• La conversation interminable. Au fil des échanges, le contexte se remplit de pistes abandonnées et de code obsolète, et l'agent dérive. Ouvrez une nouvelle session pour chaque tâche (/clear dans Claude Code, nouvelle conversation dans Cursor), en repartant du plan validé ou d'un court résumé.
• « Corrige l'erreur » sans l'erreur. Collez le message complet, la stack trace et la commande qui permet de reproduire le problème. Sans ces éléments, l'agent corrige ce qu'il imagine.
• Laisser l'agent modifier les tests pour les faire passer. Face à un test qui échoue, un assistant peut « corriger » le test plutôt que le code. Précisez que les tests existants ne doivent pas changer, et relisez toujours le diff des fichiers de test.
• Accepter sans relire. Le code généré engage votre responsabilité exactement comme celui que vous écrivez. Un diff que vous ne comprenez pas ne doit pas être fusionné.
• Coller des secrets ou des données clients. Le contenu d'un .env, un extrait de base de production ou un fichier client n'ont rien à faire dans un prompt. C'est l'une des dérives décrites dans notre article sur le shadow AI en entreprise.

Vibe coding : savoir quand lâcher la bride

Le terme vibe coding a été popularisé début 2025 par Andrej Karpathy, ancien directeur de l'IA de Tesla : décrire ce que l'on veut, accepter le code proposé sans vraiment le lire, et itérer au ressenti jusqu'à ce que « ça marche ». Pour un prototype jetable, une démo ou un script ponctuel, c'est une manière légitime d'aller vite.

Pour du code destiné à la production, c'est une autre affaire. L'accélération apportée par Claude Code ou Cursor est réelle, mais elle ne transfère pas à l'outil quatre responsabilités qui restent humaines :

• L'architecture. Le découpage en modules, le modèle de données, la façon dont les composants communiquent et évolueront : ces choix engagent le projet sur des années. L'IA exécute une vision, elle ne la porte pas.
• La revue de code. Elle vérifie la pertinence métier, repère les failles de sécurité, garantit la maintenabilité, et détecte un défaut typique du code généré : l'appel à une bibliothèque obsolète, ou à une fonction qui n'existe pas.
• La stratégie de test. L'IA écrit volontiers des tests, mais c'est à l'équipe de décider ce qui doit être testé et de juger si les tests couvrent les vrais risques.
• La compréhension du besoin. Traduire une demande métier en spécification précise, arbitrer entre deux fonctionnalités, dire non à une troisième : aucun prompt ne fait ce travail à votre place.

Le code produit avec un assistant doit donc suivre le même circuit que le reste : revue par un développeur, tests automatisés, analyse statique et contrôles de sécurité en intégration continue. Si votre application a été construite en vibe coding et doit maintenant passer en production, notre checklist d'audit technique d'un projet vibe-codé et notre article sur les failles de sécurité du vibe coding détaillent les points à vérifier.

Conclusion

Bien prompter un assistant de code tient moins de la formule magique que de la rigueur d'un bon ticket : du contexte ciblé et permanent, un plan avant le code, des tâches courtes, une référence à imiter, un critère de fin vérifiable et des contraintes explicites. Ces habitudes coûtent quelques minutes par demande et font la différence entre un code qu'on fusionne après relecture et un code qu'on réécrit.

L'outil évolue vite, ces principes beaucoup moins : ce sont ceux d'une bonne délégation, appliqués à un collaborateur qui écrit très vite et ne connaît de votre projet que ce que vous lui en dites. Si vous voulez installer ces pratiques dans votre équipe, nous proposons un accompagnement dédié à l'intégration et à la formation à l'IA, et nous développons avec Claude Code sur nos propres projets.