Ingénierie des prompts avancée : des astuces à la méthodologie

Le 17ᵉ résultat de test est sorti.

Même prompt — « Analysez les goulots d’étranglement de performance de ce code et proposez des optimisations » — : lundi matin Claude répond en détail et avec professionnalisme ; vendredi après-midi, c’est du vide générique. J’ai essayé un autre modèle : ChatGPT a modifié le code directement, sans demander si c’était souhaité ni expliquer pourquoi.

L’effet d’un prompt oscille toujours entre « pas mal » et « complètement inutilisable ». En programmation assistée par IA ou en construction d’applications Agent, cette instabilité agace. J’ai fini par comprendre : j’empilais des astuces isolées sans jamais bâtir une vraie méthodologie.

Cet article veut clarifier ce passage — de « connaître quelques recettes » à « maîtriser une méthodologie systématique » : cadre à trois niveaux, principes de Chain-of-Thought et ReAct, l’optimisation automatique avec DSPy, et comment adapter les prompts à Claude et ChatGPT. Enfin, une méthode d’évaluation concrète — sans mesurer l’effet d’un prompt, optimiser revient à tâtonner.

Pourquoi passer des « astuces » à la « méthodologie »

Vous avez sûrement entendu ces recettes : demander à l’IA de « réfléchir étape par étape », ajouter des exemples à imiter, lui donner un rôle d’« expert »… Elles marchent parfois, mais l’effet reste trop instable.

Les limites de l’approche empirique

De 2023 à 2024, la plupart des techniques de prompt étaient empiriques. Concrètement : « on essaie » — on change quelques mots, on lance, si ça va on garde, sinon on recommence. Plusieurs points douloureux :

Effet imprévisible. Un même prompt peut échouer en changeant de modèle. Parfois, sur un même modèle, la qualité varie fortement selon le moment. Beaucoup (moi inclus) passent des heures à tuner un prompt, pour découvrir le lendemain que la « bonne » version d’hier ne l’est plus.

Difficile à reproduire et transmettre. Vous trouvez un excellent prompt ; un collègue obtient un résultat différent. Pourquoi ? Votre prompt embarque peut-être un contexte implicite — historique de conversation, habitudes d’écriture — impossible à documenter.

Absence de critères d’évaluation. Un prompt est-il bon ? Souvent on se fie au ressenti. « Cette sortie a l’air correcte » — trop subjectif. Sans métriques, pas d’optimisation systématique.

Un chiffre parlant : avant d’adopter une méthode systématique (leur « formule 3C » — Context, Constraint, Content), une fintech affichait 61 % de compréhension correcte dès la première fois. Avec le cadre systématique : 89 %. Ce n’est pas un petit gain, c’est un saut de qualité.

Le virage 2025-2026

Depuis 2025, l’ingénierie des prompts bascule du « réglage artisanal » vers « l’ingénierie systématique ». Trois avancées clés :

Conception modulaire. Découper le prompt en composants réutilisables, assemblés comme du code. Plus besoin de réécrire un long prompt à chaque fois : on combine des modules standards, testables et optimisables séparément — stabilité nettement meilleure.

Optimisation automatique. Des frameworks optimisent le prompt à votre place. DSPy est le plus représentatif : vous définissez tâche et critères d’évaluation, il itère vers la meilleure configuration. L’idée centrale : « Programming, not prompting ».

Évaluation standardisée. Métriques quantitatives et frameworks de test : exactitude, cohérence, sécurité, efficacité des coûts avec DeepEval, Promptfoo, etc. On ne se fie plus au ressenti, on regarde les données.

Franchement, ces trois points ont changé ma façon de travailler. Avant, tuner un prompt, c’était de la chance ; maintenant, c’est de l’ingénierie — conception, tests, itération, données. C’est le cœur du passage des astuces à la méthodologie.

Cadre à trois niveaux de l’ingénierie des prompts

Structurer les techniques en trois niveaux — base, raisonnement, système — clarifie beaucoup. Chaque niveau résout un type de problème différent.

Niveau base : faire comprendre le modèle

Ce niveau répond à la question la plus simple : comment obtenir la sortie voulue.

Zero-shot (zéro exemple) : aucun exemple, la tâche est donnée directement.

Expliquez ce qu'est une architecture microservices.

Simple et direct, adapté aux tâches faciles ou aux questions de culture générale. Pour des tâches complexes ou un format précis, Zero-shot reste souvent instable.

Few-shot (peu d’exemples) : 2 à 5 exemples pour guider le modèle. Par exemple, des descriptions produit au ton dynamique :

À partir des exemples suivants, rédigez la description d'un nouveau produit :

Exemple 1 :
Produit : écouteurs Bluetooth sans fil
Description : Un petit univers dans l'oreille, un son clair comme en concert, une autonomie qui tient un vol intercontinental.

Exemple 2 :
Produit : machine à café portable
Description : Le café du barista dans le sac à dos, un espresso partout, marc contrôlé au gramme près.

Maintenant, rédigez la description pour « gourde intelligente ».

Le modèle imite le style. Clés : exemples alignés sur le style attendu, 2 à 5 suffisent, qualité avant quantité.

Role Prompting (prompt de rôle) : une identité fixe pour contraindre style et niveau de expertise.

Vous êtes architecte backend avec 10 ans d'expérience, spécialisé en performance et conception système.
Analysez les problèmes de performance du code suivant, identifiez les goulots et proposez des optimisations.
Code : [coller le code]

Le modèle raisonne plus « professionnellement ». Le rôle doit être précis — « vous êtes expert » est trop vague ; précisez domaine et expérience.

Sortie structurée : imposer JSON, Markdown, tableaux, etc. Très utile pour l’extraction de données ou l’intégration en aval.

Extrayez les informations produit du texte suivant, au format JSON :
{
  "product_name": "nom du produit",
  "price": "prix",
  "features": ["liste des caractéristiques"]
}

Texte : [coller le texte]

Les contraintes de structure améliorent fortement l’utilisabilité de la sortie.

Niveau raisonnement : apprendre au modèle à « penser »

Ce niveau permet un raisonnement complexe, pas seulement la compréhension.

Chain-of-Thought (CoT), chaîne de pensée : le modèle expose son raisonnement avant la réponse. L’idée : ne pas sauter directement à la conclusion.

L’article de Wei et al. (2022) montre que CoT améliore nettement les tâches de raisonnement complexe. Les problèmes difficiles demandent plusieurs étapes ; les écrire crée une « zone tampon de réflexion » et limite les erreurs.

Usage minimal : ajouter en fin de prompt :

Réfléchissez étape par étape à cette question, puis donnez la réponse.

Ou Few-shot CoT avec des exemples montrant le raisonnement :

Question : Ming a 5 pommes, en donne 2 à Hong, puis en cueille 3. Combien lui en reste-t-il ?
Raisonnement : Ming commence avec 5 pommes. Après en avoir donné 2, il reste 5-2=3. Après en avoir cueilli 3, il a 3+3=6.
Réponse : 6 pommes.

Résolvez de la même façon : un panier contient 12 fraises, Ming en mange 4, Hong en ajoute 6. Combien de fraises dans le panier ?

ReAct (Reasoning + Acting) : boucle réflexion + action. Schéma : Thought → Action → Observation → Thought… Idéal quand il faut des outils externes ou de la recherche.

Vous êtes un assistant capable de rechercher des informations. Utilisez ce format :

Thought: [ce qu'il faut faire maintenant]
Action: search("[requête]")
Observation: [résultat de recherche]
... (boucle jusqu'à la réponse)
Final Answer: [réponse finale]

Question : Quel film a remporté l'Oscar du meilleur film en 2024 ?

ReAct est central en développement Agent — le cœur d’un agent, c’est la boucle « penser-agir-retour ».

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

Self-Consistency : plusieurs raisonnements sur la même question, puis vote pour la réponse la plus crédible. Utile quand la précision est critique ; coût plus élevé (appels multiples).

Tree of Thoughts (ToT) : explorer plusieurs chemins de raisonnement et retenir le meilleur. Adapté aux décisions complexes, génération créative, planification stratégique.

Niveau système : gestion industrialisée des prompts

Ce n’est pas une technique isolée, mais un système de gestion.

Prompt modulaire. Découper un prompt complexe : rôle, tâche, contraintes de sortie, appels d’outils. Chaque module se gère séparément, l’assemblage reste flexible.

Optimisation automatique. Avec DSPy, plus de réglage manuel des paramètres de prompt : signature de tâche, métriques, itération automatique (détaillé plus loin).

Évaluation standardisée. Jeu de test, métriques, exécution batch, suivi des scores à chaque itération — l’optimisation repose sur des données.

Le cadre à trois niveaux indique quel niveau mobiliser : tâche simple → base ; raisonnement complexe → raisonnement ; construction de système → système.

Chain-of-Thought : analyse approfondie

CoT mérite un focus : c’est la technique de renforcement du raisonnement la plus mature, avec une barrière d’entrée faible — quelques phrases dans le prompt suffisent, sans framework lourd.

Zero-shot CoT vs Few-shot CoT

Deux usages, des contextes différents.

Zero-shot CoT : pas d’exemple, seulement une phrase d’incitation. La plus connue :

Let's think step by step.

Ou en français :

Réfléchissez étape par étape à cette question.

Simple, peu coûteux, adapté à la plupart des cas. Même cette seule phrase peut améliorer le taux de réussite de 20 à 40 % sur le raisonnement complexe.

Few-shot CoT : exemples avec raisonnement complet « question → processus → réponse » :

Question : Un magasin achète 100 articles à 20 € pièce. Jour 1 : 30 vendus à 35 €. Jour 2 : 50 à 30 €. Jour 3 : le reste soldé à 15 €. Quel est le profit total ?

Raisonnement :
1. Coût total : 100 × 20 € = 2 000 €
2. Revenu jour 1 : 30 × 35 € = 1 050 €
3. Revenu jour 2 : 50 × 30 € = 1 500 €
4. Reste jour 3 : 100-30-50=20, revenu : 20 × 15 € = 300 €
5. Revenu total : 1 050+1 500+300 = 2 850 €
6. Profit : 2 850-2 000 = 850 €

Réponse : 850 €

Résolvez de la même façon :
Question : Une entreprise a 200 employés, salaire moyen 8 000 €. Début d'année : licenciement de 30 personnes, indemnité 2 mois chacun. Puis embauche de 50 nouveaux à 6 000 € pendant 3 mois d'essai. Quelle variation des charges salariales sur l'année ?

Few-shot CoT guide un format de raisonnement précis — mais des exemples médiocres induisent le modèle en erreur.

Quand utiliser quoi ?

• Tâche simple, chemin de raisonnement clair : Zero-shot CoT suffit
• Tâche complexe, format de raisonnement spécifique : Few-shot CoT avec de bons exemples
• Modèle puissant (ex. Claude 4) : Zero-shot CoT suffit souvent
• Modèle modeste, exigence de précision : Few-shot CoT plus stable

Cas d’usage de CoT

CoT n’est pas nécessaire partout. Il brille surtout pour :

Raisonnement mathématique et logique. Calculs ou déductions multi-étapes ; CoT évite sauts et oublis.

# Sans CoT, la sortie peut être :
« La réponse est 850 €. » (résultat direct, erreur possible en cours de route)

# Avec CoT :
« Calculons étape par étape… »
puis le détail de chaque étape.

Planification multi-étapes. Plan de projet, architecture système : décomposer puis développer.

Analyse avant génération de code. Analyser le besoin, concevoir, coder — pas cracher du code directement.

Suivez ces étapes pour implémenter un système d'authentification utilisateur :

Étape 1 : analyser le besoin, lister les fonctionnalités clés
Étape 2 : concevoir modèle de données et interfaces
Étape 3 : fournir le code d'implémentation
Étape 4 : décrire la stratégie de tests

Besoin : [votre description]

Variantes de CoT

Auto-CoT : le modèle génère lui-même les chaînes de raisonnement des exemples Few-shot. Gain de temps, mais la qualité dépend de la première génération — une erreur initiale se propage.

CoD (Chain of Debate), chaîne de débat : deux rôles débattent, se contestent, convergent vers une réponse. Efficace sur problèmes ouverts ; coût et latence plus élevés.

Points d’attention CoT

Quelques pièges que j’ai rencontrés :

Ne pas forcer le raisonnement partout. « Quelle est la population de Pékin ? » — CoT alourdit inutilement, voire induit des erreurs. Critère : la tâche exige-t-elle un raisonnement multi-étapes ?

Exemples alignés sur la tâche. Exemples mathématiques pour une tâche logique : le modèle applique la mauvaise méthode.

Ne pas allonger excessivement. Une dizaine d’étapes augmente le risque d’erreur intermédiaire. Pour les cas très complexes : découper en sous-problèmes.

En résumé, CoT est la technique de raisonnement la plus pratique. Maîtriser Zero-shot et Few-shot, et savoir quand l’employer ou non, améliore nettement vos prompts.

ReAct : combiner raisonnement et action

ReAct = Reasoning + Acting. Il unit réflexion et action : appels d’outils dynamiques, collecte d’information, décisions. Si CoT, c’est « bien réfléchir », ReAct, c’est « réfléchir en agissant ».

Boucle Thought → Action → Observation

Structure centrale :

Thought (réflexion) → Action (action) → Observation (observation) → Thought → ...

Chaque tour fait avancer la résolution. Exemple de Q&R enrichie par recherche :

Tâche : identifier le domaine de recherche des lauréats du prix Nobel de physique 2024.

Thought: Je dois d'abord identifier les lauréats 2024.
Action: search("2024 Nobel Prize in Physics winners")
Observation: [résultat] Le prix 2024 est décerné à John Hopfield et Geoffrey Hinton pour leurs travaux sur les réseaux de neurones artificiels.

Thought: Je connais les lauréats, je dois préciser leurs domaines.
Action: search("John Hopfield research field")
Observation: [résultat] John Hopfield, physicien, auteur du modèle de réseau de Hopfield…

Thought: J'ai assez d'information pour répondre.
Final Answer: Les lauréats 2024 John Hopfield et Geoffrey Hinton travaillent sur les réseaux de neurones artificiels…

Le modèle complète l’information au fil du raisonnement — contrairement à CoT, limité aux connaissances internes.

ReAct vs CoT : différences clés

CoT convient quand le modèle sait déjà assez (maths, logique). ReAct quand il faut du temps réel (actualité, base de données, API).

Structure d’un prompt ReAct

Un prompt ReAct standard comprend :

Vous êtes un assistant intelligent avec accès à des outils. Utilisez ce format :

Outils disponibles :
- search(query): recherche web
- database_query(sql): requête base de données
- calculate(expression): calcul mathématique

Format :
Thought: [analyse de ce qu'il faut faire]
Action: [nom et paramètres, ex. search("requête")]
Observation: [résultat de l'outil, injecté automatiquement]
... (plusieurs tours possibles)
Final Answer: [réponse finale]

C'est parti !

Tâche : [votre tâche]

Points clés :

Définir les outils. Noms, paramètres, types de retour — documentation API.

Format de sortie strict. Thought, Action, Observation parseables par votre système.

Condition d’arrêt. Final Answer quand l’information suffit, pas de boucle infinie.

ReAct dans le développement d’agents

ReAct est un pattern de base des agents modernes — support, analyse de données, ops automatisées.

En production, c’est plus qu’un prompt :

1. Registre d’outils : interfaces, validation, permissions
2. Moteur d’exécution : parser Action, appeler l’outil, renvoyer Observation
3. Contrôle de boucle : nombre max de tours, timeout
4. Gestion d’erreurs : informer le modèle en cas d’échec d’outil

Points d’attention ReAct

Modèle suffisamment capable. ReAct exige de maintenir le contexte sur plusieurs tours et de choisir les bonnes actions. Claude et GPT-4 conviennent bien.

Descriptions d’outils claires. Comme une doc API — sinon mauvais appels ou absence d’appel.

Ne pas sur-utiliser les outils. Parfois la connaissance interne suffit. Ajoutez : « Si la réponse est dans vos connaissances, répondez directement sans outil. »

Maîtrise des coûts. Plusieurs appels d’outils = facture API. ReAct pour le complexe ; prompt simple pour le reste.

ReAct transforme le prompt de « script statique » en « programme dynamique » — étape clé de l’IA conversationnelle à l’IA actionnelle.

DSPy : optimiser les prompts automatiquement

CoT et ReAct supposent un prompt rédigé à la main. DSPy change la donne — « Programming, not prompting » : définir la tâche en code, le framework génère et optimise le prompt.

Qu’est-ce que DSPy

Framework du groupe Stanford NLP. L’ingénierie des prompts devient programmation : Signature (structure entrée/sortie), Module, Optimizer — le framework itère vers la meilleure configuration.

Avantages :

Plus fiable. Moins d’oublis, de formats incorrects ou de contraintes floues qu’en artisanal.

Plus maintenable. Versioning, tests unitaires, itération continue.

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

Plus portable. Changement de modèle sans retuner manuellement — adaptation automatique.

Composants clés de DSPy

Signature : structure entrée/sortie de la tâche.

import dspy

class QuestionAnswer(dspy.Signature):
    """Répondre à la question avec une explication détaillée"""
    question = dspy.InputField(desc="Question de l'utilisateur")
    answer = dspy.OutputField(desc="Réponse détaillée incluant le raisonnement")

Comme une interface de fonction — pas de texte de prompt explicite, seulement la structure.

Module : composants réutilisables encapsulant une technique.

# Module de base : prédiction directe
qa_basic = dspy.Predict(QuestionAnswer)

# Module avec chaîne de pensée
qa_cot = dspy.ChainOfThought(QuestionAnswer)

# Module ReAct (outils à configurer)
qa_react = dspy.ReAct(QuestionAnswer, tools=[search_tool, calculator_tool])

CoT, ReAct, etc. sont encapsulés — le framework génère le prompt correspondant.

Optimizer : optimisation automatique.

from dspy.teleprompt import BootstrapFewShot

# Données d'entraînement
trainset = [
    dspy.Example(question="Qu'est-ce que la récursion ?", answer="La récursion est l'appel d'une fonction à elle-même…"),
    dspy.Example(question="Expliquez le tri à bulles", answer="Le tri à bulles compare les éléments adjacents…"),
]

# Optimiseur
optimizer = BootstrapFewShot(max_bootstrapped_demos=3)

# Optimisation du module
qa_optimized = optimizer.compile(qa_cot, trainset=trainset)

L’optimiseur génère des exemples Few-shot, ajuste la structure, itère — comme un entraînement, mais sur le prompt, pas les poids du modèle.

Exemple DSPy complet

Système de Q&R programmation :

import dspy

# 1. Signature
class CodeQA(dspy.Signature):
    """Répondre aux questions de programmation avec explication et exemples"""
    question = dspy.InputField(desc="Question de programmation")
    answer = dspy.OutputField(desc="Réponse détaillée avec concepts et exemples de code")

# 2. Modèle de langage
lm = dspy.LM("claude-3-5-sonnet-20241022", api_key="your_key")
dspy.settings.configure(lm=lm)

# 3. Module ChainOfThought
qa = dspy.ChainOfThought(CodeQA)

# 4. Appel
result = qa(question="Comment implémenter un décorateur en Python ?")
print(result.answer)

Aucun texte de prompt écrit à la main. ChainOfThought injecte automatiquement la chaîne de pensée.

Pour optimiser :

# 5. Données d'entraînement
train_examples = [
    dspy.Example(
        question="Qu'est-ce qu'une API REST ?",
        answer="Une API REST est un style d'interface pour applications réseau…"
    ),
    dspy.Example(
        question="Expliquez les branches Git",
        answer="Une branche Git permet de diverger du flux principal…"
    ),
]

# 6. Fonction d'évaluation
def evaluate_answer(example, pred):
    """Vérifie mots-clés et longueur"""
    keywords = example.question.lower().split()
    has_keywords = sum(1 for k in keywords if k in pred.answer.lower()) >= 2
    length_ok = len(pred.answer) > 100
    return has_keywords and length_ok

# 7. Optimisation
optimizer = BootstrapFewShot(metric=evaluate_answer, max_bootstrapped_demos=4)
qa_optimized = optimizer.compile(qa, trainset=train_examples)

# 8. Module optimisé
result = qa_optimized(question="Comment implémenter un décorateur en Python ?")

Few-shot, format de prompt — optimisés sans réglage manuel.

Quand DSPy, quand le prompt artisanal

DSPy convient :

• Application IA réutilisable
• Structure entrée/sortie standardisable
• Données d’entraînement disponibles
• Migration multi-modèles
• Projet complexe avec beaucoup de prompts

Prompt artisanal convient :

• Usage unique
• Tâche floue, difficile à standardiser
• Pas de données d’entraînement
• Prototype rapide
• Tâche simple (Zero-shot suffit)

Mon expérience : pour un projet durable, DSPy paie son investissement initial. Pour une requête ponctuelle, le prompt direct reste plus rapide.

Points d’attention DSPy

Métriques d’évaluation. L’optimiseur suit votre fonction d’évaluation — une métrique mal conçue dérive l’optimisation.

Qualité des données. BootstrapFewShot s’appuie sur vos exemples — garbage in, garbage out.

Ne pas sur-optimiser. Risque de surapprentissage sur le jeu d’entraînement. Fixez une limite d’itérations.

DSPy incarne le passage du réglage manuel à l’optimisation automatique — un outil clé pour construire des applications IA de façon systématique.

Claude vs ChatGPT : bonnes pratiques différenciées

Claude et ChatGPT dominent le marché. Pourquoi un même prompt produit des sorties différentes ? Comment optimiser pour chacun ?

Comparaison des modèles

Tendances générales : Claude pour le raisonnement structuré ; ChatGPT pour la flexibilité et la créativité.

Bonnes pratiques Claude

1. Balises XML pour structurer

Claude comprend très bien le XML :

Analysez les problèmes de performance du code suivant :

<code>
function processData(data) {
  let result = [];
  for (let i = 0; i &lt; data.length; i++) {
    result.push(transform(data[i]));
  }
  return result;
}
</code>

Format de sortie :

<analysis>
[analyse des problèmes de performance]
</analysis>

<suggestions>
[suggestions d'optimisation]
</suggestions>

Les balises séparent clairement entrée et sortie — Claude respecte la structure.

2. Rôle + contraintes + exemple

Claude prend au sérieux le rôle et les contraintes :

Rôle :
Vous êtes ingénieur senior en optimisation de performance, 8 ans d'expérience Java backend. Vous identifiez les goulots et proposez des optimisations concrètes.

Contraintes :
- Pointer des goulots précis (pas de « on pourrait optimiser » vague)
- Inclure des exemples de modification de code
- Signaler explicitement les risques

Exemple de sortie :
<analysis>
Problème : création fréquente d'objets dans la boucle, pression mémoire possible.
Emplacement : boucle for lignes 3-5.
</analysis>
<suggestions>
Suggestion 1 : pré-allouer la taille du tableau.
Code : let result = new Array(data.length);
Risque : aucun notable.
</suggestions>

Analysez maintenant :
[coller votre code]

3. Exploiter le long contexte

200K tokens : fichiers entiers, centaines de lignes :

Analysez le fichier complet suivant et listez tous les problèmes de performance possibles :

<code>
[coller le fichier entier]
</code>

Analysez module par module avec problèmes et suggestions.

128K chez ChatGPT suffit souvent ; pour les très longs documents, Claude a l’avantage.

Bonnes pratiques ChatGPT

1. Contraintes de format explicites

ChatGPT est flexible — le format peut varier sans contrainte :

Analysez les problèmes de performance, format obligatoire :

## Analyse des problèmes
- Problème 1 : [description]
- Problème 2 : [description]

## Suggestions d'optimisation
| Problème | Suggestion | Exemple de code |
|-----|-----|---------|
| [problème 1] | [suggestion] | [code] |

Code :
[coller le code]

Titres Markdown et tableaux : ChatGPT suit strictement.

2. Paramètre temperature

temperature = 0 : sortie déterministe ; 0,7–1 : plus créatif.

# Sortie déterministe (code, analyse)
response = client.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": prompt}],
    temperature=0
)

# Sortie créative (rédaction, design)
response = client.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": prompt}],
    temperature=0.8
)

Claude propose des paramètres similaires ; l’effet de temperature est souvent plus marqué chez ChatGPT.

3. Guidage par étapes

ChatGPT peut sauter des étapes. Pour les tâches complexes :

Accomplissez cette tâche par étapes :

Étape 1 : lister les modules fonctionnels du code
Étape 2 : analyser les caractéristiques de performance de chaque module
Étape 3 : identifier les goulots
Étape 4 : proposer des optimisations

Commencez par l'étape 1.

Même tâche, prompts différents

Extraction d’informations produit depuis un texte.

Version Claude :

Extrayez les informations produit du texte suivant :

<text>
[texte de présentation]
</text>

Format :
<product_info>
<name>[nom]</name>
<price>[prix]</price>
<features>
<feature>[caractéristique 1]</feature>
<feature>[caractéristique 2]</feature>
</features>
</product_info>

Version ChatGPT :

Extrayez les informations produit, sortie JSON.

Texte :
[texte de présentation]

Exemple de format :
{
  "name": "nom du produit",
  "price": "prix",
  "features": ["caractéristique 1", "caractéristique 2"]
}

Respectez strictement cette structure JSON, sans champs supplémentaires.

Claude : XML ; ChatGPT : JSON + contraintes explicites.

Recommandations

• Raisonnement rigoureux, sortie structurée : Claude en priorité
• Créativité, prototype rapide : ChatGPT
• Longs documents, fichiers complets : Claude (200K)
• Code, Q&R technique : les deux, styles légèrement différents
• Rédaction, design créatif : ChatGPT (temperature élevée)

En projet, choisissez selon la tâche ou comparez les deux — un prompt mal adapté au modèle dégrade fortement le résultat.

Méthodologie d’évaluation et d’itération des prompts

Beaucoup de techniques — mais comment savoir si un prompt fonctionne ? Sans évaluation, l’optimisation est aveugle.

Quatre dimensions d’évaluation

Exactitude. Le contenu est-il correct ? Crucial, parfois difficile à mesurer. Tâches objectives (calcul, faits) : comparaison directe. Tâches subjectives (création, design) : conformité aux attentes.

Exemples :

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

• Maths : comparer au résultat attendu
• Code : exécuter, lancer les tests
• Q&R : vérifier les points d’information
• Rédaction : notation humaine ou métriques (longueur, mots-clés)

Cohérence. Même prompt, plusieurs appels : qualité stable ? Un prompt incohérent n’est pas prêt pour la production.

Méthode : 10 exécutions sur la même tâche, mesurer la variance.

Sécurité. Contenu nuisible, fuite de données, biais ? Critique en support client, modération.

Méthode : règles de détection, outils d’évaluation dédiés.

Efficacité des coûts. Consommation de tokens raisonnable ? Trop long = cher ; trop court = mauvaise qualité. Trouver l’équilibre.

Méthode : enregistrer les tokens par appel, comparer les versions.

Outils d’évaluation

DeepEval. Framework open source, métriques variées (exactitude, cohérence, pertinence), tests batch.

from deepeval import evaluate
from deepeval.metrics import AnswerRelevancyMetric, FaithfulnessMetric

metrics = [
    AnswerRelevancyMetric(threshold=0.7),
    FaithfulnessMetric(threshold=0.8)
]

evaluate(test_cases, metrics)

Promptfoo. CLI pour tests batch, comparaison de modèles, rapports — validation rapide.

promptfoo eval --prompts my_prompt.txt --providers openai:gpt-4 --tests test_cases.yaml

OpenAI Evals. Framework officiel OpenAI, orienté capacités modèle, utilisable aussi pour les prompts.

Schéma commun : jeu de test → exécution batch → scoring → rapport. Bien plus efficace que le test manuel.

Processus de test A/B

Étape 1 : jeu de test. 20 à 50 tâches types, scénarios variés — pas seulement des cas faciles.

Étape 2 : métriques. Q&R : taux de bonnes réponses + couverture ; code : taux de passage + qualité.

Étape 3 : benchmark. Prompt actuel sur tout le jeu — score de référence.

Étape 4 : version améliorée. Selon les faiblesses : CoT si exactitude faible ; contraintes de format si cohérence faible.

Étape 5 : comparaison. Même jeu, nouvelle version — comparer les métriques.

Étape 6 : itération. Si gain insuffisant, analyser et recommencer jusqu’à l’objectif.

Tableau simplifié :

Chaque changement doit être tracé.

Gestion de versions des prompts

Les prompts sont du code — versionnez-les.

Numérotation. v1, v2, v3… avec date et changements.

Journal des modifications. Quoi, pourquoi, résultats des tests.

## Historique des versions de prompt

### v3 (2026-04-15)
Changement : 3 exemples Few-shot, contraintes de format renforcées
Raison : v2 instable en cohérence
Test : exactitude 78 % → 82 %, variance ±10 % → ±5 %

### v2 (2026-04-10)
Changement : incitation CoT « réfléchissez étape par étape »
Raison : v1 faible sur raisonnement complexe
Test : exactitude 65 % → 78 %

### v1 (2026-04-05)
Version initiale
Test : exactitude 65 %, variance ±20 %

Stockage. Prompts et données de test ensemble — Git ou outil dédié.

Clés de l’itération

Une variable à la fois. CoT et Few-shot : pas en même temps — tester séparément.

Surveiller les coûts. Exactitude +100 % et tokens ×2 : arbitrage nécessaire.

Consigner les échecs. Éviter de refaire les mêmes erreurs.

Objectif d’arrêt. Ex. 80 % d’exactitude — puis stop. L’optimisation infinie a des rendements décroissants.

Évaluation et itération ferment la boucle : sans mesure, pas d’amélioration scientifique ; sans itération, pas de progrès continu. L’ingénierie des prompts devient alors un vrai processus d’ingénierie.

Conclusion

Le message central : l’ingénierie des prompts passe de « art obscure » à « discipline d’ingénierie ».

Le cadre à trois niveaux indique quelle technique employer — base pour « faire comprendre », raisonnement pour « faire penser », système pour « gérer à l’échelle ». CoT et ReAct sont les renforts de raisonnement les plus pratiques ; DSPy pointe vers l’optimisation automatique. Claude et ChatGPT demandent des prompts adaptés — XML pour Claude, format explicite + temperature pour ChatGPT. L’évaluation est la dernière pièce : sans elle, pas d’optimisation rigoureuse.

Prochaines étapes :

Auditez vos prompts actuels. Où se situent-ils dans le cadre ? Instabilité, coût, format incohérent ?

Essayez DSPy. Si votre projet s’y prête, un module simple suffit pour sentir l’optimisation automatique.

Définissez vos métriques. Jeu de test, quelques indicateurs, benchmark — les données orientent l’optimisation.

L’ingénierie des prompts demande de la pratique — mais avec une méthodologie, on ne « règle plus au feeling ». J’espère que cet article vous aide à construire un cadre de réflexion systématique. Questions bienvenues.

Références

• PromptingGuide.ai — Guide officiel de l’ingénierie des prompts
• DSPy Official — Site officiel du framework DSPy (Stanford)
• Claude Prompt Engineering Best Practices — Documentation Anthropic
• Chain-of-Thought Prompting Elicits Reasoning — Wei et al., 2022
• A Systematic Survey of Prompt Engineering — Revue systématique 2025