Le zero-shot prompting, c’est le storytelling marketing dont vous avez besoin pour vendre des LLM. C’est aussi la première chose à oublier le jour où vous passez en production. Demandez à un benchmark interne : sur 90 % des tâches métiers réelles, un prompt zero-shot donne 15 à 35 % de qualité en moins qu’un prompt few-shot, à modèle constant. Cette différence ne se voit pas sur les benchmarks publics. Elle se voit sur vos livrables clients.
On va expliquer pourquoi, et surtout comment construire des prompts few-shot qui marchent en moins de 30 minutes.
Le malentendu autour du zero-shot
Le zero-shot, c’est l’idée qu’un LLM moderne (GPT-5, Claude Sonnet 4.6, Gemini 2.5 Pro) est suffisamment compétent pour comprendre une tâche à partir d’une simple description, sans exemple. Sur les benchmarks publics, c’est partiellement vrai. Sur les tâches métiers où la « bonne réponse » dépend du style maison, de la nomenclature interne et des règles tacites de votre organisation, c’est faux.
Le modèle ne sait pas ce que votre cabinet d’expertise comptable appelle un « rappel à l’expert ». Il ne connaît pas votre nomenclature commerciale (« lead chaud », « lead tiède », « opportunité dormante »). Il invente une logique cohérente mais générique. Et c’est ce qui rend ses livrables creux : techniquement corrects, contextuellement à côté.
Pourquoi le few-shot marche aussi bien
Le few-shot prompting consiste à donner 2 à 5 paires (entrée → sortie attendue) avant la tâche réelle. C’est l’équivalent du « voici à quoi ressemble un bon résultat » qu’on donne à un nouveau collaborateur. Les LLM s’appuient massivement sur cette structure pour caler la forme, le ton et les conventions.
Concrètement, sur une tâche de classification (« cet e-mail est-il un lead qualifié, une réclamation, ou une demande SAV ? »), passer de zero-shot à 3-shot fait monter la précision de 78 % à 94 % sur Claude Sonnet 4.6. Sur une tâche de génération (« rédige un e-mail de relance commercial »), le few-shot ramène votre ton de marque dans 100 % des cas (sur la structure plus que la créativité, voir aussi demander à l’IA d’être structurée), alors que le zero-shot oscille entre LinkedIn-influenceur et chatbot poli.
Comment construire un few-shot efficace en 30 minutes
Étape 1 : récoltez 5 à 8 exemples réels de bons livrables. Vous avez des e-mails commerciaux qui ont converti ? Des comptes rendus de réunion bien faits ? Des analyses concurrentielles que votre boss valide sans corriger ? Ce sont vos exemples.
Étape 2 : reconstituez l’entrée correspondante pour chacun. Pour un e-mail de relance, l’entrée est typiquement « voici la fiche du prospect, voici notre offre, voici l’historique d’échanges ». Pour un compte rendu, c’est la transcription brute de la réunion.
Étape 3 : assemblez le prompt avec 3 paires bien choisies. Pas 8 paires – le modèle pourra over-fit sur des biais que vous n’aviez pas remarqués. 3 exemples bien différents les uns des autres couvrent 90 % des cas.
Étape 4 : testez sur 10 inputs hors lot. Si le modèle reproduit le bon style, vous avez gagné. Sinon, identifiez ce qui dévie et ajoutez un 4ème exemple ciblé.
Le piège des exemples trop similaires
L’erreur classique : choisir 3 exemples qui se ressemblent tous. Le modèle va alors généraliser cette ressemblance et plafonner sur des cas atypiques. La bonne pratique est de prendre des exemples qui couvrent les 3 principaux profils de difficulté de votre tâche : un cas typique, un cas court/simple, un cas long/complexe.
Cas concret pour la rédaction d’e-mails commerciaux : prenez un e-mail court à un prospect chaud, un e-mail long à un prospect technique exigeant, et un e-mail de relance après silence. Vous couvrez le spectre. Si vous mettez 3 e-mails « relance après silence », le modèle pensera que c’est le seul mode.
Quand le few-shot ne suffit plus : le RAG et le fine-tuning
Le few-shot a une limite : le contexte fini. Au-delà de 10-15 exemples bien rédigés, vous saturez la fenêtre de tokens du modèle ou vous augmentez la latence. Pour des cas où il faut raisonner sur un corpus large (vos 200 fiches produits, votre historique d’avis clients sur 3 ans), passez au le RAG expliqué simplement. Pour des cas où la tonalité doit être profondément intégrée (vous publiez 100 articles/mois avec une voix éditoriale très spécifique), le fine-tuning ou la création d’un agent dédié devient pertinent.
Mais 80 % des cas en PME se règlent en few-shot. C’est l’outil le plus rentable du prompt engineering : 30 minutes d’investissement pour des résultats qui passent du « ok pour un brouillon » au « directement envoyable ».
Le bon prompt est concret, pas vague
On a tous tendance à considérer un LLM comme un humain à former. Erreur. Un LLM est un système qui infère des patterns à partir d’entrées. Plus vous lui montrez explicitement le pattern attendu, plus il devient bon. Le zero-shot impose à la machine de deviner ce que vous voulez. Le few-shot le lui montre.
Dans nos formations chez Neowin Academy, c’est la première technique qu’on enseigne aux managers (en cohérence avec former les key users plutôt que tout le monde) qui veulent industrialiser leurs cas d’usage. C’est aussi la moins glamour. C’est précisément pour ça qu’elle marche.
Pour approfondir
- Arrêtez de demander à l’IA d’être créative, demandez-lui d’être structurée
- Le RAG expliqué à ma grand-mère (sans parler de vecteurs)
- Arrêtez de former tout le monde au prompting (formez les key users)
Pourquoi les benchmarks publics vous mentent sur le zero-shot
Il faut comprendre d’où vient le mythe du zero-shot, sinon on ne s’en débarrasse jamais. Il vient des benchmarks publics : MMLU, GSM8K, et consorts. Ces tests mesurent la capacité d’un modèle à répondre à des questions dont la « bonne réponse » est universelle et documentée. Combien font 17 × 23 ? Quelle est la capitale du Kazakhstan ? Sur ce terrain, le modèle n’a besoin d’aucun exemple : la réponse existe indépendamment de votre organisation.
Le problème, c’est que vos tâches métiers ne ressemblent pas du tout à ça. Quand vous demandez à un LLM de classer un e-mail client selon votre taxonomie interne, ou de rédiger une relance dans votre ton de marque, il n’existe pas de « bonne réponse universelle ». La bonne réponse dépend de conventions que vous êtes seul à connaître. Le modèle, livré à lui-même, produit une réponse plausible et générique : la moyenne statistique de ce qu’il a vu pendant son entraînement. Techniquement correcte, contextuellement à côté.
C’est tout le malentendu : on confond compétence générale et alignement contextuel. Un modèle peut être brillant en culture générale et totalement incapable de deviner que votre cabinet appelle « dossier sensible » ce que tout le monde appelle « litige ». Les exemples sont ce qui comble ce fossé. Ils transforment une compétence générale en compétence applicable à votre réalité.
Ce que les exemples font réellement au modèle
Quand vous donnez trois paires entrée → sortie, le modèle ne « mémorise » pas vos exemples. Il fait quelque chose de plus subtil et de plus puissant : il infère les règles implicites qui relient vos entrées à vos sorties. Il repère que vos e-mails commencent toujours par un rappel du contexte, que vos comptes rendus séparent décisions et actions, que votre ton reste direct sans jamais tomber dans le jargon. Ces règles, vous ne les avez jamais écrites ; vos exemples les contiennent.
C’est pour cela que le few-shot bat presque toujours une longue consigne verbale. Essayez de décrire par écrit, exhaustivement, ce qui fait un « bon » e-mail de relance selon vous : vous y passerez une heure et vous oublierez la moitié des règles tacites. Montrez trois bons e-mails : le modèle les extrait tout seul en quelques secondes. Montrer est radicalement plus efficace que décrire, parce qu’un exemple encode des dizaines de micro-décisions qu’aucune consigne n’expliciterait jamais.
La méthode complète : du bon exemple au prompt robuste
Construire un few-shot qui tient en production demande un peu plus de rigueur que de coller trois exemples au hasard. Voici la méthode que nous enseignons, affinée sur des dizaines de cas d’entreprise.
Choisir des exemples qui couvrent le spectre, pas qui se répètent
La règle d’or : vos trois exemples doivent être aussi différents que possible tout en restant tous « bons ». Un cas typique, un cas limite court, un cas limite long. Si vos exemples se ressemblent, le modèle généralise la ressemblance et s’effondre dès qu’une entrée sort du moule. On appelle ça l’over-fitting sur la forme, et c’est le piège le plus courant.
Nettoyer les exemples avant de les utiliser
Un exemple réel contient souvent du bruit : une coquille, une tournure maladroite, un détail propre à un client. Le modèle va reproduire ce bruit, parce qu’il ne sait pas distinguer l’intention de l’accident. Un exemple sert de modèle : il doit être impeccable. Prenez cinq minutes pour corriger chaque exemple avant de l’intégrer. C’est l’investissement le plus rentable de tout le processus.
Expliciter la structure attendue autour des exemples
Les exemples montrent le pattern ; une courte consigne encadre le contrat. Dites au modèle, en une phrase, ce qu’il doit produire et dans quel format. L’association « consigne brève + exemples riches » surpasse systématiquement la consigne seule comme les exemples seuls. C’est d’ailleurs le lien direct avec notre conviction qu’il faut demander à l’IA d’être structurée avant de lui demander d’être créative : le few-shot est l’outil qui impose la structure sans brider le contenu.
Tester sur des entrées hors lot
Ne validez jamais un few-shot sur les entrées qui ont servi à le construire : c’est un test truqué. Prenez dix entrées nouvelles, inconnues du prompt, et regardez si le modèle reproduit le bon style. Si trois sur dix dévient, identifiez le point commun de ces trois cas et ajoutez un quatrième exemple ciblé qui le couvre. Deux itérations suffisent généralement à stabiliser un prompt de production.
Les erreurs qui ruinent un few-shot
- Trop d’exemples. Au-delà de cinq, vous saturez le contexte, augmentez la latence et le coût, et vous risquez l’over-fit. Trois exemples bien choisis battent huit exemples redondants.
- Des exemples contradictoires. Si deux de vos exemples traitent le même cas de deux façons différentes, le modèle ne sait plus quelle règle suivre et produit un résultat incohérent.
- Des sorties incomplètes. Si vos exemples de sortie sont tronqués ou résumés, le modèle apprend à tronquer. Montrez toujours la sortie dans son intégralité, telle que vous la voulez.
- Oublier de mettre à jour les exemples. Vos conventions évoluent ; un few-shot figé sur des exemples d’il y a deux ans propage des pratiques obsolètes. Rafraîchissez vos exemples quand votre standard change.
Trois cas d’usage où le few-shot change tout
Pour sortir de l’abstrait, voici trois situations concrètes que nous rencontrons sans cesse en entreprise, et où le passage au few-shot transforme un livrable médiocre en livrable utilisable.
La classification de demandes entrantes
Un service client reçoit des centaines de messages par jour : réclamations, demandes SAV, prospects, relances de facturation. En zero-shot, le modèle invente des catégories génériques qui ne correspondent pas à votre organisation interne. En 3-shot, vous lui montrez trois messages réels étiquetés avec vos propres catégories, et la précision bondit. Le gain n’est pas marginal : il fait la différence entre un tri automatique fiable et un tri qu’il faut relire entièrement, donc inutile.
La rédaction dans un ton de marque
C’est le cas le plus spectaculaire. Le ton d’une marque est une somme de micro-conventions : longueur des phrases, niveau de familiarité, vocabulaire autorisé ou proscrit, façon d’ouvrir et de clore. Aucune consigne ne capture tout ça. Trois exemples validés par votre direction, oui. En few-shot, le modèle produit des textes qui « sonnent comme vous » dès le premier jet, au lieu d’osciller entre l’influenceur LinkedIn et le chatbot aseptisé.
L’extraction structurée d’informations
Extraire des champs précis d’un document — montant, date, référence, partie prenante — semble simple, mais le diable est dans les conventions : format de date, gestion des valeurs manquantes, normalisation des noms. Deux ou trois exemples montrant exactement comment vous voulez que ces cas soient traités suppriment l’essentiel des erreurs. C’est aussi le socle de tout pipeline de données fiable : on ne construit rien de robuste sur une extraction hasardeuse.
Few-shot, RAG, fine-tuning : savoir où s’arrête chaque outil
Le few-shot est l’outil le plus rentable, mais il n’est pas magique. Il a une limite nette : le contexte fini. Vous ne pouvez pas y mettre trois ans d’historique client ou deux cents fiches produits. Quand il faut raisonner sur un grand corpus, c’est le RAG qui prend le relais : il va chercher dynamiquement les bons extraits et les injecte au moment de la requête. Le few-shot montre comment répondre ; le RAG fournit sur quoi répondre. Les deux se combinent très bien.
Le fine-tuning, lui, n’a de sens que dans un cas précis : un volume massif et répété, avec une tonalité à intégrer en profondeur, où le coût de réinjecter des exemples à chaque requête devient prohibitif. Pour l’écrasante majorité des PME, ce seuil n’est jamais atteint. Commencez toujours par le few-shot ; ne montez en complexité que quand une limite réelle vous y oblige, pas par anticipation ni par effet de mode. La plupart des projets qui échouent ont sauté cette étape et investi dans du fine-tuning avant d’avoir épuisé ce que trois bons exemples pouvaient leur apporter.
Industrialiser le few-shot : d’une astuce à un actif d’entreprise
Un bon few-shot n’est pas une astuce personnelle, c’est un actif réutilisable. Le réflexe à prendre : constituer une bibliothèque d’exemples validés, par cas d’usage, maintenue dans le temps. Chaque fois qu’un collaborateur produit un livrable exemplaire, il le verse à la bibliothèque. Chaque fois qu’une convention change, on met les exemples à jour. Au bout de quelques mois, vous disposez d’un capital de prompts qui encode littéralement le savoir-faire de votre organisation.
C’est un changement de nature. Tant que le few-shot reste dans la tête d’un expert, il disparaît avec lui. Versé dans une bibliothèque partagée, il devient transmissible, auditable, améliorable collectivement. C’est exactement la logique que nous poussons en formation : ne formez pas tout le monde à improviser des prompts, formez quelques key users à construire et maintenir les bons exemples dont tout le monde bénéficiera ensuite.
Cette approche rejoint une conviction que nous défendons sur le fait que l’IA ne rend pas idiot : bien utilisée, elle capitalise l’expertise humaine au lieu de la diluer. Le few-shot en est l’illustration parfaite : il demande de savoir ce qu’est un bon livrable, donc il valorise l’expertise métier plutôt que de la remplacer.
Pourquoi la technique la moins glamour est la plus rentable
Le prompt engineering est devenu un terrain de surenchère : techniques exotiques, chaînes de raisonnement sophistiquées, personas élaborés. La vérité, un peu décevante, c’est que la technique la plus rentable est aussi la plus ennuyeuse : montrer des exemples. Trente minutes d’investissement, des résultats qui passent du « brouillon acceptable » à « directement envoyable ». Aucun autre levier n’offre ce rapport effort/résultat.
Si le few-shot est négligé, c’est précisément parce qu’il n’est pas spectaculaire. Il ne se raconte pas bien en conférence. Il ne fait pas la une. Il marche, c’est tout. Et dans un contexte où beaucoup d’entreprises cherchent à former vite et former juste, c’est exactement le genre de compétence à ancrer en premier : immédiatement applicable, immédiatement rentable, sans dépendance à un outil particulier.
C’est ce que nous travaillons concrètement dans nos sessions à Paris et Lyon : chaque participant repart avec des few-shots fonctionnels sur ses propres cas d’usage, pas avec de la théorie. Pour aller plus loin sur l’intégration dans des systèmes applicatifs, notre parcours développement logiciel IA montre comment versionner et tester ces prompts comme du code.
FAQ
Combien d’exemples faut-il mettre dans un prompt few-shot ?
Trois dans la plupart des cas, à condition qu’ils soient bien différents les uns des autres et qu’ils couvrent le spectre de votre tâche. En dessous, le modèle manque de repères ; au-delà de cinq, vous saturez le contexte et vous risquez l’over-fit sur des biais involontaires. La qualité et la diversité des exemples comptent bien plus que leur nombre.
Le few-shot fonctionne-t-il sur tous les modèles ?
Oui, c’est l’une des rares techniques universelles : GPT-5, Claude Sonnet 4.6, Gemini 2.5 Pro et leurs équivalents s’appuient tous massivement sur les exemples fournis. L’effet est d’autant plus marqué que la tâche dépend de conventions internes. Un prompt few-shot bien construit reste donc largement portable d’un modèle à l’autre.
Faut-il abandonner complètement le zero-shot ?
Pas pour les tâches à réponse universelle : une traduction simple, un calcul, une question de culture générale n’ont pas besoin d’exemples. Le zero-shot reste parfait là. Il devient un piège dès que la bonne réponse dépend de votre style, de votre nomenclature ou de vos règles tacites. La règle : réponse universelle → zero-shot ; réponse contextuelle → few-shot.
Combien de temps pour construire un bon few-shot ?
Environ trente minutes pour une première version fonctionnelle : collecter cinq à huit bons livrables, en nettoyer trois, assembler le prompt, tester sur dix entrées hors lot. Une ou deux itérations ciblées suffisent ensuite à le stabiliser. C’est le meilleur rapport temps investi / qualité gagnée de tout le prompt engineering.
Passez à l’action
Le zero-shot est une promesse marketing ; le few-shot est une pratique de production. Si vous ne deviez changer qu’une habitude après cette lecture : ne lancez plus jamais une tâche métier sans montrer au moins deux ou trois bons exemples au modèle. Vos livrables passeront du générique à l’utilisable sans changer de modèle ni dépenser un euro de plus.
Pour construire cette compétence avec vos équipes sur vos propres cas d’usage, découvrez nos certifications préparées, parcourez nos réalisations en formation IA, consultez notre FAQ ou déposez votre candidature pour une session adaptée à votre métier.
Le few-shot comme discipline de pensée
Au fond, construire un bon few-shot vous oblige à répondre à une question que vous aviez peut-être esquivée : à quoi ressemble un livrable excellent, précisément ? Tant que vous ne savez pas le montrer, vous ne le savez pas vraiment. L’exercice force la clarté. Il transforme un standard flou, logé dans la tête de quelques experts, en exemples explicites que n’importe qui peut comprendre et reproduire.
C’est peut-être le bénéfice le plus durable de la technique : au-delà de meilleurs prompts, elle produit une meilleure compréhension collective de vos propres standards. Les équipes qui adoptent le few-shot finissent par mieux définir ce qu’elles attendent, indépendamment de l’IA. L’outil le moins glamour du prompt engineering est aussi, discrètement, un outil de management de la qualité.
