Version HTML intégrale

Session 4, prompt engineering, orchestration et contrôle

Cette séance montre comment passer d’un prompt isolé à une architecture de travail plus robuste. L’enjeu est de comprendre quand décomposer une tâche, quand structurer la sortie, quand évaluer, quand optimiser les coûts et quand envisager un levier plus structurel comme le fine-tuning.

Ce que vous devez retenir

  • Une tâche complexe gagne souvent à être décomposée.
  • Un format propre ne garantit jamais un contenu vrai.
  • Les evals servent à mesurer, pas à rassurer artificiellement.
  • Le caching agit sur l’efficacité système, pas sur la vérité de la réponse.
  • Le fine-tuning peut aider sur la structure, pas abolir le risque d’erreur.
Session 4

Prompt engineering — deuxième partie

Le vrai sujet n’est plus d’écrire un prompt isolé, mais de concevoir un petit système de production. Quand la tâche devient complexe, il faut penser en étapes, en validation intermédiaire, en contrat de sortie, en critères d’évaluation et en arbitrage coût-latence-fiabilité.

7objectifs pédagogiques dans la séance
4études de cas transformées en interfaces LLM
3tableaux comparatifs réécrits
1question interactive finale
Objectifs pédagogiques

À la fin de cette séance, l’étudiant doit être capable de choisir une méthode de prompting selon l’objectif, d’expliquer le prompt chaining et les sous-agents, de produire des sorties structurées, de résumer de longs documents avec une stratégie explicite, d’utiliser des evals avec prudence, de comprendre le prompt caching et de situer le fine-tuning comme levier plus structurel.

  • Choisir une méthode de prompting selon le besoin réel.
  • Comprendre le bénéfice d’une chaîne analyse → production → vérification → correction.
  • Distinguer format robuste et contenu vrai.
  • Voir pourquoi les evals comptent quand les modèles varient.
  • Comprendre pourquoi le caching relève aussi de l’ingénierie système.
Décomposition et orchestration

Prompt chaining, métaphore simple

Au lieu de demander au modèle de tout faire en une seule fois, on fragmente la tâche. Chaque étape produit un livrable intermédiaire que l’on peut relire, tester ou corriger. On réduit ainsi la charge cognitive et l’ambiguïté, mais on paie davantage en appels, en latence et en orchestration.

Prompt AAnalyse le besoin et produit un plan exploitable.
Prompt BRédige ou produit le livrable à partir du plan fixé.
Prompt CVérifie le format, les contraintes et les oublis.
Prompt DCorrige puis finalise la sortie.

Sous-agents, spécialisation et parallélisme

Un agent principal peut déléguer à plusieurs sous-agents spécialisés. L’un cherche, l’autre critique, un troisième vérifie la conformité, un dernier consolide. Cette spécialisation améliore souvent la couverture du problème, mais elle crée de nouveaux enjeux de cohérence globale et de coût.

Le sous-agent n’est pas un miracle. C’est une division du travail qui devient utile quand les sous-tâches sont réellement distinctes.

Format et vérification

Sorties structurées, evals, caching, fine-tuning

Les sorties structurées reposent sur un contrat de sortie. On fixe des champs, des types et parfois des sections obligatoires pour rendre la réponse plus facilement exploitable par une machine ou par un workflow de contrôle.

Mais le gain de format ne garantit pas la vérité. Un schéma peut être parfaitement respecté tout en contenant une réponse fausse ou spéculative. C’est là que les evals prennent le relais. Elles servent à mesurer si le système tient réellement ses promesses.

Le prompt caching intervient sur un autre plan. Il n’améliore pas directement l’intelligence du modèle. Il réduit surtout les coûts et la latence lorsque le préfixe d’un prompt est réutilisé. Enfin, le fine-tuning doit être présenté comme un levier plus structurel sur les formats, les styles et certains comportements, jamais comme une garantie absolue.

À retenir

Structured output améliore l’adhérence au format. Evals améliorent la mesure. Caching améliore l’efficacité système. Fine-tuning améliore parfois la robustesse structurelle. Aucun de ces leviers ne remplace une vérification humaine quand l’enjeu est élevé.

Erreur classique

Confondre format propre, réponse convaincante et contenu exact. Les trois ne coïncident pas automatiquement.

Exemple minimal de schémacontrat de sortie
{
  "policy_name": "string",
  "definitions": ["string"],
  "exceptions": ["string"],
  "audit_procedure": ["string"],
  "uncertainties": ["string"]
}
Méthode concrète

Reverse prompt engineering, comment reconstruire un bon prompt à partir d’une bonne sortie

Le reverse prompt engineering consiste à partir d’une sortie jugée bonne pour remonter vers les instructions qui ont probablement permis de l’obtenir. La logique est simple. On n’essaie pas d’abord d’écrire le prompt parfait. On observe une réponse utile, puis on démonte sa structure pour identifier les variables invisibles qui l’ont produite.

Cette méthode est particulièrement utile dans trois situations. Quand un LLM produit parfois une bonne réponse mais de manière instable. Quand on veut standardiser un style de sortie pour une équipe. Quand on veut comprendre pourquoi un modèle concurrent semble mieux cadrer une tâche que le sien.

But réel

Transformer une bonne sortie ponctuelle en procédure reproductible.

Limite

On reconstruit des hypothèses plausibles de prompt, pas l’historique exact interne du modèle.

Procédure simple en cinq temps

1 — Collecter une bonne sortie
Choisir une réponse réellement utile, pas seulement élégante. Elle doit être juste sur le fond, bien structurée et exploitable.

2 — Décomposer cette sortie
Identifier son plan, son niveau de détail, son ton, ses contraintes implicites, son format, ses critères de sélection et son degré d’incertitude affiché.

3 — Inférer les instructions invisibles
Se demander ce que le modèle a probablement reçu pour produire cela. Par exemple, un rôle, un public cible, une structure en sections, l’interdiction d’inventer, un format JSON, une longueur maximale ou une demande de citations.

4 — Réécrire un prompt testable
Reformuler ces hypothèses sous la forme d’un prompt court et contrôlable, puis relancer plusieurs fois pour voir si la qualité revient.

5 — Stabiliser
Ajouter ensuite seulement ce qui manque, par exemple quelques exemples, une checklist, un schéma de sortie ou une étape de vérification séparée.

Grille d’analyse très concrète pour démonter une bonne réponse

Élément observé dans la sortie Question à se poser Hypothèse de prompt à reconstruire
Réponse en sections nettes Le plan était-il imposé Réponds en 4 sections avec titres imposés
Tonalité sobre et régulière Un registre ou un public était-il défini Écris pour un public débutant en style académique simple
Aucun fait non sourcé Une règle anti-spéculation était-elle donnée Si l’information manque, écris information non disponible
Sortie très exploitable Le format était-il contraint Rends la réponse en tableau ou en JSON
Réponse très stable entre essais Des exemples ou une checklist étaient-ils fournis Voici 2 exemples et une checklist finale à respecter

Comment le faire concrètement dans un LLM

Prompt de rétro-analyseà utiliser directement
Analyse la réponse suivante comme si tu devais reconstruire le prompt qui a pu la produire.

Fais apparaître séparément
1. l’objectif probable
2. le public cible probable
3. les contraintes implicites
4. le format attendu
5. les règles de prudence éventuelles
6. une proposition de prompt minimal
7. une proposition de prompt renforcé

Puis explique quels éléments de la sortie te font inférer chaque hypothèse.
Prompt de stabilisationde la bonne sortie vers le bon système
À partir de cette bonne réponse, produis un prompt réutilisable qui permette d’obtenir un résultat du même niveau.

Contraintes
- garder le même niveau de précision
- garder la même structure
- éviter toute invention
- prévoir un bloc final pour les incertitudes
- proposer ensuite une version few-shot si nécessaire

Exemple très simple

Sortie observée
« Le texte distingue trois causes principales, donne un exemple pour chacune et termine par une limite méthodologique. »

Ce que l’on peut reconstruire
Le modèle a probablement reçu une consigne du type résume en trois causes, ajoute un exemple par cause, puis termine par une limite ou une prudence.

Prompt reconstruit
Résume ce texte en trois causes principales.

Pour chaque cause, donne un exemple tiré du texte.

Termine par une limite méthodologique ou un point d’incertitude.

N’invente aucune information absente du document.

Le bon réflexe est de partir de ce qui est visible dans la sortie. Structure, ton, longueur, prudence, format, densité informationnelle. Ce sont ces indices qui permettent de remonter vers un prompt plus précis.

Tableaux comparatifs

Prompt simple vs prompt structuré

Aspect Prompt simple Prompt structuré
Clarté de l’objectifSouvent impliciteExplicite et observable
AmbiguïtésPlus fréquentesRéduites
Contrôle du formatFaible à moyenFort, surtout avec schéma
ExploitabilitéVariableMeilleure
RisqueRéponse hors cibleRisque réduit, jamais nul

Prompt unique vs prompt chaining

DimensionPrompt uniquePrompt chaining
SimplicitéTrès simpleOrchestration requise
Fiabilité sur tâche complexeSouvent limitéeSouvent meilleure
Coût et latenceFaiblesPlus élevés
VérificationDifficileÉtapes vérifiables

Sortie libre vs sortie structurée

DimensionSortie libreSortie structurée
Lisibilité humaineSouvent bonneVariable, mais claire si l’UI la met bien en forme
Parsing machineFragileRobuste
Risque de dérive formatPlus élevéPlus faible
Vérité du contenuNon garantieNon garantie
Études de cas

Études de cas obligatoires avec interfaces LLM simulées

Les quatre cas suivants montrent ce que change une bonne architecture de prompt. L’objectif n’est pas seulement d’obtenir une réponse plus propre. Il s’agit surtout d’obtenir une sortie plus lisible, plus traçable et plus facile à vérifier.

Cas 1 — Résumé de document long

Le problème n’est pas seulement de résumer. Il faut chunker, produire des résumés intermédiaires, citer les sections et signaler l’incertitude.

Map-reduce
Version faibleprompt monolithique
PromptRésume ce document en détail.
Sortie du modèleLe document explique les idées principales de manière globale, insiste sur plusieurs enjeux importants et propose différentes recommandations. Il souligne notamment la nécessité d’une approche rigoureuse et cohérente.Problème — très fluide, mais sans points d’ancrage, sans citations internes, sans gestion de l’incertitude.
Réponse peu traçableEnvoyer
Version robustestratégie + contrôles
PromptÉtape 1 — découper par titres.

Étape 2 — résumer chaque section en 5 puces avec citation interne page/section.

Étape 3 — produire une synthèse globale de 300 mots avec liste des points incertains.

Si un fait n’apparaît pas, écrire « non trouvé dans le document ».
Sortie du modèleSection 1 — 5 puces sourcées. Section 2 — 5 puces sourcées. Synthèse globale courte. Bloc final « Points incertains ».Gain — la sortie devient plus vérifiable et plus facile à corriger.
Chunking
oui
Citations internes
oui
Aveu d’incertitude
oui
Lecture pédagogique

Ce cas améliore surtout la fidélité opérationnelle du résumé. Il ne supprime pas le risque d’interprétation erronée si le document source lui-même est ambigu.

Cas 2 — Livrable structuré et conformité

Le modèle doit produire une politique IA au format attendu, avec sections obligatoires et étape de contrôle séparée.

JSON Schema
Productioncontrat de sortie
PromptGénère une politique IA conforme.
Sortie du modèlePolitique IA générale, ton convaincant, quelques rubriques, mais aucune garantie que les définitions, exceptions et procédures d’audit soient réellement présentes ni faciles à parser.
Sortie libre difficile à intégrerEnvoyer
Pipeline recommandéprod + check
PromptFormat JSON Schema avec sections obligatoires. Inclure définitions, exceptions, procédure d’audit. Puis lancer une étape séparée de contrôle conformité au schéma et à une checklist métier.
Sortie structuréemachine-friendly
{ "policy_name": "Politique IA institutionnelle", "definitions": ["outil d’IA", "usage autorisé"], "exceptions": ["dérogation sur validation formelle"], "audit_procedure": ["revue trimestrielle", "journal de contrôle"], "uncertainties": ["base réglementaire locale à confirmer"] }
ChampOKDéfinitions présentes
ChampOKExceptions présentes
ChampÀ revoirConformité juridique réelle non démontrée, expertise humaine requise

Cas 3 — Vérification de conformité à des consignes

Ici, le point critique est la traçabilité. Le modèle doit citer la preuve et proposer une correction sans inventer d’évidence.

Prompt contrat
Vérification faibleavis global
PromptVérifie si c’est bon.
Sortie du modèleLe document semble correct dans l’ensemble, même si certaines parties pourraient être améliorées.Problème — aucune règle explicite, aucune preuve, aucune traçabilité.
Vérification robusterègles numérotées
PromptDonne une grille de règles numérotées et réponds sous la forme {rule_id, status, evidence_quote, fix}. Interdiction d’inventer des preuves. evidence_quote doit être extrait du texte fourni.
R1PASSevidence_quote — « les sources sont citées en fin de document »
R2FAILevidence_quote — « aucun protocole de validation n’est mentionné » · fix — ajouter une checklist finale
R3PARTIALevidence_quote — « format annoncé mais schéma non fourni » · fix — insérer le schéma attendu
Ce que ce cas montre

Le bon prompt ne demande pas « ton avis ». Il demande des décisions traçables, indexées et rattachées à des preuves explicites.

Cas 4 — Décomposer une tâche complexe en sous-prompts et sous-agents

Le PDF prend l’exemple d’une étude de marché, d’un plan produit et d’un business plan. Une seule demande mélange ici plusieurs métiers cognitifs différents.

Multi-agent
Prompt trop largemonolithe
PromptFais une étude complète de marché, un plan produit et un business plan.
Sortie du modèleRéponse longue, générique, peu hiérarchisée, mélangeant hypothèses, marché, produit, finances et risques sans protocole de consolidation.
Orchestration recommandée4 agents
Agent 1 — RechercheSources, hypothèses, incertitudes, signaux faibles.
Agent 2 — ProduitProblème, solution, différenciation, proposition de valeur.
Agent 3 — RisquesContraintes, conformité, dépendances, points de blocage.
Agent 4 — ConsolidationVérifie la cohérence inter-parties puis finalise le document.
Spécialisation meilleure, coût plus élevéLancer
Spécialisation
meilleure
Cohérence globale
à piloter
Coût tokens
plus élevé
Question interactive

Choisir la bonne méthode

Vous devez extraire des champs nom, date et montant d’un lot de factures hétérogènes puis les intégrer dans une base. Quelle méthode est la plus adaptée.

Question
A — Prompt unique en texte libre
B — Few-shot avec quelques exemples + sortie structurée schéma
C — CoT obligatoire « explique ton raisonnement en détail » en sortie libre
D — Température élevée pour créativité
Pourquoi B

L’extraction a besoin d’un mapping stable entre le document source et les champs cibles. Le few-shot montre le comportement attendu. Le schéma facilite le parsing.

Pourquoi pas les autres

A reste fragile à parser. C ajoute de la verbosité sans résoudre le format. D augmente les dérives alors que l’on cherche une sortie sobre et stable.

Fin de séance

Erreurs fréquentes et mini-résumé final

Erreurs fréquentes à éviter

  1. Penser que sortie structurée veut dire contenu vrai.
  2. Utiliser un juge LLM comme seule validation en contexte à enjeu.
  3. Oublier que chaining et sous-agents augmentent latence et tokens.
  4. Croire qu’une stratégie de résumé efface le risque de non-fidélité.
  5. Oublier qu’une petite modification du début du prompt peut casser le bénéfice du cache.

Mini-résumé

Le prompt engineering avancé consiste moins à écrire un prompt parfait qu’à concevoir un système. Décomposition, chaining, sous-agents, sorties structurées, caching et évaluation améliorent la robustesse, mais ne garantissent ni la vérité ni l’absence d’erreur. Ils doivent être articulés avec des stratégies de vérification.

Contrôle qualité final à conserver
  • Tokenisation et embedding clairement distingués.
  • Paramètres et dimension d’embedding bien séparés.
  • Pas de vision simpliste du premier LLM.
  • Nuance explicite sur position et self-attention.
  • Pas de promesse irréaliste sur la suppression des hallucinations.
  • Alignement présenté comme amélioration utile, pas comme vérité absolue.
  • Fine-tuning présenté comme levier, pas comme garantie.
Bibliographie

Bibliographie commentée de la séance

  • Structured model outputs — documentation officielle. Usage dans la séance, sorties structurées et schéma.
  • Summarizing Long Documents — cookbook officiel. Usage dans la séance, stratégie de résumé long par chunking puis synthèse.
  • Prompt caching — API guide et cookbooks. Usage dans la séance, optimisation coût et latence.
À retenir dans l’ensemble de la séance. Un bon système de prompting améliore la robustesse, la lisibilité et la vérifiabilité. Il ne transforme jamais une probabilité en certitude.