Mise en œuvre

Prompt engineering pour entreprise en 2026 — la méthode qui marche vraiment

Au-delà du 'soyez précis' : la méthode de prompt engineering en 6 étapes qu'on déploie en production chez nos clients PME en 2026, avec exemples avant/après.

Le prompt engineering en 2026 n’est plus l’art de “deviner les mots magiques” qu’il était en 2023. C’est une discipline structurée avec des patterns reproductibles. Voici la méthode en 6 étapes qu’on applique en production chez nos clients PME, avec exemples concrets.

Pourquoi votre premier prompt ne marche pas

Quand on demande “rédige-moi un email de relance commercial”, le LLM produit du texte générique parce que :

  • Il ne sait pas qui vous êtes (votre marque, votre tone)
  • Il ne sait pas qui est le destinataire
  • Il ne sait pas le contexte (quel produit, quel deal, quelle relation)
  • Il ne sait pas le format attendu (long ? court ? signature ?)
  • Il n’a pas d’exemple de ce que “bon” veut dire chez vous

Le bon prompt résout les 5 manques. C’est la base de la méthode.

La méthode en 6 étapes

Étape 1 — Donner un rôle

Premier ingrédient : qui doit être l’IA pour cette tâche ?

Tu es responsable commercial senior chez [entreprise], 12 ans d'expérience
dans le SaaS B2B. Ton style est direct mais cordial, jamais commercial agressif.
Tu signes toujours par ton prénom + numéro WhatsApp pour faciliter la relance.

L’effet : le LLM calibre son tone sur ce profil. C’est l’équivalent d’un casting d’acteur avant la scène.

Étape 2 — Donner le contexte de la tâche

Pas la consigne — le contexte avant la consigne. Exemple :

Marie Dupont (CFO, PME industrielle 80 personnes) a demandé une démo de notre
plateforme il y a 3 semaines. Elle a participé à la démo, a posé des questions
techniques pointues, mais n'a pas répondu à notre dernier email il y a 8 jours.
On sait qu'elle compare avec [concurrent X]. Le décisionnaire est son DG.

Le LLM adapte le ton et l’angle au contexte. Une relance sur un dossier chaud est différente d’une relance sur un cold lead.

Étape 3 — Donner la consigne précise

Maintenant le quoi, en imperative claire :

Rédige un email de relance à Marie. Objectif : obtenir un nouvel appel,
idéalement avec son DG cette fois. Format : maximum 120 mots, pas de
"j'espère que vous allez bien", une accroche concrète qui montre qu'on a
suivi sa réflexion, une proposition de créneau, signature standard.

Étape 4 — Donner des exemples (few-shot)

Le levier le plus sous-estimé. 1-3 exemples de ce que “bon” veut dire chez vous :

Voici 2 emails de relance qui ont bien marché chez nous :

Exemple 1 :
Subject: 3 minutes pour aligner Marie + Pierre ?
Hey Marie, vous m'aviez parlé de la complexité du reporting multi-BU
chez [concurrent X]. On a une demo ciblée sur ce point précis [...]

Exemple 2 :
Subject: Le chiffrage que je vous avais promis
Marie, comme convenu après notre échange, voici la fourchette pour [...]

Avec 2-3 exemples, le LLM apprend votre style. Sans exemples, il invente un style générique.

Étape 5 — Donner des contre-exemples

Aussi important : ce qu’il ne doit JAMAIS faire.

Ce qu'il ne faut PAS faire :
- Commencer par "J'espère que vous allez bien" (interdit chez nous)
- Mentionner le prix (on ne le dit jamais en relance)
- Promettre une démo "gratuite" (notre démo n'est jamais "gratuite", elle est "rapide")
- Utiliser des emojis (jamais en B2B chez nous)
- Faire plus de 120 mots (rebute Marie)

Le LLM est très bon pour SUIVRE des contre-règles si on les explicite.

Étape 6 — Demander la livrable au bon format

Réponds en JSON strict avec ces 3 clés :
- subject (string, max 60 caractères)
- body (string, format markdown autorisé)
- proposed_slots (array de 3 créneaux ISO 8601 dans les 5 jours ouvrés)

Aucun texte hors JSON.

Format structuré = exploitable directement par votre CRM. Texte libre = re-traitement humain.

Exemple complet avant / après

Avant (90 % des prompts qu’on voit)

Rédige un email de relance commercial à un prospect.

Sortie : email générique de 200 mots, “j’espère que vous allez bien”, proposition vague d’appel, format texte plat.

Après (méthode en 6 étapes)

[~250 mots structurés selon les 6 étapes ci-dessus]

Sortie : JSON exploitable, ton aligné Kezify, accroche personnalisée, 3 créneaux concrets, 110 mots, signature correcte.

Différence en production : taux d’utilisation par les commerciaux passe de 15 % (ils ré-écrivent tout) à 85 % (ils valident tel quel ou éditent légèrement).

Les 5 anti-patterns courants

Anti-pattern 1 : “Sois créatif”

Vague, déclenche des hallucinations. Préférer “explore 3 angles différents” + lister les angles.

Anti-pattern 2 : “Réponds en français”

Le LLM répond souvent en français déjà. Si vous insistez, il prend ça pour une demande de traduction. Inutile.

Anti-pattern 3 : Prompt-puzzle géant en 1 message

2000 mots de contexte avant la question. Le LLM se perd. Découper en système prompt (rôle + tone) + user prompt (contexte + tâche).

Anti-pattern 4 : “Important: ne fais pas X”

Le mot “important” + caps n’augmente PAS le respect de la règle. Mieux : reformuler positivement (“réponds uniquement en JSON, aucun texte hors JSON”) + exemples + tester.

Anti-pattern 5 : Pas de validation

Vous écrivez un prompt, vous le testez sur 1 cas, vous mettez en prod. Erreur. Il faut tester sur 20-50 cas réels et mesurer le taux de réussite avant de mettre en prod.

La validation : 50-cas dataset minimum

Pour valider qu’un prompt marche en prod :

  1. Constituer 50 cas réels représentatifs (pas synthétiques)
  2. Faire tourner le prompt sur les 50
  3. Annoter manuellement : OK / pas OK / borderline
  4. Si > 90 % OK → prod
  5. Si 70-90 % OK → ajuster sur les borderline, retester
  6. Si < 70 % OK → revoir la méthode (probablement étape 4 manquante)

Sans cette validation, votre prompt fonctionne en démo et casse en prod.

Les outils qu’on utilise chez Kezify

  • Langfuse ou Helicone pour observabilité prompts en prod
  • Promptfoo pour tester un prompt sur 50 cas en parallèle
  • Anthropic Workbench ou OpenAI Playground pour itérer
  • Notion pour documenter les prompts validés (versionné)

L’erreur de positionnement

Le prompt engineering n’est pas un substitut au reste de l’engineering. C’est l’interface entre votre code et le LLM. La majorité du travail reste :

  • Récupérer les bonnes données pour mettre dans le prompt
  • Valider la sortie du LLM avant de l’utiliser
  • Gérer les cas d’erreur (LLM down, output invalide, etc.)
  • Mesurer la qualité en continu

Si quelqu’un vous propose un projet IA “tout en prompt engineering” sans architecture autour, fuyez.

Pour aller plus loin

← Retour au blog
#prompt engineering#Claude#GPT#Mistral