Prompt engineering pour Product Owners : les bases qui changent tout

Le prompt engineering est souvent présenté comme une discipline technique réservée aux développeurs. C’est faux. C’est avant tout une compétence de communication — et les Product Owners ont tout ce qu’il faut pour exceller dedans.

Voici les bases qui font vraiment la différence.

Ce qu’un LLM fait vraiment

Avant d’écrire un prompt, il faut comprendre ce que vous demandez réellement à un LLM.

Un LLM ne “comprend” pas vos instructions dans le sens humain du terme. Il génère une réponse qui ressemble statistiquement à ce qu’il a appris à générer dans des contextes similaires. Il suit des patterns, pas des intentions.

Cette distinction change tout dans la façon d’écrire des prompts. Au lieu de se demander “est-ce que c’est clair pour un humain ?”, la bonne question est : “est-ce que le pattern que je décris est suffisamment précis pour que le modèle ne puisse pas l’interpréter autrement ?”

Les 4 composants d’un prompt système efficace

1. Le rôle

Commencez par définir qui est le modèle dans ce contexte :

“Tu es un assistant spécialisé dans la gestion de tickets support pour une SaaS B2B.”

Ce n’est pas de la magie — c’est de l’ancrage contextuel. Le modèle va s’appuyer sur tout ce qu’il a appris sur ce rôle pour calibrer ses réponses.

2. Le périmètre

Dites explicitement ce que l’agent fait ET ce qu’il ne fait pas :

“Tu traites uniquement les demandes liées aux fonctionnalités du produit. Tu ne donnes pas de conseils sur les tarifs, la facturation ou les contrats — pour ces sujets, tu rediriges vers l’équipe commerciale.”

Les LLMs ont tendance à vouloir être utiles sur tout. Définir des limites claires évite les réponses hors-scope.

3. Le format de sortie

Ne laissez jamais le format au hasard :

“Réponds toujours en JSON avec cette structure exacte :

{
  "categorie": "bug" | "question" | "feature_request",
  "priorite": "basse" | "moyenne" | "haute" | "critique",
  "resume": "string (max 80 caractères)",
  "action_suggree": "string"
}
```"

Si vous n’avez pas besoin de JSON mais d’une réponse lisible, définissez quand même la structure : titres, longueur, ton.

4. Les exemples

Les exemples sont le composant le plus sous-utilisé. Un exemple vaut mieux que trois paragraphes de description :

“Exemples : Input: ‘Je n’arrive pas à me connecter depuis ce matin’ Output: {"categorie": "bug", "priorite": "haute", ...}

Input: ‘Comment exporter mes données ?’ Output: {"categorie": "question", "priorite": "basse", ...}”

Les erreurs les plus communes

Utiliser des adjectifs subjectifs sans les définir. “Réponds de façon professionnelle” ne veut rien dire pour un LLM. “Utilise le vouvoiement, évite les expressions familières, termine par une question ou une proposition d’action” — voilà de la précision.

Ne pas gérer les cas d’incertitude. Que fait l’agent quand il ne sait pas ? Sans instruction, il invente. Avec instruction : “Si tu n’es pas sûr de la catégorie, utilise ‘autre’ et explique pourquoi dans le champ notes.”

Écrire le prompt une fois et ne jamais le retoucher. Un prompt système est un artefact vivant. Il faut le faire évoluer en fonction des cas réels que vous observez en production.

Un template pour démarrer

# Rôle
[Qui es-tu ? Dans quel contexte ?]

# Ce que tu fais
[Description précise des tâches]

# Ce que tu ne fais pas
[Limites explicites du périmètre]

# Format de réponse
[Structure exacte attendue]

# Comportement en cas d'incertitude
[Que faire si l'input est ambigu ?]

# Exemples
Input: [exemple 1]
Output: [output attendu 1]

Input: [exemple 2]
Output: [output attendu 2]

Vous n’avez pas besoin de code pour écrire un bon prompt. Vous avez besoin de clarté, de précision et d’une bonne dose de pensée critique. Ce sont exactement les compétences qu’on développe en faisant du product management.