Le prompt engineering (ou ingénierie de prompt) consiste à écrire, tester et affiner les instructions que vous donnez à un modèle d'IA pour qu'il produise le résultat voulu, de façon fiable. Il porte sur ce que vous mettez dans un prompt (la tâche, le contexte, des exemples, l'entrée) et sur la manière de l'organiser (ordre, format, séparateurs). Le terme a l'air technique, mais l'essentiel consiste à écrire avec soin puis à vérifier les résultats.
Cette page est le sommaire du guide de prompt engineering de Coddy. Elle explique pourquoi la pratique fonctionne, relie chaque technique de base à la page qui l'enseigne et montre la différence entre un prompt improvisé et un prompt travaillé.
Pourquoi le prompt engineering fonctionne
Un modèle de langage génère du texte en prédisant la suite, petit morceau par petit morceau, à partir de tout ce qu'il a devant lui. Il n'a accès ni à vos intentions, ni à votre projet, ni à vos conversations passées, sauf si ce texte figure dans son entrée. Le prompt n'est donc pas une requête adressée à un esprit qui vous comprend déjà : c'est toute la situation à laquelle le modèle répond.
Il en découle une conséquence directe. Chaque question que le prompt laisse ouverte, le modèle a tendance à la trancher par le choix le plus typique : le langage le plus courant, la longueur la plus courante, le public le plus courant. Parfois, ce choix typique est justement ce que vous vouliez. Quand ce n'est pas le cas, la solution est de fermer la question dans le prompt. Un bon prompt réduit l'éventail des réponses plausibles jusqu'à ce que presque tout ce qui reste soit utile.
Deux autres faits façonnent la pratique. Les réponses sont échantillonnées, donc un même prompt peut donner des réponses différentes d'une exécution à l'autre ; un prompt n'est bon que s'il marche la plupart du temps, pas une seule fois. Et le modèle considère que tout le texte du prompt peut avoir du sens : un e-mail collé ou une phrase égarée peut être lu comme une consigne si vous ne le signalez pas clairement comme du contenu.
Un prompt improvisé face à un prompt travaillé
Les deux onglets demandent la même chose : classer des avis clients en positifs et négatifs. Comparez ce que chacun obtient.
Voici le détail :
- Mitigé. L'utilisateur apprécie la rapidité mais la déconnexion l'agace.
- Positif. L'application répond à son besoin de suivi de course.
- Négatif. L'utilisateur est mécontent de ne pas avoir eu de réponse du support.
Dans l'ensemble, les retours sont partagés : un avis positif, un négatif et un mitigé.
La réponse improvisée convient à une personne qui la lit, mais un programme ne peut pas s'en servir : les étiquettes sont noyées dans les explications, une troisième catégorie que la question ne proposait pas est apparue, et un résumé a été ajouté à la fin. Le prompt travaillé définit chaque étiquette, fixe la forme de la sortie avec un exemple et entoure les avis de balises pour qu'on les confonde moins avec des consignes. Lancé sur mille avis, il produit une sortie qu'un programme peut analyser de façon bien plus régulière, et quand il vous faut une garantie, les fonctions de sortie structurée de l'API et une étape de validation dans votre code comblent le reste de l'écart.
Les techniques de base
Chaque technique ci-dessous comble un écart différent entre ce que vous vouliez dire et ce que le modèle a reçu. La plupart des vrais prompts en combinent plusieurs.
| Technique | Ce qu'elle fait | Quand l'utiliser |
|---|---|---|
| Prompting zero-shot | Donne une consigne sans exemple | La tâche est courante et clairement décrite |
| Prompting few-shot | Montre quelques exemples d'entrée et de sortie | Le format ou le jugement est plus facile à montrer qu'à décrire |
| Chain of thought | Demande le raisonnement avant la réponse | Le problème comporte plusieurs étapes, comme en maths ou en logique |
| Prompting par rôle | Fixe la voix et les exigences à adopter | Le public et le niveau comptent |
| Sortie structurée | Impose du JSON, un tableau ou un modèle | Un programme ou un tableur lit le résultat |
| Délimiteurs et balises XML | Sépare les consignes du contenu collé | Le prompt contient des documents, du code ou du texte d'utilisateur |
| Modèles de prompts | Transforme un bon prompt en texte à trous | Vous répétez le même type de demande |
| Chaînage de prompts | Découpe un travail en étapes qui s'alimentent | Un seul prompt essaie d'en faire trop |
| Self-consistency | Échantillonne plusieurs réponses et garde la majorité | Un seul raisonnement n'est pas fiable |
| Tree of thought | Explore et note plusieurs pistes de raisonnement | Le problème demande de planifier ou de chercher |
| ReAct | Alterne raisonnement et appels d'outils | Le modèle doit chercher des informations ou agir |
| Méta-prompting | Fait écrire ou améliorer un prompt par le modèle | Vous ne savez pas comment formuler un prompt |
| Context engineering | Conçoit tout ce que voit le modèle, pas seulement la consigne | Vous construisez une application ou un agent autour d'un modèle |
Si vous débutez, commencez par les éléments d'un prompt dans comment écrire un prompt, puis le prompting few-shot et la sortie structurée. Ces trois pages couvrent la plupart des problèmes du quotidien.
Un prompt conçu pour un programme
Les prompts intégrés à un logiciel s'exécutent des milliers de fois sur des entrées que personne n'a encore vues, ils en disent donc plus long qu'un message de chat. Celui ci-dessous rédige des messages de commit à partir d'un diff. Désactivez des parties pour voir contre quoi chacune protège : sans les exemples, le style dérive, et sans les contraintes, le modèle peut utiliser des types que votre équipe n'utilise pas, comme perf ou style.
function validatePassword(password) {
- if (password.length > 8) {
+ if (password.length >= 8) {
return null;
}
return 'Password must be at least 8 characters';
}fix(auth): accepte les mots de passe de 8 caractères pile
- La condition utilisait > 8, donc un mot de passe de 8 caractères était refusé
- La règle correspond désormais au message d'erreur, qui dit "at least 8"
Comment apprendre le prompt engineering
On l'apprend en lançant des prompts et en examinant de près ce qui revient. Un parcours concret :
- Apprenez les éléments d'un prompt. Tâche, contexte, entrée, format et contraintes. La plupart des échecs viennent de l'absence de l'un d'eux.
- Choisissez une vraie tâche que vous répétez, comme résumer des tickets, expliquer des erreurs ou rédiger des e-mails, et écrivez un prompt pour elle.
- Réunissez cinq à dix entrées de test, y compris des cas difficiles : une entrée vide, une très longue, une dans une autre langue.
- Changez une seule chose à la fois et relancez toutes les entrées. Si vous changez trois choses et que le résultat s'améliore, vous ne saurez pas laquelle a aidé. Itérer sur un prompt détaille cette boucle.
- Ajoutez des techniques quand un échec précis les réclame. Des exemples quand le format dérive, un raisonnement étape par étape quand les réponses en plusieurs étapes sont fausses, des délimiteurs quand le texte collé déborde sur les consignes.
Les grands fournisseurs de modèles publient aussi des guides de prompting pour leurs propres modèles. Ils valent la lecture, car chacun décrit ce à quoi sa famille de modèles réagit le mieux.
Prompt engineer, est-ce un métier ?
Certaines entreprises ont recruté sous l'intitulé "prompt engineer", surtout quand les modèles de chat sont devenus accessibles au grand public. Le plus souvent, la compétence fait partie d'un autre métier. Les développeurs écrivent des prompts pour les fonctionnalités d'IA qu'ils construisent, les équipes support pour les assistants qui répondent aux clients, et les analystes comme les rédacteurs s'en servent tous les jours.
Dans les équipes qui construisent des produits d'IA, le travail s'est élargi. Choisir ce qui entre dans l'entrée du modèle (documents récupérés, résultats d'outils, historique de conversation, mémoire) compte autant que la formulation de la consigne, et ce travail plus large s'appelle souvent context engineering. Mesurer si un prompt fonctionne sur de nombreuses entrées, ce qu'on appelle en général l'évaluation, en est l'autre moitié.
Ce qui change avec les modèles récents
Les débuts du prompt engineering reposaient sur des astuces : phrases magiques, personnages élaborés, consigne répétée plusieurs fois. Les modèles actuels suivent beaucoup mieux les consignes simples, et les modèles de raisonnement travaillent déjà un problème en interne avant de répondre, si bien que leur demander de réfléchir étape par étape apporte moins qu'avant.
Ce qui n'a pas changé, c'est la partie qui n'a jamais été une astuce. Le modèle ne peut toujours pas connaître votre public, vos données, vos contraintes ni ce qu'est un bon résultat si vous ne le dites pas. Savoir spécifier clairement est la compétence durable, et c'est à elle que ce guide consacre la plupart de ses pages.
Questions fréquentes
Le prompt engineering, c'est quoi en termes simples ?
Le prompt engineering consiste à rédiger les instructions d'un modèle d'IA avec assez de soin pour obtenir la réponse voulue, puis à les tester et les ajuster jusqu'à ce que le résultat soit fiable. Il porte sur ce que vous dites au modèle (la tâche, le contexte, les exemples) et sur la façon de l'organiser (ordre, format, séparateurs).
Peut-on apprendre le prompt engineering sans savoir coder ?
Oui. Les compétences de base, formuler clairement une tâche, fournir du contexte, donner des exemples et préciser le format de sortie, s'exercent toutes dans une application de chat. Le code devient utile quand vous voulez exécuter un prompt de nombreuses fois, le tester sur un jeu d'entrées ou envoyer le résultat à un programme.
Combien de temps faut-il pour apprendre le prompt engineering ?
Les bases s'apprennent en un après-midi : les éléments d'un bon prompt et quelques techniques comme les exemples few-shot et la sortie structurée. Obtenir des résultats fiables sur une vraie tâche prend plus de temps, car cela passe par des tests sur de nombreuses entrées et la correction des cas où le prompt échoue.
Prompt engineer, est-ce un vrai métier ?
Certaines entreprises ont recruté sous l'intitulé "prompt engineer", mais le plus souvent la compétence fait partie d'un autre poste : développeurs qui créent des fonctionnalités d'IA, rédacteurs, analystes, équipes support. Dans les équipes qui construisent des produits d'IA, elle recoupe le travail d'évaluation et la conception de tout ce que voit le modèle, qu'on appelle désormais souvent context engineering.
Le prompt engineering sert-il encore avec les modèles récents ?
Les modèles récents ont besoin de moins d'astuces. Ils suivent mieux les consignes simples, et les modèles de raisonnement décomposent un problème sans qu'on leur demande de réfléchir étape par étape. Ce qui reste utile, c'est la partie qui n'a jamais été une astuce : formuler la tâche, donner au modèle les faits qu'il ne peut pas connaître et définir ce qu'est une bonne réponse.
