Deux personnes posent la même question à la même IA et obtiennent des réponses très différentes - parce qu'elles ont demandé différemment. Le prompt engineering est la compétence d'écrire l'entrée pour qu'un grand modèle de langage donne une sortie exacte et utile au lieu de remplissage vague. Ce guide explique ce qu'est le prompt engineering, les techniques qui marchent vraiment, son application au code, et où s'arrête le battage.
Ce qu'est le prompt engineering
Un LLM répond exactement à ce que vous demandez et à la façon dont vous le demandez. La formulation, le contexte, les exemples et la structure de votre prompt façonnent fortement le résultat. Le prompt engineering est de façonner cette entrée délibérément - être précis, donner du contexte, montrer des exemples, demander un format - plutôt que de taper une question vague en espérant.
C'est moins de la « programmation » qu'une communication claire et structurée avec un système qui vous prend au pied de la lettre. (Pour ce que fait le modèle dessous, voyez ce qu'est un LLM.)
Les techniques qui marchent
- Soyez précis sur la tâche et la sortie voulue - levez l'ambiguïté.
- Donnez du contexte - arrière-plan, contraintes, public, les données réelles.
- Montrez des exemples d'entrée→sortie souhaitée (few-shot).
- Assignez un rôle - « tu es un relecteur Python senior ».
- Spécifiez le format - JSON, tableau, puces.
- Demandez un raisonnement étape par étape sur les problèmes complexes.
- Itérez - affinez le prompt selon ce qui est revenu.
Aucune n'est une astuce ; chacune lève l'ambiguïté pour que le modèle ait ce qu'il faut.
Zero-shot, few-shot, chain-of-thought
Quelques schémas nommés couvrent l'essentiel de ce qui marche :
- Zero-shot - tu décris la tâche sans exemple. Suffit pour des demandes simples et courantes que le modèle a vues d'innombrables fois.
- Few-shot - tu inclus quelques exemples entrée→sortie dans le prompt. Le modèle imite le motif, ce qui améliore nettement la régularité sur le format et les cas limites.
- Chain-of-thought - tu demandes au modèle de raisonner étape par étape avant de répondre. Utile sur la logique multi-étapes, les maths et le débogage, où sauter à la réponse est risqué.
- Rôle / system prompt - tu poses un persona et des règles d'emblée (« tu es un relecteur sécurité senior ; signale les risques, cite la ligne »). Ça ancre le ton et les priorités de tout l'échange.
- Sortie structurée - tu spécifies un schéma exact (clés JSON, tableau) pour un résultat exploitable par machine, pas de la prose à re-parser.
Prends le few-shot quand le format compte, le chain-of-thought quand le raisonnement compte, et un rôle + sortie structurée quand tu réinjecteras le résultat ailleurs.
Le prompt engineering pour le code
Avec les assistants de code, de bons prompts transforment la qualité :
- Collez le code et les messages d'erreur réels plutôt que de les décrire.
- Indiquez le langage, le framework et les versions.
- Précisez les contraintes - performance, style, pas de nouvelle dépendance.
- Demandez des tests ou des explications avec le code.
- Découpez les grandes tâches en étapes plus petites et bien définies.
Fournir un vrai contexte - la fonction réelle, la vraie stack trace - est le plus grand levier. C'est aussi pourquoi le RAG, qui alimente le modèle avec votre vrai code, améliore l'exactitude, et pourquoi le bon assistant de code IA associé à de bons prompts surpasse l'un ou l'autre seul.
La partie honnête : compétence, pas magie
Les fondamentaux - clarté, contexte, exemples, structure - améliorent réellement les résultats sur tous les modèles et ne disparaîtront pas. Ce qui est survendu, c'est de traiter les prompts comme des incantations secrètes ou un métier permanent. À mesure que les modèles comprennent mieux l'intention, les astuces pointilleuses comptent moins tandis que la communication claire et le bon contexte comptent plus. C'est une littératie pratique pour travailler avec l'IA, pas des mots magiques.
Erreurs courantes qui gâchent un prompt
La plupart des résultats faibles viennent de quelques erreurs évitables :
- Être vague. « Améliore ça » ne donne aucune cible ; dis ce que « mieux » signifie.
- Pas d'exemples quand la forme de sortie compte - le modèle devine le format et se trompe.
- Surcharger un seul prompt de cinq demandes sans rapport ; sépare-les pour que chacune ait toute l'attention.
- Cacher le vrai contexte - décrire le code ou les données au lieu de les coller.
- Ne pas spécifier le format, puis refaire le travail pour remettre en forme.
- Abandonner après un essai au lieu d'affiner ; le second prompt, nourri de la première réponse, est souvent le bon.
Corriger l'une de ces erreurs fait souvent plus que n'importe quelle formulation astucieuse.
En résumé
Le prompt engineering, c'est façonner délibérément votre entrée pour qu'un LLM réponde bien - instructions précises, vrai contexte, exemples, format explicite, et itération. Pour le code, coller le code réel et les contraintes bat la description vague à chaque fois. Les principes se transfèrent entre modèles même quand les détails pointilleux changent. Apprenez les fondamentaux, oubliez le mystère : c'est une communication claire avec une machine littérale, et c'est une compétence à avoir.
Guides associés : Qu'est.
