Prompt engineering 2026 : 10 techniques qui marchent vraiment

Le prompt engineering a évolué. En 2026, les modèles sont plus intelligents, plus robustes, et pardonnent beaucoup de choses. Mais bien écrire un prompt reste une compétence clé — surtout quand on route des requêtes entre GPT-4o, Claude, Groq et Gemini. Ce guide couvre les 10 techniques qui font vraiment une différence, avec des exemples concrets.

Pourquoi le prompt engineering en 2026 ?

On entend parfois que "les modèles sont tellement bons que le prompt engineering va disparaître". C'est faux. Ce qui disparaît, ce sont les astuces de magie noire ("respire profondément", "mets un pourboire de 100€", "mon grand-père me racontait"). Ce qui reste, c'est l'essentiel : donner au modèle le contexte, la structure et les contraintes nécessaires pour faire le bon travail.

Un bon prompt divise par 3 vos coûts, double la qualité des réponses, et transforme un prototype en produit fiable. Voyons comment.

Les 3 composants d'un bon prompt

Avant les techniques, le modèle mental. Tout prompt sérieux contient trois éléments :

1. Le rôle ou contexte — qui est le modèle, pour quelle tâche ?
2. La tâche ou consigne — qu'est-ce qu'on lui demande exactement ?
3. Le format attendu — quelle structure doit avoir la réponse ?

Un prompt qui rate l'un des trois produit des réponses floues. Retenez ce triptyque et 80% du travail est fait.

1. Utiliser un system prompt clair

Le system prompt définit le rôle du modèle pour toute la conversation. C'est le levier le plus sous-utilisé.

# Mauvais
messages = [{"role": "user", "content": "Résume ce contrat"}]

# Bon
messages = [
    {"role": "system", "content": """Tu es un avocat senior spécialisé en droit commercial.
Tu rédiges des résumés de contrats clairs, structurés et orientés décision.
Tu identifies les risques et tu les quantifies."""},
    {"role": "user", "content": "Résume ce contrat : ..."},
]

Le system prompt a trois effets : il cadre le ton (professionnel, technique, vulgarisé), il oriente le contenu (focus décision, focus risques), et il rend le modèle cohérent sur toute la conversation.

2. Few-shot prompting : montrer plutôt qu'expliquer

Le few-shot prompting consiste à donner 2-5 exemples dans le prompt. C'est la technique la plus puissante pour contrôler le format de sortie.

Classifie l'intention du client dans l'une de ces catégories :
demande-info, plainte, annulation, autre.

Exemples :

Client : "Comment je peux changer mon mot de passe ?"
Catégorie : demande-info

Client : "Ça fait 3 semaines que j'attends ma commande, c'est scandaleux"
Catégorie : plainte

Client : "Je veux résilier mon abonnement"
Catégorie : annulation

Client : "Bonjour, comment ça marche ?"
Catégorie :

Trois exemples suffisent à fixer le format. Le modèle comprend qu'il doit répondre par un seul mot parmi la liste, pas par une phrase. Zero-shot (sans exemple) est rarement aussi précis que few-shot, même avec GPT-4o.

3. Chain of thought : laisser le modèle réfléchir

Pour les tâches complexes (raisonnement, math, déduction), ajoutez simplement "Raisonne étape par étape avant de répondre". Cette phrase magique augmente la précision de 30 à 70% selon les benchmarks.

Question : Si j'ai 3 pommes et j'en donne la moitié à Paul,
puis Marie m'en donne 4, combien j'en ai ?

Raisonne étape par étape avant de donner la réponse finale.

Réponse sans CoT : souvent fausse. Réponse avec CoT : le modèle détaille 3 - 1.5 = 1.5, puis 1.5 + 4 = 5.5. Plus long, plus précis.

4. JSON mode : forcer la structure

Si votre app consomme la réponse du LLM en code, n'attendez pas une chaîne en texte libre. Demandez explicitement du JSON et utilisez le mode structuré quand il existe.

# Avec OpenAI, Groq, Mistral
response = client.chat.completions.create(
    model="auto",
    messages=[{"role": "user", "content": "..."}],
    response_format={"type": "json_object"},
)

Dans le prompt, décrivez le schéma attendu :

Extrait les informations clés de cet email et retourne-les en JSON
avec exactement cette structure :

{
  "expediteur": "string",
  "sujet": "string",
  "urgence": "low" | "medium" | "high",
  "action_requise": "string ou null"
}

Email : ...

Sans schéma explicite, le modèle va parfois ajouter des champs, changer le nom des clés, ou retourner des strings au lieu d'enum. Avec schéma, c'est déterministe à 99%.

5. Role prompting : personas concrètes

"Tu es un expert en..." fonctionne mais c'est générique. Ce qui marche mieux : une persona concrète.

Comparaison :

• Générique : "Tu es un expert en nutrition" → conseils OK mais fades
• Concret : "Tu es nutritionniste à l'hôpital de Lyon, spécialisé en diabète type 2. Tu as 15 ans d'expérience et tu tutoies tes patients." → conseils précis, ton adapté, cohérence tenue sur toute la conversation

La spécificité réduit les hallucinations car elle contraint le modèle à rester dans un cadre précis.

6. Délimiter les sections avec des balises

Quand le prompt contient plusieurs blocs (contexte, exemples, consigne, données), isolez-les. Les modèles ont été entraînés sur des formats structurés et comprennent mieux des sections balisées.

<contexte>
L'utilisateur est client depuis 2021, plan Pro, niveau support Premium.
</contexte>

<historique>
...
</historique>

<consigne>
Rédige une réponse empathique à son email.
Ton : professionnel mais chaleureux.
Longueur : 3-4 phrases max.
</consigne>

<email_client>
...
</email_client>

Les balises XML-like marchent avec tous les modèles. Claude en particulier a été entraîné explicitement sur ce format et réagit très bien.

7. Contraintes positives plutôt que négatives

Les modèles suivent mal les instructions négatives. "Ne dis pas bonjour" a 30% de chances d'être ignoré. "Commence directement par la réponse" marche à 95%.

8. Prompt engineering multi-provider

C'est le sujet le moins documenté mais le plus important en 2026. Si vous routez vos requêtes entre plusieurs modèles (pour coût, latence ou fallback), votre prompt doit être robuste au changement de provider.

Les prompts "portables"

Évitez les tournures qui ne marchent que sur un modèle précis.

• Évitez les balises propriétaires : <|im_start|> (ChatML), [INST] (Llama), Human: (Anthropic). Elles cassent sur les autres providers.
• Évitez les références à un modèle : "En tant que GPT-4..." — si Routtx route vers Claude, le modèle sera confus.
• Privilégiez les balises XML-like : comprises par tous, tokenisées pareil partout.

Tester sur 2-3 modèles

Prenez vos 10 prompts les plus importants et testez-les sur Groq (Llama 3.3), GPT-4o et Claude Sonnet. Si la qualité diverge de plus de 20%, votre prompt est trop fragile. Simplifiez-le jusqu'à ce qu'il marche partout.

Température pour la stabilité

Pour une app en prod avec fallback multi-provider, utilisez temperature=0.1 ou temperature=0. Les résultats seront plus déterministes et vous éviterez les surprises quand le routing bascule.

9. Prompts en français : quelques nuances

Les LLMs sont meilleurs en anglais, mais l'écart s'est réduit. En français, quelques règles :

• Tutoiement pour instruire le modèle, vouvoiement pour le style de la réponse finale. "Tu es expert, rédige une réponse au vouvoiement."
• Évitez les anglicismes dans le prompt : "output" → "réponse", "input" → "entrée". Les modèles comprennent les deux, mais rester cohérent aide.
• Accents : écrivez correctement avec accents. Certains modèles se synchronisent sur le registre du prompt — un prompt sans accents produit parfois une réponse sans accents.

10. Itération et monitoring

Un prompt n'est jamais fini. Ce qu'il faut mesurer en production :

• Taux de succès (la réponse est-elle utilisable ?)
• Taux de format valide (si JSON attendu, parseable ?)
• Longueur moyenne (détection de verbosité inutile)
• Distribution des providers utilisés (si votre prompt marche moins bien sur Groq que sur GPT-4o, vous payez plus cher sans raison)
• Coût par requête (tokens in + tokens out)

Un bon gateway LLM vous donne ces métriques sans effort. Chez Routtx, chaque requête est loguée avec provider, tokens, latence et classification de tâche. Vous voyez en un coup d'œil quel prompt est optimal.

Les erreurs à éviter

1. Le prompt trop long

Plus de 2000 tokens de prompt pour une tâche simple, c'est trop. Vous payez à chaque appel, la latence monte, et le modèle dilue son attention. Coupez l'inutile.

2. L'oubli du contexte conversationnel

Dans un chatbot, chaque message contient l'historique. Si votre system prompt change entre deux messages, le modèle perd la cohérence. Fixez-le une fois et n'y touchez plus dans la session.

3. La sur-spécification

Dire "Réponds en 47 mots exactement, avec 3 paragraphes, dont le premier fait 12 mots" — c'est du bruit. Le modèle va faire de son mieux mais rarement respecter tout. Donnez des contraintes claires mais pas militaires.

4. Faire confiance aux benchmarks publics

Les benchmarks MMLU, HumanEval, etc. testent des tâches génériques. Pour votre cas précis, testez vous-même sur vos données. Un modèle "moins bon" en général peut être excellent sur votre niche.

Conclusion : le prompt engineering reste une compétence

Même en 2026, même avec GPT-5 qui arrive, écrire un bon prompt reste un investissement rentable. Ce qui change : les astuces magiques disparaissent, le fondamental reste.

Mes 3 règles personnelles :

1. Rôle précis, tâche claire, format imposé. Si l'un des trois manque, le prompt est fragile.
2. Few-shot chaque fois que possible. C'est le meilleur ratio effort/qualité.
3. Tester sur plusieurs providers. Si votre prompt ne marche que sur GPT-4o, vous payez trop cher.

Le prompt engineering en 2026 n'est plus de la magie. C'est de l'ingénierie.

← Retour au blog