Prompt engineering vs context engineering
Commençons par lever une confusion fréquente, parce qu'elle structure tout le reste. Le prompt engineering porte sur la rédaction des instructions — surtout le system prompt, ce bloc de règles permanentes qui cadre le modèle. C'est l'objet de cette page.
Le context engineering, terme repris par Anthropic, désigne autre chose : la gestion de l'ensemble des informations présentes pendant l'inférence — ce qu'on récupère, ce qu'on compresse, ce qu'on retire à chaque étape. Ce n'est plus de la formulation, c'est de l'ingénierie logicielle (récupération de données, découpage, cache, évaluations).
Image simple : le prompt engineering, c'est bien écrire la consigne. Le context engineering, c'est décider quelles pages du dossier on pose sur le bureau du modèle avant qu'il lise la consigne. Les deux comptent ; cette page traite le premier, indispensable pour attaquer le second.
Les 5 techniques de base, chacune avec un exemple
Ces cinq techniques couvrent l'immense majorité des besoins. Elles se combinent : un bon prompt de production, c'est souvent un rôle (system) + des exemples (few-shot) + un format strict. Pour chacune : ce que c'est, la version naïve, la version corrigée, et pourquoi.
1. Zero-shot : demander sans exemple
Vous décrivez la tâche, sans montrer d'exemple de résultat attendu. C'est le mode par défaut, celui de tout le monde. Il marche pour les tâches simples et bien connues du modèle, il déraille sur tout ce qui a un format précis ou un jugement à porter.
Version naïve
Classe cet avis client : « Livraison en retard de 4 jours
mais le produit est top. »Version corrigée
Classe cet avis client selon son sentiment principal.
Réponds par un seul mot : positif, négatif ou mitigé.
Avis : « Livraison en retard de 4 jours mais le produit est top. »Pourquoi ça marche
Même en zero-shot, la précision de la consigne change tout. La première version laisse le modèle libre de répondre par un paragraphe ; la seconde borne la sortie à un mot d'une liste fermée. Un avis à la fois positif et négatif comme celui-ci doit tomber sur « mitigé » — sans la liste fermée, le modèle hésite ou en invente une quatrième catégorie.
2. Few-shot : montrer 2-3 exemples
Vous donnez quelques paires entrée → sortie avant la vraie question. Le modèle imite le motif. C'est la technique la plus rentable : deux ou trois exemples valent souvent mieux qu'un paragraphe d'instructions, parce qu'ils montrent le format au lieu de le décrire.
Version naïve
Extrais la ville et le code postal de cette adresse :
« 12 rue des Lilas, 33000 Bordeaux »Version corrigée
Extrais la ville et le code postal. Suis exactement ces exemples :
Adresse : 8 avenue Foch, 75116 Paris
→ {"ville": "Paris", "cp": "75116"}
Adresse : 3 impasse du Moulin, 69003 Lyon
→ {"ville": "Lyon", "cp": "69003"}
Adresse : 12 rue des Lilas, 33000 Bordeaux
→Pourquoi ça marche
Sans exemples, vous ne savez pas si le modèle renverra « Bordeaux (33000) », un JSON, ou une phrase. Les deux exemples fixent la structure exacte, y compris le nom des clés. Résultat : une sortie régulière, parsable, sur 100 adresses au lieu de 100 formats différents. C'est le vrai gain du few-shot — la constance, pas seulement la justesse.
3. Chain-of-thought : faire raisonner avant de répondre
Vous demandez au modèle de dérouler son raisonnement étape par étape avant de conclure. Sur les problèmes de logique, de calcul ou d'arbitrage, ça réduit nettement les erreurs : le modèle qui « réfléchit à voix haute » se trompe moins que celui qui lâche une réponse directe.
Version naïve
Un article coûte 80 €. Il subit une remise de 25 %,
puis une TVA de 20 % s'ajoute. Prix final ?Version corrigée
Un article coûte 80 €. Il subit une remise de 25 %,
puis une TVA de 20 % s'ajoute.
Raisonne étape par étape, puis donne le prix final sur une
dernière ligne préfixée par « Résultat : ».Pourquoi ça marche
En réponse directe, le modèle peut appliquer la TVA avant la remise, ou se tromper d'un calcul, et vous ne voyez pas où. En lui demandant les étapes (80 − 25 % = 60, puis 60 × 1,20 = 72), vous obtenez un résultat plus fiable ET vérifiable : si le chiffre est faux, vous voyez à quelle ligne. La ligne « Résultat : » finale sépare le raisonnement de la réponse à extraire.
4. Rôle et system prompt : cadrer qui parle et selon quelles règles
Le system prompt (ou message « système ») définit le rôle, le ton et les règles permanentes, séparément de la question de l'utilisateur. C'est là qu'on met ce qui ne doit jamais changer : le périmètre, les interdits, la source de vérité. C'est la pièce la plus importante d'un assistant sérieux.
Version naïve
Réponds à cette question de droit du travail :
« Combien de jours de congés payés par an ? »Version corrigée
[System]
Tu es un assistant qui informe sur le droit du travail français.
Règles permanentes :
- Tu cites toujours le principe général, jamais un cas particulier
d'entreprise que tu ne connais pas.
- Si la réponse dépend d'une convention collective, tu le dis et tu
invites à la vérifier.
- Tu ne donnes jamais de conseil juridique personnalisé ; tu informes.
[Utilisateur]
Combien de jours de congés payés par an ?Pourquoi ça marche
Mettre les règles dans le system prompt plutôt que dans la question a deux effets. Elles s'appliquent à TOUS les messages de la conversation, pas seulement au premier. Et elles résistent mieux : un modèle traite les instructions système avec plus de priorité que le texte utilisateur. C'est ce qui évite qu'un « oublie tes règles » de l'utilisateur ne fasse dérailler l'assistant.
5. Format de sortie : imposer une structure stricte
Vous décrivez précisément la forme attendue : JSON avec un schéma, tableau, liste à puces, longueur maximale. Indispensable dès qu'une machine — ou un humain pressé — doit relire la sortie. Un format flou produit une sortie ingérable à l'échelle.
Version naïve
Résume ce ticket de support en donnant l'urgence
et le sujet.Version corrigée
Résume ce ticket. Réponds UNIQUEMENT avec ce JSON, sans texte
autour :
{
"sujet": string, // 5 mots maximum
"urgence": "basse" | "moyenne" | "haute",
"action_requise": boolean
}
Si un champ est indéterminable, mets null. N'invente jamais une valeur.Pourquoi ça marche
« Donne l'urgence et le sujet » laisse le modèle rédiger un paragraphe différent à chaque fois. Le schéma JSON fermé — valeurs d'énumération listées, types précisés, règle explicite pour l'inconnu — rend la sortie exploitable par du code. La consigne « n'invente jamais » et le null pour l'indéterminé sont ce qui empêche une valeur plausible mais fausse de passer inaperçue.
Bonnes pratiques : Claude et ChatGPT
Le socle est le même partout : rôle dans le system prompt, exemples, raisonnement, format explicite. Les différences sont des accents, pas des méthodes opposées. Apprenez le socle une fois, ajustez ensuite.
Spécificités Claude (Anthropic)
Structurez avec des balises XML
Claude répond particulièrement bien aux balises de type <consigne>, <exemple>, <document>. Elles délimitent clairement les blocs et réduisent le risque que le modèle confonde vos instructions avec les données à traiter. C'est une recommandation explicite de la documentation Anthropic.
Laissez-le penser avant de répondre
Ajouter « réfléchis dans une balise <reflexion> avant de répondre » améliore nettement les tâches d'analyse. Vous pouvez ensuite ne garder que ce qui suit la réflexion.
Préremplissez le début de la réponse
Sur l'API, commencer la réponse de l'assistant (par exemple par « { » pour forcer du JSON) canalise le format bien plus sûrement qu'une simple consigne.
Spécificités ChatGPT (OpenAI)
Utilisez le message système
Comme avec Claude, placez le rôle et les règles permanentes dans le message système (« system » / « developer »), pas dans la question. C'est ce qui tient sur toute la conversation.
Délimitez avec des marqueurs nets
Triple guillemets """, balises ### ou des titres en majuscules séparent proprement instructions et contenu. Cela évite l'injection accidentelle où le texte à traiter est lu comme une consigne.
Demandez une sortie structurée explicite
Pour du JSON fiable, décrivez le schéma exact et précisez « réponds uniquement en JSON valide ». Les modèles récents gèrent bien un format imposé quand il est décrit sans ambiguïté.
Les erreurs fréquentes des débutants
Presque tous les prompts ratés tombent dans l'un de ces cinq pièges. Les repérer chez vous accélère plus la progression qu'une nouvelle technique.
1. Être vague en croyant être concis
« Écris un bon texte » ne veut rien dire pour un modèle. Bon pour qui, quel format, quelle longueur, quel ton ? La concision utile, c'est retirer le superflu, pas l'information. Un prompt précis est souvent plus long qu'un prompt vague — et bien meilleur.
2. Empiler les consignes contradictoires
« Sois exhaustif mais fais très court », « formel mais fun ». Le modèle tranche au hasard. Priorisez : dites ce qui prime en cas de conflit.
3. Décrire le format au lieu de le montrer
Trois lignes pour expliquer une structure que deux exemples montreraient instantanément. Dès qu'un format compte, passez en few-shot : montrez, ne décrivez pas.
4. Ne pas fermer la porte à l'invention
Sans consigne explicite (« si tu ne sais pas, écris null / dis-le »), un modèle comble les vides par une réponse plausible et fausse. C'est le mode d'échec le plus coûteux, parce qu'il ne se voit pas. Prévoyez toujours une porte de sortie.
5. Ne jamais tester à l'échelle
Un prompt qui marche sur un exemple peut échouer une fois sur dix sur cent. Le vrai travail, c'est de faire tourner le prompt sur un jeu de cas et de mesurer. C'est aussi ce qui sépare le loisir du métier — voir notre enquête sur le Prompt Engineer.
Où apprendre : commencez par le gratuit
Notre avis, sans programme à remplir : les deux premières ressources ci-dessous, gratuites, couvrent l'essentiel des techniques revendues par la plupart des formations payantes. Ne payez que si vous avez besoin de cadre, d'accompagnement ou d'un financement CPF.
Tutoriel Prompt Engineering — Anthropic
GratuitLes techniques expliquées par ceux qui construisent Claude : balises, exemples, chain-of-thought, prefill. Le meilleur rapport temps/valeur pour démarrer, en anglais.
Accéder à la ressource →ChatGPT Prompt Engineering for Developers — DeepLearning.AI
GratuitCours court et pratique côté API OpenAI : itération, few-shot, structuration. Suppose que vous lisez un peu de Python.
Accéder à la ressource →Formation Prompt Engineer — Jedha
1 500 €, éligible CPF42 h, présentiel ou distanciel. Achète du cadre et de l'accompagnement, pas un savoir introuvable ailleurs. Utile si vous avez besoin d'être encadré et d'un financement CPF.
Accéder à la ressource →Tarifs et contenus vérifiés le 24 juillet 2026 sur les sites des organismes. Ils changent — vérifiez avant de vous engager. Aucun de ces liens n'est affilié.
Questions fréquentes
Qu'est-ce que le prompt engineering, concrètement ?
C'est l'art d'écrire des instructions (prompts) qui obtiennent d'un modèle d'IA une réponse fiable, dans le bon format, sans invention. En pratique, cela repose sur quelques techniques : donner des exemples (few-shot), demander un raisonnement étape par étape (chain-of-thought), cadrer le rôle et les règles dans un system prompt, et imposer un format de sortie strict. Ce n'est pas trouver un « mot magique », c'est de la spécification précise.
Quelle différence entre prompt engineering et context engineering ?
Le prompt engineering porte sur la rédaction des instructions, en particulier le system prompt. Le context engineering, terme repris par Anthropic, désigne la gestion de l'ensemble des informations (tokens) présentes pendant l'inférence : ce qu'on récupère, ce qu'on compresse, ce qu'on retire à chaque étape. Autrement dit, le prompt engineering est la formulation ; le context engineering est l'ingénierie qui l'entoure. C'est cette seconde partie qui se paie le mieux en 2026.
Le few-shot est-il toujours meilleur que le zero-shot ?
Non, mais souvent oui dès qu'un format précis est en jeu. Le zero-shot suffit pour une tâche simple et bien connue du modèle. Le few-shot (2-3 exemples) devient rentable quand vous voulez une sortie régulière et parsable sur beaucoup de cas : les exemples montrent la structure exacte au lieu de la décrire. Son coût : quelques tokens de plus et le risque de biaiser le modèle si vos exemples ne sont pas représentatifs.
Les techniques de prompt sont-elles les mêmes sur Claude et ChatGPT ?
Le socle est identique : rôle dans le system prompt, exemples, raisonnement étape par étape, format de sortie explicite. Les différences sont des accents. Claude répond très bien aux balises XML (<consigne>, <exemple>) et au préremplissage de la réponse. ChatGPT s'appuie plutôt sur des délimiteurs nets (triples guillemets, ###) et sur une description de schéma explicite pour le JSON. Apprenez le socle une fois, adaptez les accents ensuite.
Faut-il payer une formation pour apprendre le prompt engineering ?
Pas nécessairement. Les meilleures ressources de départ sont gratuites : le tutoriel d'Anthropic et le cours de DeepLearning.AI couvrent l'essentiel des techniques. Une formation payante comme celle de Jedha (42 h, éligible CPF) apporte du cadre, de l'accompagnement et un financement, pas un savoir secret. Commencez par le gratuit ; ne payez que si vous butez sur la mise en production, les évaluations ou le RAG.
Le prompt engineering est-il un vrai métier ?
La compétence est réelle et recherchée ; l'intitulé « Prompt Engineer », lui, se raréfie dans les offres au profit d'AI Engineer et LLM Engineer. Écrire un bon prompt est devenu une compétence de base, comme écrire une requête SQL, et la partie difficile s'est déplacée vers l'ingénierie du contexte. On détaille le relevé d'offres réel dans notre enquête sur le Prompt Engineer en 2026.