Prompt engineering avancé : les techniques qui changent vraiment les résultats

Sur LinkedIn, le prompt engineering se résume souvent à "soyez précis" et "donnez du contexte". Dans une application d'entreprise en production, ces conseils ne valent rien. Ce qui fait la différence, ce sont des techniques d'ingénierie rigoureuses que très peu d'articles en français expliquent correctement.

Chez Tensoria, nous concevons des system prompts de production pour des assistants RAG, des agents IA et des pipelines d'automatisation au quotidien. Ce travail représente souvent 2 à 3 jours d'ingénierie par projet. Pas une "astuce de 5 minutes", une vraie discipline technique.

Cet article présente les techniques de prompt engineering avancé qui changent réellement les résultats en contexte professionnel. Chaque technique est illustrée par des exemples métier concrets, pas par des démos académiques.

Pourquoi le prompt engineering "basique" ne suffit pas en entreprise

La plupart des conseils qu'on trouve en ligne concernent l'utilisation conversationnelle de ChatGPT : poser une bonne question, reformuler si la réponse est mauvaise, demander un format particulier. C'est utile pour un usage personnel. C'est insuffisant pour un usage professionnel.

En entreprise, un prompt ne sert pas à discuter avec un chatbot. Il sert à alimenter un système de production : un assistant qui répond aux clients, un pipeline qui classe des documents, un agent qui génère des devis. La différence fondamentale :

C'est cette différence qui fait du prompt engineering une discipline d'ingénierie, pas une collection de tips. Dans nos projets, un bon system prompt structuré peut améliorer la qualité des sorties de 30 à 50 % sans toucher au modèle ni aux données.

Les fondamentaux qui changent tout

Avant d'aborder les techniques avancées, quatre éléments de base doivent être maîtrisés. Ce sont les fondations de tout prompt de production.

Définir un rôle précis

Le rôle n'est pas une formalité. Il conditionne le registre de vocabulaire, le niveau de détail et les hypothèses que le modèle va poser. Comparez :

❌ "Analyse ce contrat."

✅ "Tu es un juriste spécialisé en droit des contrats commerciaux français.
Tu analyses des contrats de prestation de service pour identifier :
- les clauses de responsabilité déséquilibrées
- les pénalités de retard excessives
- les clauses de résiliation abusives
Tu raisonnes en droit français (Code civil, Code de commerce)."

Le second prompt active un registre lexical spécialisé et des schémas de raisonnement adaptés. Le modèle ne "devient" pas juriste, mais il mobilise les connaissances pertinentes de façon plus ciblée.

Fournir le contexte métier, pas le contexte technique

L'erreur classique : donner au modèle des instructions techniques ("utilise le format JSON avec les clés suivantes") sans lui expliquer pourquoi. Un LLM produit de meilleurs résultats quand il comprend l'objectif métier.

❌ "Extrais les entités du texte en JSON."

✅ "Tu traites des emails de réclamation client pour un bureau d'études BTP.
Ton objectif : extraire les informations nécessaires pour créer un ticket
dans notre CRM (client, projet concerné, nature du problème, urgence).
Format de sortie : JSON avec les clés client_name, project_ref,
issue_type, urgency_level (1 à 5), summary."

Spécifier le format de sortie explicitement

En production, "donne-moi un résumé" ne suffit pas. Il faut définir la longueur, la structure, les contraintes. Nous reviendrons en détail sur le structured output plus bas, mais le principe est simple : tout ce qui n'est pas spécifié sera improvisé par le modèle.

Poser les contraintes et les interdictions

Les LLM ont tendance à être "serviables" au point d'inventer des informations quand ils n'en ont pas. En production, les interdictions explicites sont aussi importantes que les instructions :

CONTRAINTES :
- Si tu ne trouves pas l'information dans le contexte fourni,
  réponds "Information non disponible". Ne fabrique JAMAIS de donnée.
- Ne cite JAMAIS de texte juridique dont tu n'es pas certain de l'exactitude.
- Limite ta réponse à 200 mots maximum.
- Si la demande est ambiguë, liste les interprétations possibles
  au lieu de choisir silencieusement.

Chain-of-thought : forcer le raisonnement étape par étape

Le chain-of-thought (CoT) est la technique la plus documentée en recherche académique, et pourtant la plus mal utilisée en entreprise. Le principe est simple : demander au modèle d'expliciter son raisonnement avant de donner sa réponse finale.

Pourquoi le CoT change les résultats

Un LLM qui répond directement "saute" des étapes de raisonnement. Sur des tâches simples, ça passe. Sur des tâches qui demandent du raisonnement (analyse, classification complexe, diagnostic), les erreurs se multiplient. Le CoT force le modèle à décomposer son raisonnement, ce qui réduit significativement les erreurs logiques.

Exemple métier : analyse de conformité contractuelle

Tu es un analyste juridique. Analyse la clause suivante et détermine
si elle est conforme aux standards du marché.

RAISONNE ÉTAPE PAR ÉTAPE :
1. Identifie le type de clause (responsabilité, résiliation, pénalité, etc.)
2. Résume ce que la clause stipule en langage clair
3. Compare avec la pratique standard du marché pour ce type de contrat
4. Identifie les points de vigilance ou déséquilibres
5. Donne ton verdict : CONFORME / À NÉGOCIER / RISQUE ÉLEVÉ

Clause à analyser :
"""
{clause_text}
"""

Sans le CoT, le modèle donne un verdict avec une explication vague. Avec le CoT, il produit une analyse structurée et traçable. Dans un contexte où un cabinet d'avocats utilise l'IA pour pré-analyser des contrats, cette traçabilité est indispensable.

Exemple métier : diagnostic technique

Tu es un technicien de maintenance industrielle expérimenté.
Un opérateur signale le problème suivant sur une machine CNC.

PROCÉDURE DE DIAGNOSTIC :
1. Analyse les symptômes décrits
2. Liste les 3 causes les plus probables, classées par fréquence
3. Pour chaque cause, indique le test de vérification à effectuer
4. Recommande l'ordre d'investigation (du plus simple au plus complexe)

Signalement :
"""
{incident_description}
"""

Le CoT transforme une réponse générique en un protocole de diagnostic actionnable. C'est la différence entre un outil qui impressionne en démo et un outil que les techniciens utilisent réellement sur le terrain.

Few-shot prompting : montrer au modèle ce que vous attendez

Le few-shot prompting est probablement la technique la plus sous-estimée. Le principe : fournir au modèle quelques exemples concrets de ce que vous attendez (entrée + sortie souhaitée) avant de lui soumettre la vraie requête.

Sur un projet de classification de mails pour un cabinet comptable, 5 exemples dans le prompt ont fait passer la précision de 72 % à 94 %. Le modèle n'a pas changé, les données n'ont pas changé. Seul le prompt a été enrichi d'exemples.

Comment bien choisir ses exemples

Le few-shot ne consiste pas à mettre 10 exemples identiques. La qualité des exemples compte plus que la quantité :

• Variété : couvrir les différentes catégories ou cas de figure, y compris les cas limites
• Représentativité : utiliser des exemples tirés de vraies données, pas des cas idéalisés
• Cohérence : le format de sortie doit être identique dans chaque exemple
• Parcimonie : 3 à 5 exemples suffisent dans la majorité des cas. Au-delà de 8, les gains sont marginaux

Exemple métier : classification d'emails entrants

Tu classes les emails entrants d'un cabinet comptable.
Catégories possibles : FISCAL, SOCIAL, COMPTABLE, JURIDIQUE, ADMIN, SPAM.

EXEMPLES :

Email : "Bonjour, nous avons reçu un contrôle URSSAF, quels documents
devons-nous préparer ?"
Catégorie : SOCIAL
Justification : Contrôle URSSAF = cotisations sociales, domaine social.

Email : "Pouvez-vous nous confirmer le montant de TVA collectée
sur le T3 2025 ?"
Catégorie : FISCAL
Justification : TVA = fiscalité, demande de données fiscales.

Email : "Notre salarié en CDD souhaite une rupture conventionnelle,
est-ce possible ?"
Catégorie : JURIDIQUE
Justification : Rupture conventionnelle d'un CDD = question de droit
du travail, pas de gestion sociale courante.

Email : "Les factures fournisseurs de janvier ne sont pas encore
comptabilisées dans le grand livre."
Catégorie : COMPTABLE
Justification : Grand livre, saisie de factures = comptabilité courante.

---

Email à classer :
"""
{email_content}
"""

Réponds au format :
Catégorie : [CATÉGORIE]
Justification : [une phrase]

L'exemple 3 est volontairement un cas limite (CDD + rupture conventionnelle : social ou juridique ?). C'est précisément ces cas ambigus qui font la différence en production. Pour aller plus loin sur les prompts métier, consultez nos guides dédiés aux prompts IA pour la comptabilité et aux prompts IA pour les RH.

Structured output : forcer des formats exploitables par du code

En production, la sortie d'un LLM est rarement lue par un humain. Elle est parsée par du code, injectée dans un CRM, stockée en base de données. Le structured output consiste à forcer le modèle à produire un format strict (JSON, XML, CSV) que votre code peut exploiter de façon fiable.

Les trois niveaux de structured output

Niveau 1 : instruction dans le prompt. Vous demandez au modèle de répondre en JSON. Ça marche dans 90 % des cas, mais le modèle peut ajouter du texte avant ou après le JSON, ou produire un JSON invalide.

Niveau 2 : JSON mode natif. La plupart des API modernes (OpenAI, Anthropic, Mistral) proposent un mode JSON qui garantit une sortie JSON valide. C'est le minimum en production.

Niveau 3 : JSON Schema contraint. Vous définissez un schéma JSON précis (types, champs obligatoires, valeurs autorisées) et l'API garantit que la sortie le respecte. C'est la référence pour les systèmes critiques.

Exemple métier : extraction structurée depuis un bon de commande

Extrais les informations du bon de commande ci-dessous.

Réponds UNIQUEMENT avec un objet JSON valide, sans texte avant ni après.
Respecte exactement ce schéma :

{
  "numero_commande": "string",
  "date_commande": "YYYY-MM-DD",
  "client": {
    "nom": "string",
    "siret": "string ou null"
  },
  "lignes": [
    {
      "reference": "string",
      "designation": "string",
      "quantite": number,
      "prix_unitaire_ht": number
    }
  ],
  "total_ht": number,
  "tva_applicable": "string (ex: 20%, 10%, 5.5%)",
  "total_ttc": number,
  "confidence_score": number entre 0 et 1
}

Si une information est illisible ou absente, utilise null.
Le champ confidence_score reflète ta confiance globale dans l'extraction.

Bon de commande :
"""
{document_text}
"""

Le champ confidence_score est un pattern que nous utilisons systématiquement chez Tensoria. Il permet au code en aval de décider automatiquement si l'extraction est fiable (score > 0.85) ou si elle nécessite une validation humaine (score < 0.85). C'est une brique essentielle dans les systèmes IA que nous déployons.

Self-consistency : réduire les hallucinations

Le self-consistency est une technique de validation croisée. Au lieu d'appeler le modèle une fois et de faire confiance au résultat, vous l'appelez plusieurs fois (3 à 5 appels) avec le même prompt, puis vous comparez les réponses.

Le principe

Si le modèle donne la même réponse 4 fois sur 5, la confiance est élevée. S'il donne 3 réponses différentes sur 5, le résultat est incertain et nécessite une intervention humaine.

En pratique, cette technique se combine bien avec le chain-of-thought : chaque appel produit un raisonnement différent, mais la conclusion convergente valide la réponse.

Quand utiliser le self-consistency

• Extraction de données critiques : montants financiers, dates contractuelles, noms propres
• Classification à enjeu : triage de réclamations, détection de fraude, scoring de leads
• Diagnostic technique : quand une erreur de classification coûte plus cher que 5 appels API

Le coût est multiplié par le nombre d'appels (x3 à x5), mais pour les tâches critiques, c'est un investissement largement rentable. Sur un pipeline d'extraction de données financières, nous avons réduit le taux d'erreur de 8 % à moins de 2 % avec 3 appels en self-consistency.

Prompt chaining : découper une tâche complexe en étapes

Le prompt chaining (chaînage de prompts) consiste à découper une tâche complexe en une séquence d'étapes, chacune gérée par un prompt spécialisé. La sortie de l'étape N devient l'entrée de l'étape N+1.

Pourquoi c'est plus fiable qu'un prompt unique

Un prompt qui essaie de tout faire en une fois ("lis ce document, extrais les entités, vérifie la cohérence, génère un résumé et propose des actions") a un taux d'erreur cumulatif élevé. Chaque sous-tâche ajoutée dégrade la performance globale.

Le prompt chaining isole chaque étape. Si l'extraction échoue, vous le savez immédiatement sans que la suite du pipeline ne produise des résultats erronés en cascade.

Exemple métier : pipeline de traitement d'une candidature RH

ÉTAPE 1 : Extraction structurée du CV
→ Input : CV en texte brut
→ Output : JSON (nom, expérience, compétences, formation)
→ Prompt : spécialisé extraction, avec few-shot

ÉTAPE 2 : Matching avec la fiche de poste
→ Input : JSON du CV + fiche de poste
→ Output : score de matching (0-100) + justification
→ Prompt : spécialisé évaluation, avec chain-of-thought

ÉTAPE 3 : Génération du compte-rendu pour le recruteur
→ Input : JSON du CV + score + justification
→ Output : texte formaté de 150 mots max
→ Prompt : spécialisé rédaction, ton professionnel

Chaque étape utilise un prompt optimisé pour une seule tâche. En cas d'erreur, on sait exactement où intervenir. Cette architecture est la base de nos agents IA déployés en production avec n8n.

System prompts de production : architecture et bonnes pratiques

Le system prompt est le prompt permanent qui cadre le comportement du modèle dans une application. C'est l'équivalent d'un cahier des charges technique pour votre IA. Quand nous construisons un assistant RAG, le system prompt représente souvent 2 à 3 jours de travail d'ingénierie.

Anatomie d'un system prompt de production

Un system prompt professionnel suit une structure standardisée :

## IDENTITÉ
Tu es [rôle précis] pour [entreprise/contexte].

## MISSION
Ton objectif principal : [objectif clair et mesurable].

## RÈGLES MÉTIER
- [Règle 1 : contrainte spécifique au domaine]
- [Règle 2 : interdiction critique]
- [Règle 3 : comportement en cas d'incertitude]

## SOURCES DE DONNÉES
Tu as accès à [description des sources].
Tu ne dois utiliser QUE ces sources pour tes réponses factuelles.

## FORMAT DE SORTIE
[Structure précise attendue]

## GESTION DES CAS LIMITES
- Si la question sort de ton périmètre : [comportement]
- Si l'information n'est pas dans tes sources : [comportement]
- Si la demande est ambiguë : [comportement]

## EXEMPLES
[2-3 exemples few-shot de l'échange attendu]

Les erreurs les plus fréquentes dans les system prompts

Après avoir audité des dizaines de system prompts pour nos clients via notre service d'audit IA, voici les erreurs récurrentes :

1. Trop vague sur les interdictions. "Sois précis" ne veut rien dire. "Ne cite jamais de montant que tu n'as pas trouvé dans les documents fournis" est une vraie contrainte.
2. Pas de gestion des cas limites. Le modèle fait face à des cas imprévus tous les jours. Sans instructions explicites, il improvise, et l'improvisation en production coûte cher.
3. Exemples absents ou génériques. Sans few-shot, le modèle interprète vos instructions à sa façon. Avec 2-3 exemples concrets, il calibre précisément le niveau de détail et le ton attendus.
4. Prompt trop long sans priorisation. Un prompt de 3 000 tokens où tout est au même niveau d'importance. Le modèle ne sait pas ce qui est critique et ce qui est secondaire. Structurez avec des sections claires et des mots-clés comme "CRITIQUE", "OBLIGATOIRE", "OPTIONNEL".
5. Aucune instruction sur le format de sortie. Le modèle alterne entre prose, listes à puces, tableaux et JSON selon son "humeur". En production, le format doit être prévisible à 100 %.

Les erreurs de prompt engineering les plus coûteuses

Au-delà des erreurs de system prompt, certaines erreurs de méthodologie coûtent cher en temps et en argent.

Erreur 1 : optimiser le prompt sans jeu de test

Modifier un prompt "à l'instinct" en testant sur 2-3 cas puis déployer en production. C'est l'équivalent de coder sans tests unitaires. Chaque modification de prompt doit être validée sur un jeu de test représentatif (20 à 50 cas minimum) qui couvre les cas normaux ET les cas limites.

Erreur 2 : ignorer le coût en tokens

Un prompt enrichi de 10 exemples few-shot et d'instructions détaillées consomme plus de tokens. Si ce prompt est exécuté 500 fois par jour, la différence entre un prompt de 500 tokens et un prompt de 2 000 tokens représente des centaines d'euros par mois. Il faut trouver le juste équilibre entre précision et coût.

Erreur 3 : ne pas versionner ses prompts

Un prompt de production évolue. Sans historique des versions, impossible de savoir pourquoi une modification a été faite, ni de revenir en arrière si les performances se dégradent. Traitez vos prompts comme du code : versionnez-les, documentez les changements, mesurez l'impact.

Erreur 4 : compenser un mauvais prompt par un modèle plus puissant

J'ai vu des clients dépenser 10 000 euros en fine-tuning alors qu'un prompt bien construit en chain-of-thought aurait résolu 80 % du problème. Avant de changer de modèle ou de lancer un fine-tuning, épuisez les possibilités du prompt engineering. C'est plus rapide, moins cher, et réversible.

Quand le prompt engineering ne suffit plus

Le prompt engineering a ses limites. Savoir les reconnaître évite de perdre des semaines à itérer sur un prompt qui ne résoudra jamais le problème.

Les signaux qui indiquent qu'il faut aller plus loin

• Le prompt dépasse la fenêtre de contexte. Si vos exemples few-shot + instructions + contexte RAG saturent la fenêtre, il faut repenser l'architecture (chunking, résumé, ou fine-tuning).
• Le modèle n'adopte pas le bon style/ton. Si malgré les exemples, le modèle ne produit pas le registre de langue souhaité, un fine-tuning sur des exemples de votre production peut être justifié.
• Le coût en tokens explose. Un prompt très long exécuté des milliers de fois par jour : le fine-tuning peut absorber les instructions dans les poids du modèle et réduire drastiquement le coût d'inférence.
• Les données nécessaires ne sont pas dans le prompt. Si le modèle a besoin d'accéder à des documents, bases de données ou historiques, c'est un cas d'usage pour le RAG, pas pour un prompt plus long.

Le passage naturel se fait généralement ainsi : prompt engineering → RAG (pour l'accès aux données) → fine-tuning (pour le style ou les coûts). Pour comprendre les pièges à éviter lors de cette transition, consultez notre article sur les erreurs qui font échouer les projets RAG. Et pour savoir exactement quand le fine-tuning vaut l'investissement, notre guide sur le fine-tuning LLM en PME détaille les critères de décision.

Table récapitulative : quelle technique pour quel besoin

Ces techniques ne sont pas mutuellement exclusives. Un system prompt de production combine généralement un rôle précis, des exemples few-shot, des contraintes de format structuré et du chain-of-thought sur les étapes critiques. L'art du prompt engineering avancé, c'est de savoir quelles techniques combiner pour chaque cas d'usage.

Pour voir ces techniques appliquées dans un contexte RAG, consultez notre guide sur l'optimisation des systèmes RAG où le prompt engineering est une des briques fondamentales.

Questions fréquentes

Pour aller plus loin

Le prompt engineering avancé n'est pas une mode passagère. C'est une compétence fondamentale pour toute entreprise qui déploie de l'IA en production. Les techniques présentées dans cet article (chain-of-thought, few-shot, structured output, self-consistency, prompt chaining, system prompts structurés) sont celles que nous appliquons quotidiennement chez Tensoria.

La bonne nouvelle : ces techniques sont accessibles. Elles ne nécessitent pas de changer de modèle, de réentraîner quoi que ce soit, ni d'investir dans de l'infrastructure. Un prompt mieux conçu coûte le même prix qu'un mauvais prompt. Seul le résultat change.

Si vos prompts de production ne donnent pas les résultats attendus, commencez par appliquer les fondamentaux (rôle, contexte, format, contraintes), ajoutez du few-shot sur les cas critiques, et structurez vos sorties en JSON. Ces trois actions seules résolvent la majorité des problèmes.

Articles recommandés

• Fine-tuning LLM en PME : quand ça vaut le coup : comprendre quand le prompt ne suffit plus et quand investir dans le fine-tuning.
• RAG en entreprise : tout comprendre : le prompt engineering dans un contexte de Retrieval-Augmented Generation.
• Optimiser votre système RAG : les techniques de prompt engineering appliquées à la couche de génération d'un RAG.
• Agents IA vs chatbots pour PME : le rôle du prompt engineering dans la conception d'agents autonomes.
• Agents IA n8n en production : comment le prompt engineering s'intègre dans des pipelines d'automatisation réels.
• 5 erreurs qui font échouer les projets RAG : les pièges classiques, dont les erreurs de prompting, dans les projets RAG.
• Prompts IA pour avocats, pour la comptabilité et pour les RH : des listes de prompts métier prêts à l'emploi.
• RAG vs fine-tuning : comment choisir : quand le prompt engineering ne suffit plus, quelle architecture adopter.
• Évaluer un LLM en entreprise : mesurer objectivement si vos prompts donnent les bons résultats.
• Déployer un LLM en production : l'infrastructure derrière les prompts de production.
• Embeddings et recherche sémantique : la technologie derrière la recherche dans un RAG.