Rédaction des prompts

Le prompt est l'endroit où vous définissez ce que fait votre agent et comment il se comporte. Bien le rédiger est l'action la plus déterminante pour la qualité de vos appels. Cette page présente nos recommandations : rédiger manuellement, structurer, gérer correctement les variables et expliciter l'usage des outils.

Découper en nœuds spécialisés

Plutôt qu'un seul agent avec un prompt long et complexe, découpez votre flux en plusieurs nœuds Agent (sous-agents), chacun dédié à une tâche précise : accueil, qualification, prise de rendez-vous, etc. Utilisez les routes de sortie (classificateur) pour aiguiller automatiquement l'appelant vers le bon sous-agent en fonction de son intention.

Cela permet d'obtenir des réponses plus cohérentes et prévisibles, car chaque nœud travaille avec un contexte focalisé et le classificateur (une fois configuré) se charge de la logique de navigation entre les étapes. Un prompt court et focalisé est bien plus facile à suivre pour le modèle qu'un prompt long qui tente de couvrir tous les cas à la fois.

Voir Types de nœuds, nœud Agent pour les sous-agents et les routes de sortie, ainsi que l'éditeur de flux pour les relier entre eux.

Structurer le prompt

Utilisez des sections claires dans votre prompt : rôle, contexte, consignes, contraintes et ton. Plus le prompt est structuré, plus le comportement de l'agent sera stable d'un appel à l'autre.

[RÔLE]
Tu es Alex, assistant support pour ACME Assurance.

[CONTEXTE]
Tu gères les appels entrants concernant les dossiers de réparation d'appareils.

[CONSIGNES]
- Identifie l'appelant et son dossier avant de donner un quelconque statut.
- Utilise l'outil de recherche de dossier avant d'annoncer un statut de réparation.

[CONTRAINTES]
- Limite chaque réponse à 1 ou 2 phrases. C'est un appel téléphonique.
- Langage parlé uniquement : pas de listes, de puces ni de markdown.
- Réponds toujours dans la langue de l'appelant.
- Si tu ne peux pas aider, dis « Je vous transfère vers un collègue » et arrête-toi.

[TON]
Calme, concis, professionnel.

Syntaxe des variables

Il existe deux façons de référencer des données dynamiques dans un prompt, et leur comportement est très différent :

Le piège de la référence de variable

Quand vous écrivez une règle du type Si [[error_message]] n'est pas vide, fais ceci, l'erreur la plus fréquente est de supposer que le LLM connaît la valeur. Par défaut, il ne la connaît pas.

Une référence {{error_message}} est remplacée par sa valeur au moment de la construction du prompt : le modèle voit donc la donnée. Une référence [[error_message]] reste intacte : le modèle ne voit que le jeton littéral, pas la valeur derrière. Pour que les règles [[...]] fonctionnent, vous devez fournir au modèle les valeurs courantes dans un bloc de contexte dédié.

Style 1a (en-tête verbeux et explicite) :

[VARIABLES DE CONTEXTE : valeurs courantes pour cet appel. Une valeur "" vide signifie que la donnée n'est pas disponible, ne jamais l'inventer.]
- Référence  : "{{claim_reference}}"
- Client     : "{{customer_first_name}}" "{{customer_last_name}}"
- Appareil   : "{{device_category}}" "{{device_brand}}"
- Erreur     : "{{error_message}}"

Style 1b (en-tête compact) :

[DONNÉES DU DOSSIER. "" = absent, ne jamais inventer.]
- Référence  : "{{claim_reference}}"
- Client     : "{{customer_first_name}}" "{{customer_last_name}}"
- Appareil   : "{{device_category}}" "{{device_brand}}"
- Erreur     : "{{error_message}}"

Style 2 (associe chaque jeton de référence à sa valeur) :

[VARIABLES DE CONTEXTE : valeurs courantes pour cet appel. Une valeur "" vide signifie que la donnée n'est pas disponible, ne jamais l'inventer.]
- [[claim_reference]] : "{{claim_reference}}"
- [[error_message]] : "{{error_message}}"

• Styles 1a / 1b : à privilégier quand vos règles sont en langage naturel (ex. « si la référence est vide, demandez-la »).
• Style 2 : à privilégier quand vous utilisez le format de référence recommandé [[error_message]] dans vos règles (ex. « si [[error_message]] est vide »), car le modèle peut associer le jeton de la règle à la valeur du bloc.

Outils et web services

Les connecteurs et web services configurés sur votre agent sont automatiquement disponibles pour le LLM. Il n'y a pas de syntaxe spéciale pour les référencer dans le prompt. Vous pouvez toutefois préciser quand et comment les utiliser :

Utilise l'outil de recherche client avant de proposer un rendez-vous.
N'annonce jamais un statut de réparation sans avoir d'abord appelé l'outil de recherche de dossier.

Voir Web services et Intégrations pour configurer les outils.

Rédiger pour la voix

Les agents vocaux ont des contraintes qu'un prompt de chat n'a pas. Intégrez-les à chaque prompt :

• Réponses courtes : 1 ou 2 phrases maximum par tour. Les réponses longues sonnent faux au téléphone et ajoutent de la latence.
• Pas de markdown : les astérisques, tirets et crochets sont lus à voix haute littéralement par la synthèse vocale. Demandez du langage parlé uniquement.
• Repli explicite : indiquez toujours au modèle quoi dire et faire lorsqu'il ne peut pas aider, plutôt que de le laisser improviser.
• Verrouillage de langue : si l'agent ne doit pas changer de langue, dites-le explicitement.
• Ne jamais inventer de données : associez chaque règle [[variable]] à un bloc de contexte et à une consigne interdisant de fabriquer les valeurs manquantes.
• Tester dans le simulateur : itérez sur le prompt avec l'appel de test dans le navigateur avant la mise en service.

Expressivité et couche vocale

La plateforme injecte automatiquement un bloc de règles de sortie parlée dans chaque prompt de nœud Agent. Vous ne le voyez jamais, mais il régit la façon dont l'agent s'exprime à voix haute. Les règles qu'il impose sont :

• La mise en avant d'un seul mot est autorisée : entourer un mot d'astérisques, ex. C'est *exactement* ça., fait porter la voix sur ce mot. Le mot entouré d'astérisques doit faire partie de la phrase prononcée.
• [laughter] est le seul tag non verbal autorisé. Tout autre tag entre crochets que vous inventez ([smile], [sigh], …) est lu à voix haute littéralement.
• Les étiquettes d'émotion et les didascalies sont interdites : des marqueurs isolés comme (chaleureusement), [excited] ou *soupire* seraient prononcés mot pour mot par la synthèse vocale, c'est pourquoi les règles injectées les bannissent.

Comme ces règles sont déjà en place, n'ajoutez pas vos propres tags d'émotion ou didascalies dans un prompt, et n'écrivez pas d'instructions qui tentent de remplacer le bloc injecté (par exemple demander à l'agent d'utiliser des tags d'humeur entre crochets). Laissez la plateforme gérer l'expressivité et gardez votre prompt centré sur ce que l'agent doit dire.

Dates

Vous n'avez pas besoin d'apprendre à l'agent à faire des calculs de calendrier. Quand un appelant mentionne une date, relative (« jeudi prochain », « dans deux semaines ») ou absolue, la plateforme la résout de manière déterministe et ajoute les valeurs résolues au message de l'utilisateur dans un bloc [DATES: ...]. Le modèle a pour consigne d'utiliser ces valeurs telles quelles et de ne jamais calculer ni inventer de dates.

Ainsi, quand vous rédigez des prompts de prise de rendez-vous ou de réservation, n'ajoutez pas vos propres calendriers, tableaux de jours de la semaine ni instructions de calcul de dates. Ils sont inutiles et peuvent entrer en conflit avec les valeurs pré-résolues. Indiquez simplement à l'agent quoi faire d'une date (la confirmer, la transmettre à un outil de réservation, etc.) et laissez le bloc [DATES: ...] fournir les valeurs réelles.

Étapes suivantes