Atelier : cas réel de bout en bout

Le cas de bout en bout

Les chapitres précédents ont traité chaque brique séparément : structurer un promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire, définir un rôle, contraindre une sortie JSON, se prémunir des hallucinationshallucinationIAProduction par un modèle d'un énoncé faux formulé avec la même assurance qu'un fait établi. Le phénomène est structurel : le modèle optimise la vraisemblance, pas la vérité.Voir dans le glossaire, mesurer la qualité. Ce chapitre les assemble sur un cas réel, du brief initial jusqu'à une mise en production légère, avec les arbitrages qu'on ne rencontre qu'en travaillant sur un cas complet plutôt que sur des exemples isolés.

L'objectif n'est pas de recopier le prompt final présenté ici, mais de suivre le raisonnement qui mène d'un brief flou à un prompt exploitable, testé et surveillé. Le cas change d'un projet à l'autre ; la méthode, elle, reste stable d'un contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire métier à l'autre.

Le cas : générer des fiches produit à partir de données fournisseur

TechConfort, un revendeur d'électroménager en ligne, reçoit de ses fournisseurs des fiches techniques brutes : tableaux de caractéristiques parfois incomplets, rédigés dans un style télégraphique, sans cohérence de format d'un fournisseur à l'autre. L'équipe e-commerce veut transformerTransformerIAArchitecture introduite en 2017, fondée sur le mécanisme d'attention, qui traite une séquence entière en parallèle. Elle sert de base à tous les grands modèles de langage actuels.Voir dans le glossaire chaque fiche brute en contenu publié sur le site : un titre, une méta-description, une description longue, une liste de points forts et une courte FAQ — le tout dans un format structuré exploitable par le CMS, avec un ton de marque défini, et sans jamais inventer une caractéristique absente de la source.

Ce cas cumule volontairement plusieurs contraintes rencontrées dans les chapitres précédents : sortie structurée, ton contraint, risque d'hallucination élevé — un chiffre de consommation électrique inventé est un problème légal, pas une coquetterie stylistique —, volume important (plusieurs centaines de fiches par mois), et nécessité d'un contrôle qualité avant publication.

Étape 1 — Traduire le brief métier en spécification de prompt

Le brief initial reçu de l'équipe e-commerce tient en une phrase orale : « on veut des fiches produit qui donnent envie, à partir des fiches fournisseur ». Ce type de formulation est inutilisable tel quel pour concevoir un prompt — il faut le décomposer en éléments vérifiables avant d'écrire la moindre ligne d'instruction.

Traduire ce brief suppose de répondre à des questions concrètes :

• Quel est le format de sortie exact attendu par le CMS — un objet JSON avec des champs nommés, ou du texte libre à recopier manuellement ?
• Quelles donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire sont garanties présentes dans la fiche fournisseur, et lesquelles sont optionnelles selon les marques ?
• Quel est le ton de marque, avec des exemples de fiches déjà jugées réussies par l'équipe ?
• Quelles mentions sont obligatoires pour des raisons légales — étiquetteétiquetageIATravail consistant à associer à chaque exemple la réponse attendue. C'est presque toujours le poste le plus coûteux d'un projet d'apprentissage supervisé.Voir dans le glossaire énergétique, garantie, précautions d'usage ?
• Quel est le comportement attendu quand une donnée nécessaire manque dans la fiche source ?

Brief oral : « des fiches qui donnent envie ». Spécification retenue après clarification avec l'équipe : un objet JSON avec les champs titre (70 caractères maximum), meta_description (140 à 160 caractères), description_longue (150 à 250 mots), points_forts (3 à 5 puces) et faq (2 à 4 questions). Ton direct et factuel, sans superlatifs non justifiés. Aucune caractéristique ne doit apparaître si elle n'est pas présente dans la fiche source ; en cas de donnée manquante, le champ concerné est omis plutôt que complété par une estimation.

Cette étape prend souvent plus de temps que la rédaction du prompt elle-même. C'est normal : un brief mal clarifié se traduit systématiquement par des allers-retours coûteux une fois le prompt en test, alors qu'une heure de clarification en amont désamorce l'essentiel des ambiguïtés qui apparaîtraient sinon plus tard, au pire moment.

Étape 2 — Écrire la première version du prompt

Une fois la spécification stabilisée, le prompt reprend les briques vues dans les chapitres sur l'anatomie d'un prompt et sur les rôles et contraintes : un rôle, un contexte, une tâche, des contraintes de format, des contraintes de contenu.

Tu rédiges des fiches produit pour un site e-commerce d'électroménager.

CONTRAINTES DE CONTENU :
- N'utilise que les informations présentes dans la fiche fournisseur fournie ci-dessous.
- Si une caractéristique n'est pas mentionnée dans la source, ne l'invente pas et omets le champ concerné.
- Ton direct et factuel, sans superlatifs non justifiés par une donnée (\"le meilleur\", \"incroyable\").

FORMAT DE SORTIE (JSON strict, aucun texte hors de l'objet) :
{
  \"titre\": \"string, 70 caractères maximum\",
  \"meta_description\": \"string, 140 à 160 caractères\",
  \"description_longue\": \"string, 150 à 250 mots\",
  \"points_forts\": [\"string\", \"...\"],
  \"faq\": [{\"question\": \"string\", \"reponse\": \"string\"}]
}

FICHE FOURNISSEUR :
{{fiche_source}}

Cette première version couvre déjà l'essentiel, mais elle reste incomplète sur un point critique pour ce cas précis : rien n'empêche encore le modèle de compléter une donnée manquante par une estimation plausible — exactement le risque identifié dans le brief.

Étape 3 — Neutraliser le risque d'hallucination sur les données techniques

Sur ce cas, une caractéristique inventée — une classe énergétique, une capacité, une durée de garantie — n'est pas seulement une imprécision : elle expose l'entreprise à une réclamation client, voire à un litige. Le garde-fou anti-hallucination n'est pas optionnel ici, il conditionne la validité du contenu publié.

Trois ajustements réduisent ce risque, dans la continuité du chapitre consacré à l'anti-hallucination :

1. Instruction explicite de non-complétion, déjà présente ci-dessus, mais renforcée par une reformulation négative en plus de la positive : « n'invente aucune caractéristique » redit sous la forme « si tu hésites entre plusieurs valeurs possibles, omets le champ plutôt que de choisir ».
2. Séparation stricte source / génération : la fiche fournisseur est injectée dans un bloc clairement délimité, et le prompt précise que seul ce bloc fait autorité — le modèle ne doit pas mobiliser sa connaissance générale sur des produits similaires pour combler les trous.
3. Contrôle programmatique post-génération : chaque valeur numérique de la sortie (puissance, capacité, dimensions) est comparée automatiquement à la fiche source avant publication ; toute valeur absente de la source déclenche un rejet automatique de la fiche, avant même une relecture humaine.

Ce dernier point illustre une règle générale : certains garde-fous ne relèvent pas du prompt lui-même mais du pipeline qui l'entoure. Un prompt, aussi bien écrit soit-il, ne garantit jamais à cent pour cent l'absence d'erreur — la vérification programmatique en aval est ce qui transforme une réduction de risque en contrôle fiable.

Étape 4 — Stabiliser la sortie avec des exemples ciblés

Les premiers tests sur une dizaine de fiches réelles révèlent une instabilité typique : la longueur de description_longue varie du simple au triple selon la richesse de la fiche source, et le style des points_forts change de fiche en fiche — tantôt des phrases complètes, tantôt des fragments isolés.

Deux ajustements, issus du chapitre sur le few-shotFew-shotIATechnique de prompt où l'on fournit quelques exemples entrée-sortie pour guider le modèle sans réentraînement.Voir dans le glossaire et le chaînage de raisonnement, stabilisent ce comportement :

• Un exemple complet inséré dans le prompt, montrant une fiche source pauvre et la sortie attendue correspondante — précisément pour calibrer le comportement sur le cas difficile (peu de données disponibles), et non sur le cas facile qui ne pose aucun problème en pratique.
• Une contrainte de style reformulée par la forme plutôt que par l'adjectif : au lieu de « des points forts percutants », le prompt précise « chaque point fort est une phrase complète de 8 à 15 mots, commençant par un verbe ou un nom, sans ponctuation finale ». Une contrainte vérifiable programmatiquement vaut toujours mieux qu'un adjectif qualitatif laissé à l'interprétation du modèle.

Un exemple few-shot choisi parmi les fiches source les plus complètes n'apprend rien d'utile au modèle sur la gestion du manque d'information — c'est précisément le cas inverse qui doit figurer dans le prompt, parce que c'est là que la variance de sortie est la plus forte.

Étape 5 — Construire le golden set et la rubrique d'évaluation

Avant tout déploiement à volume, TechConfort constitue un golden set de 40 fiches : 20 fiches sources riches et complètes, 10 fiches pauvres avec des données manquantes, 5 fiches contenant des incohérences internes (deux valeurs contradictoires pour une même caractéristique), et 5 fiches dans un format inhabituel reçu d'un nouveau fournisseur.

La rubrique reprend les critères bloquants et gradués vus au chapitre précédent :

Les critères bloquants filtrent automatiquement l'essentiel des échecs avant toute relecture humaine, ce qui limite le temps de relecture au strict nécessaire — un point décisif dès qu'on parle d'un volume de plusieurs centaines de fiches par mois.

Étape 6 — Mise en production légère

« Léger » ne signifie pas « sans garde-fou » : cela signifie une infrastructure proportionnée au volume et à l'enjeu réel du projet, sans complexité inutile. Pour ce cas, la mise en production repose sur quatre éléments.

Un wrapper de validation. Le script qui appelle le modèle ne publie jamais directement la sortie brute : il la fait d'abord passer par les contrôles programmatiques de l'étape précédente. Une fiche qui échoue à un critère bloquant part dans une file de relecture manuelle plutôt que d'être publiée ou simplement rejetée sans suite.

Un versionnement du prompt. Chaque modification du prompt est enregistrée avec un identifiant de version, associée aux résultats obtenus sur le golden set à cette version. Cela permet de revenir à une version antérieure en cas de régression détectée après un changement, et d'expliquer précisément pourquoi une fiche générée un mois donné diffère d'une fiche générée le mois suivant.

Un échantillonnage de suivi. Cinq pour cent des fiches publiées sont relues a posteriori chaque semaine par un membre de l'équipe e-commerce, indépendamment du contrôle qui a précédé la publication. Cet échantillon sert à détecter une dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire progressive — un fournisseur qui change le format de ses fiches sources, par exemple — avant qu'elle ne dégrade la qualité perçue à grande échelle.

Un plan de repli explicite. Si le taux de rejet automatique dépasse un seuil défini à l'avance (10 % des fiches sur une semaine, dans ce cas), la génération automatique est suspendue pour ce fournisseur et les fiches repassent en rédaction manuelle, le temps d'investiguer la cause — changement de format source, dérive du modèle, ou faille du prompt révélée par un nouveau type de cas.

Le golden set continue de s'enrichir avec les cas remontés par l'échantillonnage de suivi et par le plan de repli. Un prompt en production reste un prompt en évolution, pas un livrable figé une fois validé la première fois.

Ce que cet atelier révèle sur la méthode

Trois enseignements se dégagent, valables au-delà de ce cas précis.

D'abord, le brief prend systématiquement plus de temps à clarifier que le prompt à écrire, dès que le cas dépasse un exemple isolé. Accepter cette réalité en amont évite de la découvrir en retard, au moment le plus coûteux du projet.

Ensuite, les garde-fous les plus fiables ne sont pas toujours dans le prompt lui-même. Le contrôle programmatique post-génération de ce cas — comparer chaque valeur numérique à la source — offre une garantie que le prompt seul, aussi bien rédigé soit-il, ne peut pas offrir avec la même certitude.

Enfin, une mise en production légère reste une mise en production sérieuse si elle intègre validation, versionnement, suivi et plan de repli. La légèreté porte sur l'infrastructure, jamais sur la rigueur du contrôle qui l'entoure.

Erreurs fréquentes observées sur ce type de projet

• Sauter l'étape de clarification du brief et découvrir les ambiguïtés seulement lors des premiers retours utilisateurs, une fois le prompt déjà en production.
• Tester uniquement sur des cas favorables — fiches sources complètes et bien formées — qui ne révèlent aucune des instabilités qui apparaissent sur les cas pauvres ou incohérents.
• Confondre validation du format et validation du contenu : un JSON syntaxiquement valide peut malgré tout contenir une caractéristique inventée ; les deux contrôles sont nécessaires et distincts.
• Ne pas versionner le prompt, ce qui rend impossible d'expliquer une régression constatée après une modification, ou d'y revenir rapidement.
• Négliger le plan de repli, en supposant implicitement que le taux d'erreur restera stable dans le temps alors que les données sources, elles, évoluent au fil des mois.

Checklist de l'atelier

• Le brief a été traduit en spécification écrite, avec des champs, des plages de longueur et un comportement défini pour les données manquantes.
• Le prompt sépare explicitement rôle, contraintes de contenu, format de sortie et source de données.
• Un garde-fou anti-hallucination existe à la fois dans le prompt et dans un contrôle programmatique en aval.
• Le golden set couvre les cas riches, pauvres, incohérents et atypiques, pas seulement les cas favorables.
• La rubrique distingue critères bloquants et critères gradués.
• Le prompt est versionné, avec un historique des résultats obtenus à chaque version sur le golden set.
• Un échantillonnage de suivi post-publication est en place.
• Un seuil de repli est défini à l'avance, avec une procédure claire en cas de dépassement.

Conclusion

Ce cas de bout en bout n'a rien d'exceptionnel : il ressemble à la majorité des projets de prompt engineeringprompt engineeringIADiscipline consistant à concevoir des instructions précises pour guider un LLM vers la réponse souhaitée. Elle inclut les techniques de chain-of-thought, few-shot, rôle et format de sortie.Voir dans le glossaire rencontrés en entreprise, où l'enjeu n'est jamais la sophistication d'un prompt isolé mais la solidité de l'ensemble — du brief à la surveillance post-déploiement. Les chapitres précédents fournissent chacun une brique ; cet atelier montre comment ces briques s'assemblent, s'arbitrent et se maintiennent une fois le projet vécu, pas seulement conçu sur le papier.