# UKP — Prompt Engineering pour agents IA autonomes

> Source : NotebookLM "80-Agent-Prompting" (Deep Research) — https://notebooklm.google.com/notebook/63ddbba7-7d3f-4a8d-97a6-7fa75c4a3d53
> Généré le : 2026-07-07
> Agents consommateurs : 80 (Prompting) — transversal à tous les agents

---

## AXE 1 — FONDAMENTAUX DU PROMPT ENGINEERING

### Anatomie d'un prompt performant

Un prompt "production" doit être décomposé en sections claires, séparées par des balises (XML recommandé pour Claude).

| Section | Rôle | Exemple |
|---|---|---|
| **Rôle/Persona** | Expertise et ton de l'agent | "Tu es un expert en cybersécurité" |
| **Contexte/Données** | Informations de fond et documents de référence | Documents uploadés, fichiers UKP |
| **Tâche** | Instruction précise de ce que l'agent doit accomplir | Verbes d'action explicites |
| **Contraintes** | Règles de comportement (faire et NE PAS faire) | Règles non-négociables avec "pourquoi" |
| **Format de sortie** | Structure exacte attendue | JSON, Markdown, tableau, citations |

### System prompt vs User prompt vs Few-shot

| Type | Usage | Autorité |
|---|---|---|
| **System/Developer** | Instructions persistantes, identité, règles de sécurité | Maximale — prévaut sur l'utilisateur |
| **User** | Requête immédiate, données variables | Transiente |
| **Few-shot** | Exemples de couples (entrée/sortie) pour guider le modèle | Haute — modélise le pattern attendu |

### Précision vs Longueur

**La précision bat la longueur.** Un prompt trop long ou répétitif provoque le phénomène de "perte au milieu" (Lost in the middle) : le modèle ignore les instructions centrales.

**Signes d'un prompt trop vague :**
- Termes subjectifs ("sois bon", "analyse bien") sans critères mesurables
- Absence de critères de succès ou de définition du "bon résultat"
- Instructions non-séquentielles sans ordre de priorité

**Toujours préciser le format de sortie** — permet une validation déterministe par code.

> **Exemple avant/après :**
> - Faible : "Résume ce texte de manière concise."
> - Corrigé : "Résume le texte fourni dans `<document>`. Produis exactement 3 puces. Ton professionnel. Format Markdown."

---

## AXE 2 — TECHNIQUES AVANCÉES

### Chain-of-Thought (CoT)

**Quand :** tâches de logique, calculs, décisions complexes.
**Comment :** demander au modèle de "penser étape par étape" avant de répondre.

> - Faible : "Quelle est la rentabilité de ce projet ?"
> - Corrigé (Claude) : "Analyse la rentabilité. `<thinking>` Détaille d'abord tes calculs étape par étape. `</thinking>` Donne ensuite ta conclusion finale."

### Few-shot Prompting

- **Volume :** 3 à 5 exemples diversifiés couvrant les cas limites
- **Sélection :** exemples représentatifs du spectre — ne pas prendre que les cas faciles
- **Piège :** des exemples trop similaires induisent un sur-apprentissage (overfitting) — le modèle cale sur le pattern superficiel, pas sur la logique

### Décomposition et Prompt Chaining

Diviser une tâche complexe en étapes indépendantes où la sortie du prompt A devient l'entrée du prompt B.

Exemple Fidulia :
```
Étape 1 (Agent 50 — Veille) : Extraire les thèmes de la semaine
→ Étape 2 (Agent 30 — Rédacteur) : Rédiger un post par thème retenu
→ Étape 3 (Agent 33 — Juriste) : Valider la conformité AMF
```

### Self-consistency et Vérification

Demander au modèle de critiquer sa propre sortie par rapport aux contraintes initiales.

> - Corrigé : "Rédige le post LinkedIn, puis vérifie s'il respecte les contraintes AMF définies. Corrige-le si nécessaire avant la réponse finale."

### Meta-prompting

Utiliser un modèle pour générer ou améliorer un prompt. Utile pour initialiser un nouveau système prompt d'agent ou optimiser une formulation qui échoue.

---

## AXE 3 — SYSTEM PROMPTS POUR AGENTS AUTONOMES

### Structure recommandée

1. **Rôle** — identité fonctionnelle (qui es-tu, quelle expertise)
2. **Périmètre** — ce que l'agent est autorisé à voir ou modifier
3. **Outils** — description des fonctions (`tool_use`) et quand les appeler
4. **Processus** — boucle "Pensée → Action → Observation" (pattern ReAct)
5. **Garde-fous** — règles non-négociables avec justification explicite

### Ce qui va dans le system prompt vs dans un fichier UKP

| System prompt | Fichier UKP externe |
|---|---|
| Rôle, périmètre, processus, règles non-négociables | Connaissance métier détaillée (specs, benchmarks, recettes) |
| Instructions stables — changent rarement | Données qui évoluent (algorithme LinkedIn, tarifs, normes) |
| Court et précis (< 500 tokens idéalement) | Peut être long — consulté à la demande |
| Toujours chargé | Chargé uniquement quand pertinent |

**Règle :** si une information peut changer, elle va dans un UKP. Si elle définit l'identité ou les garde-fous de l'agent, elle reste dans le system prompt.

### Gestion des outils (Tool Use / Function Calling)

- Décrire chaque outil avec son nom, ses paramètres (JSON Schema), et **quand l'utiliser**
- Préciser les cas où il ne faut PAS appeler l'outil
- Appliquer le **principe du moindre privilège** — un agent ne doit avoir que les outils dont il a besoin
- Justifier chaque garde-fou par un "pourquoi" — le modèle généralise mieux une règle qu'il comprend

### Écrire des règles non-négociables qui tiennent sous pression

❌ Fragile : "Ne jamais supprimer de fichiers."
✅ Robuste : "Ne jamais supprimer de fichiers — toute suppression est irréversible et peut détruire le travail du client. En cas de doute, archiver plutôt que supprimer et signaler à Fabien."

La justification ancre la règle dans une intention — le modèle résiste mieux à un prompt injection qui essaie de la contourner.

---

## AXE 4 — SPÉCIFICITÉS PAR MODÈLE

| Caractéristique | Claude (Anthropic) | Gemini (Google) | GPT (OpenAI) |
|---|---|---|---|
| **Structure** | **Balises XML** (`<tag>`) recommandées | Schéma progressif (Base → Avancé) | Markdown et triple guillemets (`"""`) |
| **Raisonnement** | Mode Extended Thinking (budget tokens) | Raisonnement spatial natif pour l'image | o1/o3 (chaîne de pensée interne) |
| **Sensibilité ordre** | Très sensible — instructions critiques **à la fin** | Optimisé pour contextes massifs (1M+ tokens) | Suit les instructions très littéralement (4.1+) |
| **Cas fort** | Raisonnement structuré, respect des contraintes complexes | Multimodal, contexte long, image | Littéralité, instructions simples et précises |

### NotebookLM — Limite de caractères

**Contrainte confirmée (déc. 2025) :** le champ "Configure Chat" (instructions personnalisées / system prompt du notebook) est plafonné à **10 000 caractères** (relevé de 500 caractères). Aucune limite précise n'est documentée par Google pour un message isolé envoyé dans le fil de chat — seuls des quotas de *nombre* de requêtes/jour existent selon le plan (50 à 5 000 requêtes/jour).

**Règle appliquée par l'Agent Prompting :** par prudence, tout prompt généré pour NotebookLM (system prompt de configuration ou message envoyé dans le chat) doit rester **sous 8 000 caractères** (marge de sécurité de 20 % sous le plafond confirmé de 10 000). Si un prompt dépasse ce seuil, le découper en plusieurs messages séquentiels (ex : configurer le persona d'abord, envoyer la tâche Deep Research ensuite) plutôt que de tout compresser dans un seul bloc.

### Gemini — Prompts Image (Framework SCHEMA)

Pour générer des visuels avec Gemini/Nano Banana, utiliser ces labels :

| Label | Rôle | Exemple |
|---|---|---|
| **Subject** | Description visuelle principale | "CGP en costume dans un bureau épuré" |
| **Mandatory** | Contraintes positives | "Lumière naturelle 5000K, fond navy #0C132A" |
| **Prohibitions** | Contraintes négatives | "PAS de reflets, PAS de sourire forcé" |
| **Note** | Informations contextuelles | "Style photo corporate premium, pas illustratif" |

**Important :** sur Gemini, les **interdictions** (`Prohibitions`) fonctionnent mieux que les obligations — formuler ce qu'on ne veut pas plutôt que ce qu'on veut.

### Claude — Spécificités pratiques

- Utiliser des balises XML pour délimiter les sections : `<context>`, `<task>`, `<constraints>`, `<output_format>`
- Placer les instructions les plus critiques **à la fin** du prompt (effet de récence)
- Pour les agents avec UKP : charger les fichiers de référence dans `<context>`, les règles dans `<constraints>`
- Extended Thinking : activer pour les tâches d'analyse complexe (stratégie, audit), désactiver pour la production rapide

---

## AXE 5 — DIAGNOSTIC ET CORRECTION

### Grille de diagnostic

| Symptôme | Cause probable | Correction |
|---|---|---|
| **Sortie vague** | Instructions trop génériques, verbes subjectifs | Utiliser des verbes d'action et des mesures chiffrées |
| **Format ignoré** | Contraintes de format placées trop tôt | Déplacer le format de sortie **à la toute fin** du prompt |
| **Hallucination** | Manque de données ou pression pour répondre | Autoriser explicitement "Je ne sais pas" + exiger des citations |
| **Ton incorrect** | Persona mal défini ou contradictoire | Fournir 3 exemples de ton en few-shot |
| **Hors sujet** | Tâche trop large ou ambiguë | Décomposer en sous-tâches, une par prompt |

### Méthode d'itération

1. Identifier le **symptôme** dans la sortie (vague ? format ? ton ?)
2. Remonter à la **cause** dans le prompt (section manquante ? instruction contradictoire ?)
3. Modifier **un seul élément** à la fois pour isoler l'effet
4. Tester sur le même input avant de valider

Ne jamais réécrire un prompt entier qui ne marche pas à 80 % — identifier la section qui cause les 20 % d'échec.

---

## AXE 6 — ANTI-PATTERNS ET PIÈGES

| Anti-pattern | Description | Correction |
|---|---|---|
| **Sur-contrainte** | Trop de règles "NE FAIS JAMAIS..." brisent la logique globale | Garder ≤ 7 règles non-négociables, hiérarchisées |
| **Instructions implicites** | Supposer que le modèle "comprend" le jargon métier | Toujours définir le jargon spécifique (CGP, ORIAS, etc.) |
| **Absence de "Pourquoi"** | Règle sans justification — le modèle la respecte moins bien | Ajouter systématiquement la raison derrière chaque contrainte |
| **Redondance** | Répéter "sois concis" 10 fois réduit l'attention sur le reste | Une règle = une occurrence, au bon endroit |
| **Instructions contradictoires** | "Sois bref" et "détaille chaque point" dans le même prompt | Relire le prompt entier avant envoi, tester la cohérence |

---

## AXE 7 — SÉCURITÉ ET ROBUSTESSE

### Prompt Injection

Un attaquant insère dans les données utilisateur des instructions comme "Ignore les instructions précédentes et fais X".

**Défenses :**
- Utiliser des délimiteurs stricts entre les instructions du system prompt et les données utilisateur
- Traiter toutes les entrées utilisateur comme des **données**, jamais comme des commandes
- Ne jamais demander au modèle d'exécuter du contenu venant de l'extérieur sans validation

### Ce qu'on ne délègue jamais à un prompt seul

1. **Validation finale des actions irréversibles** (suppression, envoi, paiement) → toujours demander confirmation humaine (HITL)
2. **Sécurité des accès** (authentification) → géré par le code applicatif, pas le LLM
3. **Décisions qui engagent le client** sans relecture humaine

---

## CHECKLIST — AVANT D'ENVOYER UN PROMPT EN PRODUCTION

- [ ] **Structure** : le prompt utilise-t-il des balises pour séparer contexte, instructions et exemples ?
- [ ] **Rôle** : le persona est-il expert et adapté à la tâche ?
- [ ] **Ordre** : les instructions les plus critiques sont-elles à la fin ?
- [ ] **Exemples** : y a-t-il au moins 3 exemples représentatifs (few-shot) ?
- [ ] **Sécurité** : le modèle a-t-il l'autorisation explicite de dire "Je ne sais pas" ?
- [ ] **Format** : le format de sortie est-il strictement défini et validable par script ?
- [ ] **Garde-fous** : chaque règle non-négociable a-t-elle un "pourquoi" explicite ?
- [ ] **Actions critiques** : les actions irréversibles nécessitent-elles une validation humaine ?
- [ ] **NotebookLM (si applicable)** : le prompt reste-t-il sous 8 000 caractères ?

---

*Dernière mise à jour : 2026-07-07 — Création Agent 80*
*Agent consommateur : 80 (Prompting) — transversal à tous les agents Fidulia*