Le prompt engineering pour le code, c'est ce qui sépare un agent qui livre une pull request fonctionnelle d'un autre qui casse discrètement quelque chose en production. On l'a appris à nos dépens : une instruction trop vague dans notre propre pipeline a un jour généré 54 pages en double avant que quiconque s'en aperçoive. Aujourd'hui, un dispositif Claude Code à 16 agents rédige, traduit et publie notre contenu, et les prompts qui le pilotent ne ressemblent en rien aux listes de 50 modèles qu'on trouve en première page de Google. Voici les 7 techniques qu'on tape tous les jours, chacune avec un vrai avant-après.
Réponse rapide : les bons prompts de codage partagent tous la même structure. Vous énoncez l'objectif et la définition de « terminé », vous nommez les fichiers concernés avec précision, vous forcez un plan avant toute modification, vous fournissez les tests, et vous exigez des preuves plutôt qu'un « ça a l'air bon ». Faites cela, et un agent moderne (Claude Code, Cursor, GitHub Copilot) écrit un code qui passe la revue du premier coup bien plus souvent. Sautez cette étape, et vous obtenez du code bâclé, mais qui a l'air convaincant.
Les 7 techniques, dans l'ordre où on s'en sert :
- Cadrage de la tâche : objectif, contraintes et « terminé » énoncés d'emblée
- Sélection du contexte : nommer les fichiers, isoler le reste
- Plan d'abord : le faire proposer avant qu'il ne modifie
- Tests d'abord : mettre les tests d'acceptation dans le prompt
- Débogage : erreur, reproduction et résultat attendu, cause racine avant le correctif
- Refactoring : changer la structure, garder le comportement, montrer le diff
- Revue : une checklist à confronter au code, plus des preuves
Prompt Engineering pour le Code vs Fichiers de Config : Qui Fait Quoi
Les fichiers de config et les prompts par tâche ne font pas le même travail, et les confondre est l'erreur la plus fréquente dans ce domaine. Un fichier CLAUDE.md ou .cursor/rules est une politique permanente que l'agent lit à chaque session : votre stack, vos conventions de nommage, votre commande de test. Un prompt, lui, décrit la tâche précise que vous lui confiez sur l'instant. Les règles durables vont dans la config ; la tâche va dans le prompt.
La plupart des sélections de « prompts de codage » brouillent cette distinction et vous disent de coller un immense prompt de personnage dans .cursorrules. Résultat : la config que l'agent charge à chaque tâche gonfle, sans même réussir à cadrer le travail du moment. Gardez les deux séparés :
| Fichier de config (CLAUDE.md, .cursor/rules) | Prompt par tâche | |
|---|---|---|
| Contient | Règles permanentes : stack, style, commande de test, garde-fous | La tâche précise : quoi construire ou corriger, maintenant |
| Se charge | Automatiquement, à chaque session | Une fois, quand vous le tapez |
| Change | Rarement, revu comme du code | À chaque tâche |
| Exemple | « Lancer pnpm test avant de dire que c'est terminé » | « Corriger l'arrondi de taxe dans cart.ts pour les commandes de plus de 1 000 $ » |
Si vous voulez soigner la partie config, on en parle en détail dans nos meilleures pratiques CLAUDE.md et notre guide des règles Cursor. Cet article couvre l'autre moitié : les prompts que vous tapez à chaque fois. Les deux s'inscrivent dans notre guide du prompt engineering plus général, si vous voulez d'abord les fondamentaux.
Prompt Engineering pour le Code : les 7 Techniques Qu'on Utilise au Quotidien
Chaque technique ci-dessous a sa version faible, celle que les gens tapent vraiment, et sa version forte, celle qui produit du code qui fonctionne. L'écart entre les deux tient presque toujours au même geste : remplacer un souhait par un cahier des charges.
1. Cadrage de la Tâche : Énoncer l'Objectif, les Contraintes et le « Terminé »
Le cadrage de la tâche consiste à écrire l'objectif, les contraintes et à quoi ressemble le « terminé » avant que l'agent ne touche à une seule ligne. Un agent optimise pour ce que vous avez littéralement demandé, donc une requête floue produit un correctif flou. Nommez le fichier, le comportement voulu, le critère d'acceptation, et ce qui ne doit surtout pas changer.
C'est cette technique qui nous a coûté 54 pages. Notre ancienne instruction de traduction n'était rien de plus qu'un souhait :
Faible : Retraduis cet article en allemand et garde les noms de marque.Rien là-dedans ne dit ce qu'un slug a le droit de faire. Du coup, lors d'une nouvelle exécution, l'agent a « amélioré » le slug de l'URL, et comme un nouveau slug veut dire un nouveau document, on s'est retrouvés avec deux pages allemandes en ligne pour le même article. Multipliez ça par les langues et les anciens articles, et vous obtenez 54 doublons et un tas d'exclusions pour contenu dupliqué. La solution, ce n'était pas un souhait plus joli, mais un cahier des charges :
Fort : Retraduis cet article en allemand.
- Si un fichier allemand existe déjà, copie son slug existant mot pour mot.
Ne le redérive jamais et ne "l'améliore" jamais.
- Avant de créer un quelconque document, retrouve celui qui existe déjà via
sa référence canonique et réutilise cet enregistrement.
- Si le slug que tu générerais diffère de celui en ligne, ARRÊTE-TOI et
préviens-moi. Un slug modifié crée une seconde URL en ligne pour la même
page.Le prompt fort nomme le mode d'échec à voix haute. Cette seule habitude, dire ce qui ne doit pas se produire et pourquoi, est le changement le plus rentable que la plupart des équipes puissent adopter. On termine aussi chaque prompt de tâche par un contrat de sortie explicite (« ton message final doit indiquer le nombre de mots, le score de validation, et les fichiers touchés ») pour que l'agent sache ce que produit le « terminé », pas seulement ce qu'il faut faire.
2. Sélection du Contexte : Nommer les Fichiers, Isoler le Reste
La sélection du contexte consiste à dire précisément à l'agent quels fichiers lire et lesquels laisser tranquilles, plutôt que de le laisser fouiller partout et remplir sa fenêtre de bruit. La documentation d'Anthropic est directe sur la raison : la fenêtre de contexte se remplit vite et la qualité baisse à mesure qu'elle se remplit, donc la plupart des bonnes pratiques existent pour la protéger (bonnes pratiques Claude Code).
Faible : Corrige le bug dans le flux de paiement.
Fort : Lis uniquement src/checkout/cart.ts et src/checkout/tax.ts.
L'arrondi de la taxe est faux pour les commandes de plus de 1 000 $ (il
arrondit chaque ligne au lieu du total de la commande). Corrige l'arrondi.
Ne touche à rien en dehors de src/checkout/.On isole sans concession. Une vraie ligne tirée de nos prompts d'agent dit : « n'écris pas dans url-mapping.json, pipeline.md, ni config.json, et ne touche jamais à un fichier en dehors de ton répertoire scratchpad. » Cette seule phrase a évité plus de dégâts accidentels que n'importe quel nettoyage après coup. Quand la tâche a réellement besoin de docs en direct ou d'outils supplémentaires, on les ajoute délibérément via des serveurs MCP plutôt que d'espérer que l'agent tombe sur le bon fichier par hasard. Et si une partie de ce contexte vient de l'extérieur de votre dépôt, traitez-le comme non fiable : consultez notre note sur la prévention de l'injection de prompt avant de coller une page scrapée dans un agent de codage.
3. Plan d'Abord : le Faire Proposer Avant Qu'il ne Modifie
Le prompt « plan d'abord » force l'agent à vous soumettre une approche avant de toucher à quoi que ce soit. Dans Claude Code, le Plan Mode est un état de lecture seule strict et imposé, pas un poli « réfléchis d'abord » que le modèle peut contourner : il ne peut littéralement pas écrire tant que vous n'avez pas approuvé le plan. Séparer la recherche et la planification de l'exécution est la pratique sur laquelle Anthropic insiste le plus pour éviter de résoudre le mauvais problème.
Faible : Ajoute une limitation de débit à l'API.
Fort : Avant d'écrire le moindre code, donne-moi un plan numéroté : quel
middleware, où vivent les compteurs, comment tu gères la réponse 429 et ses
en-têtes, et quels tests tu vas ajouter. Attends mon approbation avant de
modifier quoi que ce soit.Pourquoi ça marche : un plan coûte peu à lire et peu à corriger. Corriger un plan faux coûte une phrase ; corriger du code faux coûte un cycle de revue complet. Cela s'associe naturellement avec le fait de demander au modèle de raisonner étape par étape en premier (voir le chain-of-thought prompting), et c'est l'ossature des workflows Claude Code en plusieurs étapes qu'on fait tourner pour tout ce qui n'est pas trivial.
4. Tests d'Abord : Mettre les Tests d'Acceptation dans le Prompt
Le prompt « tests d'abord » place les critères d'acceptation dans le prompt sous forme d'entrées et de sorties concrètes, pour que l'agent écrive du code face à une cible que vous avez définie plutôt qu'une cible qu'il a devinée. Collez le test qui échoue, ou un petit tableau de résultats attendus, et dites « fais passer ce test sans le modifier ».
Faible : Écris une fonction pour parser les dates ISO 8601.
Fort : Fais passer ce test qui échoue, sans le modifier :
parseIso("2026-07-20T15:00:00Z") -> Date à cet instant UTC exact
parseIso("2026-07-20") -> Date à 2026-07-20T00:00:00Z
parseIso("not-a-date") -> lève RangeError
parseIso("") -> lève RangeError
Renvoie uniquement la fonction et ses imports.Des exemples concrets battent les adjectifs à tous les coups. « Gère les cas limites » est un vœu pieux ; quatre lignes entrée-sortie sont une spécification que le modèle peut réellement satisfaire, et vous pouvez les exécuter dès que le code arrive.
5. Débogage : Erreur, Reproduction, Résultat Attendu, Cause Racine Avant Correctif
Un prompt de débogage donne à l'agent le texte de l'erreur, l'entrée qui la déclenche et ce que vous attendiez, puis demande la cause avant tout correctif. Sautez cette étape, et l'agent corrige le symptôme, si bien que le bug se déplace simplement ailleurs, plus discrètement.
Faible : Ça lève une erreur, corrige-la.
Fort : Ça plante au paiement. Voici la stack trace : [coller]. Ça n'arrive
que quand le panier a un code de réduction ET une carte cadeau (reproduction :
ajoute les deux, puis paie). Résultat attendu : les deux s'appliquent, la
carte cadeau en dernier. Trouve la cause racine et explique-la en une phrase
avant de changer quoi que ce soit. N'enveloppe pas ça dans un try/catch qui
masquerait l'erreur.La ligne « explique la cause en une phrase d'abord » fait vraiment le travail. Elle force le modèle à s'engager sur un diagnostic que vous pouvez vérifier, au lieu de livrer un correctif dont vous ne verrez jamais la logique. La ligne « ne le cache pas dans un try/catch » ferme l'échappatoire la plus courante.
6. Refactoring : Changer la Structure, Garder le Comportement, Montrer le Diff
Un prompt de refactoring contraint le périmètre sans concession : changer la structure, garder le comportement identique, et montrer le diff. Sans cette clôture, les agents « rangent » des choses que vous n'avez jamais demandées, et vous perdez la capacité à revoir le changement qui comptait vraiment.
Faible : Nettoie ce fichier.
Fort : Extrais la logique de validation de submitOrder() dans une fonction
pure validateOrder(). Garde toutes les signatures publiques et tout le
comportement identiques. Ne change rien d'autre dans ce fichier. Montre-moi
un diff avant/après et une ligne expliquant pourquoi chaque changement
préserve le comportement.C'est l'autre face de la séparation config/prompt vue plus haut : vos règles de style permanentes vivent dans les règles Cursor, mais le périmètre de ce refactoring appartient au prompt. « Ne change rien d'autre » est la phrase qui garde les refactorings faciles à relire.
7. Revue : une Checklist à Confronter au Code, Plus des Preuves
Un prompt de revue confie à l'agent une checklist à confronter au code et exige des preuves, pas un verdict. « Ça a l'air bon » ne vaut rien ; la commande qu'il a lancée et le résultat qu'il a obtenu, si. Anthropic le dit clairement : faites montrer des preuves à l'agent (la sortie des tests, la commande et son résultat) plutôt que d'affirmer un succès, parce que lire une preuve va plus vite que de tout revérifier soi-même.
Faible : Relis ma PR.
Fort : Vérifie ce diff par rapport exactement à ces cinq points :
1. Aucun secret ni clé API ajoutés
2. Chaque nouvelle fonction a un test
3. Aucun changement de comportement en dehors de src/checkout/
4. Les chemins d'erreur renvoient des erreurs typées, pas des chaînes
5. Aucun console.log oublié
Pour chaque point, cite la ligne qui le respecte ou le viole. Lance ensuite
la suite de tests et colle la sortie. Ne dis pas "terminé" ; montre-le-moi.Notre propre portail de revue est construit exactement comme ça. Avant qu'un agent ait le droit de signaler un article comme publié, il grep le brouillon contre une liste de mots bannis (un blocage strict, tolérance zéro) et lance une requête pour confirmer que le corps du document n'est pas vide. L'agent n'a pas le droit de prétendre au succès ; il doit produire la sortie de la vérification. Pour les rôles de relecteur que vous réutilisez souvent, élevez la checklist au rang de persona sauvegardée, ce qui nous amène aux exemples de system prompt.
Claude Code vs Cursor vs Copilot : Où Vit Chaque Technique
Les trois grands agents de 2026 prennent en charge toutes les techniques ci-dessus, mais la surface diffère. Claude Code s'appuie sur le Plan Mode et les subagents, Cursor sur le mode Agent et sa fenêtre Agents, et GitHub Copilot sur le mode agent plus des fichiers d'instructions. Choisissez l'outil dans lequel votre équipe vit ; les techniques se transposent proprement.
| Technique | Claude Code | Cursor | GitHub Copilot |
|---|---|---|---|
| Règles permanentes | CLAUDE.md | .cursor/rules | .github/copilot-instructions.md, AGENTS.md |
| Plan d'abord | Plan Mode (lecture seule imposée) | Étape de plan en mode Agent | Aperçu du plan avant application |
| Travail scopé/parallèle | Subagents, chacun son contexte | Fenêtre Agents, un worktree par agent | Tâches d'agent cloud |
| Règles par chemin | CLAUDE.md imbriqué par répertoire | Globs de règles | .instructions.md avec applyTo |
Quelques détails actuels valent la peine d'être connus. Le Plan Mode de Claude Code est un véritable verrou en lecture seule, et chacun de ses subagents tourne dans un contexte isolé avec ses propres outils (docs subagents). La version 2026 de Cursor a ajouté une fenêtre Agents qui lance des agents en parallèle, chacun dans son propre worktree git (Cursor 2.0). Le mode agent de GitHub Copilot lit des instructions personnalisées depuis .github/copilot-instructions.md, plus des fichiers .instructions.md scopés par chemin avec un champ applyTo (instructions personnalisées Copilot). Si Cursor est votre outil quotidien, consultez notre article sur comment utiliser Cursor plus efficacement.
Comment on Prompt nos Agents de Codage chez Techsy
On fait tourner un pipeline de contenu comme une équipe de 16 agents Claude Code : un chercheur, un rédacteur de brief, un rédacteur de contenu, neuf traducteurs, un validateur et un éditeur, coordonnés par des messages de tâche. Deux conventions de ce système se transposent à n'importe quelle équipe de développement.
D'abord, chaque prompt de tâche se termine par un contrat de sortie. La dernière ligne est toujours une variante de « ton message final doit indiquer X, Y et Z. » Un agent qui connaît la forme exacte du « terminé » s'égare bien moins qu'un agent à qui on n'a dit que par où commencer.
Ensuite, on ne laisse jamais un agent corriger son propre devoir en prose. La génération et la vérification sont deux étapes séparées, et la vérification est une commande avec une sortie, pas une opinion. Cette séparation entre construction et vérification est au cœur de la façon dont Anthropic présente la construction d'agents fiables, et c'est pour ça que notre portail de revue grep et interroge au lieu de faire confiance à un « ça a l'air bon ».
C'est aussi notre métier au quotidien. Chez Techsy, on construit des agents IA et de l'automatisation pour des équipes B2B, et une discipline de prompt comme celle-ci fait la majeure partie de la différence entre une démo et quelque chose qu'on peut présenter à un client. Si vous voulez qu'un workflow de codage ou d'agent soit configuré correctement, notre service d'intégration IA est exactement là pour ça, et vous pouvez réserver une consultation gratuite pour discuter de votre stack.
Un Modèle de Prompt à Copier-Coller et Adapter
Voici le squelette dont on part pour toute tâche de codage non triviale. Supprimez les sections dont vous n'avez pas besoin, mais gardez l'ordre, parce qu'il reflète les sept techniques.
OBJECTIF
Une phrase : ce qui doit être vrai une fois que c'est terminé.
CONTEXTE
Lire uniquement : <fichiers exacts>. Ignorer tout le reste.
Faits pertinents : <contraintes, versions, déclencheur du bug>.
PLAN D'ABORD
Avant de modifier quoi que ce soit, donne-moi un plan numéroté et attends
mon approbation.
TESTS / TERMINÉ
Terminé signifie : <coller le test qui échoue ou les lignes entrée->sortie>.
Ne change pas les tests.
CONTRAINTES
Garde toutes les signatures publiques et le comportement identiques, sauf
indication contraire.
Ne touche pas à <fichiers/zones>. Nomme toute hypothèse que tu fais.
SORTIE
Montre un diff avant/après, lance les tests, et colle la sortie.
Ne dis pas "terminé" ; montre la preuve.Enregistrez-le comme snippet, ou mieux, séparez-le : les contraintes permanentes vont dans votre fichier de config, et l'objectif, le contexte et les tests vont dans le prompt. Cette séparation, c'est tout l'enjeu.
À Propos de l'Auteur
Mert Batur Gurbuz est Cofondateur de Techsy.io, où l'équipe livre des agents IA, des systèmes d'automatisation et des pipelines voix/SDR pour des clients B2B. Il étudie à l'University of Birmingham et écrit sur la stack d'outils LLM que l'équipe Techsy utilise réellement en production.
Qualifications : Cofondateur, Techsy.io, University of Birmingham. Retrouvez-le sur LinkedIn.
Questions Fréquentes
Qu'est-ce que le prompt engineering pour le code ?
Le prompt engineering pour le code est la pratique consistant à écrire des instructions qui amènent un agent IA à produire du code correct et relisible. En pratique, cela veut dire énoncer l'objectif et la définition du « terminé », nommer les fichiers concernés, forcer un plan avant toute modification, fournir des tests, et exiger des preuves. C'est plus proche de la rédaction d'un cahier des charges que de celle d'une phrase habile.
En quoi est-ce différent d'écrire un fichier CLAUDE.md ou .cursor/rules ?
Les fichiers de config contiennent une politique permanente que l'agent lit à chaque session : votre stack, vos conventions et votre commande de test. Un prompt par tâche est le travail précis que vous lui confiez sur l'instant. Mettez les règles durables dans la config et la tâche dans le prompt. Coller des prompts de tâche entiers dans un fichier de config gonfle chaque session sans pour autant réussir à cadrer la tâche individuelle.
Quelle est la meilleure structure de prompt pour les agents de codage IA ?
Utilisez des sections étiquetées plutôt qu'un seul paragraphe : OBJECTIF, CONTEXTE, PLAN, TESTS, CONTRAINTES et SORTIE. Les agents analysent les prompts structurés de façon plus fiable que des murs de texte. Énoncez les critères de succès d'emblée, donnez un à trois exemples concrets plutôt que des adjectifs, et précisez le format de sortie exact que vous attendez en retour.
Comment écrire un bon prompt de débogage ?
Donnez à l'agent quatre choses : l'erreur exacte ou la stack trace, l'entrée qui la reproduit, ce que vous attendiez, et une demande de cause racine avant tout correctif. Ajoutez « explique la cause en une phrase avant de changer quoi que ce soit » pour pouvoir vérifier le diagnostic, et « ne la cache pas dans un try/catch » pour qu'il corrige le bug plutôt que de le masquer.
Faut-il inclure des tests dans mes prompts de codage ?
Oui, dès que vous le pouvez. Coller le test qui échoue, ou un petit tableau de lignes entrée-sortie, transforme une requête floue en une cible que le modèle peut réellement atteindre, et vous pouvez exécuter le résultat immédiatement. Dites à l'agent de faire passer les tests sans les modifier, pour qu'il ne puisse pas déplacer les buts et faire paraître son propre code correct.
Ces prompts fonctionnent-ils aussi dans Cursor et GitHub Copilot ?
Oui. Les techniques sont indépendantes de l'outil. Claude Code les expose via le Plan Mode et les subagents, Cursor via le mode Agent et sa fenêtre Agents avec un worktree par agent, et GitHub Copilot via le mode agent plus .github/copilot-instructions.md. La surface change ; le cadrage de la tâche, la sélection du contexte, le plan d'abord et la revue basée sur des preuves, eux, ne changent pas.
Quelle longueur doit avoir un prompt de codage ?
Assez long pour être un cahier des charges, assez court pour rester concentré. La qualité du raisonnement se dégrade à mesure que le contexte se remplit, donc privilégiez la structure au volume : un prompt étiqueté de 150 à 300 mots avec les bons fichiers et les bons tests bat un prompt qui divague. Déplacez tout ce qui s'applique à chaque tâche dans votre fichier de config au lieu de le répéter.
Comment empêcher un agent IA de modifier du code que je n'ai pas demandé ?
Isolez le périmètre dans le prompt. Dites exactement quels fichiers il peut modifier, ajoutez « ne change rien d'autre », et exigez de « garder toutes les signatures publiques et le comportement identiques, sauf indication contraire de ma part ». Pour les refactorings, demandez un diff avant/après avec une ligne expliquant pourquoi chaque changement préserve le comportement, pour que toute modification non demandée saute aux yeux à la revue.
Les bibliothèques de prompts à copier-coller en valent-elles la peine ?
Comme point de départ, parfois. Comme outil fini, rarement. Une bibliothèque de 50 prompts vous donne une formulation, mais elle ne peut pas connaître vos fichiers, vos tests ou vos contraintes, ce qui est justement là où réside la justesse. Apprenez les techniques, gardez un modèle adaptable, et remplissez les spécificités de la tâche qui est devant vous.