Curriculum
Cours: Prompt Engineering
Connexion
Text lesson

Module 02 — Les 4 piliers d’un prompt efficace

Module 02 — Les 4 piliers d’un prompt efficace


L’illusion de la simplicité

Il y a une croyance très répandue chez les nouveaux utilisateurs de l’IA générative : l’idée que la qualité d’une réponse dépend principalement de la qualité du modèle. Si la réponse est décevante, c’est que l’IA n’est pas assez bonne. Si elle est excellente, c’est que l’IA est impressionnante.

Cette croyance est confortable. Elle décharge l’utilisateur de toute responsabilité. Et elle est presque toujours fausse.

La vérité, que vous allez intégrer définitivement au fil de ce module, c’est que la qualité d’une réponse est le reflet direct de la qualité du prompt qui l’a produite. Le modèle, lui, fait toujours de son mieux avec ce qu’on lui donne. Si vous lui donnez peu, il comble les vides avec des suppositions. Si vous lui donnez beaucoup, et bien, il produit quelque chose de remarquable.

Ce module vous présente les quatre piliers sur lesquels repose tout prompt efficace. Pas des règles arbitraires — des principes logiques, chacun avec une raison d’être claire, chacun illustré par des exemples que vous pouvez comparer et évaluer par vous-même.


Pilier 1 — L’instruction : dites exactement ce que vous voulez

Le problème du verbe vague

Tout prompt commence par une instruction. C’est l’ordre que vous donnez au modèle, l’action que vous lui demandez d’accomplir. Et c’est précisément là que la majorité des utilisateurs commettent leur première erreur : ils choisissent des verbes vagues.

“Parle-moi de la stratégie digitale.” “Dis-moi quelque chose sur le leadership.” “Fais un truc sur le changement climatique.”

Ces instructions sont des invitations à l’improvisation. Le modèle va produire quelque chose — il produit toujours quelque chose — mais ce quelque chose sera générique, prévisible, et peu utile. Parce que vous ne lui avez pas dit ce que vous vouliez vraiment faire de cette information.

Comparez maintenant avec des instructions précises :

“Explique en 5 étapes comment élaborer une stratégie de contenu digital pour une PME sans équipe marketing dédiée.” “Analyse les trois qualités de leadership les plus citées dans la littérature managériale des dix dernières années, et explique pourquoi elles ont émergé dans ce contexte précis.” “Résume en un paragraphe les principaux mécanismes du changement climatique pour un public de lycéens qui découvrent le sujet.”

Vous voyez la différence ? Dans chaque cas, un verbe d’action précis — expliquer, analyser, résumer — déclenche dans le modèle un registre cognitif spécifique. “Expliquer” appelle une structure pédagogique. “Analyser” appelle un regard critique et distancé. “Résumer” appelle la synthèse et la sélection. Ce n’est pas anecdotique : le choix du verbe conditionne l’architecture entière de la réponse.

Le catalogue des verbes efficaces

Il existe une famille de verbes qui fonctionnent particulièrement bien avec les LLM, parce qu’ils désignent des tâches cognitives précises et délimitées. En voici quelques-uns, avec leurs usages typiques.

Expliquer est votre meilleur allié pour tout ce qui est pédagogique. Il invite le modèle à décomposer, à clarifier, à rendre accessible. C’est le verbe de l’enseignant.

Analyser convoque le regard critique. Il demande au modèle d’aller au-delà de la description, d’identifier des patterns, de peser des facteurs, d’évaluer des causes et des conséquences.

Rédiger signale que vous voulez un texte fini, prêt à l’emploi. Un email, un article, un discours, une fiche produit. Le modèle sait qu’il ne doit pas vous donner un plan ou des suggestions — il doit livrer le texte lui-même.

Comparer structure la réponse autour de deux ou plusieurs éléments mis en parallèle. C’est le verbe de la décision éclairée, du choix argumenté.

Lister produit une énumération directe et sans détour. Efficace quand vous voulez de la densité d’information sans développement.

Résumer commande la synthèse. Il signale que vous avez déjà de l’information et que vous voulez l’essentiel distillé.

Formuler demande une reformulation, souvent dans un autre registre ou pour un autre public.

Évaluer invite le modèle à porter un jugement argumenté sur quelque chose — une idée, une stratégie, un texte, un plan.

Choisir le bon verbe, c’est déjà faire la moitié du travail.

La précision au-delà du verbe

L’instruction ne se résume pas au verbe. Elle inclut aussi la portée de la tâche — son périmètre exact. Combien d’éléments ? Quelle profondeur ? Quel angle ?

“Explique la photosynthèse” est une instruction. “Explique les trois étapes principales de la photosynthèse en utilisant des termes accessibles à un enfant de douze ans, sans jargon scientifique, et en terminant par une question qui invite à la réflexion” est une instruction précise.

La différence de résultat entre ces deux formulations est abyssale. Et pourtant, l’effort supplémentaire pour passer de l’une à l’autre ne vous prend que trente secondes.


Pilier 2 — Le contexte : donnez au modèle ce qu’il ne peut pas deviner

Le consultant qui ne vous connaît pas

Voici l’image la plus utile pour comprendre pourquoi le contexte est indispensable. Imaginez que vous venez d’embaucher un consultant extraordinaire — brillant, polyvalent, au fait des dernières avancées dans presque tous les domaines. Mais ce consultant arrive dans vos locaux sans rien savoir de vous. Il ne connaît pas votre secteur, votre histoire, vos clients, vos contraintes, votre culture d’entreprise, vos priorités du moment. Il ne sait même pas si vous êtes une startup de trois personnes ou une multinationale de cinquante mille employés.

Si vous lui dites simplement “faites-moi une analyse de notre situation”, que va-t-il faire ? Il va improviser. Il va supposer. Il va produire quelque chose de raisonnablement pertinent pour une situation moyenne, une situation qui n’est probablement pas la vôtre.

C’est exactement ce qui se passe quand vous donnez un prompt sans contexte. Le modèle comble les vides avec des suppositions statistiquement raisonnables — et ces suppositions ne collent presque jamais parfaitement avec votre réalité.

Les cinq dimensions du contexte

Il n’existe pas de liste universelle de ce qu’il faut inclure dans un contexte, parce que cela dépend entièrement de la tâche. Mais il y a cinq dimensions qui reviennent systématiquement et qui, lorsqu’elles sont précisées, transforment radicalement la qualité de la réponse.

Qui êtes-vous ? Votre rôle, votre position, votre domaine d’expertise. Le modèle calibre son langage, son niveau de détail et ses références en fonction de qui vous êtes. Un prompt écrit par un médecin qui s’adresse à ses confrères n’appelle pas le même registre qu’un prompt écrit par un patient qui découvre un diagnostic.

À qui est destiné le résultat ? Le public final change tout. Un document destiné à un comité de direction n’a pas la même structure qu’une note destinée à une équipe opérationnelle. Un email à un client fidèle n’a pas le même ton qu’un email à un prospect froid. Préciser l’audience cible permet au modèle de calibrer précisément son niveau de langage, son degré de technicité et sa façon de structurer l’information.

Quel est l’enjeu de la situation ? Pourquoi avez-vous besoin de ce texte, de cette analyse, de cette réponse maintenant ? Quel problème cherchez-vous à résoudre ? Quelle décision éclairez-vous ? Cette information donne au modèle une direction stratégique. Sans elle, il peut répondre correctement à votre question tout en passant à côté de ce dont vous avez vraiment besoin.

Quelles sont vos contraintes ? Budget, délai, longueur, format imposé, politique interne, sensibilités particulières. Les contraintes ne sont pas des limites arbitraires — ce sont des informations précieuses qui permettent au modèle de produire quelque chose de réellement utilisable dans votre monde réel.

Quel est le contexte factuel pertinent ? Les données, les chiffres, les noms propres, les événements récents, les décisions déjà prises. Tout ce que le modèle ne peut pas deviner mais qui est indispensable pour traiter votre demande avec précision.

La règle d’or du contexte

Plus le contexte est précis et pertinent, meilleure est la réponse. Mais attention au mot “pertinent”. Il ne s’agit pas de noyer le modèle dans des informations superflues. Il s’agit de sélectionner ce qui a un impact direct sur la qualité de la réponse attendue.

Une façon simple de tester la pertinence d’un élément de contexte : si je retire cette information, est-ce que la réponse pourrait être significativement différente ou moins adaptée ? Si oui, gardez-la. Si non, supprimez-la.

Voici un exemple qui illustre la puissance du contexte. Même instruction, deux niveaux de contexte très différents.

Version sans contexte : “Rédige un email de demande de délai.”

Version avec contexte : “Je suis chef de projet dans une agence web de quinze personnes. Nous travaillons depuis six mois avec un client important, directeur général d’une PME de quarante salariés dans le secteur agroalimentaire. La relation est bonne, fondée sur la confiance mutuelle. Nous devons lui livrer une refonte de site le 3 du mois prochain, mais nous avons découvert hier un problème technique majeur dans l’intégration de son système de paiement. Nous aurons besoin de dix jours supplémentaires. Rédige un email professionnel, chaleureux et rassurant pour lui annoncer ce délai tout en maintenant sa confiance.”

La première version produit un email générique et impersonnel, utilisable dans zéro situation concrète. La seconde produit un email que vous pouvez envoyer presque tel quel, en changeant juste les noms propres. C’est la même instruction. C’est le contexte qui fait toute la différence.


Pilier 3 — Le format de sortie : décidez de la forme avant d’obtenir le fond

Pourquoi le format est sous-estimé

Si vous interrogez des utilisateurs d’IA sur ce qui rend un prompt efficace, la plupart mentionneront la clarté de l’instruction et l’importance du contexte. Très peu mentionneront spontanément le format de sortie. Et pourtant, c’est l’un des leviers les plus immédiatement impactants que vous puissiez actionner.

La raison est simple. Un modèle de langage, livré à lui-même, va choisir un format par défaut — généralement un format qui lui semble raisonnablement adapté à la question posée. Ce format par défaut est parfois exactement ce que vous vouliez. Mais très souvent, il ne l’est pas. Et l’inadéquation du format peut rendre inutilisable une réponse qui était pourtant juste sur le fond.

Imaginez que vous demandiez au modèle de vous aider à comparer trois offres logicielles. Sans instruction de format, il va probablement vous produire trois paragraphes descriptifs, l’un après l’autre. Ce n’est pas faux. Mais ce n’est pas ce dont vous avez besoin pour comparer efficacement. Ce dont vous avez besoin, c’est d’un tableau avec des critères en lignes et les trois logiciels en colonnes, pour voir les différences en un coup d’œil.

Spécifier le format, c’est décider de la forme de l’information avant même de l’obtenir. C’est une façon de penser en termes d’usage : à quoi ce résultat va-t-il me servir ? Comment vais-je l’utiliser ? Dans quel contexte vais-je le partager ?

Les formats les plus utiles

Le tableau est votre meilleur outil de comparaison. Il structure l’information de façon visuelle, facilite la lecture transversale et met en évidence les différences. Il est particulièrement adapté pour comparer des options, synthétiser des données ou organiser des informations avec plusieurs dimensions.

La liste numérotée est l’outil des instructions séquentielles et des classements. Elle impose un ordre, ce qui est précieux quand la séquence a une importance — une procédure à suivre, des priorités à respecter, des étapes chronologiques.

La liste à puces est plus souple que la liste numérotée. Elle organise sans hiérarchiser. Elle est idéale pour les récapitulatifs, les ensembles d’éléments de même niveau d’importance, ou les listes d’idées sans ordre imposé.

La prose narrative est le format de l’analyse, du rapport, de l’argumentation. Elle permet la nuance, le lien entre les idées, le développement d’une pensée. Elle est adaptée aux documents destinés à être lus de bout en bout plutôt que scannés visuellement.

Le JSON ou le format structuré est le format de l’automatisation. Si le résultat doit être traité par un programme, intégré dans une base de données ou alimenter un autre système, c’est le format à spécifier. Sa précision est sa force.

Le format question-réponse est utile pour les FAQ, les documents de support, ou toute situation où le résultat sera présenté sous forme de dialogue ou de Q&A.

Comment spécifier le format

La spécification du format peut être intégrée naturellement dans l’instruction ou placée à la fin du prompt dans une section dédiée. Ce qui compte, c’est qu’elle soit explicite et sans ambiguïté.

Quelques formulations efficaces :

“Réponds sous forme d’un tableau avec trois colonnes : l’avantage, l’inconvénient, et un exemple concret.”

“Présente ta réponse sous forme de liste numérotée de cinq points, chaque point en une phrase unique.”

“Rédige en prose continue, sans bullet points ni titres, sur un maximum de trois paragraphes.”

“Formate ta réponse en JSON valide avec les clés suivantes : titre, description courte, public cible, et niveau de difficulté.”

“Structure ta réponse avec un titre H2 pour chaque grande partie, et des bullet points pour les sous-éléments.”

Vous pouvez même spécifier la longueur avec précision : “en exactement deux paragraphes”, “en moins de cent mots”, “en cinq à huit lignes”. Cette précision peut sembler anecdotique, mais elle élimine l’un des problèmes les plus fréquents avec les LLM : la tendance à produire des réponses soit trop longues soit trop courtes par rapport à l’usage prévu.

Format et destination sont liés

Une règle pratique : réfléchissez toujours à la destination du résultat avant de spécifier le format. Où va atterrir ce texte ? Dans un email ? Dans une présentation ? Dans un tableau de bord ? Dans un rapport imprimé ? Dans un outil de gestion de projet ? La réponse à cette question dicte naturellement le format le plus adapté.

Un résumé destiné à être lu sur mobile appelle des phrases courtes et des bullet points. Un rapport destiné à un comité de direction appelle une prose structurée avec des titres. Un contenu destiné à alimenter une base de données appelle du JSON. Laissez la destination guider le format.


Pilier 4 — Les exemples : montrez plutôt que d’expliquer

Pourquoi un exemple vaut mille mots

Il existe une limite à ce que les mots peuvent faire lorsqu’il s’agit de décrire précisément ce que vous attendez. Vous pouvez passer cinq minutes à expliquer le ton que vous souhaitez — chaleureux mais professionnel, décontracté mais sérieux, clair mais nuancé. Le modèle va faire de son mieux pour interpréter ces descriptions. Mais il va nécessairement combler les zones grises avec ses propres suppositions.

La façon la plus efficace de contourner ce problème est de ne pas expliquer — de montrer. C’est le principe du few-shot learning, et c’est l’une des techniques les plus puissantes de tout le prompt engineering.

L’idée est simple : avant de poser votre question, vous donnez au modèle un ou plusieurs exemples de la forme que vous attendez. Entrée → sortie, question → réponse, texte original → texte transformé. Le modèle identifie le pattern dans vos exemples et l’applique à votre cas réel, avec une précision que vous n’auriez jamais obtenue avec des descriptions verbales.

La mécanique du few-shot

Le terme few-shot désigne simplement le nombre d’exemples que vous fournissez. Zero-shot signifie aucun exemple — vous faites confiance aux capacités générales du modèle. One-shot signifie un seul exemple. Few-shot signifie quelques exemples, généralement entre deux et cinq.

Chacune de ces approches a sa place.

Le zero-shot convient parfaitement aux tâches simples et bien définies, pour lesquelles le modèle dispose déjà de tout ce dont il a besoin dans ses données d’entraînement. “Traduis cette phrase en anglais.” “Corrige les fautes de grammaire dans ce texte.” Ces tâches sont si courantes et si bien représentées dans les données d’entraînement que des exemples supplémentaires n’apportent rien.

Le one-shot et le few-shot deviennent précieux dès que vous avez un format spécifique à respecter, un style particulier à reproduire, ou une tâche assez atypique pour que le modèle puisse facilement se tromper sur ce que vous attendez. Plus votre demande est inhabituelle ou spécifique, plus les exemples deviennent indispensables.

Ce qui fait un bon exemple

Tous les exemples ne se valent pas. Un mauvais exemple peut être aussi nuisible qu’une absence d’exemple, parce qu’il oriente le modèle dans la mauvaise direction.

Un bon exemple est représentatif. Il illustre le cas général que vous souhaitez traiter, pas un cas marginal ou exceptionnel. Si vous voulez classifier des emails selon leur urgence, vos exemples doivent couvrir les cas typiques — un email urgent, un email non urgent — et non des cas ambigus qui ne permettent pas au modèle d’identifier le pattern avec clarté.

Un bon exemple est cohérent. Si vous fournissez plusieurs exemples, ils doivent tous suivre exactement le même format, le même niveau de détail, la même structure. Une incohérence entre vos exemples crée de la confusion et dilue l’efficacité de la technique.

Un bon exemple est minimal. Il contient exactement ce qui est nécessaire pour illustrer le pattern, sans informations superflues qui pourraient distraire. La clarté prime sur l’exhaustivité.

Un exemple de few-shot en pratique

Voici une illustration concrète. Supposons que vous vouliez classifier des verbatims clients selon la catégorie de problème qu’ils expriment, en suivant votre propre taxonomie interne — une taxonomie que le modèle ne peut pas connaître.

Sans exemples, vous devriez décrire chaque catégorie en détail, espérer que le modèle comprenne vos nuances, et probablement corriger plusieurs fois avant d’obtenir le résultat voulu.

Avec des exemples, vous écrivez simplement ceci :

Classifie chaque verbatim selon l’une des catégories suivantes : LIVRAISON, QUALITÉ, SERVICE, PRIX.

Exemples : “Mon colis est arrivé cassé.” → QUALITÉ “J’attends ma commande depuis trois semaines.” → LIVRAISON “Personne n’a répondu à mes messages pendant cinq jours.” → SERVICE “C’est beaucoup trop cher pour ce que c’est.” → PRIX

À classifier : “La matière est vraiment décevante pour le tarif affiché.”

Le modèle comprend immédiatement la structure. Il n’a pas besoin que vous lui expliquiez en quoi consiste chaque catégorie — il l’a inféré à partir de vos exemples. Et il va appliquer cette logique avec une cohérence remarquable, même sur des cas qui n’étaient pas explicitement couverts dans vos exemples.


Les quatre piliers ensemble

Ces quatre piliers — instruction, contexte, format, exemples — ne sont pas des cases à cocher dans un formulaire. Ce sont des dimensions d’un même objet : votre prompt. Et leur force réside précisément dans leur interaction.

Une instruction précise sans contexte produit une réponse correcte mais inadaptée à votre situation. Un contexte riche sans instruction précise produit une réponse informée mais sans direction. Un format explicite sans instruction ni contexte produit une structure vide. Des exemples sans instruction claire peuvent désorienter plutôt qu’orienter.

C’est l’articulation des quatre qui produit des prompts véritablement efficaces. Et avec la pratique, cette articulation devient naturelle — aussi naturelle que de rédiger un bon brief pour un collaborateur.

Commencez par vous poser systématiquement ces quatre questions avant d’écrire votre prochain prompt :

Quelle est exactement la tâche que je demande, et quel verbe d’action la désigne le mieux ? Quel contexte le modèle doit-il connaître pour répondre précisément à ma situation ? Sous quelle forme vais-je utiliser ce résultat ? Ai-je des exemples qui pourraient montrer au modèle ce que j’attends ?

Ces quatre questions, posées dans cet ordre, sont la structure de base de tout prompt professionnel.


Avant de passer à la suite

Ce module vous a donné les fondations. Vous savez maintenant ce qui distingue un prompt amateur d’un prompt efficace. Vous avez les outils pour construire des instructions précises, des contextes riches, des formats adaptés et des exemples orientants.

Mais jusqu’ici, nous avons parlé de prompts relativement simples — des requêtes en une seule pièce, pour une seule tâche. Le module 3 va changer la donne. Vous allez découvrir des techniques qui permettent de décupler la puissance de vos prompts : forcer le modèle à raisonner à voix haute, lui assigner une identité d’expert, et séparer ce qui définit son comportement de ce que vous lui demandez à chaque échange.

La pratique commence vraiment maintenant.

Layer 1