Prompt engineering pour développeurs : écrire des prompts qui fonctionnent

Le prompt engineering n’est pas une magie réservée aux chercheurs. C’est une discipline pragmatique : formuler des instructions claires pour obtenir des sorties prévisibles et de qualité. Pour un développeur qui intègre des LLMs dans ses applications, maîtriser ces techniques fait la différence entre un produit fiable et un produit imprévisible.

La structure d’un prompt efficace

Un prompt bien construit se compose de 4 éléments :

1. RÔLE     — Qui est le LLM dans cette interaction ?
2. CONTEXTE — Quelle est la situation, les contraintes ?
3. TÂCHE    — Qu'est-ce qu'on lui demande de faire exactement ?
4. FORMAT   — Comment doit être structurée la sortie ?

Exemple — sans structure :

Analyse ce contrat.

Exemple — avec structure :

Tu es un expert juridique spécialisé en droit des contrats commerciaux.

Contexte : tu analyses des contrats de prestation pour identifier les clauses
à risque avant signature. L'utilisateur est le prestataire (la partie qui signe).

Tâche : analyse le contrat fourni et identifie :
- Les clauses de responsabilité disproportionnées
- Les conditions de résiliation défavorables
- Les engagements de délai irréalistes
- Les clauses de propriété intellectuelle à surveiller

Format de sortie : JSON avec la structure suivante :
{
  "risque_global": "faible|moyen|élevé",
  "clauses_a_risque": [
    {"type": "...", "extrait": "...", "recommandation": "..."}
  ],
  "points_positifs": ["..."]
}

La version structurée produit une sortie exploitable par du code. La première produit du texte imprévisible.

Few-shot : montrer plutôt qu’expliquer

Le few-shot prompting consiste à donner des exemples de l’entrée → sortie attendue. Les LLMs généralisent très bien à partir de 2-5 exemples.

prompt = """
Tu extrais le sentiment et le sujet principal d'un avis client.

Exemples :
Avis: "La livraison était rapide mais le produit est décevant."
→ {"sentiment": "mitigé", "sujet": "livraison et qualité produit"}

Avis: "Excellent service client, problème résolu en 10 minutes."
→ {"sentiment": "positif", "sujet": "service client"}

Avis: "Impossible de joindre quelqu'un, j'attends depuis 3 jours."
→ {"sentiment": "négatif", "sujet": "réactivité support"}

Maintenant, analyse cet avis :
Avis: "{avis_client}"
→
"""

Avec des exemples, le LLM comprend précisément le format attendu et le niveau de granularité. Sans exemples, il peut produire des variations imprévisibles.

Chain of Thought : forcer le raisonnement étape par étape

Pour les tâches qui nécessitent un raisonnement (mathématiques, logique, analyse complexe), demander au LLM de réfléchir étape par étape améliore significativement la précision.

# Sans Chain of Thought
prompt = "Quel est le meilleur choix technologique pour ce projet ?"

# Avec Chain of Thought
prompt = """
Analyse ce besoin et recommande une stack technique.

Réfléchis étape par étape :
1. Identifie les contraintes techniques (charge, équipe, délais)
2. Liste les options possibles pour chaque couche
3. Évalue les compromis de chaque option
4. Formule ta recommandation finale avec justification

Besoin : {description_projet}
"""

La directive “réfléchis étape par étape” (ou “think step by step”) active un mode de raisonnement plus structuré. Claude et GPT-4o produisent des réponses nettement plus précises sur les problèmes complexes avec cette technique.

Contrôler le format de sortie

Pour les applications, vous avez besoin de sorties parsables. Deux approches :

JSON strict :

prompt = """
Extrais les données de cette facture.
Retourne UNIQUEMENT un JSON valide, sans texte avant ou après.
Ne mets pas de markdown (pas de ```json).

Schema attendu :
{
  "fournisseur": string,
  "date": "YYYY-MM-DD",
  "montant_ht": number,
  "tva": number,
  "montant_ttc": number,
  "numero_facture": string
}

Facture : {texte_facture}
"""

Avec l’API Claude (structured output) :

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": prompt}],
    # Forcer la sortie JSON valide
)
# Puis parser avec json.loads() + validation Pydantic

Limiter les hallucinations

Les hallucinations surviennent quand le LLM n’a pas l’information mais génère quand même une réponse. Pour les applications critiques :

# Ajouter une instruction explicite
system = """
Tu réponds uniquement à partir des informations fournies dans le contexte.
Si tu ne trouves pas l'information, réponds exactement :
"Information non disponible dans le contexte fourni."
N'invente pas, ne complète pas par conjecture.
"""

Demander la source : “Pour chaque affirmation, cite le passage exact du contexte qui la justifie.” Force le LLM à ancrer ses réponses dans des données réelles.

Prompts système vs prompts utilisateur

Dans les API LLM, il y a deux types de messages :

• System prompt : instructions permanentes, rôle du LLM, règles de comportement — définit QUI est le LLM
• User messages : la requête spécifique — définit CE qu’on demande

# Architecture correcte
system = """
Tu es un assistant de support technique pour le logiciel MonApp.
Tu réponds uniquement sur les questions liées à MonApp.
Tu utilises un ton professionnel et concis.
Si la question est hors sujet, redirige vers support@monapp.com.
"""

user_message = "Comment exporter mes données en CSV ?"

Le system prompt est envoyé à chaque requête mais n’est généralement pas visible par l’utilisateur final. Mettez-y vos instructions invariantes.

Patterns courants en production

Classification :

Classifie ce message dans exactement une des catégories suivantes :
["facturation", "support_technique", "commercial", "autre"]
Retourne uniquement le nom de la catégorie, rien d'autre.

Résumé avec longueur contrainte :

Résume ce texte en exactement 3 phrases. Pas plus, pas moins.
Commence par les informations les plus importantes.

Extraction d’entités :

Extrais toutes les entités nommées (personnes, organisations, lieux, dates)
du texte suivant. Format : {"personnes": [], "organisations": [], "lieux": [], "dates": []}

Conclusion

Un bon prompt n’est pas inné — il s’itère. Commencez avec un prompt structuré, testez-le sur 20-30 cas réels, identifiez les erreurs, raffinez. Les meilleurs prompts en production résultent de plusieurs itérations. Gardez un historique des versions de vos prompts comme vous le feriez avec du code — les régressions après modification sont fréquentes.