Prompt engineering pour développeurs : les techniques qui marchent

Le prompt engineering est l’art de formuler des instructions efficaces pour un modèle de langage. Pour un développeur, ce n’est pas une compétence gadget : la différence entre un prompt bâclé et un prompt soigné, c’est souvent la différence entre du code inutilisable et un correctif prêt à committer. La bonne nouvelle, c’est qu’il n’y a rien de magique ni de mystérieux. Ce sont quelques techniques concrètes, applicables immédiatement, que ce guide passe en revue dans le contexte spécifique du code — que vous utilisiez Claude, ChatGPT ou un autre assistant.

Pourquoi ça compte pour coder

Un LLM ne « comprend » pas votre projet : il complète du texte à partir de ce que vous lui donnez. Sa réponse est donc entièrement conditionnée par votre requête. Si vous omettez le langage, la version, les contraintes ou le comportement attendu, le modèle comble les trous par des suppositions — parfois justes, souvent non. Le prompt engineering consiste à réduire les suppositions en fournissant ce qu’il faut, ni trop ni trop peu.

Technique 1 : donner du contexte précis

C’est la technique la plus rentable. Un modèle bien renseigné produit un code adapté ; un modèle mal renseigné produit du code générique.

Un prompt faible :

Écris une fonction pour récupérer un utilisateur.

Un prompt fort :

En TypeScript avec Prisma, écris une fonction getUserById(id: string) qui retourne l’utilisateur ou null s’il n’existe pas. Respecte notre convention : les erreurs de base sont propagées, pas avalées. Ajoute un type de retour explicite.

Précisez systématiquement :

le langage et la version (Python 3.12, Node 20…) ;
les bibliothèques et frameworks imposés ;
les conventions du projet (style, gestion d’erreurs, nommage) ;
le comportement attendu aux limites (valeurs nulles, erreurs, cas vides).

Quand c’est possible, collez le code existant pertinent : le modèle s’aligne alors sur votre style réel plutôt que sur une moyenne statistique.

Technique 2 : les exemples (few-shot)

Montrer vaut mieux que décrire. En fournissant un ou plusieurs exemples d’entrée/sortie, vous cadrez précisément ce que vous attendez. C’est le few-shot prompting.

Voici comment nous écrivons nos tests :
def test_addition():
    assert add(2, 3) == 5
Sur ce modèle, écris les tests pour la fonction multiply.

Le modèle calque la structure, le style de nommage et le niveau de détail de votre exemple. Pour des formats de sortie stricts (JSON, un schéma précis, un style de commit), un ou deux exemples valent des paragraphes d’explication.

Technique 3 : décomposer les tâches

Un LLM se trompe davantage sur une consigne monolithique que sur une série d’étapes claires. Plutôt que « construis toute l’authentification », découpez :

« Crée le modèle User avec les champs email et mot de passe haché. »
« Ajoute la route d’inscription qui valide l’email et hache le mot de passe. »
« Ajoute la route de connexion qui vérifie les identifiants et renvoie un token. »
« Écris les tests pour ces deux routes. »

Vous gardez le contrôle, vous validez à chaque étape, et le modèle raisonne mieux sur des unités bien définies. Vous pouvez aussi lui demander explicitement de réfléchir étape par étape avant de coder : « Décris d’abord ton plan, puis implémente. » Cela améliore souvent la qualité sur les problèmes non triviaux.

Technique 4 : spécifier le format de sortie

Dites précisément sous quelle forme vous voulez la réponse. Sinon, le modèle choisit pour vous, avec de longues explications quand vous vouliez juste du code, ou l’inverse.

« Réponds uniquement avec le bloc de code, sans commentaire. »
« Renvoie un objet JSON avec les clés status et data, rien d’autre. »
« Donne le diff au format unified. »
« Explique en trois puces maximum, puis le code. »

Le contrôle du format est crucial quand la sortie est consommée par un programme : dans un pipeline ou un système de RAG pour développeurs, une réponse au format imprévisible casse le traitement en aval.

Technique 5 : itérer plutôt que tout attendre du premier coup

Le premier jet est rarement parfait, et ce n’est pas grave. Le prompt engineering est un dialogue. Quand la réponse n’est pas bonne, ne recommencez pas de zéro : corrigez.

« Ça plante quand items est vide, gère ce cas. »
« Utilise async/await plutôt que des .then(). »
« Trop verbeux, garde seulement la logique métier. »

Fournir le message d’erreur exact, la stack trace ou le comportement observé accélère énormément la convergence. Traitez le modèle comme un collègue à qui vous donnez un retour précis.

Technique 6 : donner un rôle et des contraintes

Un cadrage initial oriente utilement le modèle. « Tu es un développeur Rust expérimenté et tu privilégies la sécurité mémoire » ou « Tu fais une revue de code stricte, signale les risques avant de proposer des changements » modifie la posture des réponses. Ajoutez des contraintes négatives quand c’est pertinent : « N’ajoute aucune dépendance externe », « Ne modifie pas la signature publique de la fonction ».

Erreurs fréquentes à éviter

Rester vague : « améliore ce code » sans dire selon quel critère (lisibilité ? perf ? sécurité ?).
Surcharger : noyer la vraie demande sous du contexte inutile. Fournissez le pertinent, pas tout.
Faire confiance aveuglément : un LLM peut inventer une API ou une signature. Vérifiez et testez.
Ne pas donner de retour : abandonner après un mauvais résultat au lieu d’itérer.

Prompt engineering et outils agentiques

Ces techniques prennent tout leur sens avec des agents comme Claude Code, où un fichier de consignes projet joue le rôle de contexte permanent. Les principes sont les mêmes : contexte précis, conventions explicites, tâches décomposées, format attendu. Un agent bien briefé au départ produit des résultats bien plus fiables. Pour approfondir, voyez notre guide complet sur Claude, qui détaille comment ces modèles exploitent le contexte que vous leur donnez.

En résumé

Le prompt engineering pour développeurs tient en quelques réflexes : donner un contexte précis, montrer des exemples, découper les tâches, spécifier le format de sortie, itérer avec des retours concrets et cadrer par un rôle et des contraintes. Aucune de ces techniques n’est complexe ; leur combinaison transforme radicalement la qualité des réponses. La compétence clé n’est pas de connaître des formules secrètes, mais de communiquer clairement — exactement comme avec un coéquipier humain.