Configuration de l'agent

Les onglets Initialisation et Paramètres de l'éditeur d'agent, ainsi que l'onglet Voice & AI de chaque nœud dans Workflow d'agent, exposent tous les paramètres configurables. De la sélection du fournisseur IA à la gestion du silence et du contexte, chaque champ au niveau de l'agent correspond directement à une propriété stockée sur l'agent ; les surcharges par nœud (y compris la gestion du silence, désormais personnalisable par nœud) vivent sur le nœud de flux à la place.

Prompt système

Le prompt système est le jeu d'instructions principal envoyé au LLM au début de chaque appel. Il définit la personnalité, le rôle, le périmètre et les contraintes strictes de l'agent.

Vous êtes Sophie, une chargée de support client pour TechCorp.
Votre objectif est d'aider les appelants avec leurs questions de facturation et problèmes de compte.

Règles :
- Gardez les réponses en moins de 2 phrases. C'est un appel téléphonique, pas un chat.
- Ne révélez jamais les tarifs internes ou les informations sur les concurrents.
- Si vous ne pouvez pas résoudre le problème, dites : "Je vous transfère vers un spécialiste."
- Confirmez toujours le nom de l'appelant avant d'accéder à son compte.
- Répondez dans la même langue que l'appelant.

Le prompt système au niveau de l'agent s'applique au nœud Welcome lorsqu'il est en mode conversationnel. Chaque nœud Agent dans le flux possède son propre prompt système indépendant, celui au niveau agent n'est pas automatiquement hérité par les nœuds du flux.

Injection de variables : toute variable disponible au démarrage de l'appel peut être référencée avec la syntaxe {{nom_variable}}. Les variables définies via les en-têtes SIP ou les appels API d'initialisation sont disponibles dès le premier nœud.

Vous appelez {{customer_name}} au sujet de son abonnement {{product}}.
Son identifiant de compte est {{account_id}}.

Rédiger des prompts efficaces

• Personnalité en premier, nom, rôle, entreprise, ton (amical, professionnel, concis)
• Limites explicites, quels sujets sont hors périmètre, quoi dire quand on est bloqué
• Réponses courtes, les agents vocaux ne doivent jamais produire de listes ou de puces ; précisez-le
• Comportement de repli, quoi faire quand l'appelant pose une question hors périmètre
• Langue, si l'agent doit rester dans une seule langue, dites-le explicitement
• Pas de mise en forme, le TTS lit les astérisques et symboles littéralement ; utilisez uniquement de la prose simple

Messages statiques

Ces messages sont prononcés textuellement via TTS (non générés par le LLM). Ils supportent l'interpolation {{variable}}.

Reconnaissance vocale (STT)

Le moteur STT convertit l'audio de l'appelant en texte en temps réel. Choisissez le fournisseur et le modèle qui correspondent le mieux à votre langue et à vos exigences de latence.

Langues (agents multilingues)

Un agent parle une ou plusieurs langues. La liste se règle dans Initialization → Agent → Languages (dans la carte Speech-to-Text quand votre organisation dispose de plusieurs fournisseurs de reconnaissance vocale). La première langue est la langue principale : l'accueil et le résumé de fin d'appel l'utilisent toujours, et les textes que vous rédigez sont dans la langue principale, avec des traductions facultatives pour les autres langues. Ajoutez d'autres langues quand le même agent doit répondre à des appelants de plusieurs langues : pendant l'appel, l'agent suit la langue parlée par l'appelant et change automatiquement de langue de réponse et de voix.

Configurer les langues

• Ajoutez une langue avec la liste déroulante + Add a language…. Une nouvelle langue s'ajoute en fin de liste ; elle ne devient jamais langue principale d'elle-même.
• Réordonnez avec les flèches Move up / Move down, retirez une langue avec la croix. Placer une langue en tête en fait la langue principale, avec le même effet que Set as main. Un agent garde toujours au moins une langue.
• Set as main fait d'une langue la langue principale. Les textes d'au revoir, de silence et de transfert ainsi que les messages des étapes du flux sont échangés avec leur traduction dans la nouvelle langue principale. Les textes encore sans traduction sont conservés et signalés comme restant à traduire. Enregistrez pour garder le changement.
• Chaque langue porte un badge. Full support : prise en charge native des dates, des nombres épelés et des détails de ce type (français, anglais, espagnol, portugais, allemand, italien, néerlandais, polonais). Supported : la langue fonctionne, mais la compréhension des dates et des nombres épelés peut être moins précise.
• Une langue n'est proposée que si votre fournisseur TTS dispose d'une voix pour elle.

Voix et messages par langue

La carte Voice affiche une ligne par langue, la principale marquée Main. Chaque langue a sa propre voix et sa propre vitesse (Speed, de 0,6 à 1,5). Une langue laissée sans voix utilise une voix par défaut de cette langue ; une langue laissée sans vitesse reprend la vitesse de la langue principale.

Dans la carte Conversation Behavior, un bloc repliable Other languages apparaît dès que l'agent a plus d'une langue : l'un sous les relances de silence, l'autre sous le message d'au revoir (affiché quand l'appel se termine après la dernière relance). Ils contiennent les traductions de ces textes. Laissez une traduction vide pour dire le texte de la langue principale avec la voix principale : l'agent ne lit jamais un texte avec la voix d'une autre langue.

Chaque en-tête Other languages fermé indique ce qui est traduit, par exemple English 1/2, en orange quand il manque des traductions dans une langue, et un bloc partiellement traduit s'ouvre de lui-même. Les mêmes en-têtes figurent dans les fenêtres des nœuds. Sur le canevas, l'audit du flux signale une étape qui a son propre texte (relances de silence, message, message de transition ou de repli) sans traduction dans une des langues de l'agent : les appelants de cette langue l'entendront dans la langue principale. C'est permis ; l'avertissement le rend seulement visible. Dans la fenêtre d'un nœud, OK garde vos modifications dans l'éditeur : cliquez sur Save pour les conserver.

Fonctionnement de la bascule pendant l'appel

• L'accueil est toujours prononcé dans la langue principale, avec la voix principale.
• L'agent bascule dès que l'appelant dit une phrase de 4 mots ou plus dans une autre langue de la liste, ou après deux réponses courtes d'affilée dans cette même langue. Sinon l'appel reste dans sa langue courante.
• Des chiffres seuls, du bruit et les réponses données pendant que l'agent recueille un nom, une adresse e-mail ou un numéro de téléphone ne déclenchent jamais de bascule.
• Après une bascule, la réponse suivante utilise la nouvelle langue avec sa voix, sa vitesse et son dictionnaire de prononciation, et les messages automatiques utilisent leur traduction. Une réponse déjà commencée n'est jamais basculée en cours de route.
• L'agent ne bascule qu'entre les langues de la liste. Un appelant qui parle une autre langue reçoit des réponses dans la langue courante.

Langue par étape

Sur un agent multilingue, le champ Language d'un nœud Agent (groupe Listening (STT) de son onglet Voice & AI) ou d'un nœud Chatbot (son onglet Listening (STT)) propose Follow the caller (détection parmi les langues de l'agent, par défaut) ou Pin to une langue. Une étape épinglée tourne toujours dans cette langue et ne bascule jamais ; quand l'appel la quitte, la détection reprend depuis la langue courante. Les mêmes dialogues portent une voix et une vitesse par langue (sur un nœud Chatbot, dans son onglet Speaking (TTS)). Les textes des nœuds ont leurs propres traductions Other languages : sur un nœud Agent, la phrase d'ouverture dite quand l'appel arrive d'une autre étape, ses relances de silence, ses messages de transition des routes de sortie et ses messages d'attente d'outil ; sur un nœud Chatbot, ses messages de transition des routes de sortie ; sur les nœuds Transfer et Hangup, leur message parlé. Voir Types de nœuds → Agent.

Grand modèle de langage (LLM)

Le LLM génère les réponses de l'agent tour par tour. Tous les fournisseurs configurés par votre administrateur apparaissent dans la liste déroulante.

Modèle d'aiguillage des sorties

Lorsque la conversation doit passer à une autre étape, un modèle distinct et plus rapide peut prendre cette décision à la place du LLM principal, c'est ce qui alimente les routes de sortie conversationnelles sur les nœuds Welcome et Agent. Il s'exécute en parallèle du LLM principal, donc utiliser ici un modèle petit et rapide économise ~250 ms par tour. Laissez-le vide (l'option Platform default) et la classification s'exécute sur un modèle rapide désigné par la plateforme, réglé spécifiquement pour cette tâche. Les routes de sortie basées sur une règle n'utilisent jamais ce modèle : elles sont vérifiées de manière déterministe par le moteur de flux, sans aucun appel LLM, voir Types de nœuds → Routes de sortie basées sur des règles.

Synthèse vocale (TTS)

Le moteur TTS convertit les réponses textuelles du LLM en audio diffusé en temps réel vers l'appelant.

Règles d'expressivité (couche vocale)

La plateforme ajoute automatiquement un bloc de règles de sortie vocale à chaque prompt de nœud Agent, vous n'avez donc pas besoin d'écrire (ni de contrer) ces règles vous-même :

• L'emphase sur un seul mot avec des *astérisques* est autorisée et encouragée, ex : « La table est *disponible* demain ! ». Le mot entre astérisques doit faire partie de la phrase prononcée.
• [laughter] est la seule balise non verbale supportée. Les autres balises entre crochets ([smile], [sigh]…) sont lues à voix haute, ne les utilisez donc pas.
• Les étiquettes d'émotion isolées et les didascalies (ex : (joyeusement), [excité]) sont interdites, car le TTS les prononcerait littéralement.

Rédigez vos prompts en prose simple et laissez cette couche gérer la diction. Voir Rédaction des prompts pour des conseils de rédaction approfondis.

Comportement & timing

Ces paramètres contrôlent quand l'agent parle après un silence et comment l'appel se termine quand l'appelant arrête de répondre. Ce sont les valeurs par défaut au niveau de l'agent, définies dans l'onglet Initialisation. Un agent tout neuf démarre avec une échelle de deux relances dans sa propre langue, une courte sollicitation puis une question explicite (français : Allo ? puis Vous êtes toujours là ? ; anglais : Hello? puis Are you still there?), plutôt qu'une seule phrase répétée. Tout nœud Welcome ou Agent peut les remplacer (ou désactiver les relances de silence pour ce nœud) dans la section Conversation Behavior de son onglet Voice & AI, voir Types de nœuds → Agent.

Variables d'initialisation

Les variables d'initialisation (input_variables) définissent quelles variables sont peuplées avant l'exécution de tout nœud. Elles sont déclarées dans l'onglet Initialisation de l'agent, où chaque variable choisit une source d'action de démarrage :

Signer une action de démarrage avec une connexion de service web

Quand votre API est protégée par un serveur de jetons (OAuth 2.0 client credentials, par exemple Keycloak ou une passerelle d'API), ne collez pas de jeton dans un en-tête : il expire, et un en-tête est stocké en clair. Utilisez plutôt une connexion de service web. La plateforme obtient alors le jeton, le renouvelle avant son expiration et, si votre API répond encore 401, en obtient un nouveau et réessaie une fois.

• Type Service web : exécute une des actions de la connexion. Rien d'autre à configurer.
• Type Requête HTTP avec Authentification : Connexion de service web : garde votre URL, votre méthode et votre corps, et ajoute les identifiants de la connexion. L'URL doit commencer par l'adresse de la connexion : le jeton n'est jamais envoyé ailleurs, et l'enregistrement est refusé sinon. Les en-têtes supplémentaires que vous ajoutez sont conservés. Une connexion qui envoie ses identifiants dans le corps de la requête ne peut pas signer une requête HTTP ; utilisez pour elle le type Service web.

Les identifiants et les jetons de la connexion n'apparaissent jamais dans les journaux d'appel ni sur la page de détail de l'appel.

Le même choix d'Authentification, avec les mêmes règles, existe sur une étape Appel API en mode API brute et sur un webhook des Actions de fin d'appel.

Listes d'éléments (ne garder que certains champs de chaque élément)

Beaucoup d'API répondent par une liste de longueur variable : une réparation pour un appelant, dix pour un autre, chaque élément contenant bien plus que ce dont l'agent a besoin (historique, adresses...). Ne créez pas une variable par position (premiere_reparation_reference...), qui casse dès qu'un appelant a plus d'éléments que prévu, et ne mappez pas la liste entière ($.data), qui envoie tous les champs à l'agent à chaque tour. Cliquez plutôt sur List of items sur la ligne du mapping, et ne gardez que les quelques champs utiles à l'agent. Le même bouton existe sur les actions de web service (Web services) et sur les étapes API Call en mode Raw API.

Mise en place dans une action de démarrage :

1. Dans l'onglet Initialization, ouvrez votre action de démarrage HTTP (ou ajoutez-en une) et renseignez son URL.
2. Sous Response Mapping, cliquez sur Add mapping. Donnez un nom à la variable, par exemple repairs, et le chemin de la liste, par exemple $.data[*].
3. Cliquez sur List of items sur la ligne. (Quand le chemin se termine par [*], une suggestion sous la ligne le propose aussi.)
4. Pour chaque champ à garder, remplissez Field inside each item : le champ tel qu'il apparaît dans un élément, sans $.. Utilisez un point pour un champ rangé dans un autre : bike.model. Le Name the agent sees se remplit tout seul (model) ; modifiez-le si vous le souhaitez.
5. Cliquez sur Add a field pour le champ suivant. Ne gardez que ce dont l'agent a besoin pour parler à l'appelant.
6. Vérifiez l'aperçu, What the agent reads in {{repairs}}, et notez la variable de comptage, {{repairs_count}}.

L'agent lit alors une ligne numérotée par élément, quel que soit leur nombre :

1. reference: AT-2041; model: Urban 500; status: Waiting for parts
2. reference: AT-2057; model: Trail X; status: Ready for pickup

Utiliser la liste :

• Dans un prompt : écrivez {{repairs}} là où l'agent doit voir la liste, par exemple « Réparations en cours de l'appelant : {{repairs}}. Aide-le pour celle dont il parle. »
• Pour orienter l'appel : utilisez {{repairs_count}} dans des règles de sortie ou une étape Branch : égal à 0 (rien trouvé, ou la requête a échoué), égal à 1 (aller directement à l'élément), supérieur à 1 (demander lequel).
• Pour retenir l'élément choisi par l'appelant : déclarez une variable collectée (par exemple chosen_reference) et réglez D'où vient la valeur sur Ce que dit l'appelant, ou choisi dans les données récupérées. Quand l'appelant dit « l'Urban 500 », la variable reçoit AT-2041 depuis la liste. Voir Variables d'initialisation.

Options des champs et limites :

Ce n'est pas une source de démarrage : les variables collectées. Une variable dont la source est llm_collect n'est pas peuplée au démarrage de l'appel. C'est un concept distinct, une variable que vous déclarez pour que le LLM la recueille pendant l'appel : l'extracteur de variables parallèle, qui s'exécute aux côtés des tours des nœuds Agent, la renseigne au fur et à mesure que la conversation fait apparaître la valeur. Jusque-là, elle contient une valeur typée vide. Utilisez les sources d'initialisation ci-dessus pour les données que vous possédez avant la connexion de l'appel, et llm_collect pour les données que l'appelant fournit en parlant.

Variables collectées : d'où vient la valeur. Chaque variable collectée dispose d'un réglage D'où vient la valeur. Par défaut, Ce que dit l'appelant n'enregistre que ce que l'appelant a réellement dit. Choisissez Ce que dit l'appelant, ou choisi dans les données récupérées lorsque la valeur se trouve dans des données déjà récupérées pendant l'appel (appel API de démarrage, nœud API ou outil de service web). Exemple typique : l'agent énumère les trois dossiers de l'appelant par appareil et par date, l'appelant répond « celui du four », et la variable doit contenir la référence de ce dossier, que seules les données récupérées contiennent. Avec cette option, l'extracteur peut enregistrer cette référence lorsque l'appelant choisit ou confirme un élément, mais elle doit correspondre exactement à une valeur présente dans les données récupérées : une valeur inventée n'est jamais acceptée. N'écrivez pas dans le prompt des consignes du type « remplir la variable » : l'agent ne peut pas renseigner une variable lui-même, la variable est capturée automatiquement.

Tables de correspondance

Une action de démarrage Lookup table cherche une valeur dans une des tables de correspondance du compte avant que l'agent ne parle : le numéro composé par l'appelant donne la marque à annoncer, un code postal donne une agence. Elle remplit une variable par colonne de la ligne trouvée, plus le nombre de lignes trouvées (0 = introuvable). Guide pas à pas : Tables de correspondance.

Contrôles de format

Pour vérifier un code que l'appelant dicte (une plaque, un numéro de bon, un SIRET...), définissez un contrôle de format dans le compte et attachez-le à l'étape qui recueille le code : à chaque tour, l'agent reçoit la valeur propre ou la raison de l'erreur. Guide pas à pas : Contrôles de format.

Bases de connaissances globales

Le champ global_knowledge_bases configure quelles bases de connaissances sont recherchées pour le contexte RAG sur tous les nœuds Agent qui n'ont pas leur propre configuration KB. La configuration KB au niveau du nœud a la priorité sur le paramètre au niveau de l'agent.

Configurez les bases de connaissances globales dans l'onglet Paramètres, section Base de connaissances. Voir Configuration RAG pour les détails sur les paramètres de récupération.

Comportement sortant

Ces paramètres contrôlent le comportement de l'agent au début d'un appel sortant : la fenêtre entre le décrochage de la personne appelée et le premier énoncé de l'agent. Ils se trouvent dans l'onglet Paramètres, section Outbound Behavior, et la section n'apparaît qu'une fois que l'agent a au moins une campagne ; sur un agent uniquement entrant, elle ne serait que du bruit. Les valeurs enregistrées sont conservées tant qu'elle est masquée.

Quand la Détection de répondeur d'une campagne est activée (par défaut, quand votre ligne la propose), les répondeurs sont détectés par l'opérateur avant la connexion de l'appel : un appel de campagne décroché est donc une personne. Utilisez {{call_direction}} (outbound / inbound) dans le flux pour saluer différemment selon la direction, et voir Appels sortants pour la vue d'ensemble.

Actions de fin d'appel

Le champ end_flow_actions, dans l'onglet Initialisation à côté des actions de démarrage, configure les appels webhook déclenchés après la fin d'un appel (après chaque appel, ou seulement après les sorties que vous choisissez, voir ci-dessous). Chaque action spécifie une URL, une méthode et un payload. Tous les placeholders {{variable}} sont résolus en utilisant l'état final des variables de l'appel avant l'envoi du webhook.

Cas d'usage courants : mises à jour CRM post-appel, journalisation de qualification de leads, archivage de transcription vers un système externe.

Limiter une action à certaines sorties. Par défaut, une action se déclenche à chaque fin d'appel. Réglez Se déclenche sur → Uniquement certaines sorties pour la restreindre aux appels terminés sur des nœuds raccrocher ou transfert précis — par exemple, envoyer le SMS de confirmation uniquement quand l'appel s'est terminé sur le raccrochage « rappel confirmé », ou appeler un service de liste rouge uniquement sur la sortie « appelant hostile ». Un appel où l'appelant raccroche en cours de flux n'atteint jamais de nœud de sortie : les actions limitées ne se déclenchent pas, les actions non limitées si. La sortie est aussi disponible dans les payloads via {{terminal_node_id}}.

Signer un webhook avec une connexion. Au lieu de saisir un en-tête Authorization, réglez l'Authentification de l'action sur Connexion de service web et choisissez une des connexions de service web du compte (clé API, Basic, Bearer ou OAuth 2.0). La plateforme ajoute les identifiants à l'envoi du webhook et renouvelle pour vous un jeton OAuth. L'URL doit commencer par l'URL de base de la connexion, sinon l'agent ne peut pas être enregistré, et les identifiants n'apparaissent jamais dans les journaux d'appel. Voir Signer une action de démarrage pour l'ensemble des règles.

Save vs Make live

L'éditeur sépare l'enregistrement de la mise en live, afin que vous puissiez affiner un agent, même un agent live, sans perturber les appelants. Deux actions dans l'en-tête :

• Save, écrit l'état de l'éditeur comme nouvelle version nommée. Ne change jamais ce qu'entendent les appelants. Actif lorsqu'il y a des modifications non enregistrées.
• Make live, promeut la version enregistrée affichée dans l'éditeur vers la version live qu'entendent les appelants. Actif uniquement lorsque l'éditeur est propre et que la version affichée n'est pas déjà live.

Le flux sûr sur un agent en production : éditer → Save (l'ancienne version reste live, les appelants ne sont pas affectés) → tester la nouvelle version dans le simulateur navigateur → Make live quand vous êtes confiant. Il n'y a pas de bascule « mode brouillon » ; ce modèle à deux verbes l'a remplacée.