Prompts Système pour les Agents de Présentation IA : Guide du Développeur (2026)

Les prompts système pour les agents de présentation IA sont différents des prompts utilisateur — ils encodent le rôle de l'agent, les contraintes et le contrat de sortie plutôt que la tâche spécifique. Un prompt système bien conçu transforme un LLM généraliste en agent de génération de slides fiable : voix cohérente, structure prévisible et utilisation d'outils appelables. Ce guide du développeur couvre le modèle de prompt système en 7 sections utilisé en production par le pipeline d'agent propre à 2Slides, un prompt système prêt à copier-coller pour construire un agent de slides avec Claude, GPT-4o ou DeepSeek, les trois anti-patterns qui produisent des sorties peu fiables, et comment intégrer un prompt système avec l'API V1 de 2Slides (generate, create-pdf-slides, create-like-this, generate-narration, jobs/:id, themes/search). Le guide se termine par trois exemples détaillés : un agent de pitch deck qui convertit des notes de fondateur en decks investisseurs, un agent de board deck qui formate des métriques trimestrielles pour des audiences de direction, et un agent d'ingestion qui convertit des PDF en présentations.

Si vous développez un chatbot, un assistant de codage qui produit des slides en sortie, ou un outil interne qui automatise le reporting, la différence entre une démo et la production réside presque entièrement dans le prompt système. Ce guide est écrit pour une audience de développeurs : pas de jargon marketing, du vrai code, de vrais endpoints.

Prompts système vs prompts utilisateur : Quelle est la vraie différence ?

Un prompt utilisateur est la tâche. Un prompt système est le manuel d'utilisation.

Quand un chef de produit tape « crée-moi 10 slides sur le chiffre d'affaires du T3 », c'est un prompt utilisateur. Quand votre agent renvoie systématiquement du JSON valide, ne dépasse jamais votre budget de slides, cite toujours les sources dans les notes de présentation, et appelle l'endpoint

quand l'utilisateur télécharge un fichier — ce comportement provient du prompt système.

Dans les API OpenAI, Anthropic et Google, le prompt système est un champ séparé (

chez Anthropic, rôle dans les complétions chat OpenAI, dans Gemini). Les modèles sont entraînés pour lui accorder plus de poids qu'aux tours utilisateur et pour le traiter comme non-modifiable par les messages suivants. Cela en fait l'endroit approprié pour :

• La définition du rôle — quel type d'agent il s'agit
• Les contrats de sortie — schéma JSON, format markdown, ou structure d'appel d'outil
• Les contraintes strictes — limites de mots, règles de ton, contenu interdit
• L'inventaire des outils/API — quelles fonctions sont appelables et quand
• Les règles d'escalade — quand refuser, demander une clarification, ou déléguer

Les prompts utilisateur qui tentent d'encoder tout cela se cassent dès que le texte de la tâche utilisateur devient long. Les prompts système survivent à chaque tour.

Le Modèle de Prompt Système en 7 Sections

Chaque agent de génération de diapositives fiable que nous avons déployé ou audité chez 2Slides utilise une variante de cette structure en sept sections. L'ordre compte — les LLM accordent plus de poids aux instructions placées plus tôt, donc le rôle et le contrat viennent en premier, les exemples pratiques viennent en dernier.

1. Identité & Rôle — description en un paragraphe de qui est l'agent et ce qu'il fait
2. Contrat de Sortie — schéma ou format exact que l'agent doit retourner
3. Contraintes Strictes — règles non négociables (longueur, ton, modèles interdits)
4. Inventaire des Outils — chaque API ou fonction disponible, avec des conseils sur quand l'appeler
5. Politique de Raisonnement — comment l'agent doit réfléchir (chaîne de pensée, auto-vérification, escalade)
6. Gestion des Échecs — que faire lorsque l'entrée est ambiguë, mal formée ou hors sujet
7. Exemples Pratiques — deux à quatre paires complètes entrée/sortie démontrant le comportement correct

Le modèle est délibérément opiniâtre. Lorsque nous auditons des agents qui se comportent mal en production, la cause est presque toujours une section manquante plutôt qu'une mauvaise section. Les agents sans inventaire des outils hallucinent des points de terminaison. Les agents sans section de gestion des échecs inventent des données lorsque les entrées sont maigres. Les agents sans exemples pratiques dérivent en ton au fil des conversations longues.

Identité et Rôle

Vous êtes SlideAgent, un assistant de génération de présentations. Votre mission est de prendre des informations non structurées (notes, transcriptions, PDF, données brutes) et de retourner une spécification structurée de présentation pouvant être rendue par l'API 2Slides V1. Vous n'êtes pas un chatbot généraliste. Vous ne répondez pas aux questions de culture générale, n'écrivez pas de code, et ne tenez pas de longues conversations. Vous produisez des présentations, puis vous arrêtez.

Contrat de Sortie

Pour chaque tour utilisateur décrivant une présentation à construire, vous DEVEZ retourner un unique objet JSON correspondant à ce schéma :

{
  "title": string,              // 3-10 mots, casse de titre
  "audience": string,           // ex: "investisseurs série A", "comité exécutif"
  "tone": "formal" | "conversational" | "technical",
  "slide_count": integer,       // 5 <= n <= 40
  "language": string,           // code ISO 639-1, défaut "fr"
  "theme_hint": string,         // texte libre, sera passé à themes/search
  "slides": [
    {
      "layout": "title" | "content" | "two-column" | "quote" | "chart" | "image",
      "heading": string,        // <= 12 mots
      "bullets": string[],      // 0-5 éléments, chacun <= 18 mots
      "speaker_notes": string,  // 30-80 mots, phrases complètes
      "image_prompt": string?,  // optionnel, pour les mises en page image
      "chart_data": object?     // optionnel, pour les mises en page graphique
    }
  ],
  "api_call": {
    "endpoint": "generate" | "create-pdf-slides" | "create-like-this",
    "reasoning": string         // une phrase : pourquoi ce point de terminaison
  }
}

Aucune prose avant ou après le JSON. Aucune balise markdown autour du JSON. Si l'utilisateur pose une question qui n'est pas une demande de présentation, retournez :

{ "error": "not_a_deck_request", "suggestion": string }

Contraintes Strictes

• Ne jamais dépasser 40 diapositives. Si l'utilisateur en demande plus, limiter à 40 et le noter dans les speaker_notes de la diapositive 1.
• Chaque diapositive doit avoir des speaker_notes. Des speaker_notes vides constituent un bug.
• Les puces doivent être parallèles grammaticalement (toutes commencent par un verbe, ou toutes sont des groupes nominaux — jamais mélangés).
• N'inventez pas de statistiques. Si l'utilisateur n'a pas fourni de chiffre, n'en écrivez pas. Utilisez "[source nécessaire]" comme espace réservé.
• N'incluez pas de coordonnées, numéros de téléphone ou adresses e-mail sauf si l'utilisateur les a explicitement fournis.
• Les titres sont en casse de titre. Les puces sont en casse de phrase. Pas de MAJUSCULES PARTOUT.
• Refusez de produire du contenu diffamatoire, ou qui fait des affirmations médicales, légales ou financières que l'utilisateur n'a pas sourcées.

Inventaire d'Outils (API 2Slides V1)

Vous pouvez diriger le code appelant vers ces points de terminaison. Vous ne les appelez pas vous-même ; vous les nommez dans le champ "api_call".

• generate — Par défaut. Texte en entrée, présentation en sortie. À utiliser pour la plupart des demandes.
• create-pdf-slides — Quand l'utilisateur a téléchargé ou collé une URL PDF. Passez l'URL PDF dans le prompt utilisateur.
• create-like-this — Quand l'utilisateur a dit "comme ma dernière présentation" ou a fourni une URL de présentation de référence. Réutilise le thème + la structure.
• generate-narration — Après qu'une présentation est construite, pour ajouter une voix off TTS à chaque diapositive. N'appelez que lorsque l'utilisateur demande une vidéo ou une narration explicitement.
• download-slides-pages-voices — Téléchargement par lot des pages rendues et de l'audio. Appelez à la fin d'un flux de travail vidéo.
• jobs/:id — Interroger le statut d'une tâche asynchrone. Le code appelant gère l'interrogation ; vous ne le faites pas.
• themes/search — Trouver un thème par mot-clé. Votre champ "theme_hint" sera passé ici par le code appelant.

Politique de Raisonnement

Avant d'émettre le JSON, réfléchissez étape par étape dans des balises :

1. Analyser l'entrée utilisateur. De quoi traite réellement la présentation ?
2. Identifier l'audience. Investisseurs ? Ingénieurs ? Conseil d'administration ? Équipe commerciale ?
3. Choisir slide_count en fonction de la densité du contenu, pas de la flatterie de l'utilisateur.
4. Sélectionner le point de terminaison : generate (défaut) | create-pdf-slides | create-like-this.
5. Rédiger le plan, puis auto-vérifier : les puces sont-elles parallèles ? Les chiffres sont-ils sourcés ?

Après , émettez l'objet JSON. N'incluez pas la réflexion dans la sortie finale — le code appelant supprime les blocs avant le rendu.

Gestion des Erreurs

• Sujet ambigu : posez UNE question de clarification dans le champ "suggestion" d'une réponse d'erreur. Ne posez pas plusieurs questions.
• Entrée mal formée (l'utilisateur a collé du charabia) : retournez { "error": "unintelligible_input", "suggestion": "..." }.
• Instructions contradictoires (l'utilisateur veut 50 diapositives en 5 minutes) : respectez la contrainte stricte (max 40) et notez le conflit dans les speaker_notes de la diapositive 1.
• URL PDF qui semble invalide : émettez quand même le JSON avec api_call = create-pdf-slides ; le backend retournera une erreur claire si l'URL ne peut pas être récupérée.

Exemples Pratiques

Exemples de traduction : Entrée Minimale & Ingestion PDF

Exemple 1 : Entrée minimale

Utilisateur : « crée-moi un deck sur notre chiffre d'affaires du T3, on a atteint 4,2 M$, en hausse de 30 % en glissement annuel, l'audience est le conseil d'administration »

Audience conseil d'administration -> ton formel. Deck sur le chiffre d'affaires -> 8-12 slides est standard. Les chiffres sont sourcés (fournis par l'utilisateur). Endpoint : generate. { "title": "Bilan du Chiffre d'Affaires T3", "audience": "conseil d'administration", "tone": "formal", "slide_count": 10, "language": "fr", "theme_hint": "minimal corporate finance", "slides": [ { "layout": "title", "heading": "Bilan du Chiffre d'Affaires T3", "bullets": [], "speaker_notes": "Slide d'ouverture. ..." }, ... ], "api_call": { "endpoint": "generate", "reasoning": "Entrée texte uniquement, pas de deck de référence ni de PDF." } }

Exemple 2 : Ingestion PDF

Utilisateur : « transforme ce livre blanc en un résumé de 12 slides pour des ingénieurs : https://example.com/whitepaper.pdf »

URL PDF présente -> create-pdf-slides. Audience ingénieurs -> ton technique. L'utilisateur a spécifié 12 slides -> respecter cette consigne. { "title": "Résumé du Livre Blanc", "audience": "ingénieurs logiciels", "tone": "technical", "slide_count": 12, "language": "fr", "theme_hint": "technical documentation dark", "slides": [ ... ], "api_call": { "endpoint": "create-pdf-slides", "reasoning": "L'utilisateur a fourni une URL PDF." } }

Exemple 3 : Pas une demande de deck

Utilisateur : « quelle est la capitale de la France ? »

{ "error": "not_a_deck_request", "suggestion": "Je crée des présentations. Essayez : 'crée un briefing de 5 slides sur la France'." }

Le prompt ci-dessus fait environ 1 800 tokens. C'est le plafond que nous recommandons — tout ce qui est plus long commence à empiéter sur l'entrée réelle de l'utilisateur sur les modèles avec des fenêtres de contexte de 8k ou 16k. Pour les modèles avec un contexte de 200k, vous pouvez en toute sécurité développer les exemples détaillés pour couvrir davantage de cas limites.

## Intégration avec l'API 2Slides V1

Le prompt système nomme les endpoints ; le code appelant les invoque. Voici ce que fait chaque endpoint et quand votre agent doit l'utiliser.

- **`POST /api/v1/slides/generate`** — Le moteur principal. Accepte un prompt texte plus des indices structurés optionnels (nombre de diapositives, langue, ID de thème) et retourne un ID de tâche. Quatre-vingt-dix pour cent du trafic des agents utilise cet endpoint.
- **`POST /api/v1/slides/create-pdf-slides`** — Accepte une URL PDF et la convertit en présentation. À utiliser quand l'utilisateur télécharge un document. Gère l'extraction, le découpage et la synthèse côté serveur, évitant ainsi à votre agent d'avoir besoin d'un analyseur PDF.
- **`POST /api/v1/slides/create-like-this`** — Accepte une URL ou un ID de présentation de référence et un nouveau sujet. Réutilise le thème visuel et le rythme structurel de la référence. À utiliser pour les workflows du type « faire ressembler à notre dernier deck de conseil d'administration ».
- **`POST /api/v1/slides/generate-narration`** — Ajoute une voix off TTS à une présentation existante. Retourne les URL audio par diapositive. À chaîner après `generate` lorsque la sortie finale est une vidéo.
- **`GET /api/v1/slides/download-slides-pages-voices`** — Endpoint batch qui retourne les images de pages rendues et l'audio de narration en une seule réponse. À utiliser dans l'étape finale d'un pipeline d'export vidéo.
- **`GET /api/v1/jobs/:id`** — Endpoint de polling. Votre agent ne l'appelle pas ; c'est votre code appelant qui le fait. Retourne `pending`, `processing`, `success` ou `failed` plus l'URL finale de la présentation une fois terminée.
- **`GET /api/v1/themes/search?q=...`** — Recherche par mots-clés dans la bibliothèque de thèmes publics. Passez le champ `theme_hint` de la sortie de votre prompt système ici pour le résoudre en un ID de thème concret avant d'appeler `generate`.

Une boucle d'agent complète ressemble à ceci en pseudocode :

```ts
const completion = await llm.messages.create({
  system: SYSTEM_PROMPT,           // le template à 7 sections ci-dessus
  messages: [{ role: "user", content: userInput }],
});

const spec = JSON.parse(stripThinking(completion.content));
if (spec.error) return handleError(spec);

const theme = await fetch(`/api/v1/themes/search?q=${spec.theme_hint}`);
const job = await fetch(`/api/v1/slides/${spec.api_call.endpoint}`, {
  method: "POST",
  body: JSON.stringify({ ...spec, themeId: theme.id }),
});

const result = await pollJob(job.id); // appelle /api/v1/jobs/:id
return result.deckUrl;

Si vous découvrez la structure de l'API, le guide développeur pour créer un agent de présentation AI détaille le flux complet avec du TypeScript fonctionnel. Pour une architecture de plus haut niveau basée sur les compétences — où le prompt système n'est qu'une compétence parmi plusieurs — consultez l'aperçu des compétences d'agent de diapositives AI.

3 Anti-Patterns Qui Cassent Les Agents de Slides

Après avoir examiné des dizaines d'agents en production — des outils d'analyse internes aux copilotes de vente publics — les trois mêmes modes de défaillance apparaissent encore et encore.

Anti-Pattern 1 : Le Contrat de Sortie Sans Limites

Symptôme : L'agent renvoie parfois du JSON, parfois du markdown, parfois un paragraphe poli. Votre parseur lance

une fois toutes les 50 requêtes.

Cause : Le prompt système dit « renvoie un jeu de slides » sans spécifier la forme exacte, ou il spécifie une forme mais autorise de la prose autour.

Solution : Écrivez le schéma dans le prompt système. Dites explicitement : « Pas de prose avant ou après le JSON. Pas de barrières markdown autour du JSON. » Ensuite, passez chaque sortie dans un validateur (Zod, Pydantic, io-ts) et réessayez en cas d'échec. Traitez la conformité au schéma comme une exigence produit stricte, pas comme un bonus.

Anti-Pattern 2 : La Dérive de l'Inventaire d'Outils

Symptôme : L'agent dit avec assurance à l'utilisateur « Je vais appeler l'endpoint

» — un endpoint qui n'existe pas. Le deck de l'utilisateur n'arrive jamais.

Cause : Le prompt système mentionne les outils en prose plutôt que dans un inventaire structuré, donc le modèle hallucine des variations. Ou l'inventaire est obsolète après la mise en production de nouveaux endpoints.

Solution : Maintenez un seul inventaire canonique d'outils dans le prompt système, actualisé à chaque changement de l'API. Si votre API a 7 endpoints, listez exactement 7, chacun avec une ligne décrivant quand l'appeler. Interdisez au modèle de nommer quoi que ce soit d'autre — « Si aucun des endpoints ci-dessus ne s'applique, renvoyez

et escaladez. »

Anti-Pattern 3 : L'Hallucination de Statistiques

Symptôme : L'utilisateur dit « fais un deck sur nos chiffres du T3 » sans fournir de chiffres. L'agent écrit joyeusement « Le chiffre d'affaires a augmenté de 47,3 % pour atteindre 8,2 M$ ». Le directeur financier est furieux.

Cause : Aucune contrainte stricte n'interdit l'invention de données. Le modèle opte par défaut pour une fiction qui semble plausible, car c'est ce que font la plupart des LLMs quand les spécifications sont insuffisantes.

Solution : Ajoutez une règle explicite : « N'inventez pas de statistiques. Si l'utilisateur n'a pas fourni de chiffre, utilisez

comme espace réservé. » Ensuite, scannez les sorties avec une regex ou une vérification par LLM séparé pour détecter une spécificité suspecte. Cette seule règle a détecté plus de bugs de niveau escalade client dans notre revue que toute autre.

Exemple Pratique 1 : Agent Pitch-Deck

L'agent pitch-deck convertit les notes du fondateur en une présentation investisseur de 10 diapositives. Ajoutez ces lignes au prompt système de base :

# Spécialisation : Mode Pitch-Deck
Lors de la création d'un pitch deck, utilisez exactement cette structure :
1. Titre
2. Problème
3. Solution
4. Taille du marché (TAM/SAM/SOM)
5. Démo produit / capture d'écran
6. Métriques de traction
7. Modèle économique
8. Concurrence
9. Équipe
10. Demande (montant du financement + utilisation des fonds)

Forcer slide_count = 10. Forcer tone = "conversational but confident."
Si l'utilisateur n'a pas fourni de chiffre pour la taille du marché, la traction ou la demande,
utilisez "[source needed]" — n'inventez pas.

Exemple d'entrée : "SaaS B2B pour cabinets dentaires, nous les aidons à automatiser les demandes d'assurance, nous avons 12 clients payants, nous levons 1,5 M$ en seed."

Exemple de sortie (abrégé) : JSON de dix diapositives avec la structure fixe,

, , et la diapositive de traction affichant plutôt que des chiffres inventés.

Exemple pratique 2 : Agent Board-Deck

Les présentations pour conseil d'administration ont un contrat différent : ton formel, tableaux denses, zéro emoji, ordre de slides spécifique que les DAF attendent. Ajoutez :

# Spécialisation : Mode Board-Deck
Utilisez exactement cette structure pour les réunions de conseil d'administration :
1. Résumé exécutif (3 points)
2. Finances (chiffre d'affaires, marge, runway)
3. Tableau de bord KPI (mise en page tableau)
4. Initiatives stratégiques (statut + risque)
5. Plan de recrutement
6. Risques et mesures d'atténuation
7. Demandes au conseil

Forcer ton = "formel." Forcer la langue pour correspondre à la locale de l'utilisateur.
Chaque chiffre doit avoir une source dans speaker_notes.
Pas de slides image — les board decks sont texte et tableaux.

L'agent board-deck se marie bien avec

lorsque le conseil a vu les précédentes présentations trimestrielles. Passez l'URL du deck précédent ; le nouveau deck hérite du thème et du rythme.

Exemple Pratique 3 : Agent d'Ingestion PDF-vers-Présentation

Cet agent convertit les livres blancs clients, les PDF de recherche ou les appels d'offres en présentations résumées digestes. C'est le plus simple à construire car l'endpoint

de 2Slides fait l'essentiel du travail.

# Spécialisation : Mode d'Ingestion PDF
Déclencheur : l'utilisateur fournit une URL se terminant par .pdf OU dit explicitement
"transforme ce PDF/livre blanc/rapport en slides."

Toujours définir api_call.endpoint = "create-pdf-slides".
Définir slide_count en fonction de la longueur du PDF :
  - < 5 pages -> 5 slides
  - 5-20 pages -> 8-12 slides
  - 20-50 pages -> 15-20 slides
  - > 50 pages -> 25-30 slides (plafonné à 30)

Extraire le titre du PDF pour le titre de la présentation. Si l'utilisateur a spécifié une
audience différente de l'audience originale du PDF, signaler cela dans les
speaker_notes de la slide 1 pour que le moteur de rendu sache adapter le ton.

Pour les agents qui fonctionnent dans Claude Desktop ou un hôte MCP similaire, le flux d'ingestion PDF peut être configuré en moins d'une heure — consultez comment utiliser Claude MCP pour générer des présentations pour la procédure complète.

Foire Aux Questions

Dois-je placer le prompt système dans le code ou dans une base de données ?

Pour les agents en production, placez-le dans le contrôle de version (comme fichier

importé au moment de la compilation) et étiquetez les versions. Les prompts stockés en base de données semblent flexibles mais ils rendent les retours en arrière pénibles et obscurcissent quel prompt a produit quelle sortie dans vos journaux. Si vous avez besoin de personnalisation par client, stockez les surcharges spécifiques au client dans la base de données et fusionnez-les avec le prompt de base au moment de la requête.

Quelle longueur doit avoir un prompt système ?

Pour les agents de génération de diapositives, 1 500 à 2 500 tokens représente le point optimal. Des prompts plus courts manquent de contraintes et échouent sur les cas limites. Des prompts plus longs encombrent l'entrée réelle de l'utilisateur sur les modèles à contexte plus petit et se répètent souvent. Si vous dépassez 3 000 tokens, vérifiez les redondances — la même règle est probablement énoncée deux fois.

Ai-je besoin de prompts système différents pour Claude vs GPT-4o vs DeepSeek ?

Seulement des ajustements mineurs. Le modèle à 7 sections fonctionne sur les trois. Claude réagit bien à la structure en balises XML (

, ). GPT-4o préfère du markdown épuré avec des règles numérotées. DeepSeek gère les deux mais bénéficie d'exemples plus explicites. Rédigez un prompt de base, puis testez A/B de petites variantes de format par modèle.

Puis-je mettre à jour le prompt système sans redéployer ?

Oui — et vous devriez pouvoir le faire, pour itérer rapidement. Stockez le prompt dans une variable d'environnement ou un service de feature flags afin que l'équipe SRE puisse annuler un mauvais prompt en quelques secondes. Traitez un mauvais prompt comme un mauvais déploiement : c'est un incident de production et il nécessite les mêmes contrôles de rayon d'impact.

Comment tester un prompt système ?

Construisez un ensemble de régression de 50 à 200 paires entrée/sortie qui couvrent votre distribution réelle d'utilisateurs : présentations sur le chemin nominal, entrées adversariales, tentatives de JSON mal formé, demandes hors sujet. Exécutez l'ensemble complet à chaque modification de prompt et évaluez la conformité au schéma plus la qualité notée par des humains. C'est l'investissement technique au plus fort levier pour la fiabilité des agents.

À retenir

Un system prompt est une infrastructure, pas du texte promotionnel. C'est ce qui transforme un LLM générique en un agent de génération de slides fiable avec un contrat de sortie connu, un inventaire d'outils fixe et des modes de défaillance prévisibles. Les développeurs qui traitent le system prompt comme un artefact produit — versionné, testé, surveillé — livrent des agents qui survivent au contact avec de vrais utilisateurs. Les développeurs qui le traitent comme un exercice ponctuel de prompt engineering livrent des démos.

Le template en 7 sections et l'exemple prêt pour la production dans ce guide sont le point de départ, pas le point d'arrivée. Forkez-les, spécialisez-les pour votre cas d'usage, intégrez-les à l'API V1 de 2Slides, et — plus important encore — construisez le harnais de régression avant de livrer. Les agents qui gagneront en 2026 sont ceux dont les prompts sont conçus avec la même rigueur que leur code.

Déployez votre agent de slides en production — obtenez une clé API 2Slides ou explorez le serveur MCP.