Le prompt engineering souffre d'un problème de réputation : trop de contenu vend des « formules magiques » sans jamais en vérifier l'effet. En pratique, une poignée de techniques ont un effet mesurable et reproductible — le reste est du bruit ou dépend fortement du modèle utilisé.
Les techniques qui tiennent
| Technique | Effet mesuré |
|---|---|
| Rôle système clair | Fort — cadre le registre et les limites, réduit la dérive |
| Few-shot (2-3 exemples) | Fort sur le format de sortie, faible sur le raisonnement |
| Décomposition en étapes explicites | Fort sur les tâches multi-étapes ambiguës |
| Sortie structurée (JSON schema) | Fort — élimine une classe entière de bugs de parsing |
| "Sois précis / réfléchis bien" | Négligeable — l'instruction seule ne change rien sans structure |
L'exemple qui change tout : la sortie structurée
// Mauvais : demande une sortie libre puis parse au petit bonheur
"Liste les bugs trouvés dans ce code."
// Meilleur : contraint le format dès le prompt
"Retourne un JSON de la forme :
{ "bugs": [{ "ligne": int, "gravite": "faible|moyenne|haute", "description": string }] }"Le détail des pièges de parsing et de validation est couvert dans JSON fiable depuis un LLM — la contrainte de format se décide au niveau du prompt, sa fiabilité se garantit au niveau du code appelant.
Ce qui n'est pas du prompt engineering
Deux sujets adjacents qu'on confond souvent avec le prompt engineering lui-même : la gestion des versions de prompt en prod (Prompt versioning en prod) et la défense contre l'injection de contenu malveillant dans le contexte (Injection de prompt : défense). Le prompt engineering optimise ce qu'on écrit ; ces deux sujets gèrent ce qu'on écrit une fois que ça tourne en prod, face à un input qu'on ne contrôle pas.
FAQ
Le prompt engineering va-t-il disparaître avec des modèles plus "intelligents" ?
Le besoin de formulations magiques diminue, mais la structuration (sortie contrainte, décomposition explicite) reste utile quel que soit le niveau du modèle — elle réduit la variance, pas seulement la difficulté de la tâche.
Faut-il toujours utiliser du few-shot ?
Non, seulement quand le format de sortie est ambigu sans exemple. Sur une tâche déjà bien cadrée par un schema JSON, des exemples ajoutent surtout des tokens sans gain.
Le chain-of-thought explicite aide-t-il toujours ?
Non, il aide sur des tâches de raisonnement multi-étapes mais ajoute coût et latence sans bénéfice sur des tâches d'extraction ou de classification simples.
