Lorsqu’une description laisse trop de place à l’interprétation, montrez au modèle des exemples du résultat souhaité. Un petit ensemble de paires entrée-sortie représentatives peut concrétiser le ton, le format ou les limites d’une classification mieux que des adjectifs seuls.
Cette technique s’appelle le prompting par exemples (few-shot prompting). Son nom vient de la recherche en apprentissage automatique : l’article original sur GPT-3 a étudié les performances des modèles lorsqu’une tâche et des exemples leur sont fournis dans le contexte, sans mise à jour de paramètres propres à la tâche (Brown et al., 2020). L’étude a aussi relevé des tâches où cette approche restait en difficulté. Les exemples sont donc une technique à évaluer, pas une amélioration universelle.
Cet article explique ce qu’est le prompting par exemples, quand l’utiliser et comment le tester à l’aide d’exemples détaillés.
Pourquoi les exemples fonctionnent mieux que les descriptions
Faites cette expérience de pensée. Imaginons que je veuille vous décrire le ton employé par mon entreprise dans ses textes marketing. Je pourrais dire : « amical mais professionnel, chaleureux sans être trop familier, assuré sans jamais paraître arrogant, dans un anglais clair mais pas simpliste ». Après avoir lu ces quatre expressions, vous acquiesceriez probablement avant de produire un texte assez éloigné de ce que j’attendais réellement.
En revanche, si je vous montrais trois courts paragraphes qui correspondent à ce ton, vous disposeriez d’une cible plus concrète. Vous pourriez comparer le choix des mots, la longueur des phrases et la structure au lieu d’interpréter uniquement les adjectifs.
Les modèles peuvent eux aussi utiliser les exemples de cette façon. Des adjectifs comme « amical », « professionnel » et « assuré » autorisent de nombreuses interprétations valables. Les exemples concrets révèlent des choix que l’instruction ne nomme peut-être pas. Le guide d’OpenAI sur les prompts décrit l’apprentissage par quelques exemples comme un moyen d’orienter le modèle avec une poignée de paires entrée-sortie et recommande de montrer des entrées possibles variées avec leurs sorties souhaitées. L’amélioration dépend du modèle, de la tâche, des exemples et des critères d’évaluation.
Quand utiliser le prompting par exemples
Voici quelques situations dans lesquelles il vaut la peine de tester des exemples :
Correspondre à un ton spécifique. “Écrivez dans le ton de notre entreprise.” Si une brève description laisse place à l’interprétation, montrez aussi des exemples représentatifs déjà acceptés.
Produire une mise en forme cohérente. Pour tout contenu qui doit présenter le même aspect à chaque fois, comme les descriptions de produits, messages d’erreur, réponses d’API, rapports hebdomadaires ou points d’avancement, montrez le format en plus de le décrire.
Résultats spécialisés ou inhabituels. « Écrivez un fil pour X à la manière de [a specific person you follow]. » « Générez des titres pour le blog d’un outil interne. » « Rédigez des commentaires de code comme le fait notre équipe. » Ces cas obéissent à des conventions précises, difficiles à formuler.
Répliquer un style pour la traduction, la synthèse ou la réécriture. “Réécrivez cela dans le même style que ces trois exemples que je vais vous montrer.”
Tout ce que vous corrigez systématiquement de la même manière. Si vous modifiez toujours la réponse du modèle dans le même sens, par exemple pour la raccourcir, remplacer un mot ou resserrer la structure, fournissez-lui des exemples de la version corrigée.
Structure de base
Un prompt par exemples pratique comporte trois parties : une consigne brève, un ensemble représentatif d’exemples et la nouvelle tâche.
Générez une description en une ligne pour un outil SaaS B2B. Reprenez le style de ces exemples.
Exemple 1 : Produit : ProjectHub Description : Un espace de travail partagé pour les équipes projet qui en ont assez de jongler entre cinq outils pour accomplir une seule tâche.
Exemple 2 : Produit : TimeFlow Description : Une application de suivi du temps pour les personnes qui détestent les applications de suivi du temps.
Exemple 3 : Produit : ClearStack Description : Un outil de rapport qui transforme les tableaux de bord en décisions.
Maintenant, écrivez une pour : Produit : PromptDesk Description :
Le motif demandé est court, affirmé, légèrement malicieux et structuré autour d’un problème ou d’un public précis. Vérifiez le résultat selon ces critères : les exemples peuvent orienter le motif, mais ne garantissent pas une bonne description.
Trois exemples concrets
Examinons trois situations dans lesquelles les exemples peuvent rendre la cible plus claire.
1. Signalements de bugs dans le style de votre équipe
Imaginons que votre équipe rédige ses tickets Jira d’une manière précise : brièvement, sans jargon et en privilégiant les conséquences pour l’utilisateur. Vous souhaitez que l’IA rédige des tickets dans le même style.
Rédigez une description de ticket Jira suivant le format ci-dessous.
Exemple 1 : Lorsqu’il se connecte avec Google, l’utilisateur voit brièvement la mauvaise langue avant la mise à jour de l’interface. Le problème se produit systématiquement dans Chrome sur ordinateur. Il n’est pas bloquant, mais donne une impression de dysfonctionnement.
Étapes :
- Se déconnecter
- Se reconnecter avec Google
- Observer le bref changement au premier affichage de la page
Attendu : la langue reste cohérente Réel : l’anglais, apparemment la langue par défaut, s’affiche brièvement
Exemple 2 : Le bouton “Exporter en CSV” renvoie un fichier vide sur les rapports hebdomadaires >1000 lignes. Les rapports plus petits s’exportent correctement.
Étapes :
- Ouvrir le rapport hebdomadaire avec 1000+ lignes
- Cliquer sur Exporter → CSV
- Ouvrir le fichier téléchargé
Attendu : données complètes Réel : le fichier est de 0 octets
Rédigez maintenant un ticket pour le problème suivant : Sur Safari, des utilisateurs signalent que le menu mobile ne se ferme pas après avoir touché un lien. Actualiser la page résout le problème. Il semble s’agir d’un dysfonctionnement du piège de focus.
Vérifiez que le brouillon respecte la structure, le ton et les faits demandés. Les exemples rendent la cible explicite, mais le modèle peut encore omettre un champ ou déduire un détail qui ne lui a pas été fourni.
2. Réécriture dans un ton de marque
Imaginons que vous ayez un brouillon d’e-mail à réécrire dans le ton de votre marque. « Soyez plus chaleureux » laisse place à l’interprétation ; des exemples peuvent préciser le registre attendu.
Réécrivez l’e-mail ci-dessous dans le ton des exemples suivants : direct, sans jargon d’entreprise, avec une légère autodérision ; n’employez jamais les mots « synergie » ou « tirer parti ».
Exemple 1 : « Nous avons repoussé la mise en production d’une semaine. La modification de la mise à l’échelle automatique était plus importante que prévu. Nouvelle date de livraison : vendredi 22. »
Exemple 2 : « Petit service : pourriez-vous relire ce brouillon ? Surtout la deuxième partie. Je pense qu’elle va trop loin, mais je n’en suis pas sûr. »
Exemple 3 : « À noter : je vais contester l’échéance pendant la réunion de demain. Les chiffres ne tiennent pas et je préfère le signaler maintenant plutôt que de rater la date. »
Réécrivez cela dans le même ton :
[paste your draft]
Comparez la réécriture avec les exemples et les faits sources avant de l’utiliser. Si votre offre et votre espace de travail ChatGPT permettent de créer des GPT, vous pouvez placer les exemples dans les instructions d’un GPT personnalisé. OpenAI recommande de tester les GPT configurés dans l’Aperçu, car les instructions ne garantissent pas une sortie identique à chaque exécution.
3. Extraction structurée
Imaginons que vous disposiez de factures PDF approuvées et souhaitiez qu’un modèle admissible en extraie les données dans un format propre. Après avoir confirmé que l’outil et le circuit de données sont approuvés pour ces documents, téléversez-en une, fournissez un exemple du résultat souhaité, puis traitez les autres.
Extrayez les données des factures PDF dans ce format JSON exact.
Exemple :
Entrée : [invoice PDF where vendor is “Lufthansa”, date is 2026-04-12, total is 423.50 EUR, line items are flight + bag fee]
Sortie :
{ "vendor": "Lufthansa", "date": "2026-04-12", "currency": "EUR", "total": 423.50, "line_items": [ {"description": "Flight TLL-LHR", "amount": 387.00}, {"description": "Checked bag", "amount": 36.50} ], "category": "Travel" }Extrayez maintenant les données de cette facture : [attach new PDF]
L’exemple précise le schéma cible, mais vous devez encore valider le schéma et comparer les données à la facture. Ne considérez pas un objet JSON plausible comme la preuve que les montants, dates ou lignes ont été extraits correctement.
Erreurs courantes avec le prompting par exemples
Trois erreurs à surveiller :
Exemples contradictoires. Si les exemples diffèrent par leur style ou attribuent des étiquettes différentes à des entrées similaires, le modèle peut reproduire cette ambiguïté. Gardez la règle visée cohérente tout en couvrant des variations d’entrée significatives.
Exemples qui ne couvrent pas les variations significatives. Il n’existe pas de nombre optimal universel. Commencez par le plus petit ensemble qui illustre le motif et les cas limites importants, puis ajoutez ou retirez des exemples selon des tests représentatifs. Chaque exemple consomme du contexte et peut introduire un autre motif à concilier.
Exemples qui incluent des erreurs que vous ne souhaitez pas copier. Un modèle peut reproduire une faute de frappe, une formulation maladroite ou un choix structurel accidentel. Nettoyez l’ensemble avant de l’utiliser et vérifiez les nouvelles sorties au lieu de supposer que seul le motif voulu a été transféré.
Une erreur particulièrement subtile consiste à montrer des exemples d’entrée sans les résultats correspondants. « Voici trois articles pour lesquels je veux que vous rédigiez des titres : [three articles]. » Il s’agit alors de prompting sans exemple (zero-shot), et non de prompting par quelques exemples. Le modèle n’a pas vu à quoi ressemble un bon titre. Comparez :
Voici trois articles accompagnés du type de titre que je souhaite. Reprenez leur style :
Exemple 1 : [article] → Titre : ”…” Exemple 2 : [article] → Titre : ”…” Exemple 3 : [article] → Titre : ”…”
Maintenant, rédigez un titre pour : [new article]
Le couple entrée → résultat constitue l’unité du prompting par exemples. Sans le résultat, le modèle n’a rien dont il puisse apprendre.
Comment construire une bibliothèque d’exemples
Dès que vous commencerez à utiliser le prompting par exemples, vous constituerez des ensembles d’« exemples efficaces ». Conservez-les dans :
- Des GPT personnalisés / des projets Claude : conservez les exemples testés dans des instructions de portée limitée que vous pouvez examiner et mettre à jour.
- Un gestionnaire d’extraits de texte (TextExpander, Raycast, Espanso) : créez des raccourcis qui insèrent vos exemples.
- Un fichier de notes organisé par cas d’usage (« exemples de ton de marque », « exemples de format de ticket », « exemples de titres »), depuis lequel vous pourrez les copier rapidement.
Avec le temps, cette bibliothèque peut s’appuyer sur des sorties réellement acceptées par votre équipe et devenir plus utile qu’un pack de prompts générique qui n’a pas été testé sur votre travail.
Les exemples surpassent les adjectifs
Lorsque vous pouvez décrire précisément le résultat, faites-le. Lorsque vous reconnaissez le style sans pouvoir l’exprimer complètement, ajoutez des exemples représentatifs d’entrées et de sorties. Testez ensuite le prompt sur des cas ordinaires et des cas limites avant d’en faire un flux de travail réutilisable.
Les exemples peuvent clarifier ce que les adjectifs laissent ambigu. Essayez la technique sur un prompt où le style ou le format compte, et ne la conservez que si les sorties testées s’améliorent.
