Module 03 — Techniques essentielles de prompting

Technique 1 — Zero-shot, One-shot, Few-shot : choisir le bon niveau de guidage

Une question de contexte d’entraînement

Pour comprendre ces trois approches, il faut revenir un instant sur ce que le modèle a appris. Durant son entraînement, il a été exposé à des millions d’exemples de tâches résolues — des traductions, des résumés, des analyses, des transformations de texte. Il a développé une compétence générale pour répondre à toute une gamme de demandes sans qu’on ait besoin de lui montrer comment faire.

Mais cette compétence générale a ses limites. Pour les tâches courantes et bien représentées dans ses données d’entraînement, le modèle s’en tire parfaitement sans aucun exemple. Pour les tâches plus atypiques, plus spécifiques, ou qui suivent un format inhabituel, il a besoin d’être guidé. C’est là que le choix entre zero-shot, one-shot et few-shot entre en jeu.

Zero-shot : faire confiance aux capacités du modèle

Le zero-shot est l’approche par défaut. Vous posez votre question ou formulez votre instruction sans fournir le moindre exemple. Vous faites entièrement confiance aux capacités générales du modèle.

C’est l’approche correcte pour toutes les tâches simples, bien définies, et suffisamment courantes pour être bien représentées dans les données d’entraînement. Traduire une phrase, corriger une faute de grammaire, résumer un texte standard, expliquer un concept connu — autant de situations où des exemples supplémentaires n’apporteraient rien et alourdiraient inutilement votre prompt.

Le piège du zero-shot, c’est de l’utiliser pour des tâches qui en réalité nécessitent du guidage — par flemme de construire des exemples, ou par manque de conscience du problème. Si vous constatez que le modèle ne comprend pas exactement ce que vous attendez, c’est presque toujours le signe qu’il est temps de passer au one-shot ou au few-shot.

One-shot : établir un pattern avec un seul exemple

Le one-shot consiste à fournir un unique exemple avant votre demande réelle. Cet exemple joue le rôle d’un modèle — au sens littéral du terme. Il montre au modèle la forme exacte que vous attendez, sans que vous ayez besoin de la décrire avec des mots.

Un seul exemple suffit souvent pour des patterns relativement simples — un format de réponse particulier, un style d’écriture spécifique, une structure de classification à deux ou trois catégories. Il ne résout pas les cas d’ambiguïté complexe, mais il oriente clairement le modèle pour des demandes bien délimitées.

L’efficacité du one-shot tient à quelque chose de fondamental dans le fonctionnement des LLM : leur capacité à reconnaître et prolonger des patterns. En leur montrant un exemple, vous activez cette capacité de façon directe et précise, là où une description verbale du même pattern aurait laissé des zones d’interprétation.

Few-shot : la précision par la démonstration multiple

Le few-shot, c’est la même idée portée à sa pleine puissance. Vous fournissez plusieurs exemples — généralement entre deux et cinq — avant votre demande. Chaque exemple supplémentaire réduit l’ambiguïté, couvre un cas de figure de plus, et renforce la cohérence du pattern que vous souhaitez voir reproduit.

Le few-shot est particulièrement précieux dans quatre situations. Quand votre format de sortie est très spécifique et difficile à décrire verbalement. Quand votre tâche comporte plusieurs variantes ou nuances que vous voulez toutes couvrir. Quand les enjeux d’une erreur de format ou de style sont élevés — un document juridique, une communication officielle, un contenu qui sera publié. Et quand votre taxonomie ou votre nomenclature est interne à votre organisation et donc inconnue du modèle.

Une précision importante : la qualité de vos exemples prime toujours sur leur quantité. Trois exemples parfaitement représentatifs et cohérents valent bien plus que sept exemples approximatifs ou incohérents entre eux. Avant d’ajouter un exemple, demandez-vous s’il apporte une information nouvelle sur le pattern — un cas différent, une nuance supplémentaire. Si ce n’est qu’une répétition de ce que vous avez déjà montré, supprimez-le.

Technique 2 — Le Chain-of-Thought : apprendre au modèle à raisonner à voix haute

Le problème du saut de conclusion

Les modèles de langage ont une tendance naturelle à sauter directement à la conclusion. Vous posez une question complexe, ils produisent une réponse — parfois juste, parfois fausse, presque toujours sans montrer le chemin parcouru. Et quand la réponse est fausse, vous n’avez aucun moyen de savoir où le raisonnement a déraillé, ni pourquoi.

Ce comportement est particulièrement problématique pour les tâches qui requièrent plusieurs étapes de raisonnement enchaînées — des problèmes mathématiques, des analyses logiques, des raisonnements par inférence, des plans en plusieurs étapes. Dans ces situations, une erreur à l’étape deux fausse inévitablement les étapes trois, quatre et cinq. Et si vous ne voyez que la conclusion, vous acceptez peut-être une réponse erronée sans le savoir.

Le Chain-of-Thought, ou chaîne de pensée, est la solution à ce problème. Et c’est une solution remarquablement simple.

Le principe : externaliser le raisonnement

L’idée centrale du Chain-of-Thought est de demander explicitement au modèle de montrer son raisonnement étape par étape avant de donner sa réponse finale. En textualisant chaque étape du raisonnement, le modèle se crée lui-même un contexte intermédiaire sur lequel il peut s’appuyer pour la suite.

Souvenez-vous de ce que vous avez appris sur les LLM : ils prédisent le token suivant en fonction de tout ce qui précède dans le contexte. Quand le modèle écrit “étape 1 : le train parcourt 200 km en une heure, donc sa vitesse est 200 km/h”, ce texte devient du contexte pour l’étape suivante. Il dispose maintenant d’une information correcte et explicite sur laquelle construire, au lieu de devoir l’inférer implicitement.

C’est exactement ce que vous faites quand vous résolvez un problème difficile en écrivant les étapes sur une feuille de papier. L’acte d’écriture n’est pas qu’une trace — c’est un outil de pensée. Le Chain-of-Thought donne au modèle ce même outil.

Comment l’activer

L’activation du Chain-of-Thought est d’une simplicité désarmante. Il suffit d’ajouter à votre prompt une instruction qui demande explicitement le raisonnement intermédiaire. Plusieurs formulations fonctionnent très bien :

“Raisonne étape par étape avant de donner ta réponse finale.”

“Réfléchis à voix haute, puis donne ta conclusion.”

“Montre chaque étape de ton raisonnement, puis synthétise.”

“Avant de répondre, décompose le problème en sous-questions et traite chacune d’elles.”

Ces formulations semblent presque trop simples pour être efficaces. Et pourtant, les études publiées sur le sujet ont montré des améliorations spectaculaires sur les benchmarks de raisonnement logique et mathématique — parfois plusieurs dizaines de points de pourcentage — uniquement grâce à l’ajout de cette instruction.

Au-delà des maths : le Chain-of-Thought pour toutes les tâches complexes

On associe souvent le Chain-of-Thought aux problèmes mathématiques parce que c’est là que son impact est le plus visible et le plus facilement mesurable. Mais son utilité dépasse largement ce domaine.

Pour une analyse de texte complexe, il force le modèle à identifier méthodiquement les arguments avant de les évaluer. Pour une recommandation stratégique, il oblige à poser explicitement les hypothèses avant de les mobiliser dans la conclusion. Pour la détection d’erreurs logiques dans un raisonnement, il permet de suivre le fil de bout en bout et de repérer l’étape où la logique se brise.

Une règle pratique : dès qu’une tâche comporte plus de deux ou trois étapes de raisonnement enchaînées, ou dès que vous avez du mal à vérifier la réponse sans voir le chemin parcouru, activez le Chain-of-Thought. La légère augmentation de la longueur de la réponse est largement compensée par le gain en fiabilité et en transparence.

Technique 3 — Le Role Prompting : activer l’expertise en assignant une identité

Pourquoi les rôles fonctionnent

Quand vous dites à un modèle “tu es un médecin urgentiste avec quinze ans d’expérience”, quelque chose de précis se passe. Le modèle n’acquiert pas une nouvelle compétence — il en avait déjà de vastes dans ce domaine. Ce qui se passe, c’est une activation sélective : le modèle oriente son attention vers les patterns linguistiques, conceptuels et stylistiques associés à ce rôle dans ses données d’entraînement.

Pensez-y de cette façon. Durant son entraînement, le modèle a absorbé d’innombrables textes écrits par des médecins, des juristes, des ingénieurs, des enseignants, des journalistes. Il a appris à reconnaître les patterns de chacun de ces registres — le vocabulaire, la structure argumentative, le niveau de prudence dans les affirmations, la façon de gérer l’incertitude. En lui assignant un rôle, vous lui indiquez quel sous-ensemble de ces patterns mobiliser.

Le résultat est souvent saisissant. Le même prompt, avec et sans assignation de rôle, peut produire des réponses de qualité très différente — non pas parce que le modèle a plus de connaissances dans un cas, mais parce qu’il les mobilise de façon plus ciblée et plus pertinente.

Anatomie d’un bon rôle

Un rôle efficace ne se limite pas à un titre. Il combine plusieurs dimensions qui, ensemble, orientent précisément le comportement du modèle.

La spécialité définit le domaine d’expertise. “Expert en fiscalité internationale” est plus précis que “fiscaliste”, qui est lui-même plus précis qu'”expert en finance”. Plus la spécialité est précise, plus le modèle peut calibrer finement son registre.

L’expérience ajoute de la profondeur. “Avec vingt ans d’expérience dans le conseil aux PME” oriente le modèle vers des réponses ancrées dans la pratique réelle plutôt que dans la théorie abstraite. Un expert avec vingt ans d’expérience parle différemment d’un jeune diplômé — il use moins de jargon, il anticipe les objections, il illustre avec des exemples concrets tirés du terrain.

Les traits de personnalité pertinents pour la tâche affinent encore davantage. “Pédagogue, capable d’expliquer des concepts complexes avec des analogies simples” oriente vers un style accessible. “Direct et synthétique, sans détour” produit des réponses concises et sans fioriture. “Rigoureux et prudent dans ses affirmations” produit des réponses nuancées qui signalent explicitement les zones d’incertitude.

Le contexte du rôle peut compléter l’ensemble. “Consultant qui s’adresse à des dirigeants non-spécialistes” est différent d'”expert qui s’adresse à ses pairs dans une publication académique”. Le même rôle, selon l’audience à laquelle il est censé s’adresser, adopte un registre radicalement différent.

Ce que le Role Prompting ne fait pas

Une précision importante pour ne pas surestimer la technique. Assigner un rôle ne donne pas au modèle de connaissances qu’il n’a pas. Si le modèle manque d’informations sur un sujet très pointu ou très récent, lui dire qu’il est un expert dans ce domaine ne va pas miraculeusement combler cette lacune.

Ce que le Role Prompting fait, c’est optimiser la mobilisation des connaissances existantes du modèle. Il oriente le style, le niveau de détail, le vocabulaire, la structure argumentative et l’angle d’approche. Il est particulièrement efficace dans les domaines bien représentés dans les données d’entraînement — ce qui couvre une très grande partie des besoins professionnels courants.

Pour les domaines très spécialisés, très récents, ou très peu documentés, le Role Prompting doit être combiné avec un contexte factuel riche que vous fournissez vous-même. Le rôle définit comment le modèle traite l’information. Le contexte définit quelle information il a à sa disposition.

Technique 4 — Prompt système et prompt utilisateur : séparer ce qui dure de ce qui change

Deux niveaux de dialogue

Jusqu’à présent, nous avons parlé du prompt comme d’un bloc unique — une instruction que vous écrivez, que vous envoyez, que vous obtenez. Et pour une conversation ponctuelle, c’est effectivement suffisant.

Mais dès que vous travaillez avec des LLM dans un contexte plus structuré — une application, un assistant spécialisé, un workflow automatisé, un chatbot d’entreprise — vous avez besoin d’une distinction plus fine. Vous avez besoin de séparer ce qui définit le comportement permanent du système de ce qui change à chaque interaction.

C’est précisément le rôle de la distinction entre prompt système et prompt utilisateur, disponible dans les APIs de tous les grands modèles actuels.

Le prompt système : définir le cadre permanent

Le prompt système — souvent appelé system prompt — est l’instruction fondatrice. Il est envoyé au modèle avant la conversation et persiste à travers tous les échanges qui suivent. L’utilisateur final, dans la plupart des applications, ne le voit jamais. C’est le cadre invisible qui définit qui est le modèle, comment il doit se comporter, quelles sont ses limites, son ton, son domaine de compétence, et ses obligations vis-à-vis de l’utilisateur.

Un prompt système bien conçu répond à plusieurs questions fondamentales. Quel est le rôle de l’assistant — qui est-il, quelle est sa spécialité ? Quel ton doit-il adopter — formel, chaleureux, neutre, direct ? Quelles sont les limites de son périmètre — sur quels sujets peut-il répondre, lesquels doit-il refuser ou rediriger ? Quel format de réponse doit-il privilegier par défaut ? Quelles informations contextuelles permanentes doit-il avoir en tête — le nom de l’entreprise, ses produits, ses valeurs, ses politiques ?

Dans beaucoup d’entreprises qui développent des produits basés sur des LLM, le prompt système est le principal actif intellectuel de l’équipe. C’est lui qui fait que deux applications utilisant le même modèle de base peuvent se comporter de façon radicalement différente.

Le prompt utilisateur : la requête spécifique

Le prompt utilisateur, c’est ce que l’utilisateur écrit à chaque échange. Il s’inscrit dans le cadre défini par le prompt système, et le modèle répond en tenant compte des deux simultanément.

Cette architecture est puissante parce qu’elle sépare deux préoccupations très différentes. Le prompt système répond à la question “quel type d’assistant est-ce ?” Le prompt utilisateur répond à la question “que veut l’utilisateur maintenant ?” Le modèle fusionne les deux pour produire une réponse qui respecte à la fois le cadre permanent et la demande immédiate.

Un exemple concret de cette architecture

Voici comment cette séparation se manifeste en pratique. Imaginons que vous construisiez un assistant interne pour une équipe juridique.

Le prompt système pourrait être : “Tu es LexAssist, un assistant juridique spécialisé en droit français du travail. Tu t’adresses à des juristes internes et des responsables RH. Ton ton est professionnel et précis. Tu cites systématiquement les articles de loi pertinents. Tu mentionnes explicitement les zones d’incertitude jurisprudentielle. Tu rappelles à la fin de chaque réponse que tes analyses sont informatives et ne remplacent pas un avis juridique professionnel. Tu refuses de répondre aux questions hors du champ du droit du travail français.”

Et le prompt utilisateur, à chaque échange, serait simplement la question du juriste : “Quelles sont les conditions légales pour mettre en place un accord de télétravail ?” ou “Quels sont les délais de prescription en cas de licenciement abusif ?”

Le modèle répond à chaque question en respectant systématiquement le cadre défini — le ton, le niveau d’expertise, les citations légales, la mise en garde finale, le refus de déborder hors-périmètre. Et tout cela sans que l’utilisateur ait besoin de le rappeler à chaque message.

Cette architecture est celle de presque toutes les applications professionnelles basées sur des LLM. La comprendre, c’est comprendre comment ces systèmes fonctionnent réellement — et comment les construire ou les évaluer avec discernement.

Technique 5 — Le prompting itératif : améliorer méthodiquement ce qui ne marche pas

Le mythe du prompt parfait du premier coup

Il existe une attente implicite, très répandue, selon laquelle un bon prompt engineering consiste à trouver la formule parfaite dès la première tentative. Comme si les prompts efficaces étaient le résultat d’un talent inné ou d’une intuition mystérieuse.

Cette attente est non seulement irréaliste, elle est contre-productive. Elle provoque deux comportements opposés, également nuisibles. Soit l’utilisateur abandonne trop vite après une première réponse décevante, concluant que l’IA n’est “pas faite pour ça”. Soit il reformule dans le vague en espérant que quelque chose finira par fonctionner, sans comprendre pourquoi.

La vérité est que les meilleurs prompt engineers travaillent de façon itérative. Ils considèrent leur premier prompt comme une hypothèse à tester, et la réponse obtenue comme un signal qui leur permet d’affiner. C’est un cycle de diagnostic et d’amélioration, pas une recherche de la formule magique.

Diagnostiquer avant d’ajuster

La clé du prompting itératif efficace est de ne jamais modifier son prompt dans le vague. Chaque modification doit répondre à un diagnostic précis. Qu’est-ce qui ne va pas exactement dans la réponse obtenue ? Le fond est-il incorrect ou incomplet ? La forme ne correspond-elle pas à ce que vous attendiez ? Le ton est-il inadapté ? La longueur est-elle disproportionnée ? L’angle d’approche est-il le mauvais ?

Chacun de ces problèmes a une solution spécifique, et mélanger les solutions sans avoir identifié le problème produit des résultats imprévisibles.

Si le fond est incorrect ou incomplet, c’est généralement un problème de contexte insuffisant ou d’instruction trop vague. La solution est d’enrichir le contexte ou de préciser davantage ce que vous attendez.

Si la forme ne correspond pas, c’est un problème de spécification du format. La solution est d’ajouter ou de préciser explicitement le format de sortie attendu.

Si le ton est inadapté, c’est souvent un problème d’absence de rôle ou de public cible non précisé. La solution est d’ajouter un Role Prompting et de préciser à qui la réponse est destinée.

Si la longueur est disproportionnée — trop longue, trop courte, ou inégalement distribuée — la solution est une contrainte de longueur explicite.

Si l’angle d’approche est le mauvais, c’est souvent un problème d’enjeu non explicité. Préciser pourquoi vous avez besoin de cette information et à quelle décision elle va contribuer réoriente le modèle vers ce qui vous est réellement utile.

Le cycle d’itération en pratique

Un cycle d’itération typique ressemble à ceci. Vous écrivez un premier prompt avec l’instruction de base. Vous obtenez une réponse. Vous l’évaluez selon vos critères : fond, forme, ton, longueur, angle. Vous identifiez le problème principal — un seul à la fois, dans l’idéal. Vous apportez une modification ciblée. Vous obtenez une nouvelle réponse. Vous réévaluez.

En trois à cinq itérations, vous atteignez généralement un résultat exploitable — et souvent bien meilleur que ce que vous auriez obtenu si vous aviez essayé de tout spécifier parfaitement dès la première tentative. Parce que chaque réponse vous apprend quelque chose sur ce dont le modèle a besoin pour comprendre votre demande.

Une pratique recommandée est de tenir un journal de vos prompts les plus efficaces. Notez la version finale de chaque prompt qui a produit un résultat satisfaisant, avec une courte note sur la tâche et le contexte. Avec le temps, vous construisez une bibliothèque de modèles réutilisables qui accélère considérablement votre travail et garantit une cohérence dans vos résultats.

Ce que vous maîtrisez maintenant

Vous avez maintenant en main cinq techniques fondamentales qui transforment votre façon d’interagir avec les LLM. Vous savez choisir le bon niveau de guidage selon la complexité de la tâche. Vous savez forcer le modèle à raisonner méthodiquement plutôt que de sauter aux conclusions. Vous savez activer des registres d’expertise précis en quelques mots. Vous comprenez l’architecture qui sous-tend les applications professionnelles basées sur des LLM. Et vous savez améliorer vos prompts de façon méthodique plutôt qu’au hasard.

Ces techniques ne sont pas des outils indépendants — elles se combinent. Un prompt professionnel intègre souvent un rôle, un Chain-of-Thought, un format spécifié, et quelques exemples, le tout dans une architecture système/utilisateur bien pensée. C’est cette combinaison qui produit des résultats d’une qualité difficile à atteindre autrement.

Le module 4 va encore plus loin. Vous allez découvrir des techniques avancées conçues pour les problèmes complexes, les workflows ambitieux, et les situations où les approches standards ont leurs limites. Préparez-vous à changer une nouvelle fois votre façon de voir ce que l’IA peut faire.