En clair
Rédiger un prompt, c’est passer une commande à un prestataire très compétent qui ne connaît rien de votre entreprise. Si vous lui dites « écris un message pour le client », il devine. Si vous précisez qui est le client, ce qui s’est passé, le ton souhaité et la longueur attendue, il vise juste. Le modèle ne lit pas dans vos pensées : il ne dispose que de ce qui est écrit.
Un prompt n’est pas forcément une question courte. Il peut contenir un rôle (« vous êtes relecteur juridique »), des documents à analyser, des exemples de réponses réussies et le format attendu. Dans une application, une partie de ces consignes est écrite à l’avance par les concepteurs et reste invisible pour l’utilisateur : c’est le prompt système.
Un exemple
Une équipe commerciale demande à un assistant : « Fais un résumé de cet appel. » Le résultat est correct mais peu utilisable : trop long, sans les prochaines étapes. Elle réécrit la consigne : le destinataire est le directeur commercial, le résumé tient en cinq lignes, il se termine par les engagements pris et leurs dates, et deux exemples de bons résumés sont joints.
Même modèle, même appel enregistré : la seconde version donne un résumé que l’équipe peut transmettre après une simple relecture.
Comment ça marche
Techniquement, le prompt est la totalité du texte placé dans la fenêtre de contexte avant que le modèle ne commence à générer : instructions système, messages de l’utilisateur, documents, exemples, résultats d’outils. Le modèle ne fait que prolonger cette séquence. Changer le prompt, c’est changer le point de départ du calcul, sans toucher aux paramètres du modèle.
Plusieurs techniques sont bien documentées. Fournir quelques exemples dans la consigne (few-shot) permet au modèle d’accomplir une tâche sans réentraînement, comme l’a montré l’article consacré à GPT-3 en 2020 1. Lui montrer des raisonnements par étapes (chain of thought) améliore ses résultats en arithmétique et en logique 2. Un recensement publié en 2024 dénombre 58 techniques de prompt pour les modèles de langage 3.
Les éditeurs publient leurs propres guides, qui insistent sur la clarté, les exemples, la structure de la consigne et, avant tout, sur la définition de critères de réussite et de tests 4. Avec les agents, la question s’élargit : il ne s’agit plus seulement de rédiger une consigne, mais de décider de tout ce qui entre dans le contexte. On parle alors d’ingénierie de contexte.
Ce que ça change pour une entreprise
Améliorer un prompt est le moyen le moins coûteux d’améliorer un résultat : pas d’entraînement, pas d’infrastructure, un effet immédiat. Les consignes qui fonctionnent méritent d’être traitées comme un actif : versionnées, documentées, partagées entre équipes et testées sur un jeu de cas représentatifs.
Les limites sont réelles. Un prompt ne donne pas au modèle une information qu’il n’a pas, et ne garantit pas un comportement : il le rend plus probable. Une consigne mise au point pour un modèle peut moins bien fonctionner avec le suivant. Et tout texte lu par le modèle peut contenir des instructions malveillantes : c’est le risque d’injection de prompt.
Idées reçues
- « Il existe des formules magiques. »
Les tournures miracles vieillissent vite. Ce qui dure : un contexte clair, un objectif précis, des exemples et des tests.
- « Un bon prompt suffit à empêcher les erreurs. »
Il les réduit sans les supprimer. Les usages sensibles demandent en plus des sources, des contrôles et une relecture.
- « Plus le prompt est long, mieux c’est. »
Ce qui compte est la pertinence. Des consignes contradictoires ou noyées dans le détail dégradent le résultat.
Sources
- Brown et al., « Language Models are Few-Shot Learners », 2020
- Wei et al., « Chain-of-Thought Prompting Elicits Reasoning in Large Language Models », 2022
- Schulhoff et al., « The Prompt Report: A Systematic Survey of Prompt Engineering Techniques », 2024
- Anthropic, documentation Claude, « Prompt engineering overview »