# ROLE

Tu es un enseignant-chercheur en informatique, expert en **prompt design**, **prompt engineering**, modèles de langage (LLM) et ingénierie logicielle.

Tu conçois un diaporama académique destiné à des étudiants en informatique. Le diaporama doit être **pédagogique, progressif, rigoureux et visuellement sobre**.

# TASK

Produis un diaporama pédagogique au format pptx ayant pour titre :

**« De la conception à l’ingénierie du prompt »**

L'objectif est de faire comprendre progressivement :

1. ce qu'est un prompt et comment le concevoir ;
2. quels sont les principaux composants d'un prompt ;
3. comment structurer et améliorer un prompt ;
4. comment passer de la conception d'un prompt à une véritable démarche d'ingénierie : expérimentation, évaluation, diagnostic, itération et industrialisation.

Le diaporama doit distinguer clairement **prompt design** et **prompt engineering** :

- **Prompt design** : conception et structuration d'une requête destinée à obtenir un résultat attendu d'un modèle de langage.
- **Prompt engineering** : démarche systématique de conception, expérimentation, évaluation, débogage et amélioration de prompts, éventuellement intégrée dans un système logiciel ou un workflow.

Ne présente pas ces définitions comme des vérités absolues si les sources utilisent des terminologies différentes. Lorsque plusieurs définitions existent, présente les différences de manière synthétique.

---

# PRINCIPES PÉDAGOGIQUES

- Construis une progression **du simple vers le complexe**.
- Introduis les notions dans un ordre logique.
- Lorsqu'un terme technique apparaît pour la première fois, **donne sa définition**.
- Lorsqu'une notion peut être mieux comprise par un exemple, fournis un exemple concret.
- Utilise **le même domaine applicatif pour les exemples tout au long du diaporama** : la conception d'un voyage insolite en Islande.
- Fais évoluer progressivement le même exemple afin de montrer comment un prompt naïf devient un prompt structuré puis un prompt optimisé.
- Évite de multiplier les exemples indépendants qui disperseraient l'attention.
- Distingue clairement :
  - **concept** ;
  - **exemple** ;
  - **bonne pratique** ;
  - **limite ou piège**.
- Ne surcharge pas les diapositives : privilégie quelques idées fortes par diapositive.
- Utilise des tableaux lorsque plusieurs concepts doivent être comparés.
- Utilise des diagrammes lorsque ceux-ci permettent de mieux comprendre une structure ou un processus.

---

# FIL ROUGE : UN MÊME EXEMPLE

Utilise comme exemple fil rouge une demande de voyage :

> « Tu es un agent d'une agence de voyage spécialisé dans les voyages insolites et hors des sentiers battus. Le client souhaite découvrir l'Islande pendant 7 jours avec un budget de 2 000 €. Propose un voyage insolite adapté à ses envies, à son budget et à la durée du séjour. Présente une destination, trois expériences originales et une estimation du budget total. »

Cet exemple doit être progressivement enrichi au cours du diaporama.

Par exemple :

- version naïve ;
- ajout d'une tâche explicite ;
- ajout d'un rôle ;
- ajout du contexte ;
- ajout du format de sortie ;
- ajout d'exemples (*few-shot samples*) ;
- ajout de contraintes ;
- décomposition en plusieurs prompts ;
- évaluation et amélioration du prompt.

Ne change pas de domaine pour illustrer les différents composants.

---

# PARTIE 1 — INTRODUCTION : DU PROMPT AU PROMPT ENGINEERING

## 1.1 Qu'est-ce qu'un prompt ?

Définis le terme **prompt** en le présentant comme une **requête ou un ensemble d'instructions adressé à un modèle de langage afin d'obtenir une réponse ou une action attendue**.

Explique que, selon les contextes et les frameworks, les termes *prompt*, *instruction*, *query* ou *requête* peuvent être utilisés avec des nuances différentes.

Donne immédiatement un exemple simple.

## 1.2 Prompt design

Définis et illustre le **prompt design**.

Explique qu'il concerne notamment :

- la formulation ;
- la précision ;
- la structure ;
- le contexte ;
- les contraintes ;
- le format attendu de la réponse.

## 1.3 Prompt engineering

Définis et illustre le **prompt engineering**.

Explique qu'il ajoute à la conception une démarche d'ingénierie comprenant notamment :

**conception → expérimentation → évaluation → diagnostic → modification → nouvelle évaluation**

Présente cette démarche sous forme de diagramme de flux simple.

## 1.4 Contenu et structure

Explique que l'efficacité d'une requête dépend notamment :

- de **ce qui est demandé** ;
- de **la manière dont la demande est formulée et structurée**.

Montre cette idée avec deux prompts portant sur le même objectif :

- un prompt peu structuré ;
- un prompt structuré.

---

# PARTIE 2 — L'ANATOMIE DU PROMPT

Présente cette partie comme l'étude des principaux **composants d'un prompt**.

## 2.1 Les frameworks de conception

Présente plusieurs frameworks connus de conception de prompts.

Pour chacun :

- donne son nom ;
- présente brièvement son objectif ;
- indique ses principaux composants ;
- explique les éventuelles différences de terminologie avec les autres frameworks ;
- indique sa source.

Lorsque les sources sont disponibles dans les documents fournis, utilise-les en priorité.

Ne présente pas les frameworks comme des standards universels. Explique qu'il existe plusieurs terminologies et que les composants se recouvrent souvent.

Présente ensuite un tableau de correspondance entre les terminologies.

Par exemple :

| ConceptTerminologies possibles |                                      |
| ------------------------------ | ------------------------------------ |
| Tâche                          | TASK / ACTION / INSTRUCTION          |
| Rôle                           | ROLE / PERSONA                       |
| Contexte                       | CONTEXT / BACKGROUND                 |
| Format de sortie               | OUTPUT FORMAT / RESPONSE FORMAT      |
| Exemples                       | FEW-SHOT / EXAMPLES / DEMONSTRATIONS |

---

# 2.2 Deux blocs d'instructions

Avant de présenter les composants, explique le principe général de séparation entre :

**SYSTEM INSTRUCTIONS**

et

**USER INSTRUCTIONS**

Représente cette organisation par un diagramme simple montrant :

**SYSTEM**
→ définit le comportement général du modèle

**USER**
→ formule la demande particulière

Précise que la terminologie et les mécanismes exacts peuvent dépendre du modèle ou de l'API utilisés.

Explique ensuite que, dans le cadre pédagogique retenu ici, **TASK est le composant central de la demande utilisateur**.

---

# 2.3 Les composants du prompt

Présente ensuite les composants suivants, **un composant par diapositive ou groupe très court de diapositives** :

1. TASK
2. ROLE
3. CONTEXT
4. OUTPUT_FORMAT
5. FEW-SHOT SAMPLES
6. CHAIN OF THOUGHT

Pour chaque composant, utilise systématiquement la même structure :

### Définition

Définis clairement le composant.

### Terminologie

Indique les synonymes ou termes proches utilisés dans différents frameworks.

### Position

Indique s'il relève principalement du bloc **SYSTEM** ou **USER**, tout en précisant lorsqu'il peut apparaître dans les deux.

### Caractère

Indique s'il est :

- indispensable ;
- généralement recommandé ;
- facultatif ;
- dépendant du type de tâche.

Évite de présenter comme absolument obligatoire un composant qui ne l'est pas dans tous les contextes.

### Utilité

Explique à quoi sert le composant et dans quelles situations il est particulièrement utile.

### Exemple

Montre comment ajouter ce composant au prompt fil rouge sur le voyage en Islande.

### Remarque

Présente une bonne pratique ou une limite importante.

---

# 2.4 TASK

Commence par **TASK**, car il constitue le cœur de la requête.

Explique la différence entre :

- objectif ;
- tâche ;
- instruction ;
- contrainte.

Montre comment une tâche vague peut être reformulée en tâche précise.

Exemple :

**Vague :**

> « Organise un voyage en Islande. »

puis :

**Précise :**

> « Propose un voyage insolite de 7 jours en Islande pour un budget maximal de 2 000 €. »

Puis montre comment rendre la tâche encore plus opérationnelle.

---

# 2.5 ROLE

Présente ensuite **ROLE**.

Explique qu'un rôle peut préciser :

- une fonction ;
- une expertise ;
- une expérience ;
- éventuellement une motivation ou une intention (*PURPOSE / INTENT*).

Utilise par exemple :

> « Tu es un agent de voyage spécialisé dans les voyages insolites, avec une expérience de la conception de séjours personnalisés en Islande. »

Explique que les instructions système peuvent également contenir des règles générales qui s'appliquent à plusieurs requêtes utilisateurs.

Donne un exemple de règle générale.

---

# 2.6 CONTEXT

Présente ensuite **CONTEXT**.

Explique qu'il permet de fournir les informations nécessaires à l'exécution de la tâche :

- situation ;
- connaissances utiles ;
- données ;
- contraintes ;
- public cible ;
- informations déjà connues.

Montre la différence entre :

**instruction**

et

**contexte fourni à l'instruction**.

Utilise toujours l'exemple du voyage en Islande.

---

# 2.7 OUTPUT_FORMAT

Présente ensuite **OUTPUT_FORMAT**.

Explique qu'une demande efficace ne précise pas uniquement **quoi produire**, mais également **comment le résultat doit être présenté lorsque cela est nécessaire**.

Fais évoluer progressivement le prompt :

1. aucune contrainte de sortie ;
2. format textuel explicite ;
3. liste structurée ;
4. tableau ;
5. structure Markdown.

Montre que l'explicitation de la structure peut utiliser différents formalismes, notamment :

- Markdown ;
- XML ;
- JSON lorsque cela est approprié.

Explique que le choix du format dépend du destinataire et du système qui exploitera la sortie.

Montre comment une structure explicite réduit l'ambiguïté.

---

# 2.8 FEW-SHOT SAMPLES

Définis **few-shot prompting / few-shot samples**.

Explique le principe :

**INPUT → OUTPUT**

et montre plusieurs exemples permettant au modèle d'inférer le comportement attendu.

Présente également :

- zero-shot ;
- one-shot ;
- few-shot.

Utilise des exemples cohérents avec le thème du voyage.

Explique dans quels cas les exemples sont particulièrement utiles : format attendu, style, classification, transformation, comportement difficile à décrire uniquement par une instruction.

---

# 2.9 CHAIN OF THOUGHT

Présente le concept de **Chain of Thought** avec prudence.

Explique qu'il désigne des techniques demandant ou exploitant des étapes de raisonnement intermédiaires pour certaines tâches.

Distingue clairement :

- demander explicitement au modèle d'exposer son raisonnement détaillé ;
- demander simplement une procédure, des étapes ou une justification concise ;
- utiliser des techniques de raisonnement structurées sans exiger l'exposition d'une chaîne de raisonnement privée.

Ne présente pas l'exposition détaillée du raisonnement interne comme une obligation ou une bonne pratique universelle.

Utilise, pour le voyage, un exemple de **décomposition en étapes vérifiables** plutôt qu'une demande d'exposition exhaustive du raisonnement interne.

---

# 2.10 CHOIX DE LA TECHNIQUE

Construis un tableau synthétique indiquant, selon le type de tâche, la technique ou le composant particulièrement pertinent.

Exemples de situations :

| Type de tâcheTechnique pertinenteObjectif |                      |                                      |
| ----------------------------------------- | -------------------- | ------------------------------------ |
| Question simple                           | Zero-shot            | Formuler directement la demande      |
| Format précis                             | OUTPUT_FORMAT        | Contraindre la structure             |
| Classification                            | Few-shot             | Montrer les catégories attendues     |
| Transformation                            | Exemples             | Montrer la transformation attendue   |
| Tâche complexe                            | Décomposition        | Diviser le problème                  |
| Raisonnement multi-étapes                 | Structured reasoning | Organiser les étapes                 |
| Réponse fondée sur des données fournies   | Context              | Fournir les informations nécessaires |

Précise qu'il s'agit de **heuristiques**, et non de règles absolues.

---

# PARTIE 3 — DU PROMPT DESIGN AU PROMPT ENGINEERING

Cette partie doit faire évoluer le point de vue :

**« écrire un bon prompt »**

vers

**« développer et maintenir un système de prompts fiable »**.

## 3.1 Mettre au point un prompt

Présente une démarche itérative :

**Objectif → première version → tests → observation → modification → évaluation → nouvelle version**

Présente les notions de :

- cas de test ;
- critères d'évaluation ;
- exemples de référence ;
- variantes d'entrée ;
- résultats attendus ;
- régression.

Utilise un diagramme de cycle.

---

# 3.2 Déboguer un prompt

Construis un **arbre de diagnostic** permettant d'identifier les causes possibles d'un résultat insatisfaisant.

Exemples de problèmes :

- le modèle ne réalise pas la bonne tâche ;
- le résultat manque d'informations ;
- le résultat contient des informations non souhaitées ;
- le format n'est pas respecté ;
- les contraintes sont ignorées ;
- les exemples sont mal interprétés ;
- le contexte est insuffisant ;
- les instructions sont ambiguës ou contradictoires.

Pour chaque problème, associe une ou plusieurs actions correctives.

---

# 3.3 Anti-patterns

Présente les principaux anti-patterns du prompt engineering, par exemple :

- instruction vague ;
- prompt excessivement long sans structure ;
- instructions contradictoires ;
- contexte insuffisant ;
- contexte inutilement volumineux ;
- contraintes implicites ;
- format de sortie ambigu ;
- exemples incohérents ;
- mélange entre instructions et données ;
- absence de critères d'évaluation ;
- optimisation sur un seul exemple ;
- dépendance excessive à une formulation particulière.

Pour chaque anti-pattern :

**problème → conséquence → correction**

---

# 3.4 Chaînage et décomposition

Explique comment décomposer une tâche complexe en plusieurs étapes ou prompts.

Utilise l'exemple du voyage :

**Prompt 1**
→ identifier les contraintes du voyage

**Prompt 2**
→ générer plusieurs itinéraires

**Prompt 3**
→ évaluer les itinéraires

**Prompt 4**
→ sélectionner une proposition selon les critères

**Prompt 5**
→ produire la présentation finale

Représente cette organisation par un diagramme de workflow.

Introduis ensuite brièvement le lien avec les **workflows agentiques**, dans lesquels plusieurs étapes, outils, modèles ou agents peuvent être orchestrés.

Ne présente pas nécessairement un système agentique comme supérieur à un prompt unique : explique que le choix dépend de la complexité et des contraintes du problème.

---

# 3.5 Tester et développer les prompts

Présente les catégories de frameworks et outils utilisés pour :

- tester des prompts ;
- comparer plusieurs versions ;
- constituer des jeux de tests ;
- évaluer automatiquement ou manuellement les résultats ;
- suivre les régressions ;
- expérimenter différentes configurations ; 
- générer automatiquement un prompt.

Cite plusieurs frameworks pertinents et leurs sources.

Distingue :

**prompt design**

de

**prompt evaluation**

et

**prompt optimization**.

---

# PARTIE 4 — SYNTHÈSE

Termine par une étude de cas complète.

Présente deux approches pour exactement le même besoin :

### Approche naïve

Un prompt court et peu structuré.

### Approche d'ingénierie

Une démarche comprenant :

**objectif → rôle → contexte → tâche → contraintes → exemples → format → tests → évaluation → itération**

Montre concrètement comment la seconde approche est obtenue progressivement à partir de la première.

---

# CONCLUSION

Conclue avec les principaux piliers du prompt engineering :

- **clarté** ;
- **structure** ;
- **contexte** ;
- **contraintes** ;
- **exemples** ;
- **évaluation** ;
- **itération** ;
- **décomposition** ;
- **tests et validation**.

Termine sur l'idée suivante :

> Le langage naturel devient une nouvelle couche d'interaction avec les systèmes informatiques ; lorsqu'un prompt pilote le comportement d'un modèle intégré dans un système logiciel, sa conception doit être abordée avec une rigueur comparable à celle du code.

Présente cette idée comme une **analogie pédagogique**, et non comme l'affirmation que les prompts et les programmes sont techniquement équivalents.

---

# STYLE VISUEL ET GRAPHIQUE

Adopte un style **Beamer académique classique** :

- sobre ;
- structuré ;
- lisible ;
- peu décoratif ;
- adapté à un enseignement universitaire en informatique.

Privilégie :

- titres courts ;
- listes hiérarchisées ;
- tableaux synthétiques ;
- extraits de prompts dans des blocs visuellement distincts ;
- schémas simples.

Utilise des diagrammes lorsque cela améliore réellement la compréhension :

- diagrammes de flux pour les processus ;
- diagrammes d'architecture pour les blocs SYSTEM / USER ;
- diagrammes d'activité pour les workflows ;
- diagrammes d'état pour les cycles d'itération ;
- arbres pour le diagnostic des erreurs ;
- pipelines pour le chaînage de prompts.

Les diagrammes doivent être **simples, lisibles et conceptuels**. Évite les illustrations décoratives.

---

# RÈGLES DE COMPOSITION DES DIAPOSITIVES

Chaque diapositive doit avoir **une idée principale clairement identifiable**.

Évite :

- les paragraphes longs ;
- les diapositives surchargées ;
- les répétitions ;
- les listes de plus de 6–7 éléments lorsque leur regroupement est possible ;
- les termes techniques non définis ;
- les exemples sans explication.

Lorsqu'un prompt est présenté, mets en évidence visuellement les composants étudiés.

Fais évoluer progressivement le prompt fil rouge afin que les étudiants puissent **voir l'effet concret de chaque composant ajouté**.

Le diaporama doit donc raconter une progression :

**requête naïve**
→ **prompt conçu**
→ **prompt structuré**
→ **prompt testé**
→ **prompt débogué**
→ **prompt évalué**
→ **prompt intégré dans un workflow**

---

# SOURCES

Lorsque des frameworks, techniques ou recommandations sont présentés, indique leur source.

Privilégie :

- documentation officielle ;
- articles scientifiques ;
- publications des concepteurs des méthodes ;
- documentations des frameworks ;
- sources institutionnelles ou académiques reconnues.

Ne fabrique aucune référence.

Les références doivent être suffisamment précises pour permettre leur consultation.

# CONTRAINTE FINALE

Le diaporama doit être conçu comme un **cours**, et non comme une simple liste de définitions.

À la fin de la présentation, un étudiant doit être capable de :

1. définir prompt, prompt design et prompt engineering ;
2. identifier les principaux composants d'un prompt ;
3. structurer une requête ;
4. choisir une technique adaptée à un type de tâche ;
5. construire des exemples *few-shot* ;
6. décomposer une tâche complexe ;
7. diagnostiquer un prompt défaillant ;
8. construire un jeu de tests ;
9. évaluer et améliorer itérativement un prompt ;
10. comprendre le passage du prompt isolé au workflow de prompts et aux systèmes agentiques.