Techniques de prompt engineering : un guide pratique du zero-shot, du few-shot, du chain-of-thought et plus encore

Le prompt engineering est le moyen le moins cher et le plus rapide de changer ce que fait un grand modèle de langage : vous changez l'entrée, pas le modèle. Aucun entraînement, aucun pipeline de données, aucune facture de GPU - juste des instructions plus claires. C'est le premier barreau de l'échelle de personnalisation (voir comment les modèles d'IA sont entraînés pour l'échelle complète), et il est largement testé dans chaque examen d'IA fondamentale et d'IA générative, du AWS AI Practitioner (AIF-C01) aux équivalents Azure et Google Cloud.

Ce guide est neutre vis-à-vis des fournisseurs - les techniques fonctionnent de la même manière sur n'importe quel LLM moderne. Il couvre l'anatomie d'un bon prompt, les techniques essentielles avec le moment où utiliser chacune, les paramètres d'inférence qui façonnent la sortie, et les risques de sécurité que vous devez connaître. Là où un examen s'appuie sur un point, il y a une note "À l'examen". Considérez-le comme une référence que vous parcourez par section.

Ce qu'est (et n'est pas) le prompt engineering

Ce que c'est. L'art de concevoir et d'affiner le texte que vous donnez à un modèle afin qu'il renvoie la sortie que vous voulez. Il exploite ce que le modèle a déjà appris durant le pré-entraînement ; vous orientez, vous n'enseignez pas.

Pourquoi c'est important. C'est presque gratuit et instantané. Avant de vous tourner vers le RAG ou le fine-tuning - qui coûtent des données, de l'argent et du temps - vous devez épuiser les possibilités du prompting. Souvent, un meilleur prompt comble tout l'écart.

Ce que ce n'est pas. Cela ne change pas les poids du modèle. Si le modèle manque tout simplement de la connaissance (vos données privées) ou d'un comportement fiable, le prompting seul n'y remédiera pas - c'est alors que vous montez vers le RAG ou le fine-tuning. Ne confondez pas le prompt engineering (écrire de meilleures instructions) avec le prompt tuning (une technique d'entraînement qui apprend des vecteurs de "soft prompt") ; l'examen traite le prompt engineering comme l'option sans ré-entraînement.

L'anatomie d'un bon prompt

La plupart des prompts solides contiennent jusqu'à quatre parties :

• Instruction - la tâche : "Résume", "Classe", "Traduis", "Extrais".
• Contexte - le contexte dont le modèle a besoin : audience, ton, domaine, contraintes.
• Données d'entrée - le contenu concret sur lequel agir.
• Indicateur de sortie - la forme de la réponse : "Renvoie du JSON", "Une phrase", "Une liste à puces".

Les principes qui font fonctionner chaque partie :

• Soyez précis et sans ambiguïté. "Rédige un résumé de 3 phrases pour un lecteur non technique" vaut mieux que "résume ceci".
• Préférez les instructions positives. Dites au modèle quoi faire, pas seulement quoi éviter ; "Réponds uniquement avec le nom de la catégorie" est plus clair qu'un amas de règles "ne fais pas" (bien que les contraintes négatives aient leur place - voir plus bas).
• Donnez des contraintes. Longueur, ton, niveau de lecture, format, ce qu'il faut exclure.
• Utilisez des délimiteurs. Encadrez l'entrée avec des séparateurs clairs - triples guillemets, balises de type XML, ou en-têtes markdown - pour que le modèle sache où finissent les instructions et où commencent les données. Cela réduit aussi le risque qu'un texte fourni par l'utilisateur soit lu comme des instructions (voir prompt injection).
• Spécifiez le contrat de sortie. Si un autre programme doit lire la sortie, indiquez la forme exacte (du JSON valide avec ces clés, sans prose autour). Les modèles ne respectent pas la structure à moins que vous ne l'exigiez.

Les techniques essentielles

Zero-shot prompting

Quoi. Demander au modèle d'accomplir la tâche sans aucun exemple, en s'appuyant uniquement sur sa connaissance issue du pré-entraînement.

Quand. Des tâches simples et courantes que le modèle a clairement déjà vues (classification de base, résumés directs, questions générales).

Risque. Si la tâche est inhabituelle ou éloignée de l'entraînement du modèle, les résultats en zero-shot peuvent être peu fiables - c'est le signal pour ajouter des exemples.

À l'examen. Le zero-shot signifie aucun exemple dans le prompt. Son risque nommé est une mauvaise performance lorsque la tâche est trop éloignée de ce que le modèle a appris.

One-shot et few-shot prompting (in-context learning)

Quoi. Inclure un (one-shot) ou quelques (few-shot) exemples travaillés d'entrée-et-sortie-souhaitée dans le prompt, afin que le modèle déduise le schéma. On appelle aussi cela l'in-context learning, car le modèle "apprend" la tâche à partir du contexte du prompt, sans aucune mise à jour de paramètres.

Quand. La tâche a un format, un ensemble d'étiquettes ou un style spécifique que vous voulez reproduire de manière cohérente - par exemple, classer des messages dans vos propres catégories, ou reproduire un ton particulier.

Comment. Montrez 2 à 5 exemples propres et représentatifs qui couvrent l'éventail des cas, puis donnez la nouvelle entrée. Un formatage cohérent entre les exemples compte plus que la quantité.

À l'examen. Le few-shot learning et l'in-context learning sont la même idée : des exemples dans le prompt, sans ré-entraînement. C'est la réponse de référence pour "faire suivre au modèle un schéma ou un système d'étiquettes spécifique sans fine-tuning".

Chain-of-thought (CoT) prompting

Quoi. Demander au modèle de raisonner étape par étape avant de donner la réponse finale, au lieu de sauter directement à celle-ci.

Quand. Des problèmes en plusieurs étapes : arithmétique, logique, planification, tout ce où le raisonnement intermédiaire aide.

Comment. Soit fournir des exemples qui montrent le raisonnement (CoT few-shot), soit simplement ajouter un déclencheur comme Let's think step by step pour susciter le raisonnement sans exemples (CoT zero-shot).

À l'examen. Le chain-of-thought est la technique nommée pour améliorer la performance sur le raisonnement complexe en plusieurs étapes.

Self-consistency

Quoi. Exécuter le chain-of-thought plusieurs fois (avec un peu d'aléatoire), puis retenir la réponse qui revient le plus souvent parmi les exécutions.

Quand. Un raisonnement à enjeux élevés où une seule chaîne pourrait déraper ; en échantillonner plusieurs et voter améliore la fiabilité.

Role (persona) et system prompting

Quoi. Dire au modèle qui être - "Tu es un conseiller fiscal senior", "Tu es un relecteur de code laconique". Dans les modèles de chat, cela réside souvent dans un system prompt distinct qui définit un comportement persistant.

Quand. Pour fixer le ton, le niveau d'expertise ou la perspective à travers toute une conversation.

Comment. Énoncez le rôle, l'audience et les contraintes dès le départ. Gardez le system prompt stable ; faites varier le prompt utilisateur.

Délimiteurs et structure

Quoi. Utiliser des marqueurs explicites pour séparer les parties de votre prompt (instructions vs données vs exemples).

Pourquoi. Cela améliore l'adhérence du modèle à chaque section et, ce qui est important, aide à empêcher qu'une entrée non fiable soit interprétée comme des instructions.

Formatage de la sortie

Quoi. Spécifier la forme exacte de la sortie et, idéalement, demander au modèle d'encadrer la réponse dans des balises ou de renvoyer du JSON strict.

Pourquoi. Essentiel lorsque la sortie alimente un autre programme ou modèle. Un contrat de sortie explicite transforme une analyse instable en pipelines fiables.

Prompt templates

Quoi. Des structures de prompt réutilisables et paramétrées, avec des espaces réservés que vous remplissez à l'exécution.

Pourquoi. Cohérence et maintenabilité - votre application produit le même prompt bien testé à chaque fois, ne faisant varier que l'entrée. Les plateformes gérées offrent souvent des fonctionnalités de prompt-template et de gestion de prompts précisément pour cela.

Décomposition de la tâche et prompt chaining

Quoi. Diviser un travail complexe en prompts plus petits et alimenter la sortie de chaque étape dans la suivante.

Quand. Une tâche est trop grande ou trop multi-étapes pour un seul prompt (extraire, puis analyser, puis rédiger). Le chaining est plus fiable que de tout demander d'un coup, et chaque étape est plus facile à tester.

ReAct (reason + act)

Quoi. Un schéma où le modèle alterne raisonnement et actions - appeler des outils, rechercher, ou interroger des données - puis observer le résultat et continuer. C'est l'idée de prompting derrière les agents.

Quand. Le modèle a besoin d'informations externes ou doit accomplir des étapes dans le monde réel, pas seulement répondre de mémoire. (Cela relie le prompt engineering aux frameworks d'agents.)

Negative prompting

Quoi. Énoncer explicitement ce qu'il faut exclure ou éviter - "N'inclus pas d'opinions personnelles", "Exclus tout code", ou, pour les modèles d'images, lister les éléments que vous ne voulez pas.

Quand. Pour écarter des modes d'échec connus. Utilisez-le comme un complément ciblé aux instructions positives, pas comme le prompt entier.

Les paramètres d'inférence qui façonnent la sortie

Le texte du prompt n'est que la moitié de l'histoire. Ces paramètres de génération changent la sortie sans changer un mot de votre prompt :

• Temperature - l'aléatoire. Basse (proche de 0) donne des réponses déterministes, reproductibles et focalisées ; haute donne des réponses créatives et variées.
• Top-p (nucleus sampling) et top-k - limitent le pool de tokens candidats suivants parmi lesquels le modèle peut échantillonner, un autre levier sur la diversité.
• Max tokens - plafonne la longueur de la réponse.
• Stop sequences - des chaînes qui indiquent au modèle d'arrêter la génération.

À l'examen. "Rendre les réponses plus cohérentes ou reproductibles" signifie baisser la temperature. Sachez que la temperature et le top-p/top-k contrôlent l'aléatoire et la diversité, et sont définis au moment de l'inférence, non intégrés dans le texte du prompt.

Où se situe le prompting par rapport au RAG et au fine-tuning

Le prompt engineering est la première chose à essayer, mais il a des limites. L'échelle de personnalisation, du moins cher d'abord :

• Prompt engineering - façonner les instructions. Aucune nouvelle connaissance, aucun ré-entraînement.
• RAG (retrieval-augmented generation) - injecter vos propres données à jour dans le prompt au moment de la requête. Utilisez-le quand le modèle a besoin de faits sur lesquels il n'a jamais été entraîné, ou quand la connaissance change souvent.
• Fine-tuning - ré-entraîner sur des exemples étiquetés pour intégrer un comportement ou un style. Utilisez-le quand le prompting et le RAG ne sont toujours pas assez cohérents.

À l'examen. Si un scénario a besoin de faits privés ou à jour, le prompting seul ne suffira pas - c'est le RAG. S'il a besoin d'un comportement reproduit de manière fiable ou d'un style de domaine, c'est le fine-tuning. Le prompting est la réponse quand le modèle sait déjà accomplir la tâche et n'a besoin que d'une orientation plus claire.

Sécurité des prompts et usage responsable

Les prompts sont une surface d'attaque. Les examens fondamentaux testent ces points sous la responsible-AI et la sécurité :

• Prompt injection - un attaquant cache des instructions dans une entrée fournie par l'utilisateur (ou dans un document que le modèle lit) pour outrepasser votre system prompt et détourner le comportement du modèle ou ses actions en aval.
• Jailbreaking - des prompts conçus pour contourner les guardrails de sécurité du modèle afin de produire une sortie restreinte ou nuisible.
• Prompt leaking - amener le modèle à révéler son propre system prompt caché ou un contexte confidentiel.
• Adversarial prompting en général - le terme générique pour ces techniques de manipulation.

Les mesures d'atténuation que vous devez connaître :

• Séparer et délimiter clairement les instructions de confiance de l'entrée utilisateur non fiable ; ne jamais les concaténer aveuglément.
• Valider et assainir les entrées ; contraindre ce que le modèle est autorisé à produire et à faire.
• Appliquer des guardrails / filtres de contenu et une rédaction des PII sur l'entrée comme sur la sortie.
• Donner au modèle et à tout outil connecté un accès au moindre privilège, de sorte qu'une injection réussie ne puisse pas faire grand-chose.
• Garder un humain dans la boucle pour les actions à enjeux élevés.

Le prompting aide aussi contre l'hallucination : ancrer le modèle dans des faits récupérés (RAG), lui demander de citer ses sources, et permettre explicitement "je ne sais pas" pour qu'il cesse d'inventer des réponses. Baisser la temperature et ajouter de l'ancrage réduit les absurdités assénées avec assurance.

Liste de contrôle des bonnes pratiques

• Commencez simple ; n'ajoutez de la complexité (exemples, raisonnement, chaining) que lorsque le prompt simple échoue.
• Soyez précis : énoncez la tâche, l'audience, les contraintes et le format de sortie exact.
• Utilisez des délimiteurs pour séparer les instructions des données.
• Ajoutez des exemples (few-shot) quand vous avez besoin d'un schéma spécifique ; ajoutez Let's think step by step quand vous avez besoin de raisonnement.
• Itérez et testez sur des entrées réelles ; de petits changements de formulation comptent.
• Baissez la temperature pour la cohérence ; augmentez-la pour la créativité.
• Traitez l'entrée utilisateur comme non fiable ; délimitez-la, validez-la et protégez la sortie.

Le guide de décision en 30 secondes

• Tâche simple et familière -> zero-shot
• Besoin d'un format ou d'un système d'étiquettes spécifique -> few-shot (in-context learning)
• Raisonnement en plusieurs étapes -> chain-of-thought (ajoutez Let's think step by step)
• Besoin de plus de fiabilité sur un raisonnement difficile -> self-consistency (échantillonner et voter)
• Fixer le ton ou l'expertise à travers un chat -> role / system prompt
• La sortie alimente un autre programme -> spécifiez un format de sortie strict (JSON, balises)
• Tâche trop grande pour un seul prompt -> décomposer et chaîner
• Le modèle a besoin d'outils ou de données en direct -> ReAct / agents
• Besoin de faits privés ou à jour -> RAG, pas le prompting
• Besoin d'un comportement reproduit de manière cohérente -> fine-tuning, pas le prompting
• Rendre la sortie déterministe -> baisser la temperature

Certifications associées

Le prompt engineering est central pour chaque examen d'IA générative - ce guide apparaît sous les Guides d'étude associés sur chacun de leurs hubs :

• AWS Certified AI Practitioner (AIF-C01) - teste directement les techniques de prompt, l'in-context learning et les paramètres d'inférence.
• AWS Certified Generative AI Developer Professional (AIP-C01) - approfondit la construction avec les prompts, le RAG et les agents.
• Microsoft Azure AI Fundamentals (AI-900 / AI-901) - bases de l'IA générative et du prompting.
• Google Cloud Generative AI Leader - conception de prompts et usage des modèles de fondation.
• NVIDIA-Certified Associate: Generative AI and LLMs (NCA-GENL) - prompting des LLM et adaptation.
• Claude Certified Architect - Foundations (CCA-F) - prompter Claude efficacement.
• IBM watsonx Generative AI Engineer Associate - fondations de l'IA générative.

Comment étudier ce sujet

Pour un examen, entraînez-vous à associer un scénario à une technique, et connaissez les frontières qui font trébucher : zero-shot vs few-shot, le chain-of-thought comme outil de raisonnement, la temperature comme levier de cohérence, et - le point clé - prompting vs RAG vs fine-tuning (orienter vs ajouter des faits vs changer le comportement). Pour le travail réel, gardez des prompts précis, délimités et testés, et traitez chaque chaîne fournie par l'utilisateur comme non fiable. Faites des questions d'entraînement avec le guide de décision en 30 secondes ouvert, et quand vous en ratez une, relisez cette technique ici jusqu'à ce que la distinction soit nette.

Source : le guide d'examen et les domaines de questions du AWS Certified AI Practitioner (AIF-C01), et les références standard de prompt-engineering, en date de septembre 2026.