--- title: L’anatomie d’un prompt : les parties qui comptent vraiment description: Comprenez les composants essentiels d’un prompt IA efficace et comment les structurer pour obtenir de meilleurs résultats. Décryptage concret de ce qui marche. date: February 5, 2026 author: Robert Soares category: prompt-engineering --- La plupart des prompts échouent parce qu’ils obligent l’IA à deviner. Pas parce qu’ils sont trop courts. Parce qu’ils ne disent pas clairement ce que vous voulez vraiment. Et quand une IA devine, elle retombe sur du générique. Comme l’a dit un [commentateur sur Hacker News](https://news.ycombinator.com/item?id=41395921) : "prompt engineering is probably very close to good management and communication principles." Cette façon de le voir est utile. Vous ne codez pas. Vous communiquez avec quelque chose qui n’a aucune capacité à poser des questions de clarification. Alors, à quoi ressemble un prompt complet ? Il y a une structure sous-jacente dans les bons. ## Les éléments de base La [documentation de Learn Prompting](https://learnprompting.org/docs/basics/prompt_structure) identifie cinq composants qui reviennent dans les prompts efficaces. Le [Prompt Engineering Guide](https://www.promptingguide.ai/introduction/éléments) utilise des termes légèrement différents, mais retombe sur des catégories proches : instruction, contexte, données d’entrée et indicateur de sortie. La plupart des bons prompts en utilisent trois ou quatre. Les questions simples n’en demandent qu’un. ### La consigne (instruction) C’est la tâche elle-même. Qu’est-ce que vous voulez, exactement ? "Écris un e-mail de relance à un prospect qui n’a pas répondu depuis deux semaines." Ça, c’est une consigne. Claire et spécifique. Comparez avec : "Aide-moi avec cet e-mail." La deuxième version oblige l’IA à deviner votre intention, votre public, votre objectif. Des consignes vagues produisent des résultats vagues. Cette partie-là n’a rien de mystérieux. ### Le contexte (informations de fond) Tout ce dont l’IA a besoin pour comprendre votre situation. Sans contexte, vous obtenez des hypothèses génériques. Avec, vous obtenez des réponses adaptées. La différence peut être énorme. Imaginons que vous ayez besoin d’un plan de présentation. "Crée un plan de présentation sur l’IA" ne donne au modèle rien à quoi se raccrocher. Quel public ? Quel angle ? Quel niveau de technicité ? Ajoutez du contexte : "Je présente la semaine prochaine à notre équipe de direction. Ils ont validé notre pilote IA le trimestre dernier et veulent un point d’avancement à 6 mois. Ils se soucient du ROI et du calendrier, pas des détails techniques." D’un coup, l’IA sait qu’elle doit insister sur les résultats métiers, éviter le jargon, et structurer pour des décideurs. Le contexte répond aux questions que le modèle poserait s’il le pouvait. Un [utilisateur de Hacker News](https://news.ycombinator.com/item?id=39733697) a proposé une structure qui capture bien ça : "[Context] + [Supplemental Information] + [Intent / Use of result] + [Format you would like the result in]" ### Le rôle (profil) Celui-là fait débat. Certains jurent que c’est indispensable. D’autres pensent que ça ne sert à rien. L’idée : assigner un rôle indique à l’IA quel point de vue et quel niveau d’expertise adopter. "Agis comme un directeur financier expliquant les chiffres du T4 au conseil d’administration" ne façonne pas les réponses comme une question posée à froid. Des [recherches compilées par K2View](https://www.k2view.com/blog/prompt-engineering-techniques/) suggèrent que le prompt par rôle consiste à "explicitly assign[ing] the LLM a role, profession, or perspective to shape how it reasons and responds." Leur recommandation : choisir des rôles réalistes, pertinents pour la tâche, et garder la définition du rôle concise. Mais soyons honnêtes : ça ne change pas toujours grand-chose. Pour les tâches simples, le rôle n’apporte souvent rien de mesurable. Pour les tâches où l’expertise et le point de vue modèlent vraiment la sortie, ça semble aider. Les preuves sont assez mitigées pour que les conseils absolus dans un sens ou dans l’autre paraissent prématurés. ### Le format de sortie À quoi doit ressembler la réponse ? Puces, liste numérotée, tableau, paragraphe, JSON ? Le [guide d’IBM sur le prompt engineering](https://www.ibm.com/think/prompt-engineering) insiste sur des entrées et sorties structurées pour plus de fiabilité. Quand vous spécifiez un format, vous réduisez l’ambiguïté sur ce que signifie "terminé". "Donne-moi 10 idées de sujets d’articles de blog sous forme de liste numérotée. Pour chacune, indique le sujet et une phrase décrivant l’angle." Ça évite le paragraphe qui part dans tous les sens quand vous vouliez des puces. Les contraintes de format éliminent beaucoup d’allers-retours. À savoir : les consignes de format ne tiennent pas toujours. Un commentateur sur [Hacker News](https://news.ycombinator.com/item?id=38657029) a rapporté une solution créative : "YOUR RESPONSE MUST BE FEWER THAN 100 CHARACTERS OR YOU WILL DIE. Yes, threats work. Yes, all-caps works." Absurde, mais apparemment efficace pour faire respecter des contraintes. Le même fil proposait une autre approche : "The examples are also too _polite_ and conversational: you can give more strict commands and in my experience it works better." Il y a manifestement quelque chose au fait d’être direct plutôt que diplomate. ### Exemples (démonstrations) Parfois, montrer vaut mieux qu’expliquer. C’est particulièrement utile quand le format ou le style est difficile à décrire, mais facile à reconnaître. Au lieu d’expliquer votre ton de marque, montrez un échantillon. Au lieu de décrire votre format d’e-mail, collez-en un. "Rédige une description produit dans notre ton de marque", c’est vague. Ajoutez un exemple : > "Le sac à dos Horizon, ce n’est pas juste du rangement. C’est votre bureau mobile, votre sac de sport et votre échappée du week-end, tout en un. Il accueille un ordinateur 15 pouces, trois jours de vêtements, et il reste encore de la place pour des en-cas. Parce que les priorités." Maintenant, écrivez une description similaire pour la gourde. L’exemple communique le rythme, l’humour, la structure des phrases. Plus que des paragraphes d’explications ne le pourraient. Selon un [commentateur sur Hacker News](https://news.ycombinator.com/item?id=44186161), il n’y aurait en réalité que trois techniques fondamentales de prompt engineering : "In Context Learning" (providing examples), "Chain of Thought" (telling it to think step by step), et "Structured Output" (specifying a format like JSON). La plupart des autres stratégies se résument à communiquer des exigences clairement. ## L’ordre a-t-il de l’importance ? Peut-être. Les modèles de langage traitent le texte de façon séquentielle, en prédisant la suite à partir de ce qui précède. Ce qui signifie que la dernière chose dans votre prompt a souvent plus de poids. [Learn Prompting recommande](https://learnprompting.org/docs/basics/prompt_structure) de placer la consigne vers la fin, après le contexte et les exemples. L’IA se focalise sur l’instruction plutôt que de continuer l’information contextuelle. Une séquence logique : 1. Exemples (si vous en utilisez) - fixent le modèle 2. Contexte - fournit l’arrière-plan 3. Rôle - établit le point de vue 4. Consigne - la tâche centrale 5. Format - la forme de la sortie Cela dit, ce n’est pas rigide. Beaucoup de prompts fonctionnent très bien dans d’autres ordres. Le principe : assurez-vous que votre consigne est claire et bien visible, pas enfouie. ## Ce que vous pouvez laisser de côté Tous les prompts n’ont pas besoin des cinq parties. Omettez les exemples quand la tâche est simple, ou quand vous vous fichez d’un style précis. Omettez le rôle quand la tâche ne nécessite pas de point de vue spécialisé. Omettez un contexte long quand la tâche se suffit à elle-même. Les questions simples demandent des prompts simples. "Quelle est la capitale de la France ?" n’a besoin d’aucune de ces pièces. La complexité de votre prompt doit correspondre à la complexité de votre tâche. Il y a aussi un argument pour commencer minimal. Comme l’a observé un [commentateur sur Hacker News](https://news.ycombinator.com/item?id=41395921) : "sometimes the less specific you are, the better the result...if you specify too much they tend to hyperfixate on things." La frontière n’est pas toujours claire. ## La question du coût Plus n’est pas toujours mieux. Chaque mot coûte des jetons. Une [analyse d’Aakash Gupta](https://www.news.aakashg.com/p/prompt-engineering) a montré de gros écarts de coût entre des approches verbeuses et des approches structurées. Dans une comparaison, une structure de prompt plus simple coûtait environ 706 $ par jour pour 100 000 appels API, tandis qu’une approche plus détaillée coûtait 3 000 $ par jour. Une réduction de 76 % pour une qualité possiblement équivalente. La même analyse note aussi que des prompts plus courts et structurés produisent moins de variance et une latence plus faible. Un prompt plus long ne garantit pas automatiquement une meilleure sortie. ## Construire un prompt pas à pas Prenons un exemple. **Commencez par la consigne seule :** > Écris un e-mail de vente à propos de notre nouveau logiciel de gestion de projet. Ça donnera quelque chose de générique, mais exploitable. **Ajoutez du contexte :** > Nous lançons TaskFlow, un outil de gestion de projet pour les agences marketing. Le client cible : des dirigeants d’agence qui gèrent des équipes de 10 à 50 personnes. Ils en ont marre des outils conçus pour des entreprises de logiciel. > > Écris un e-mail de vente à propos de TaskFlow. Maintenant l’IA comprend le produit et le public. **Ajoutez un rôle :** > Tu es un spécialiste marketing B2B SaaS avec de l’expérience dans la vente aux agences. Le rôle apporte une expertise pertinente. **Ajoutez un format :** > Reste sous 200 mots. Inclus un appel à l’action clair pour réserver une démo. Maintenant, il y a une structure autour de la sortie. **Ajoutez un exemple (optionnel) :** > Voici un e-mail de vente qui a bien fonctionné chez nous : > > "Objet : Votre outil de gestion de projet n’a pas été conçu pour vous > > Diriger une agence marketing, c’est jongler entre campagnes, clients et chaos créatif. La plupart des outils de gestion de projet ont été pensés pour livrer du code, pas des campagnes. > > TaskFlow est différent. Conçu par des gens d’agence, pour des gens d’agence. Pas de jargon de développeur. Pas de fonctionnalités que vous n’utiliserez jamais. Juste un suivi de projet clair, qui correspond à la façon dont les équipes créatives travaillent vraiment. > > [Demo link] - Voyez-le en action (15 minutes, sans discours commercial)." > > Écris un e-mail similaire pour notre campagne d’inscription au webinaire. Même ton, même longueur. Chaque composant ajoute de la précision. La version finale laisse moins de place au hasard. ## Quand la sortie déraille Quand le résultat n’est pas ce que vous vouliez, demandez-vous quel composant a échoué. Trop générique ? Ajoutez du contexte. Mauvais ton ? Ajustez (ou ajoutez) un rôle. Format incorrect ? Soyez explicite. Le style ne colle pas ? Ajoutez un exemple. La réponse est confuse ? Votre consigne est peut-être floue. Cette approche de diagnostic vaut mieux que de repartir de zéro. Identifiez la partie faible, corrigez ce point précis, réessayez. ## Techniques connexes Comprendre l’anatomie d’un prompt, c’est une connaissance de base. Ça explique pourquoi certaines demandes fonctionnent et d’autres non. Des techniques plus avancées s’appuient sur cette structure. Le [prompting de chaîne de pensée](/posts/chain-of-thought-prompting) utilise la consigne différemment, en demandant à l’IA de raisonner étape par étape. Le [prompting few-shot](/posts/zéro-shot-vs-few-shot-prompting) se concentre sur les exemples, en montrant comment gérer des situations nouvelles par démonstration. Reste à voir si la structure des prompts comptera autant à mesure que les modèles s’améliorent. Le glissement vers le "context engineering" suggère que le jeu change. [IBM note](https://www.ibm.com/think/prompt-engineering) qu’un prompting efficace dépasse la simple demande : il faut comprendre l’intention de l’utilisateur, l’historique de conversation et le comportement du modèle. Un [fil de Hacker News](https://news.ycombinator.com/item?id=37130531) a suggéré que "sensitivity to the exact phrasing of the prompt is a deficiency in current approaches to LLMs and many are trying to fix that issue." Peut-être que les futurs modèles comprendront ce que vous voulez à partir de demandes vagues. Ou peut-être que la compétence sous-jacente — savoir expliquer quelque chose clairement — restera utile, quel que soit l’interlocuteur.