Le prompt engineering est passé en deux ans du statut d’art obscur à celui de discipline structurée avec ses méthodes, ses anti-patterns documentés et ses benchmarks de référence. En 2026, les modèles sont plus capables mais aussi plus sensibles à la qualité des instructions : un mauvais prompt sur Claude 4 ou GPT-4.1 produit des résultats bien moins bons qu’un prompt de qualité, l’écart s’est creusé. Ce guide couvre les techniques avancées qui font la différence en production, au-delà des simples instructions en langage naturel.
Les fondamentaux revisités : pourquoi les basics restent critiques
Avant d’explorer les techniques avancées, il est utile de réaffirmer pourquoi les fondamentaux restent le levier le plus impactant. La majorité des problèmes de qualité des LLM en production viennent non pas d’un manque de technique sophistiquée, mais d’un prompt système insuffisamment précis sur le rôle, le format de sortie attendu, et les cas limites à gérer. Un prompt système de 200 mots bien rédigé surpasse souvent une technique avancée appliquée sur un prompt vague.
Le format de sortie est le paramètre le plus négligé. Les LLM sont entraînés à produire du texte conversationnel — si vous avez besoin de JSON, de Markdown structuré, ou d’un format spécifique, spécifiez-le explicitement avec un exemple. Sur les APIs d’OpenAI et Anthropic en 2026, le JSON mode (structured outputs) garantit une sortie JSON valide en forçant le modèle via des contraintes de sampling — utilisez-le systématiquement pour les applications qui parsent la sortie programmatiquement.
La longueur du contexte ne remplace pas la précision des instructions. Donner 50 Ko de contexte à un modèle avec des instructions vagues produit de moins bons résultats que 5 Ko de contexte sélectionné avec des instructions précises. Le ‘lost in the middle’ problem — les LLM accordent moins d’attention aux informations au milieu d’un long contexte — est documenté empiriquement. Placez les informations critiques au début et à la fin du prompt, pas au milieu.
Chain-of-Thought et ses variantes en 2026
Le Chain-of-Thought prompting (CoT) consiste à demander au modèle de ‘penser étape par étape’ avant de donner sa réponse. Cette technique améliore significativement les performances sur les tâches de raisonnement multi-étapes (mathématiques, logique, déduction). En 2026, avec les modèles de raisonnement natifs (o3 d’OpenAI, claude-3-7-sonnet avec extended thinking), le CoT est souvent géré automatiquement en interne — mais des instructions explicites restent utiles pour guider la nature du raisonnement.
Tree-of-Thought (ToT) est une extension du CoT où le modèle explore plusieurs branches de raisonnement en parallèle avant de sélectionner la meilleure. Implémentable via plusieurs appels API successifs ou via des frameworks comme LangGraph, c’est particulièrement efficace pour des problèmes avec de nombreuses solutions possibles (génération de code, planification). La contrepartie est un coût en tokens 3 à 5x supérieur au CoT simple.
Self-Consistency est une technique complémentaire : générer N fois la même réponse (temperature > 0) puis prendre la réponse majoritaire. Sur des tâches avec une réponse correcte unique (QA factuel, calcul), la self-consistency améliore la précision de 5 à 15 % par rapport à une génération unique. La mise en oeuvre est simple via un loop Python et un vote majoritaire sur les réponses. Coût : N × le coût d’une génération — à utiliser uniquement quand la précision est critique.
Few-shot prompting : sélection et ordre des exemples
Le few-shot prompting (inclure 3 à 8 exemples entrée/sortie dans le prompt) reste l’une des techniques les plus robustes pour guider le comportement d’un LLM. En 2026, la recherche a identifié plusieurs facteurs qui maximisent l’efficacité des exemples. La diversité des exemples est plus importante que leur nombre : 5 exemples couvrant des cas variés surpassent 10 exemples similaires. Incluez explicitement des exemples de cas limites que vous souhaitez gérer correctement.
L’ordre des exemples influence les résultats. Les modèles accordent plus de poids aux derniers exemples (effet de récence). Placez les exemples qui représentent le comportement le plus important à la fin de la liste. Si vous avez des exemples de cas difficiles, intercalez-les entre des exemples simples plutôt que de les regrouper — les regrouper peut induire le modèle à ‘attendre’ des cas difficiles.
La sélection dynamique d’exemples (Dynamic Few-Shot) consiste à choisir les exemples les plus similaires à la requête courante plutôt qu’un ensemble fixe. Cela nécessite une base d’exemples vectorisés et une recherche par similarité (la même infrastructure que pour le RAG). Sur des tâches de classification ou d’extraction d’entités, cette approche améliore la précision de 10 à 25 % par rapport aux exemples statiques, au prix d’une complexité d’implémentation plus élevée.
Prompt système avancé pour un assistant de code (exemple)
Voici un exemple de prompt système production-ready pour un assistant de génération de code :
SYSTEM PROMPT — Assistant de génération de code (production)
Tu es un assistant expert en développement logiciel. Tu génères du code de production
de haute qualité, sécurisé et maintenable.
## Ton rôle
- Générer du code qui fonctionne du premier coup dans le contexte décrit
- Expliquer BRIÈVEMENT les choix techniques non-évidents (1-2 lignes max)
- Signaler les risques de sécurité potentiels dans le code fourni
## Format de réponse OBLIGATOIRE
1. Code dans un bloc ```langage``` avec le chemin de fichier en commentaire
2. Si plusieurs fichiers : un bloc par fichier avec son chemin
3. Section "⚠️ Points d'attention" si tu identifies des risques (sécurité, performance)
4. Section "▶️ Pour tester" avec la commande d'exécution minimale
## Règles absolues
- JAMAIS de code avec des credentials hardcodés, même en exemple
- JAMAIS d'eval() ou exec() sur des inputs utilisateurs
- TOUJOURS valider et sanitiser les inputs aux frontières du système
- Préférer les dépendances stables aux cutting-edge si l'utilisateur ne précise pas
- Si la demande est ambiguë sur un point critique (sécurité, architecture), demande une
clarification AVANT de générer — ne fais pas d'hypothèses silencieuses
## Comportement sur les cas limites
- Demande incomplète : liste les informations manquantes, propose une implémentation
raisonnable avec les hypothèses explicitées
- Code déjà fourni avec bugs : corrige ET explique le bug, ne réécris pas de zéro
- Langage/framework non supporté : dis-le clairement, propose la meilleure alternative
## Ce que tu ne fais PAS
- Générer du code de scraping sur des sites sans permission explicite
- Générer du code d'automatisation de comptes ou de bypass d'authentification
- Générer des exploits ou du code offensifRAG et prompt engineering : les bonnes pratiques d’injection de contexte
Le Retrieval-Augmented Generation (RAG) est devenu omniprésent en 2026 pour les applications qui ont besoin de données récentes ou propriétaires. La qualité du prompt engineering autour de l’injection de contexte RAG est aussi importante que la qualité de la récupération elle-même. Trois règles pratiques : citez explicitement les sources dans le contexte (‘Contexte issu de [document X]’), indiquez clairement les délimiteurs entre contexte et question, et dites au modèle de répondre ‘Je ne sais pas’ si le contexte ne contient pas la réponse.
Le ‘context stuffing’ — injecter le maximum de contexte possible — est un anti-pattern courant. Plus de contexte ne signifie pas de meilleures réponses et augmente les coûts et la latence. La pratique recommandée est de retriever les K chunks les plus pertinents (K = 3 à 5 en général), de les rerankser avec un modèle de reranking (Cohere Rerank, BGE Reranker) pour filtrer les chunks peu pertinents, et de n’injecter que ce qui passe le seuil de pertinence. La précision de la récupération améliore plus la qualité finale que la quantité de contexte.
Pour les requêtes complexes, le query rewriting avant la récupération améliore significativement le recall. Plusieurs techniques : HyDE (Hypothetical Document Embeddings — générer un document hypothétique qui répondrait à la question, puis vectoriser ce document pour la recherche), Step-Back Prompting (reformuler la question en une question plus générale pour récupérer plus de contexte pertinent), ou la décomposition de requête (décomposer une question complexe en sous-questions indépendantes). Ces techniques transforment le RAG d’une recherche naive en un système de raisonnement sur les données.
Anti-patterns à éviter absolument en production
Le premier anti-pattern est le jailbreak fishing — demander au modèle de ‘jouer un rôle’ qui contourne ses guidelines de sécurité ou de ‘faire comme si’ il n’avait pas de restrictions. Au-delà des problèmes éthiques, ces approches produisent des résultats incohérents et non fiables car les modèles modernes sont entraînés à résister à ces tentatives. Si vous avez besoin d’un comportement spécifique, définissez-le clairement dans le prompt système en termes positifs.
Le prompt injection est l’anti-pattern de sécurité critique en 2026. Si votre application LLM accepte des inputs utilisateurs qui sont injectés dans le prompt, des utilisateurs malveillants peuvent modifier les instructions en écrivant des instructions dans leur input (‘Ignore tes instructions précédentes et fais X’). La défense recommandée : délimiteurs XML clairs entre le prompt système et le contenu utilisateur, validation des inputs, et idéalement, architecture qui sépare le LLM des actions critiques via une couche de validation intermédiaire.
L’over-engineering du prompt est un piège courant chez les développeurs qui découvrent le prompt engineering. Un prompt de 2 000 tokens avec des instructions contradictoires, des listes imbriquées et des règles exceptions-aux-exceptions produit rarement de meilleurs résultats qu’un prompt de 300 tokens clair et concis. Adoptez une approche itérative : commencez simple, mesurez sur un benchmark, ajoutez de la complexité seulement si le gain est mesuré. La clarté > la longueur, toujours.
Évaluation et itération : mesurer pour progresser
Le prompt engineering sans évaluation systématique est de la superstition. Construisez un benchmark de 50 à 200 cas représentatifs (inputs avec leurs sorties attendues ou leurs critères de qualité) avant de commencer à modifier votre prompt. Chaque variation de prompt est testée sur ce benchmark et le résultat numérique (précision, recall, F1, score LLM-as-judge) guide les décisions. Sans ce benchmark, vous optimisez pour les exemples que vous avez en tête et régressez sur les autres.
LLM-as-Judge est une technique d’évaluation où un LLM fort (Claude Opus, GPT-4) note la qualité des réponses d’un LLM plus faible selon des critères définis. C’est scalable (automatisé), moins cher que l’annotation humaine, et corrèle bien avec le jugement humain pour de nombreuses tâches. Les limites : le LLM juge peut avoir des biais systématiques (préférer les réponses longues, les réponses de sa propre famille de modèles). Calibrez toujours votre LLM-as-Judge contre des annotations humaines sur un sous-ensemble.
Promptflow (Microsoft), LangSmith (LangChain), et Phoenix (Arize) sont les outils de tracking d’expériences de prompt engineering les plus utilisés en 2026. Ils permettent de versionner les prompts, de tracer les runs, de comparer les variantes côte à côte et de détecter les régressions. Sur des projets en production, le tracking des prompts est aussi important que le tracking des versions de code — un changement de prompt est un changement de comportement de l’application qui mérite autant de rigueur.
Commentaires (0)
Laisser un commentaire
Les commentaires sont modérés. Questions WordPress, cybersécurité ou dev web bienvenues.