Le playbook du prompt engineering pour les programmeurs

• Les assistants de codage IA augmentent la productivité des développeurs, mais la qualité de leurs résultats dépend fortement du prompt engineering
• Pour obtenir des résultats efficaces, il faut respecter des règles comme un contexte riche, des objectifs précis, des exemples, une attribution de rôle et une amélioration itérative
• L’article présente des modèles de conception de prompts et des exemples pour les principales tâches de développement, comme le debugging, le refactoring et l’implémentation de nouvelles fonctionnalités
• Un bon prompt doit contenir des informations concrètes comme l’objectif, le langage, l’environnement, les messages d’erreur et des exemples d’entrée/sortie
• Il s’agit d’une méthode de conception de prompts que même les nouveaux ingénieurs peuvent suivre, avec des comparaisons de réponses d’IA et des commentaires concrets

---

Vue d’ensemble : l’importance d’un prompt engineering réussi

• Ces derniers temps, les développeurs accélèrent leur flux de travail avec des assistants de codage IA, depuis l’autocomplétion de fonctions jusqu’à la correction de bugs et même la rédaction de modules entiers
• Cependant, la qualité des réponses de l’IA dépend de manière décisive de la qualité du prompt
• Un bon prompt favorise des solutions de code claires et créatives, tandis qu’un prompt vague ou pauvre conduit à des réponses limitées et peu utiles
• Ce playbook rassemble de façon pratique des méthodes efficaces de conception de prompts applicables aux tâches de développement du quotidien

Principes de base d’un prompt de code efficace

• Fournir un contexte riche : l’IA ne connaît pas à l’avance le projet ni l’intention, il faut donc préciser toutes les informations pertinentes, comme le langage utilisé, le framework, les bibliothèques, les messages d’erreur et l’objectif du code
• Présenter un objectif ou une question clairs : au lieu d’une demande vague comme « Pourquoi mon code ne marche pas ? », décrire clairement le résultat attendu et la situation actuelle
• Découper les tâches complexes : pour un développement de fonctionnalité important, ne pas tout demander en une seule fois, mais fractionner la demande en petites étapes progressives
• Inclure des exemples d’entrée/sortie ou le comportement attendu : fournir de vrais exemples d’entrée, de sortie ou de comportement améliore fortement la compréhension de l’IA (« few-shot prompting »)
• Utiliser un rôle (persona) : attribuer un rôle responsable comme « relis ce code comme un développeur senior React » ou « optimise-le comme un expert performance » permet d’élever le niveau de la réponse de l’IA
• Amélioration itérative conversationnelle : à partir de la première réponse de l’IA, ajouter des demandes complémentaires ou des corrections pour converger progressivement vers le résultat souhaité
• Maintenir la cohérence du code : comme l’IA s’appuie sur le style, les noms et les commentaires du code, il faut toujours conserver un code cohérent et clair

Modèles de prompts pour le debugging

Méthode de conception d’un prompt de debugging structuré

• Décrire clairement le problème et les symptômes : fournir des informations riches, comme le langage, l’objectif de la fonctionnalité, le comportement attendu, le message d’erreur réel et des extraits de code
• Demander une analyse étape par étape ou ligne par ligne : pour les erreurs logiques ou les bugs subtils, demander par exemple de « suivre les variables ligne par ligne » ou d’expliquer une portion de code pour identifier la cause
• Utiliser un code minimal reproductible : au lieu d’un grand code complexe, extraire l’unité minimale qui provoque l’erreur afin de concentrer le diagnostic
• Poser des questions directes et faire des demandes de suivi : formuler des retours clairs et réutilisables comme « où se situe le bug ? » ou « fournis une version corrigée du code »

Exemple : mauvais prompt vs prompt amélioré

Exemple de code problématique

function mapUsersById(users) {
  const userMap = {};
  for (let i = 0; i <= users.length; i++) {  
    const user = users[i];
    userMap[user.id] = user;
  }
  return userMap;
}
const result = mapUsersById([{ id: 1, name: "Alice" }]);

Mauvais prompt :

« Pourquoi la fonction mapUsersById ne fonctionne-t-elle pas ? »

• Réponse de l’IA : elle propose des suppositions vagues comme « le tableau est peut-être vide » ou « user n’a peut-être pas d’id »
• On n’obtient que des conseils généraux à cause du manque de contexte et du flou de la demande

Prompt amélioré :

« La fonction mapUsersById est censée mapper un tableau d’utilisateurs par id, mais avec l’entrée [ {id: 1, name: "Alice"} ], l’erreur TypeError: Cannot read property 'id' of undefined se produit. Voici le code : [inclure le code]. Le résultat attendu est de la forme { "1": ... }. Quelle est la cause de ce comportement et comment le corriger ? »

• Réponse de l’IA : elle identifie que la condition de la boucle (i <= users.length) dépasse la plage valide, ce qui produit undefined à la dernière itération, et propose de remplacer par i < users.length
• Une solution précise est obtenue grâce à un contexte concret, au message d’erreur et au comportement attendu

Stratégies supplémentaires de prompts de debugging

• Demander une liste des causes possibles du bug (« Quelles sont les causes possibles de ce TypeError ? »)
• Expliquer soi-même la logique du code puis demander une vérification (« Dis-moi si mon explication est correcte et trouve le problème »)
• Demander des cas de test limites (« Propose seulement 2 entrées pour lesquelles cette fonction peut échouer »)
• Attribuer le rôle d’un relecteur de code minutieux (« Relis ce code et explique les problèmes ainsi que les améliorations possibles »)

Modèles de prompts pour le refactoring et l’optimisation

Présenter un objectif d’amélioration clair

• Dire simplement « refactorise » est trop vague ; il faut préciser des objectifs concrets comme la lisibilité, la performance, la maintenabilité ou la suppression de duplications
• Fournir suffisamment de contexte sur l’ensemble du code (ou la partie nécessaire), l’environnement, le langage et la version du framework
• Demander aussi une explication des changements (« donne-moi le code et les points d’amélioration »)
• Élever le niveau de qualité attendu grâce à une attribution de rôle, par exemple « en tant qu’expert TypeScript, conforme-toi aux pratiques les plus récentes »

Exemple : comparaison de prompts de refactoring

Code d’origine

(contient des problèmes comme des fetch dupliqués ou une structure de données peu efficace)

async function getCombinedData(apiClient) {
  // Fetch list of users
  const usersResponse = await apiClient.fetch('/users');
  if (!usersResponse.ok) {
    throw new Error('Failed to fetch users');
  }
  // ... (suite omise)
}

Prompt vague

« Refactorise la fonction getCombinedData »

• L’IA peut alors modifier arbitrairement des éléments, comme paralléliser les fetch ou fusionner les messages d’erreur (son comportement est imprévisible faute d’exigences précises)

Prompt avec objectifs explicites

« Supprime les duplications, améliore les performances, parallélise les deux fetch, sépare les messages d’erreur et améliore la combinaison des données avec une méthode efficace. Ajoute aussi des commentaires et une explication des points d’amélioration. »

• Réponse de l’IA : refactoring aligné sur les objectifs, avec fetch parallèles, distinction des erreurs, usage d’une structure map efficace et explications détaillées

Conseils supplémentaires pour le refactoring

• Procéder par étapes (« améliorer la lisibilité → optimiser l’algorithme »)
• Demander d’autres approches (« implémente aussi une version en style fonctionnel »)
• Demander du code avec explication pour favoriser l’apprentissage et en faire un mini-tutoriel
• Demander l’ajout de tests pour le code obtenu

Modèles de prompts pour l’implémentation de nouvelles fonctionnalités

Guider la génération de code étape par étape

• Commencer par une description de haut niveau (la fonctionnalité souhaitée), puis la détailler progressivement
• Fournir le contexte de travail, comme du code similaire existant, les patterns du projet ou les bibliothèques utilisées
• Utiliser des commentaires ou des TODO comme prompts pour guider directement le flux de codage de l’IA dans l’IDE
• Donner des exemples d’entrée/sortie ou des cas de test afin de fixer des attentes de résultat claires
• Si le premier résultat est insuffisant, reformuler aussitôt avec des améliorations concrètes ou des contraintes de style de code

Exemple : création d’un composant React ProductList

« Crée un composant fonctionnel React nommé ProductList. Il doit récupérer un tableau de produits depuis /api/products et l’afficher sous forme de liste ; lorsqu’on saisit un nom de produit dans un champ de saisie, le filtrage doit se faire sans tenir compte de la casse. Il faut aussi gérer le chargement et les erreurs lors de la récupération. »

• Réponse de l’IA : utilisation de useState et useEffect pour récupérer les données, gérer la saisie, le filtrage et l’UI d’erreur/de chargement
• Si le projet utilise un hook personnalisé, on peut ensuite ajouter une instruction du type « refactorise pour utiliser le hook useProducts() »

Cas pratiques d’amélioration progressive des prompts

• On peut demander une extension graduelle des fonctionnalités, par exemple « ajoute une fonction de tri avec une liste déroulante A-Z et Z-A »
• En découpant le flux d’implémentation en étapes et en variant le prompt à chaque étape, on préserve la qualité et la cohérence du code

Conclusion

• Pour exploiter pleinement le potentiel des assistants de codage IA, la conception des prompts est une compétence clé
• Pour rédiger un prompt efficace, il faut toujours garder à l’esprit le contexte concret, l’objectif, les exemples, le feedback itératif et l’attribution de rôle
• Le secret consiste à considérer l’IA comme un développeur junior ou un relecteur de code au sein du projet, à la guider précisément dans la direction voulue et à améliorer progressivement la qualité

[GN⁺]

Avis Hacker News

• D’après mon expérience, il n’existe en réalité que trois vraies techniques de prompt engineering

  • In Context Learning (fournir des exemples dans le contexte, c’est-à-dire one-shot ou few-shot, par opposition à zero-shot)

  • Chain of Thought (demander de raisonner étape par étape)

  • Structured output (par exemple, spécifier clairement un format de sortie comme du JSON)
    On pourrait peut-être y ajouter aussi le Role Prompting mentionné dans cet article
    Je classe à part le RAG, car il s’agit d’un modèle qui résume le contexte fourni
    Au final, tout le reste revient à demander clairement ce que l’on veut dans un langage simple et clair

  • Dans un prompt, le contexte est l’élément le plus important
    Par exemple, j’ai constaté qu’en commençant avec TypeScript puis en posant une question de data science, on obtient de mauvaises réponses
    En posant exactement la même question avec Python, le résultat est bien meilleur
    Les LLM ont encore du mal à transférer leurs connaissances entre domaines, donc il est essentiel de fixer un contexte adapté à l’objectif

  • Personnellement, je pense aussi que le role prompting n’a pas vraiment de sens
    C’était peut-être vrai avec GPT-3, mais la plupart des LLM connaissent déjà le rôle d’« expert »
    À mon avis, s’obséder avec le « prompt engineering », c’est surtout se raconter des histoires
    Il faut formuler clairement les exigences, ajouter des exemples si nécessaire, vérifier le livrable ou la reasoning trace, puis ajuster et réessayer si le résultat n’est pas celui attendu
    Et si après plusieurs tentatives la réponse ne vient toujours pas, il faut parfois choisir de raisonner soi-même plutôt que de s’en remettre à l’IA

  • Beaucoup pensent que le problème vient du fait de « vouloir tout mettre dans un seul prompt »
    Au lieu d’envoyer une énorme requête d’un coup, on peut plutôt la découper en plusieurs prompts avec un petit contexte, puis relier entre eux des outputs structurés et bien définis
    Chaque prompt se concentre sur son objectif et sur ses exemples, tout en évitant la surcharge de contexte
    Dans ce cas, les trois méthodes essentielles mentionnées plus haut s’appliquent naturellement

  • Avec des collègues, nous avons étudié des cas d’usage du 3e point (structured output) dans le domaine scientifique
    Lien vers l’article

  • Pour information, notre équipe s’appuie davantage sur le fine-tuning que sur le prompt engineering
    L’approche few-shot prompt n’a pas été efficace dans notre cas

• J’ai souvent l’impression que quand un prompt devient trop long ou trop complexe, les performances cognitives du modèle se dégradent
  Un prompt complexe peut donner une impression de contrôle, mais en pratique ce n’est pas forcément un avantage
  Du coup, mon usage converge naturellement vers des prompts très simples et minimalistes, puis quelques itérations pour affiner

  • J’ai moi aussi commencé à adopter exactement cette approche

    1. Transmettre brièvement uniquement le contexte, les hypothèses et l’objectif vraiment nécessaires
    2. Vérifier la réponse puis modifier le prompt initial
       Cette méthode est aussi plus efficace en termes de coût
       J’ai trop souvent vu des agents brûler 30 $ d’un coup, embrouiller la codebase ou revenir au code d’origine
       Je voudrais aussi signaler que si on laisse trop l’IA écrire du code dans son projet, ce code reste moins bien en tête ensuite et devient plus difficile à maintenir

  • Il existe aussi des éléments montrant que les performances sont meilleures quand on emploie la terminologie des experts dans un prompt
    En général, quand les gens parlent en langage courant, la précision baisse, tandis que le vocabulaire d’un domaine spécialisé conduit à des réponses plus fiables
    Les données d’entraînement reflètent aussi cette distribution

  • J’ai eu une expérience similaire
    Mais quand on regarde les system prompts des agents, ils sont souvent extrêmement longs et complexes, ce qui me laisse perplexe
    Je me demande comment ces prompts fonctionnent réellement
    Exemples de system prompts

  • Sur certaines tâches, un collègue utilisait un prompt très verbeux
    Pendant l’intégration, nous avons ajouté des CRUD operations et, à titre d’expérience, je l’ai remplacé par quelque chose de très court du type « analyse ceci du point de vue de <métier> »
    Au final, les résultats des deux côtés étaient presque identiques, et le prompt long avait même tendance à réutiliser textuellement certaines phrases dans la sortie
    Le résultat en lui-même était correct, mais au final le modèle (gemini 2.5) extrayait seulement l’information importante tout en réinjectant aussi des éléments inutiles dans la réponse
    Autrement dit, du moins pour cette tâche, la verbosité n’a pas semblé avoir d’effet intéressant sur la « manière de penser » du modèle

  • Je suis arrivé à la même conclusion, mais je me demande comment il faut interpréter les exemples de longs prompts publiés par les laboratoires d’IA
    Exemple de system prompt d’Anthropic

• Je pense que le « prompt engineering » n’existe pas vraiment comme discipline distincte
  Je me demande depuis quand écrire des phrases correctement et avec du sens est devenu de l’ingénierie
  J’ai l’impression que c’est encore pire que « software engineering »
  Cela dit, il est malheureusement possible que cela devienne une vraie profession à l’avenir, et qu’une capacité spéciale à écrire des phrases soit reconnue comme telle

  • En réalité, une « phrase correctement formulée et porteuse de sens » dépend d’une multitude de variables
    Si on y ajoute les tests, la gestion, le logging et le versioning, cela cesse d’être une simple intuition et devient bien de l’ingénierie
    La structuration — ordre précis, style, reformulation du problème, etc. — est très importante
    Quand on travaille avec des family models très paramétrés, les modèles via API exigent aussi de vérifier la compatibilité des prompts existants à chaque montée de version
    Ces contrôles et ces tests font aussi partie du prompt engineering
    À mon avis, beaucoup de gens, à force de rejeter la mode et le hype, passent à côté du fond du sujet

  • Si le barista du café près de chez moi mettait « ingénieur café » sur sa carte de visite, ça m’inspirerait presque plus confiance

  • Les consommateurs actuels, à force d’être accros aux algorithmes, perdent même la capacité de lire des phrases jusqu’au bout

  • Je ne pense pas qu’il faille vraiment s’inquiéter de voir des offres d’emploi pour des « prompt engineers »

  • Les AI sloperators font tout pour donner plus de prestige à leur travail

• D’après mon expérience, quand un LLM n’arrive pas à résoudre un problème, le « prompt engineering » n’y change souvent rien
  La seule méthode qui fonctionne consiste plutôt à découper le problème en sous-problèmes et à avancer petit à petit
  Si quelqu’un a eu l’expérience inverse, je serais curieux d’avoir des exemples

  • Une partie importante de l’usage des LLM, c’est d’acquérir l’intuition de la bonne manière de découper un problème
    Il faut savoir quand et comment le découper, et quand il vaut mieux simplement laisser faire
    Comme l’article le mentionne aussi, ce savoir-faire est important
    À l’avenir, il y aura sans doute beaucoup plus de façons de mieux organiser et commenter le code pour améliorer l’interaction avec les LLM
    Les LLM eux-mêmes vont probablement évoluer dans cette direction, au point peut-être de proposer eux-mêmes comment découper un problème

  • Le but du prompt engineering est d’obtenir plus vite de bonnes solutions, dans le format souhaité
    Dans l’idéal, on voudrait que le modèle réponde tout seul correctement, mais dans la réalité il faut aussi optimiser la façon de poser la question

• Quand j’écris un prompt, j’ai encore du mal à donner des instructions en langage naturel à cause de mes habitudes
  J’ai toujours l’impression qu’il faudrait écrire cela comme des arguments précis ou une requête SQL
  Le fait de parler à l’outil comme dans une conversation me paraît encore étrange
  Malgré tout, le fait que ce soit devenu un outil capable de comprendre des consignes en langage naturel a considérablement amélioré l’accessibilité
  Et pourtant, je trouve encore un peu ridicule de me voir écrire des prompts comme si je parlais à une personne

• Il y a énormément de guides de prompt en ce moment
  Mais j’ai l’impression qu’en pratique ils ne sont pas si nécessaires
  Il suffit d’utiliser directement l’outil, de s’y familiariser et d’apprendre à s’en servir pour comprendre naturellement ce qui fait un bon prompt

  • Cela me rappelle l’époque où Google faisait le buzz et où le FOMO battait son plein
    On disait que si on n’achetait pas les livres sur le sujet, on finirait dépassé comme un homme préhistorique, alors qu’en réalité c’est un domaine si simple qu’on peut tout apprendre en une journée et qu’il n’y a pas lieu de trop se compliquer la vie

  • Il est certain que les guides et les vidéos de conseils peuvent vraiment aider certaines personnes
    Beaucoup n’ont pas forcément l’initiative de s’améliorer seuls, mais le simple fait de regarder une fois un guide ou une vidéo d’un expert peut déjà faire progresser
    Pour ma part, j’apprends régulièrement des astuces en observant les usages des autres ou les expériences de la communauté
    Il y a des limites à ce qu’on peut découvrir uniquement en s’entraînant seul

  • Il existait autrefois une formule comme dans les « guides de rédaction de user stories » : “As a [role], I want to [task] so I can [objective]”
    Que l’on soit expert ou débutant, la plupart des gens ont besoin d’aide pour formuler des exigences claires
    Même un excellent développeur peut se tromper ou mal comprendre face à des exigences non structurées

  • Observer comment les autres gagnent en productivité avec cet outil est aussi très utile
    On peut y découvrir des idées qui nous avaient échappé
    Apprendre un peu de l’expérience déjà accumulée par d’autres est plus efficace que de tout refaire soi-même par essais et erreurs
    Personnellement, comme je n’ai pas le temps de tout tester moi-même, ce type de partage d’expérience m’est vraiment précieux

  • Il existe clairement des astuces peu visibles
    Par exemple, d’après mon expérience, on peut supprimer toutes les formules de politesse comme « please » dans les prompts

• Il y a longtemps, en master d’informatique, j’ai appris dans un cours de Science of programming un processus de vérification que j’applique très bien à la rédaction de prompts en data engineering
  Par exemple, on peut demander « d’écrire du code spark qui, étant donnés input(…) et les hypothèses (…), satisfait la post-condition (…) »
  Quand on spécifie clairement les entrées, les hypothèses et les conditions de résultat, on peut obtenir un bon code
  Références :

  1. Science of programming, David Gries
  2. Verification of concurrent and sequential systems

• Je trouve qu’on en fait trop autour du prompt engineering
  Aujourd’hui, les modèles gèrent généralement très bien les choses si on copie-colle simplement le code ou l’erreur et qu’on pose une question en langage courant
  Je ne ressens pas le besoin d’écrire des prompts inutilement tordus

• Il y a quelques jours, Sergey Brin a déclaré qu’un fait peu souvent mentionné dans la communauté IA était que « menacer physiquement le modèle améliore ses performances »
  Article lié

  • Cela m’a rappelé la blague d’un vibe coder pro dans la vidéo YouTube « Programmers are also human », qui termine toujours ses instructions au LLM par « … sinon tu vas en prison »

  • Du coup, on se demande si Google n’a pas discrètement abandonné le « Don't Be Evil »

• Appeler l’écriture de prompts de l’« engineering » donne l’impression de manquer énormément de sérieux

  • J’avais entendu une comparaison amusante à l’époque où le prompt « engineering » faisait le buzz

    Appeler quelqu’un « prompt engineer », c’est exactement comme quand les employés de chez Subway sont appelés « sandwich artists »
    Blague à part, le mot « ingénieur » est déjà employé de manière tellement large qu’il ne veut plus dire grand-chose
    Infos sur Sandwich Artist

  • Au fond, cette controverse revient à chaque fois qu’on parle de software engineering

  • C’est peut-être parce que l’imagination de certains s’arrête au niveau d’une interface de chat servant à demander des photos de chats
    En réalité, il existe aussi des prompts utilisés dans des API et des workflows d’automatisation, donc cela va au-delà

  • Aux États-Unis, il existe aussi le titre de « sales engineer », et d’après mon expérience ces gens-là ne savent souvent absolument pas comment fonctionne le produit qu’ils vendent

  • L’informatique est un endroit où les mots et leur sens disparaissent
    Au point qu’on finit par se demander si un mot a encore besoin d’avoir un sens d’origine