Prompt et context engineering avancé 2026 : guide pratique

Lecture : 15 minutes · Niveau : développeur intermédiaire · Mise à jour : avril 2026

L’expression « prompt engineering » s’est progressivement déplacée vers « context engineering » en 2025-2026 : la majorité des échecs des applications LLM en production ne sont plus des limitations du modèle, mais des erreurs de contexte (mauvais documents récupérés, historique mal géré, outils mal définis, instructions contradictoires). Ce tutoriel pratique couvre les techniques qui marchent vraiment en production 2026 : structuring de prompts, chain-of-thought, prompt caching Anthropic (-90 % coût et -85 % latence), output JSON forcé, validation, evals automatisées, et patterns anti-hallucination. Tous les exemples fonctionnent avec Claude ou OpenAI.

Pour le contexte stratégique global, voir le pillar IA générative avancée PME.

Sommaire

Prompt engineering : les bases solides
Chain-of-thought et raisonnement explicite
Output structuré (JSON, schema)
Few-shot learning
Context engineering 2026
Prompt caching Anthropic
Anti-hallucination
Evals automatisées
Optimisation coûts
Pièges fréquents
FAQ

1. Prompt engineering : les bases solides

Anatomie d’un prompt efficace.
– Rôle clair : qui est l’IA, sa mission.
– Contexte : informations stables (politiques, conventions).
– Instructions : tâche précise, étape par étape.
– Format : structure de réponse attendue.
– Exemples (few-shot) : 2-5 démonstrations.
– Question / input utilisateur : variable.

Anti-pattern : prompt trop court.

"Résume ce texte : ..."

→ Output générique, qualité variable.

Pattern correct.

Tu es un assistant éditorial pour une agence de presse francophone.

Ta mission : produire un résumé en français de 150 mots maximum, avec :
- Première phrase = essentiel (qui, quoi, quand, où).
- Phrases suivantes = contexte et conséquences.
- Ton neutre, pas d'opinion.

Si l'article fournit des chiffres, conserve-les.
Si l'article cite quelqu'un, garde au moins une citation.

Article :
{article_text}

Résumé :

Balises XML pour structure (recommandé Anthropic).

<task>
Tu dois extraire les informations de cette facture.
</task>

<output_format>
JSON avec champs : invoice_number, date, total_amount, vendor_name.
</output_format>

<examples>
<example>
<input>...</input>
<output>...</output>
</example>
</examples>

<input>
{user_input}
</input>

Avantages XML.
– Délimitation claire des sections.
– Le modèle distingue mieux instructions vs données.
– Facile à maintenir et étendre.

Spécificité opérationnelle.
– Plutôt que « écris bien », dire « phrases courtes (max 20 mots), vocabulaire courant ».
– Plutôt que « professionnel », dire « ton informatif, pas de tutoiement, pas d’emojis ».
– Plutôt que « structuré », dire « 3 sections : titre H2, paragraphe d’intro 2 phrases, liste à puces 5 items ».

2. Chain-of-thought et raisonnement explicite

Concept CoT. Demander au modèle de raisonner étape par étape avant de répondre améliore significativement la qualité sur tâches logiques.

Prompt CoT simple.

Question : Une commande de 35 articles à 12 500 FCFA pièce avec une remise de 15 %, livraison gratuite si > 250 000 FCFA. Quel est le total ?

Réfléchis étape par étape avant de répondre.

CoT structuré (mieux).

Tu vas répondre à cette question. Procède en 3 étapes :

1. Identifie les données du problème.
2. Calcule étape par étape, en montrant chaque sous-calcul.
3. Donne la réponse finale.

Format :
<analyse>
[étape 1]
</analyse>
<calcul>
[étape 2]
</calcul>
<reponse>
[étape 3]
</reponse>

Question : {question}

Modèles 2026 avec raisonnement étendu.
– Claude Sonnet 4.6 / Opus 4.7 : « extended thinking » avec budget thinking_tokens.
– GPT-5 : modes raisonnement profonds.
– DeepSeek R1, OpenAI o1/o3 : modèles spécialisés raisonnement.

Quand utiliser CoT.
– Mathématiques.
– Logique complexe.
– Multi-step reasoning.
– Décisions avec critères multiples.

Quand NE PAS utiliser CoT.
– Tâches simples (extraction directe, classification simple) : ajoute latence inutile.
– Output créatif (rédaction marketing) : le raisonnement parasité l’expression.

3. Output structuré (JSON, schema)

Pourquoi. Pour intégration dans pipelines, on veut sortie machine-readable systématique.

JSON mode OpenAI.

response = client.chat.completions.create(
    model="gpt-5-mini",
    response_format={"type": "json_object"},
    messages=[
        {"role": "system", "content": "Réponds en JSON valide uniquement."},
        {"role": "user", "content": "Extrais nom et email de : Aïssa Diop <aissa@example.sn>"}
    ]
)
data = json.loads(response.choices[0].message.content)

Structured outputs OpenAI (schema strict).

schema = {
    "type": "object",
    "properties": {
        "name": {"type": "string"},
        "email": {"type": "string"}
    },
    "required": ["name", "email"],
    "additionalProperties": False
}

response = client.chat.completions.create(
    model="gpt-5",
    response_format={"type": "json_schema", "json_schema": {"name": "extract", "schema": schema, "strict": True}},
    messages=[...]
)

Anthropic Claude : tool use pour output structuré.

tools = [{
    "name": "extract_contact",
    "description": "Extrait nom et email",
    "input_schema": {
        "type": "object",
        "properties": {
            "name": {"type": "string"},
            "email": {"type": "string"}
        },
        "required": ["name", "email"]
    }
}]

response = client.messages.create(
    model="claude-sonnet-4-6-20250101",
    tools=tools,
    tool_choice={"type": "tool", "name": "extract_contact"},
    messages=[...]
)

# Result accessible via response.content[0].input

Validation côté serveur.
– Toujours valider via Pydantic (Python) ou Zod (TypeScript).
– Gérer les cas où le modèle dévie du schema (rare avec strict mode mais possible).
– Retry avec correction si invalid.

from pydantic import BaseModel, EmailStr

class Contact(BaseModel):
    name: str
    email: EmailStr

contact = Contact.model_validate(data)  # raise si invalid

4. Few-shot learning

Principe. Donner 2-5 exemples avant la requête → modèle apprend pattern, performance grimpe.

Exemple classification sentiment.

Tâche : classifier sentiment client (positif, négatif, neutre).

<example>
Texte : "Livraison rapide, produit conforme. Très satisfait."
Sentiment : positif
</example>

<example>
Texte : "Article cassé à la réception, service client injoignable."
Sentiment : négatif
</example>

<example>
Texte : "Reçu hier, pas encore testé."
Sentiment : neutre
</example>

Texte : "{user_input}"
Sentiment :

Bonnes pratiques few-shot.
– 3-5 exemples typique (au-delà : marginal).
– Diversité des cas (positif, négatif, edge cases).
– Format identique entre exemples et requête.
– Exemples représentatifs des cas réels (pas inventés).
– Mettre en cache (avec prompt caching).

Quand few-shot.
– Classification.
– Extraction structurée.
– Style spécifique (tone of voice, format).
– Tâches où instruction pure ne suffit pas.

Quand zéro-shot.
– Tâches générales bien comprises (résumé, traduction, Q&A).
– Modèles très capables (Sonnet 4.6, GPT-5).

5. Context engineering 2026

Le shift 2026. Selon Anthropic et autres acteurs majeurs : la majorité des échecs en production ne sont plus des problèmes de modèle, mais de contexte.

Principes context engineering.

Pertinence > volume.
– 5K tokens de contexte ciblé > 100K tokens de contexte généraliste.
– Le modèle dilue son attention sur volume excessif.

Compaction.
– Pour conversations longues : résumer historique ancien.
– Garder messages récents intégraux.
– Outils : Anthropic memory tool, custom summarization.

Curation des documents RAG.
– Reranker actif.
– Filtrage metadata.
– Top-K limité (5-10 chunks).
– Contexte ne dépasse pas 30-50K tokens en pratique.

Tool descriptions courtes mais précises.
– Description + when_to_use + arguments clairs.
– Pas de tools redondants.
– Limite 5-10 tools simultanés.

System prompt stable, séparé du dynamique.
– System : qui est le modèle, contraintes, contexte projet.
– User : input variable.
– Permet prompt caching efficace.

Memory pattern.
– Long-term memory dans DB (Redis, PostgreSQL).
– Récupération sélective au début de chaque session.
– Pas tout charger systématiquement.

6. Prompt caching Anthropic

La feature qui change tout. Anthropic Prompt Caching met en cache les sections stables du prompt côté infra Anthropic, réduisant -90 % le coût et -85 % la latence pour les tokens cachés.

Cas d’usage idéaux.
– System prompt long (5K-50K tokens) : caché.
– Few-shot examples : cachés.
– Documents RAG fréquemment réutilisés : cachés.
– Code base entière (pour Claude Code) : cachée.

Activation.

response = client.messages.create(
    model="claude-sonnet-4-6-20250101",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "Tu es un assistant service client...",
        },
        {
            "type": "text",
            "text": large_static_context,  # 30K tokens politique entreprise
            "cache_control": {"type": "ephemeral"}
        }
    ],
    messages=[
        {"role": "user", "content": user_question}
    ]
)

TTL cache.
– Par défaut : 5 minutes (utilisé pour conversations).
– Extended (1 heure) : disponible pour use cases batch.

Économies réelles mesurées.
– 50K tokens system prompt × 1000 requêtes/jour :
– Sans cache : 50M tokens × 3 USD = 150 USD/jour.
– Avec cache (90 % hit) : ~15 USD/jour.
– Économie : ~135 USD/jour, 4000 USD/mois.

Compatibilité.
– OpenAI : a son propre prompt caching (différent format mais principe similaire).
– Gemini : prompt caching disponible.
– Open-source local : à implémenter manuellement.

7. Anti-hallucination

Le problème. LLMs inventent confiance dans les détails (chiffres, noms, citations) quand pas dans leurs données.

Patterns anti-hallucination.

RAG strict.

Réponds UNIQUEMENT à partir des documents fournis ci-dessous.
Si l'information n'est pas dans les documents, réponds :
"Je ne dispose pas de cette information dans les sources disponibles."

Cite chaque affirmation entre crochets [Source: nom_doc].

Documents :
{retrieved_docs}

Question : {question}

Demander incertitude explicite.

Pour chaque affirmation dans ta réponse, indique entre parenthèses :
(certain) si c'est explicitement dans les documents.
(probable) si c'est inférence raisonnable.
(incertain) si c'est extrapolation.

Self-consistency.
– Lancer même prompt 3-5 fois (température > 0).
– Comparer outputs.
– Garder réponse majoritaire ou abstain si divergent.

LLM-as-judge.
– Premier modèle génère réponse.
– Second modèle (différent ou même) évalue : « Cette réponse est-elle fidèle aux documents ? Cite les passages exacts qui la justifient. »
– Filtrer si non-faithful.

Citations obligatoires.
– Tout fait → source explicite.
– Faciliter vérification humaine.

Format ouverture explicite.

Si la question demande des chiffres, dates, ou noms propres précis non présents dans les documents, indique-le clairement plutôt qu'inventer.

Modèles « mode strict » 2026.
– Anthropic et OpenAI proposent modes où modèle préfère abstain plutôt qu’inventer.
– Configurable via system prompt et températ. basse (0-0.3).

8. Evals automatisées

Pourquoi essentiel. Sans dataset de test, modifications dégradent silencieusement la qualité.

Construire un dataset.
– 50-200 exemples représentatifs.
– Inclure cas faciles, moyens, edge cases.
– Inclure réponses idéales (ground truth).
– Versionné (git) avec données métier sensibles anonymisées.

Métriques automatisées.
– Exact match : pour réponses standardisées.
– String similarity (Levenshtein, BLEU, ROUGE) : pour textes libres.
– Embedding similarity : pour sémantique (cosine entre embeddings).
– Schema validation : pour outputs structurés.

LLM-as-judge.
– Demander à un autre LLM (souvent même famille mais plus puissant) d’évaluer.
– Critères : faithfulness, relevance, completeness, format.
– Score 1-5 ou binaire pass/fail.

Frameworks evals.
– Anthropic Inspect : framework eval Claude.
– OpenAI evals : framework eval OpenAI.
– Ragas : pour RAG spécifiquement.
– DeepEval : eval LLM générique.
– Custom : tableur + scripts si simple.

Pipeline CI/CD evals.
– À chaque modification prompt → run eval suite.
– Comparer baseline vs nouveau.
– Bloquer merge si régression > seuil.

Eval continue en production.
– Sample 1-5 % des requêtes prod.
– Eval async sur sample.
– Alerts si métriques dégradent.

9. Optimisation coûts

Hiérarchie économies.

1. Prompt caching (-90 %). Implémentation : 30 min, ROI immédiat, indispensable.

2. Modèle adapté (-70-90 %). Sonnet pour 80 % des cas, Haiku/nano pour bulk simple, Opus seulement pour complexe.

3. Réduire tokens output. max_tokens strict. Format concis.

4. Réduire tokens input. Trim documents, summary historique long, prompt concis.

5. Batch processing (-50 %). Anthropic Batch API et OpenAI Batch API pour traitements asynchrones.

6. Embedding model adapté. text-embedding-3-small (0,02 USD/M) vs large (0,13 USD/M) si qualité acceptable.

7. Cache embeddings queries fréquentes. Hash query → vector.

8. Modèles open-source self-hosted pour très haut volume (amortit infra GPU).

10. Pièges fréquents

Prompts trop longs et flous. 5K tokens d’instructions vagues = modèle confus. Concis et précis.

Instructions contradictoires. « Sois concis mais détaillé ». Choisir un focus.

Pas d’exemples. Sur tâches non-triviales, few-shot multiplie performance.

Output libre quand structuré attendu. Parsing fragile. JSON mode ou tool use.

Pas de validation. Output JSON malformé, app crash. Pydantic / Zod systématique.

Température élevée pour tâches déterministes. Extraction, classification : température 0-0.3. Création : 0.7-1.

Prompt caching ignoré. Facture API multipliée par 10. Activer en production.

Pas d’evals. Régressions silencieuses. Dataset minimum 50 ex.

Mode chat sur tâche structurée. Pour automation : API direct, pas chat conversationnel.

Versioning prompts dans le code. Déploiement nécessaire pour changer prompt. Externaliser dans DB ou config.

Trop de tokens output pour bulk. max_tokens=4096 pour classification = gâchis. max_tokens=10 suffit.

FAQ

Quelle température utiliser ?

Tâches déterministes (extraction, classification, code) : 0 à 0.3. Tâches créatives (rédaction marketing, brainstorming) : 0.7 à 1. Par défaut Claude 1.0, OpenAI 1.0 — souvent trop haut pour applications structurées.

Combien d’exemples few-shot optimal ?

3 à 5 exemples typique. Au-delà de 8-10, gains marginaux. Mettre les exemples en cache (prompt caching) pour économiser. Diversité importante (positif, négatif, edge cases).

Comment forcer un format JSON exact ?

OpenAI : response_format avec json_schema strict. Anthropic : tool use avec input_schema. Validation côté serveur via Pydantic ou Zod après. Toujours strict mode si disponible pour garantir schema.

Chain-of-thought ralentit-il les réponses ?

Oui, +30-100 % de tokens output. Compense par qualité accrue sur tâches logiques. Sur tâches simples, ne pas l’utiliser. Pour modèles avec mode raisonnement (Claude extended thinking, o1/o3) : intégré nativement.

Prompt caching fonctionne-t-il avec OpenAI et Gemini ?

Oui, formats différents mais principes similaires. OpenAI : cache automatique sur certains prompts longs. Gemini : Context Caching API. Anthropic reste le plus mature avec activation explicite et économies les plus claires.

Comment gérer l’historique conversation longue ?

Compaction : résumer messages anciens (>20 messages typique), garder récents intégraux. Outils : LangChain ConversationSummaryMemory, Anthropic memory tool. Limite typique 30-50K tokens contexte total pour qualité optimale.

Faut-il fine-tuner pour avoir un meilleur prompt ?

Rarement. Prompt engineering soigné + few-shot + RAG couvre 90 % des cas. Fine-tuning utile si volume très répétitif (millions de requêtes) où small model fine-tuné peut remplacer gros modèle pour économies.

Comment versionner les prompts ?

Externaliser dans DB ou fichiers config (YAML, JSON). Versionning Git avec releases tag. Outils dédiés : LangSmith Prompt Hub, Promptlayer, Helicone. Permet A/B testing et rollback rapide sans déploiement code.

Articles liés (cluster IA générative avancée)

Article mis à jour le 26 avril 2026. Pour signaler une erreur ou suggérer une amélioration, écrivez-nous.