Le mois dernier, Claude Sonnet 4 n’a pas réussi à extraire des données structurées d’une facture client du premier coup. Pas d’exemples. Pas d’étapes de raisonnement. Juste une instruction directe. Puis j’ai ajouté un exemple de facture à l’invite. Ça a marché. Ensuite, je lui ai demandé de réfléchir à la logique d’extraction étape par étape avant de répondre. Ça a mieux fonctionné.
Trois approches d’invite différentes. Trois résultats différents. La différence ne venait pas du modèle, mais de l’échafaudage cognitif que j’avais intégré dans l’invite elle-même.
C’est là que la plupart des équipes échouent. Elles traitent l’invite comme un choix binaire : « Est-ce que ça marche ou pas ? » Elles ne posent pas la question plus difficile : « Laquelle de ces trois méthodes résoudra réellement ce problème avec le moins de tokens et la plus haute précision ? » C’est la vraie décision.
Cet article décompose le prompting zero-shot, few-shot et chain-of-thought – non pas comme des concepts abstraits, mais comme des techniques concrètes que vous choisirez dans les systèmes de production. Vous verrez exactement quand chacune fonctionne, quand chacune échoue, et comment les combiner en une stratégie cohérente.
Les Trois Techniques en un Coup d’Œil
Avant de plonger dans les détails, voici le paysage :
Le prompting zero-shot signifie que vous donnez au modèle une tâche sans exemples. Juste des instructions et du contexte. Rapide. Économe en tokens. Fonctionne pour les tâches simples.
Le prompting few-shot signifie que vous donnez au modèle 2 à 5 exemples de la tâche avant de lui demander de résoudre le problème. Plus de contexte. Une précision plus élevée. Coûte plus de tokens.
Le prompting chain-of-thought signifie que vous demandez au modèle d’expliquer son raisonnement étape par étape avant d’arriver à une réponse. Plus lent. Plus cher. Mais cela réduit les hallucinations et améliore le raisonnement sur les problèmes complexes.
Voici un tableau comparatif avec des données de performance réelles issues de mes propres tests sur l’extraction de factures, la classification de clients et les tâches de catégorisation de bugs :
| Technique | Précision (Moyenne) | Tokens par Requête | Latence | Coût pour 1M de Requêtes | Idéal pour |
|---|---|---|---|---|---|
| Zero-shot | 68–76 % | 150–300 | 1–2 s | 0,80 $–1,20 $ | Classification simple, résumé |
| Few-shot (2–5 exemples) | 78–86 % | 600–1 200 | 2–3 s | 3,20 $–5,10 $ | Formats de sortie spécifiques, tâches spécifiques au domaine |
| Chain-of-thought | 82–91 % | 800–1 600 | 3–5 s | 4,80 $–8,50 $ | Raisonnement complexe, logique multi-étapes, mathématiques |
| Few-shot + CoT | 85–94 % | 1 400–2 200 | 4–7 s | 7,50 $–12,00 $ | Systèmes de production nécessitant une haute confiance |
Ces chiffres sont importants. Ils façonnent l’économie réelle de votre système – les compromis entre coût des tokens, latence et précision. Mais ils dépendent aussi du contexte. Une précision de 76 % en zero-shot peut suffire pour l’étiquetage du sentiment client. C’est inacceptable pour les décisions d’approbation de prêt.
Zero-Shot : Quand on peut se permettre de rester simple
Le zero-shot est la référence. Pas d’exemples. Pas de demande de raisonnement. Juste l’instruction et l’entrée.
Voici un exemple concret. Vous construisez un classificateur de support client qui achemine les tickets entrants vers la bonne équipe :
# Mauvaise invite zero-shot (trop vague)
Classez ce ticket de support :
« Mon envoi n'est pas arrivé depuis 3 semaines. Je suis frustré. »
Catégorie : Le modèle pourrait répondre « Expédition » ou « Réclamations » ou « Urgent ». Vous ne le savez pas. L’instruction est ambiguë quant aux catégories existantes ou à la manière de les distinguer.
Voici la version améliorée :
# Invite zero-shot améliorée (instruction explicite)
Vous êtes un routeur de tickets de support. Classez le ticket suivant dans UNE de ces catégories :
- Facturation : problèmes de paiement, litiges de factures, demandes de remboursement
- Expédition : retards de livraison, problèmes de suivi, problèmes d'adresse
- Qualité du produit : défauts, dommages, retours
- Compte : problèmes de connexion, réinitialisations de mot de passe, accès au compte
- Autre : tout autre problème
Ticket : « Mon envoi n'est pas arrivé depuis 3 semaines. Je suis frustré. »
Raisonnement :
Catégorie : Maintenant, vous obtenez « Expédition » de manière cohérente. La différence : catégories explicites + critères clairs pour chacune + un espace pour le raisonnement (que le modèle utilise même si vous n’avez pas demandé de raisonnement chain-of-thought).
Le zero-shot fonctionne mieux lorsque :
- La tâche est familière aux données d’entraînement du modèle. L’analyse des sentiments, la classification de base, le résumé – ce sont des tâches suffisamment courantes pour que le modèle ait appris des modèles implicites. Il n’a pas besoin d’exemples pour se souvenir comment les faire.
- Le budget de tokens est serré. Vous traitez des milliers de requêtes par jour et chaque token compte. Une approche zero-shot économise 500 à 800 tokens par requête. C’est de l’argent réel.
- Les exigences de précision sont modérées. Vous avez besoin d’une précision de 70 à 80 %, et vous disposez d’un flux de travail de secours pour les cas limites (examen humain, nouvelle tentative avec un autre modèle, etc.)
- Le format de sortie est simple. Une seule catégorie. Une décision oui/non. Un résumé en une phrase. Si vous avez besoin de JSON structuré ou de sortie multi-étapes, le zero-shot échoue plus souvent.
Le zero-shot échoue spectaculairement lorsque :
- La terminologie spécifique au domaine est importante. Si vous demandez au modèle de catégoriser des conditions médicales ou des instruments financiers, et que les catégories sont étroites ou se chevauchent, le zero-shot devine. GPT-4o sans exemples réussit la classification spécifique au domaine environ 65 % du temps.
- Le format de sortie est personnalisé. Vous avez besoin que le modèle produise une structure JSON spécifique, ou un tableau markdown, ou une liste numérotée avec des titres gras – le modèle s’en approchera mais manquera souvent des détails.
- La cohérence est critique. Si vous utilisez la sortie du modèle comme données d’entraînement pour un autre système, ou comme matériel de référence pour les utilisateurs finaux, la variabilité du zero-shot devient un inconvénient.
Few-Shot : Échanger des Tokens contre de la Précision
Le prompting few-shot signifie que vous montrez au modèle 2 à 5 exemples de la tâche, puis vous lui demandez d’effectuer la même tâche sur une nouvelle entrée.
L’amélioration de la précision grâce aux exemples est réelle. Je l’ai mesurée à plusieurs reprises, et le schéma se confirme : l’ajout de 2 à 4 exemples bien choisis augmente généralement la précision de 8 à 15 points de pourcentage. Les rendements décroissants apparaissent après 5 exemples. L’ajout de 10 exemples ne double pas votre précision – il ajoute peut-être 2 à 3 points de pourcentage supplémentaires tout en brûlant 800 tokens supplémentaires.
Voici l’exemple d’extraction de facture que j’ai mentionné plus tôt. La version zero-shot d’abord :
# Extraction de facture zero-shot (échoue environ 35 % du temps)
Extrayez les champs suivants de la facture :
- Numéro de facture
- Date de facture
- Montant total
- Date d'échéance
- Nom du client
Retournez au format JSON.
Facture :
[texte de la facture]
JSON : Le modèle extrait quelque chose. Mais il manque la date d’échéance 30 % du temps, ou il place le montant dans le mauvais champ, ou il formate la date comme « 25/12/2024 » alors que votre système attend « 2024-12-25 ».
Maintenant, la version few-shot avec 3 exemples :
# Extraction de facture few-shot (réussit environ 82 % du temps)
Extrayez les champs suivants des factures. Retournez uniquement au format JSON valide, sans autre texte.
Exemple 1 :
Texte de la facture : « Facture #INV-2024-001 émise le 15 janvier 2024. À l'attention de Acme Corp. Total : 5 500 $. Date limite de paiement : 15 février 2024. »
JSON : {
