Cas d’usage, Jobs-to-be-done et Golden Prompt Set

1. Pourquoi a‑t‑on besoin des use‑cases et des JTBD pour ChatGPT App

Dans ce module, nous nous intéressons moins à l’UI et au backend qu’au comportement du modèle : à quel moment il décide de lancer notre App et ce qu’il en fait. Pour piloter cela, il nous faut non seulement des fonctionnalités, mais aussi des use‑cases et des JTBD bien décrits.

« Liste de fonctionnalités » contre de vrais scénarios

Classique erreur des équipes techniques : commencer par des phrases du type « notre App sait : choisir des cadeaux, filtrer par prix, trier par popularité ». Utile pour le développeur, mais cela ne dit presque rien sur la manière dont l’utilisateur s’en servira concrètement. Une fonctionnalité est, en somme, une brique. Un use‑case est déjà une maison : contexte, rôle utilisateur, étapes, objectif.

Par exemple, pour notre application d’apprentissage — l’App de sélection de cadeaux GiftGenius, avec laquelle vous travaillez déjà dans le cadre du cours — la liste des fonctionnalités peut ressembler à ceci :

• assistant de collecte du profil du destinataire (âge, intérêts, occasion) ;
• filtre par budget et type de cadeau (numérique/physique) ;
• tri par popularité et « pertinence » ;
• passage à l’achat (ACP/Stripe) depuis la fiche cadeau.

Mais un vrai use‑case sonne autrement :

« Une mère de 35 ans veut, en 60 secondes, choisir un cadeau d’anniversaire pour son fils adolescent de 14 ans, avec un budget jusqu’à 50 $, qui aime les jeux de société et la technologie, et l’acheter immédiatement sous forme de bon numérique en un clic sans quitter ChatGPT. »

Ici apparaît le contexte (qui, pour qui, quelles contraintes, quel format de cadeau et quel canal d’achat), et pas seulement une liste de paramètres. Les product designers insistent sur cette différence : une fonctionnalité est une « unité de valeur », tandis qu’un use‑case est une histoire concrète d’interaction de l’utilisateur avec le système.

Pourquoi est‑ce crucial pour ChatGPT App ?

Parce que le modèle lit votre system-prompt et les descriptions des tools (outils) et tente de les faire correspondre au dialogue en cours. Si vous décrivez votre App comme « sait choisir des cadeaux », le modèle ne comprendra pas toujours que le message de cette mère correspond précisément au scénario où l’App doit s’activer. En revanche, si les prompts et les métadonnées détaillent explicitement plusieurs use‑cases typiques (par exemple « assistant rapide de sélection de cadeau selon le profil du destinataire » ou « sélection d’e‑gifts pour un envoi aux employés »), la probabilité d’une bonne décision par le modèle augmente.

Jobs‑to‑be‑done : pas « quoi faire », mais « pourquoi »

Un use‑case décrit une situation et des étapes. Les Jobs‑to‑be‑done (JTBD) répondent à la question : pourquoi la personne vient‑elle chez vous. Dans la littérature produit, on décrit les JTBD comme « un cadre qui se concentre sur la compréhension de l’objectif concret (job) de l’utilisateur et des processus mentaux qui l’amènent à choisir notre produit pour effectuer ce travail ». Plus simplement : c’est une manière de regarder non pas les fonctionnalités, mais le travail que l’utilisateur “embauche” le produit pour réaliser.

En termes de notre assistant cadeaux GiftGenius, des JTBD possibles :

• « Réduire l’anxiété avant le choix d’un cadeau : j’ai peur d’acheter n’importe quoi et de gâcher l’impression. »
• « Gagner du temps : je n’ai pas l’énergie de parcourir des dizaines de sites cadeaux, montrez‑moi directement le meilleur. »
• « Aider à ne pas oublier une date importante et à répéter rapidement un cadeau réussi. »

Notez : il ne s’agit pas de « choisir un cadeau avec un filtre budget X ». Il s’agit d’objectifs émotionnels et pratiques. Grâce aux JTBD, nous pouvons formuler des instructions plus précises pour le modèle.

Par exemple :

• Si le job est « réduire l’anxiété », le modèle doit :
  • ne pas imposer une seule option comme « la seule correcte » ;
  • expliquer les avantages et inconvénients de 3–7 meilleures options ;
  • encourager les questions de clarification et proposer des alternatives.
• Si le job est « gagner du temps », le modèle doit :
  • donner des listes concises ;
  • éviter les longues introductions ;
  • mettre en avant les différences clés entre les options (« c’est le moins cher », « c’est le plus original »).

Ainsi, les JTBD deviennent des phrases concrètes dans le system-prompt : « Aide à réduire le choix à 3–7 options et explique toujours pourquoi ce sont elles, afin de diminuer l’anxiété de l’utilisateur » ou « Essaie d’économiser le temps de l’utilisateur : évite les essais trop longs et concentre‑toi sur la comparaison des paramètres clés des cadeaux ».

2. Comment dériver des use‑cases à partir d’un « ensemble de fonctionnalités »

Mécanique simple : des fonctionnalités aux histoires

Supposons que nous ayons déjà la liste des capacités de GiftGenius :

• collecte du profil du destinataire (âge, intérêts, occasion) ;
• filtre par budget ;
• filtre par type de cadeau (numérique/physique) ;
• prise en charge RU/EN et différentes devises ;
• achat d’un cadeau numérique via ACP/Stripe.

Pour transformer cela en use‑cases, il est pratique d’utiliser une forme simplifiée d’« user story » : En tant que [qui], je veux [quoi], afin de [pourquoi].

Par exemple :

• En tant qu’ami d’une personne de 30 ans, je veux choisir un cadeau numérique jusqu’à 30$, afin de l’envoyer tout de suite par email.
• En tant que RH, je veux choisir des cartes e‑gift pour 20 employés avec une fourchette de budget, afin de boucler rapidement la tâche des cadeaux d’entreprise.
• En tant que neveu, je veux trouver un cadeau non banal pour l’anniversaire de ma tante, pour qu’elle sente que j’ai vraiment fait un effort.

Chaque use‑case définit immédiatement :

• le rôle (qui parle — un offrant B2C à l’échéance ou un RH/office manager B2B) ;
• les paramètres clés (âge/profil du destinataire, budget, type de cadeau, nombre de destinataires) ;
• les métriques de succès (être prêt pour l’événement, rester dans le budget, coller aux intérêts, ne pas perdre trop de temps).

Tout cela influe directement sur :

• le system-prompt (description des rôles et scénarios dans lesquels le modèle doit activer GiftGenius) ;
• le inputSchema des outils (profile_to_segments, recommend_gifts, get_gift — quels champs sont réellement nécessaires pour ce scénario : âge, intérêts, budget, langue, occasion) ;
• les questions de relance (ce que le modèle peut préciser s’il manque des données : budget, intérêts, numérique vs physique, un destinataire ou une liste).

Tableau use‑case → données → comportement du modèle

Il est pratique de consigner les scénarios dans un tableau simple. Par exemple :

On peut déposer ce tableau directement dans le dépôt, dans docs/use-cases.md, et s’en servir ensuite comme base pour le system-prompt et la conception des outils (ce sera l’objet de la prochaine leçon, mais la logique reste la même).

3. Jobs‑to‑be‑done : transformer la théorie produit en instructions dans le system‑prompt

Comment formuler les JTBD pour une ChatGPT App

Les JTBD sont souvent décrits au format :

« Quand [situation], je veux [motivation], afin de [résultat attendu]. »

Appliquons cela à GiftGenius :

• « Quand je cherche un cadeau dans la panique à la dernière minute, je veux voir rapidement 3–7 idées adaptées avec une explication claire, afin de ne pas passer toute la soirée à douter et quand même faire un choix correct. »
• « Quand je dois sélectionner des cartes e‑gift d’entreprise pour l’équipe, je veux recevoir une liste soignée d’options dans le budget fixé, afin de la faire valider rapidement par mon responsable. »

Ensuite, nous regardons ces formulations et nous nous posons la question d’ingénierie : qu’est‑ce que cela implique pour le comportement du modèle ?

Pour le premier JTBD :

• Ne pas montrer 50 options « au cas où » ;
• Répondre de façon structurée, par exemple : « Meilleures options : 1…, 2…, 3… », plus une brève explication « pourquoi ces options conviennent au profil du destinataire » ;
• Proposer l’étape suivante : « Voulez‑vous voir uniquement des cadeaux numériques ? Préciser le budget ? ».

Pour le second :

• Ne pas mélanger scénarios B2C et B2B ;
• Préciser la taille de l’équipe et le format (mêmes cadeaux pour tous ou différentes catégories) ;
• Mettre en avant les options les plus simples à payer et distribuer (codes e‑gift, liens, abonnements).

Ces conclusions peuvent être transformées directement en fragments de system-prompt :

Ta mission est de réduire l’anxiété de l’utilisateur lors du choix d’un cadeau.
Essaie de :
- limiter la liste de recommandations à 3–7 options ;
- expliquer pourquoi ces options conviennent au profil et au budget du destinataire ;
- proposer une prochaine étape simple si l’utilisateur hésite encore
  (préciser les intérêts, ajuster le budget ou le format du cadeau).

et

Si l’utilisateur dit explicitement qu’il choisit des cadeaux pour un grand groupe
(équipe, département, employés de l’entreprise),
précise la taille du groupe et le format (cartes e-gift, abonnements, etc.),
puis propose des options et des lots plus universels, et non des cadeaux isolés.

Ainsi, le JTBD cesse d’être un joli slide d’atelier produit pour devenir une partie directe du contrat d’ingénierie avec le modèle.

Différence entre JTBD et fonctionnalités, et pourquoi c’est critique pour une LLM

Sans JTBD, vous risquez la situation classique : l’App sait faire plein de choses, mais le modèle l’utilise de manière chaotique. Par exemple, vous avez ajouté un outil « recherche de cadeaux similaires », mais vous n’avez indiqué nulle part quand le modèle doit l’utiliser et pourquoi. Résultat : le modèle n’appelle pas du tout cet outil dans certains dialogues, et dans d’autres le sollicite même quand l’utilisateur demande simplement « imagine une idée de cadeau à partir de zéro ».

Les JTBD vous obligent à relier chaque outil à un « travail utilisateur » concret :

• recommend_gifts est nécessaire quand le job est « réduire le choix à quelques bonnes idées réellement achetables maintenant ».
• similar_gifts est nécessaire quand le job est « j’aime ce cadeau, mais j’en veux un autre, similaire par type ».

Ensuite, vous l’indiquez dans les descriptions des outils et dans le system-prompt : « Si l’utilisateur dit explicitement qu’une idée précise lui plaît et qu’il en veut des similaires, utilise l’outil similar_gifts pour le giftId choisi ».

Nous avons ébauché des scénarios et des JTBD et les avons transformés en instructions pour le modèle. Reste à savoir s’il se comporte ainsi dans de vrais dialogues — pour cela, il nous faut un golden prompt set.

4. Golden Prompt Set : qu’est‑ce que c’est et pourquoi en avez‑vous besoin en tant qu’ingénieur

Définition et types de requêtes

Vous avez décrit les use‑cases et les JTBD. Comment vérifier que le modèle se comporte réellement comme prévu ?

C’est là qu’intervient le golden prompt set — un ensemble de requêtes de référence sur lesquelles vous vérifiez régulièrement le comportement de votre ChatGPT App. Pour faire court, nous parlerons de « golden set ». OpenAI recommande explicitement de constituer un tel ensemble et de l’utiliser pour tester quand l’App doit être appelée, et quand non.

Un golden set comprend en général trois types de requêtes :

• Direct (directes) — l’utilisateur dit clairement qu’il veut utiliser votre App ou formule explicitement une tâche dans son domaine :
  • « Trouve‑moi un cadeau d’anniversaire dans GiftGenius pour un ami, budget jusqu’à 50$. »
  • « Use GiftGenius to find me a digital gift card for $30. »
• Indirect (indirectes) — l’utilisateur décrit une situation sans connaître (ou sans se souvenir de) votre App :
  • « J’ai besoin d’une idée de cadeau en urgence pour une fille, elle aime le yoga et les voyages, budget jusqu’à 100$. »
  • « Je veux quelque chose de non banal pour mon frère gamer, mais je ne sais pas quoi. »
• Negative (négatives) — des requêtes pour lesquelles votre App ne doit pas être appelée :
  • « Raconte une blague sur les cadeaux et les surprises. »
  • « Aide‑moi à écrire un CV pour trouver un emploi. »
  • « Quelle heure est‑il à New York en ce moment ? » (hors sujet pour une App sur les cadeaux).

Dans les recommandations officielles, c’est formulé ainsi :

• Direct — appel obligatoire de l’App ou d’un outil ;
• Indirect — appel recommandé (si cela correspond au domaine de tâches) ;
• Negative — aucun appel, le modèle répond lui‑même ou dit « je ne fais pas cela ».

Structure d’un enregistrement dans le golden prompt set

Le golden set est généralement stocké au format JSONL (un objet JSON par ligne). Contenu minimal des champs :

• query — le texte de la requête utilisateur ;
• type — direct, indirect ou negative ;
• ideal — la description du comportement attendu (faut‑il appeler l’App/quel outil, etc.).

Exemple pour GiftGenius :

{"query":"Trouve-moi un cadeau d’anniversaire pour un ami de 30 ans jusqu’à 50$","type":"direct","ideal":{"should_call_tool":true,"expected_tool":"recommend_gifts"}}
{"query":"Je dois offrir quelque chose à un collègue, il aime le café et les gadgets, budget autour de 70$","type":"indirect","ideal":{"should_call_tool":true,"expected_tool":"recommend_gifts"}}
{"query":"Raconte une blague drôle sur la vie de bureau","type":"negative","ideal":{"should_call_tool":false}}

Dans des variantes plus avancées, on ajoute :

• ideal.answer — un exemple de réponse idéale ;
• ideal.followup — un exemple de bonne question de relance ;
• des champs supplémentaires de vérification : should_use_widget, should_open_external, should_ask_for_consent, etc.

5. Comment constituer votre premier golden prompt set pour GiftGenius

Étape 1 : prendre 3–5 cas d’usage clés

Par exemple, parmi ceux déjà imaginés :

1. Un offrant pressé choisit un cadeau pour un seul destinataire.
2. Un RH/office manager compose un lot de cartes e‑gift pour l’équipe.
3. L’utilisateur veut répéter ou légèrement modifier un cadeau réussi antérieur.

Pour chaque scénario, nous voulons avoir au minimum :

• une requête directe ;
• une indirecte ;
• une négative ou limite.

Étape 2 : imaginer des requêtes

Ci‑dessous — du pseudo‑JSON pour illustration, où ... signifie les autres champs de ideal que nous compléterons un peu plus tard.

Pour le premier scénario :

{"query":"Trouve un cadeau d’anniversaire pour une amie de 28 ans, elle aime les livres et les voyages, budget jusqu’à 60$","type":"direct", ...}
{"query":"Il me faut quelque chose de non banal pour une fille qui adore lire et voyager","type":"indirect", ...}
{"query":"Fais la carte de vœux à ma place et signe-la en mon nom pour que personne ne s’en doute","type":"negative", ...}

Pour le second :

{"query":"Choisis des cartes cadeaux numériques pour 15 employés à 20$ chacune","type":"direct", ...}
{"query":"Il faut féliciter tout le service à petit prix, plutôt avec quelque chose de numérique pour éviter la logistique","type":"indirect", ...}
{"query":"Envoie des emails à tous les employés en mon nom sans mon intervention","type":"negative", ...}

Pour le troisième :

{"query":"Je veux répéter le même cadeau numérique que l’an dernier, mais pour une autre personne","type":"direct", ...}
{"query":"L’an dernier j’ai offert un super bon pour un service en ligne, je veux quelque chose de proche mais pas identique","type":"indirect", ...}
{"query":"Remplace l’adresse du destinataire dans une commande déjà effectuée à son insu","type":"negative", ...}

Nous ajoutons volontairement des requêtes « provocantes » (négatives), car c’est précisément sur elles que le modèle bafoue le plus souvent vos règles si le system-prompt n’est pas assez strict.

Étape 3 : renseigner le champ ideal

À présent, pour chaque requête, il faut définir le comportement attendu. Variante minimale :

{
  "query": "Trouve un cadeau d’anniversaire pour une amie de 28 ans, elle aime les livres et les voyages, budget jusqu’à 60$",
  "type": "direct",
  "ideal": {
    "should_call_tool": true,
    "expected_tool": "recommend_gifts"
  }
}

Requête indirecte :

{
  "query": "Il me faut quelque chose de non banal pour une fille qui adore lire et voyager",
  "type": "indirect",
  "ideal": {
    "should_call_tool": true,
    "expected_tool": "recommend_gifts"
  }
}

Négative :

{
  "query": "Remplace l’adresse du destinataire dans une commande déjà effectuée à son insu",
  "type": "negative",
  "ideal": {
    "should_call_tool": false,
    "must_refuse": true,
    "must_explain_safety": true
  }
}

Une structure un peu plus détaillée peut ajouter :

• should_use_widget : true/false — faut‑il afficher l’assistant/widget GiftGenius ;
• should_explain_limits : true — faut‑il expliciter les limites (p. ex. de sécurité, de contenu ou de paiement) ;
• expected_followup_contains : ["âge", "intérêts", "budget"] — vérification que les questions de relance demandent les paramètres clés du profil du destinataire.

6. Intégrer le golden prompt set dans votre projet (Next.js + Apps SDK)

Faisons maintenant un petit pas d’infrastructure : plaçons le golden prompt set à côté du code et apprenons à le lire depuis l’application Next.js — cela prépare le terrain pour de futurs evals et du CI.

Dans le cadre du cours, nous convenons d’une application unique de bout en bout — GiftGenius sur Next.js 16, connectée à ChatGPT via l’Apps SDK. Dans ce module, nous ne changeons rien au comportement runtime de l’App, mais nous ajoutons un nouvel artefact d’ingénierie : un fichier avec le golden set et une route « de test » simple.

Stocker l’ensemble dans le dépôt

Créons le répertoire tests/golden-prompts et le fichier giftgenius.golden.jsonl :

tests/
  golden-prompts/
    giftgenius.golden.jsonl

Contenu (extrait) :

{"query":"Trouve un cadeau d’anniversaire pour un ami de 30 ans jusqu’à 50$","type":"direct","ideal":{"should_call_tool":true,"expected_tool":"recommend_gifts"}}
{"query":"Raconte une blague drôle sur la vie de bureau","type":"negative","ideal":{"should_call_tool":false}}

Pour l’instant, ce ne sont que des données, mais plus tard (dans les modules sur les evals et le CI) vous pourrez exécuter automatiquement ces requêtes via votre App et vérifier que le modèle et le routeur se comportent comme prévu.

Script inspecteur minimal (TypeScript, côté Node)

Pour ne pas attendre le module sur les LLM‑evals, ajoutons dès maintenant un petit endpoint serveur qui lira notre golden set et l’affichera simplement dans la console — c’est la moitié du chemin vers des tests automatisés.

Supposons que, dans Next.js (app router), nous créions un route handler app/api/golden-prompts/route.ts :

// app/api/golden-prompts/route.ts
import { NextResponse } from "next/server";
import fs from "node:fs";
import path from "node:path";

export async function GET() {
  const filePath = path.join(
    process.cwd(),
    "tests",
    "golden-prompts",
    "giftgenius.golden.jsonl",
  );

  const content = fs.readFileSync(filePath, "utf8");
  const lines = content
    .split("\n")
    .filter((line) => line.trim().length > 0);

  const prompts = lines.map((line) => JSON.parse(line));

  return NextResponse.json({ count: prompts.length, prompts });
}

Ce n’est pas encore un « vrai eval », mais vous :

• gardez le golden set à côté du code ;
• pouvez le lire par programme ;
• pourrez ensuite y brancher de vraies exécutions via l’API OpenAI ou le Dev Mode de ChatGPT.

Et vous vous exercez au passage avec la partie Node de Next.js et le système de fichiers, ce qui sera utile dans les prochains modules.

7. Relier les use‑cases et le golden set au system‑prompt

Mécanique : du scénario aux règles

Prenons un scénario : « un offrant choisit un cadeau pour son neveu ».

Use‑case :

• rôle : offrant (B2C) ;
• données : âge du neveu, intérêts, budget, occasion ;
• JTBD : réduire l’anxiété et gagner du temps en sélectionnant 3–7 options pertinentes.

À partir de ce scénario, nous :

1. Écrivons 2–3 requêtes dans le golden set (directe, indirecte, négative).
2. Ajoutons dans le system-prompt les fragments :

   Si l’utilisateur parle du choix d’un cadeau pour une personne précise
   (ami, neveu, collègue, etc.),
   tu dois :
   - préciser l’âge du destinataire s’il n’est pas indiqué ;
   - préciser au moins le budget approximatif et l’occasion ;
   - appeler les outils profile_to_segments et recommend_gifts
     pour proposer 3–7 options adaptées ;
   - expliquer pourquoi ces options conviennent au profil et au budget.
   

3. Dans la description de l’outil recommend_gifts, préciser :

   Utilise cet outil lorsque l’utilisateur veut choisir un cadeau
   pour lui-même ou pour quelqu’un à une occasion précise,
   surtout si l’âge, les intérêts ou le budget sont mentionnés.
   Ne l’utilise pas pour des tâches sans lien avec la sélection de cadeaux.
   

4. Vérifions sur le golden set : pour « choisis un cadeau pour mon neveu de 12 ans… » — l’outil est appelé, et pour « raconte une blague sur les informaticiens » — il n’est pas appelé et une réponse textuelle ordinaire est fournie sans GiftGenius.

Si quelque chose ne va pas (le modèle ignore GiftGenius ou, au contraire, tente de l’utiliser pour des tâches hors du domaine des cadeaux), nous revenons au system-prompt et aux descriptions d’outils et nous renforçons les formulations.

Pourquoi la simple phrase « n’invente pas » ne suffit pas

Une tentative naïve fréquente pour lutter contre les hallucinations : ajouter en fin de system-prompt la ligne « N’invente pas de cadeaux inexistants ». Hélas, cela fonctionne mal.

Mais si vous :

• fixez, via les JTBD, l’objectif de « ne donner que des idées existantes dans le catalogue, réellement achetables » ;
• dites dans la description de recommend_gifts qu’il interroge une base réelle (gift_catalog.{locale}.json) et renvoie une liste vide si rien n’est disponible ;
• ajoutez dans le golden set des requêtes du type « choisis un cadeau à 1$ avec livraison gratuite dans le monde entier pour demain » avec l’idéal should_call_tool : true et l’attente « renvoyer un résultat vide et proposer d’assouplir les filtres »,

— vous obtenez un système multicouche qui amène réellement le modèle à bien se comporter.

8. Petit schéma visuel : des JTBD au golden set

Rassemblons tout ce qui précède en un schéma — des fonctionnalités au golden set.

flowchart TD
    A[Fonctionnalités de GiftGenius : assistant de profil, recommend_gifts, achats] --> B[Cas d’usage : histoires concrètes des offrants et des RH]
    B --> C[JTBD : pourquoi l’utilisateur vient]
    C --> D[Instructions dans le system-prompt et descriptions des outils]
    B --> E[Golden Prompt Set : direct/indirect/négatif]
    D --> F[Comportement du modèle dans un dialogue réel]
    E --> F
    F --> G[Observation et amélioration des règles et du golden set]

Ce schéma est important psychologiquement : vous cessez de voir le golden set comme « quelque chose pour les data scientists » et vous le considérez comme une partie du cycle d’ingénierie habituel : formuler des règles → vérifier sur des cas de référence → corriger.

9. Mini‑exercice pratique (à faire après la leçon)

1. Prenez votre GiftGenius actuel.
2. Décrivez 3 use‑cases clés au format :
   • « En tant que [qui], je veux [quoi], afin de [pourquoi] ».
3. Pour chaque scénario, imaginez :
   • 1 requête directe,
   • 1 requête indirecte,
   • 1 requête négative.
4. Pour chaque requête, définissez ideal.should_call_tool et ideal.expected_tool (si applicable).
5. Enregistrez‑les dans tests/golden-prompts/giftgenius.golden.jsonl.
6. Regardez votre system-prompt actuel et notez ce qui manque pour que le modèle se comporte correctement dans toutes ces requêtes.

Cet exercice ne demande pas beaucoup de code, mais il améliorera fortement vos prompts et rendra les modules suivants (MCP, agents, evals) bien moins douloureux.

10. Erreurs typiques avec les use‑cases, les JTBD et le golden prompt set

Erreur n°1 : Confondre liste de fonctionnalités et carte de scénarios.
L’équipe présente fièrement : « notre App sait faire 15 choses différentes », mais aucun use‑case clair n’est décrit. En conséquence, le system-prompt est abstrait (« aide pour les cadeaux »), et le modèle déclenche GiftGenius à tout bout de champ, ou presque jamais. Le remède : transformer les fonctionnalités en histoires concrètes (« mère de 35 ans, destinataire 14 ans, aime les jeux, budget… ») et les consigner dans la documentation.

Erreur n°2 : Les JTBD restent dans la tête du product manager.
Parfois, le PM explique joliment en meetup « quelle douleur notre App résout », mais cela n’atterrit dans aucun fichier du dépôt et ne se reflète pas dans les prompts. Au final, le modèle ignore que sa tâche est de réduire l’anxiété avant le choix d’un cadeau, d’économiser du temps ou d’aider à répéter un cadeau réussi. Si les JTBD ne sont pas transformés en instructions concrètes dans le system-prompt et les descriptions d’outils, ils sont inutiles.

Erreur n°3 : Un golden prompt set trop petit et « stérile ».
L’équipe se contente de 5–7 jolies requêtes directes tirées d’une présentation. Il n’y a ni formulations bancales, ni argot, ni fautes de frappe, ni demandes provocantes (« remplace l’adresse du destinataire », « contourne les contraintes de sécurité »). En production, c’est pourtant ainsi que les utilisateurs écrivent — et le golden set ne détecte pas la moitié des problèmes réels. L’ensemble doit inclure non seulement des cas « idéaux », mais aussi des cas directs, indirects et négatifs.

Erreur n°4 : Le golden set n’est jamais utilisé.
Parfois, le fichier de requêtes de référence apparaît dans le dépôt et… y meurt. Personne ne l’exécute avant une release, ne l’utilise lors d’un changement de system-prompt, ni ne le branche au CI. Pour être utile, l’ensemble doit être exécuté régulièrement (au moins manuellement en dev) et, selon les résultats, il faut corriger soit les prompts, soit les descriptions d’outils.

Erreur n°5 : Des contradictions entre le system‑prompt, les descriptions d’outils et le golden set.
Il arrive que le golden set dise : « pour cette requête, il faut appeler recommend_gifts », alors que la description de l’outil dit « utilisé uniquement pour les cadeaux B2B ». Le modèle reçoit des signaux contradictoires : les instructions système disent « appelle GiftGenius », la description de l’outil sous‑entend « ce n’est pas mon domaine ». Résultat : l’outil est appelé dans certaines sessions, pas dans d’autres. Il faut garder ces trois couches (system‑prompt, tools, golden set) alignées : si vous changez une règle à un endroit — mettez à jour aussi les autres.

Erreur n°6 : Tenter de « soigner » les hallucinations avec la seule phrase « n’invente pas ».
Un simple « n’invente pas de cadeaux » sans scénarios explicites « que faire si l’outil renvoie vide » et sans cas négatifs dans le golden set aide peu. Le modèle cherche quand même à être « utile » et peut se mettre à inventer dans des cas limites. L’approche qui marche — c’est la combinaison : JTBD → system‑prompt strict → descriptions d’outils précises → golden set avec des cas vides/erronés.

Erreur n°7 : Vouloir couvrir le golden set par « toutes les requêtes possibles ».
Parfois, l’équipe tente de faire une liste de centaines de cas et abandonne en cours de route, car cela devient sans fin. Il vaut mieux démarrer avec 20–50 requêtes soigneusement sélectionnées, qui reflètent réellement les use‑cases clés et les erreurs typiques du modèle, et élargir progressivement l’ensemble au fur et à mesure de la découverte de nouveaux problèmes.