Prompt Engineering : l'art de parler aux machines pour qu'elles vous écoutent

Ou : Pourquoi « sois précis » n’est pas une instruction précise

Un LLM fait ce que vous lui dites. Le problème, c’est que ce que vous lui dites et ce que vous voulez sont souvent deux choses différentes. Vous demandez « résume ce texte » et vous obtenez un paragraphe de 200 mots. Vous vouliez trois bullet points. Vous demandez « écris du code Python » et vous obtenez du code fonctionnel mais sans gestion d’erreurs. Vous vouliez du code production-ready.

Le prompt engineering est la discipline qui comble cet écart. C’est l’art (et de plus en plus la science) de formuler des instructions — des prompts — pour obtenir d’un modèle de langage le résultat que vous voulez réellement. Pas le résultat qu’il pense que vous voulez.

C’est la compétence la plus immédiatement utile de l’ère LLM. Pas besoin de savoir coder, pas besoin de comprendre les transformers ou les embeddings. Juste besoin de savoir formuler une demande claire — ce qui, ironiquement, est une compétence que la plupart des humains n’ont pas avec d’autres humains non plus.

Les techniques qui font la différence entre un prompt médiocre et un prompt qui marche

Zero-shot, few-shot, et la puissance de l’exemple

La distinction la plus fondamentale en prompt engineering :

Zero-shot — vous décrivez la tâche sans donner d’exemple. « Classe ce commentaire en positif ou négatif : “Ce restaurant est une catastrophe.” » Le modèle doit deviner le format, le niveau de détail, et le style de la réponse.

Few-shot — vous donnez quelques exemples avant de poser votre question. « Commentaire : “J’adore ce produit” → Positif. Commentaire : “Livraison en retard, emballage abîmé” → Négatif. Commentaire : “Ce restaurant est une catastrophe.” → ? » Le modèle reproduit le pattern.

La différence de qualité entre zero-shot et few-shot est souvent spectaculaire. Deux ou trois exemples suffisent généralement. Le modèle n’apprend pas au sens du machine learning — il n’ajuste pas ses paramètres. Il utilise les exemples comme contexte pour comprendre ce que vous attendez. C’est de l’apprentissage dans la fenêtre de contexte, pas dans les poids¹.

Chain-of-thought : forcer le modèle à réfléchir

Le chain-of-thought (CoT) est peut-être la technique de prompt engineering la plus puissante. L’idée : demander au modèle d’expliquer son raisonnement étape par étape avant de donner sa réponse finale.

Sans CoT : « Combien font 17 × 23 ? » → Le modèle donne un nombre (parfois faux).

Avec CoT : « Combien font 17 × 23 ? Explique ton raisonnement étape par étape. » → Le modèle décompose : 17 × 20 = 340, 17 × 3 = 51, 340 + 51 = 391. Le résultat est plus souvent correct.

Pourquoi ça marche ? Parce qu’un LLM génère du texte de gauche à droite, un token à la fois. Quand il doit répondre directement, il « saute » au résultat sans calcul intermédiaire. Quand on le force à écrire les étapes intermédiaires, chaque étape fournit du contexte pour la suivante. Le raisonnement écrit guide la génération — les tokens intermédiaires ne sont pas du décor, ils sont du calcul.

Le system prompt : la constitution du modèle

Le system prompt est l’instruction initiale qui définit le comportement du modèle pour toute la conversation. C’est la différence entre « tu es un assistant général » et « tu es un expert en droit fiscal français, tu réponds de façon concise, et tu cites les articles de loi pertinents ».

Un bon system prompt inclut :

• Le rôle : qui est le modèle, quelle est son expertise
• Le format : comment structurer les réponses (longueur, style, markdown)
• Les contraintes : ce qu’il ne doit PAS faire (inventer des sources, donner des avis médicaux)
• Le public : à qui il s’adresse (expert, débutant, manager)

La différence entre un system prompt de 3 lignes et un system prompt de 30 lignes bien pensé peut transformer un chatbot médiocre en outil professionnel — sans changer de modèle, sans fine-tuning, sans infrastructure.

Les anti-patterns : ce qui ne marche pas

« Sois précis. » — Imprécis par définition. Précis comment ? Sur quoi ? Dans quel format ?

« Fais de ton mieux. » — Le modèle fait toujours de son mieux. Lui demander de mieux faire, c’est comme demander à un micro-ondes de chauffer « avec plus de passion ».

Des prompts de 5 000 mots — Plus le prompt est long, plus le modèle a de chances de perdre le fil. Les instructions au milieu d’un prompt très long sont souvent ignorées (le problème lost in the middle).

Les menaces — « Si tu te trompes, je perds mon emploi » ne rend pas le modèle plus précis. Il ne comprend pas la pression sociale. Et lui donner un « pourboire » virtuel non plus.

Le dialogue du prompt itératif

DevOps Dave : Le chatbot donne des réponses trop longues. J’ai mis dans le system prompt « sois concis ».

Security Sarah : Et ?

DevOps Dave : Toujours des pavés de 500 mots.

Security Sarah : Remplace « sois concis » par « réponds en 2-3 phrases maximum, utilise des bullet points si nécessaire ». Concret, mesurable.

DevOps Dave : … Ça marche beaucoup mieux.

Security Sarah : Le prompt engineering, c’est pas de la littérature. C’est de l’ingénierie. Spécifie ce que tu veux comme tu spécifierais une API : avec des contraintes explicites, pas des adjectifs vagues.

Tableau récapitulatif

Le mot de la fin

Le prompt engineering a un problème de perception. Vu de l’extérieur, ça ressemble à « taper des trucs dans ChatGPT ». Vu de l’intérieur, c’est une discipline d’ingénierie avec ses techniques, ses patterns, ses anti-patterns, et un impact mesurable sur la qualité des résultats.

La bonne nouvelle : c’est accessible. Pas besoin de GPU, pas besoin de dataset, pas besoin de maths. La mauvaise nouvelle : c’est fragile. Un prompt qui marche parfaitement avec GPT-4 peut échouer avec Claude. Un prompt qui marchait la semaine dernière peut cesser de fonctionner après une mise à jour du modèle. C’est de l’ingénierie sur un substrat instable.

C’est pour ça que le prompt engineering n’est pas une destination — c’est un processus itératif. Tester, observer, ajuster, retester. Comme tout ce qui fonctionne en ingénierie.