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}}.
| Champ | Quand il est joué |
|---|---|
silence_messages | L'échelle de silence : une liste ordonnée de phrases, dont une est prononcée à chaque période de silence de l'appelant (premier silence → première phrase, deuxième silence → deuxième phrase, et ainsi de suite). Dix entrées au maximum. Une fois la liste épuisée, l'agent emprunte la sortie de silence, voir Comportement & timing. Comme chaque entrée n'est prononcée qu'une seule fois, elle peut poser une vraie question (« Souhaitez-vous que je vous passe un conseiller ? ») : la réponse de l'appelant parvient à l'agent comme n'importe quel autre tour de parole. Laissez la liste vide pour désactiver entièrement la détection du silence, au niveau de l'agent uniquement : sur l'onglet Voice & AI d'un nœud, une liste vide signifie hériter, et le commutateur de désactivation par nœud est plutôt l'option Off for this node. |
silence_message | Déprécié, conservé pour les intégrations existantes. Ce champ reflète la première entrée de silence_messages et est réécrit automatiquement à chaque enregistrement de l'échelle. Les agents créés avant l'échelle ne stockent que ce champ : le runtime reconstruit alors une échelle à partir de lui (voir max_silence_repetitions), leur comportement est donc inchangé. L'API accepte les deux, mais silence_messages l'emporte et le miroir est recalculé à partir de lui. |
transfer_message | Message par défaut prononcé par un nœud Transfer avant le déclenchement du transfert. Peut être personnalisé nœud par nœud. |
goodbye_message | Phrase d'adieu, prononcée juste avant que l'agent ne raccroche parce que l'appelant a cessé de répondre : l'échelle de silence est épuisée et sa sortie est « terminer l'appel ». Laissez vide pour raccrocher sans adieu. Ce n'est pas le message par défaut d'un nœud Hangup : un nœud Hangup prononce son propre champ message. Se règle dans l'onglet Initialisation et vaut pour tout le workflow, pas nœud par nœud. |
Le message d'accueil est configuré sur le nœud Welcome dans l'éditeur de flux (champ : message), et non comme paramètre global de l'agent. Cela permet d'avoir des messages d'accueil distincts pour les flux entrants et sortants sur le même agent.
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.
| Paramètre | Défaut | Description |
|---|---|---|
stt_provider | Premier fournisseur actif | Le service STT. Prérempli à la création avec le premier fournisseur STT actif de votre organisation. Les fournisseurs disponibles sont configurés par les administrateurs de la plateforme ; les utilisateurs clients choisissent depuis la liste déroulante configurée pour leur organisation. Les différents fournisseurs supportent des langues et des formats audio différents. |
stt_language | fr | Code de langue BCP-47 (ex : fr, en, en-US, es). Sélectionne le modèle acoustique et le vocabulaire. |
stt_model | - | Variante de modèle spécifique au fournisseur. Laissez vide pour utiliser le modèle par défaut du fournisseur pour la langue choisie. |
stt_keywords | [] | Termes spécifiques au domaine pour améliorer la précision de reconnaissance, ajoutés un par un comme étiquettes dans le champ de mots-clés de l'éditeur (tapez un terme, appuyez sur Entrée). Utile pour les noms de produits, codes ou jargon technique, ex : SIMLOCK, IMEI, 4G+, fibre. Un nœud Agent peut ajouter ses propres mots-clés au niveau du nœud, qui fusionnent avec cette liste par défaut via le mode Add to Initialization keywords (un sélecteur permet de passer à Replace Initialization keywords), voir Types de nœuds → Agent. |
Le réglage de la fin d'énoncé se fait au niveau du fournisseur (par les administrateurs), pas sur l'agent. Le contrôle principal est le seuil EOU (eou_ms), le nombre de millisecondes de silence que le moteur STT attend avant de déclarer que l'appelant a fini de parler. Selon le fournisseur, les administrateurs peuvent disposer de réglages d'endpointing supplémentaires à ajuster, permettant d'arbitrer entre réactivité et risque de couper l'appelant en milieu de phrase.
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.
| Paramètre | Défaut | Description |
|---|---|---|
llm_provider | - | Le backend LLM. Choisissez dans la liste de modèles validés par la plateforme (compatibilité testée, tool calls inclus), ou branchez votre propre endpoint compatible OpenAI avec votre propre clé API. |
llm_model | - | Identifiant de modèle transmis au fournisseur (ex : gpt-4o), sélectionné dans la liste de modèles validés ou parmi ceux proposés par votre propre endpoint. |
temperature | 0.7 | Température d'échantillonnage (0–2). Plus basse = plus déterministe, plus haute = plus créative. Pour les agents support, 0.3–0.5 réduit les hallucinations. Pour la vente, 0.7–0.9 sonne plus naturel. |
max_tokens | 500 | Tokens maximum par réponse. Gardez entre 150–300 pour la voix, les appelants ne peuvent pas interrompre une réponse de 500 tokens. |
disable_thinking | false | Pour les modèles qui supportent la chaîne de pensée / tokens de réflexion : définissez true pour ignorer l'étape de raisonnement et réduire la latence de 100–300 ms. Recommandé pour les flux transactionnels simples. |
reasoning_effort | Automatique | Modifie l'effort de raisonnement envoyé à votre modèle : none, minimal, low, medium, high, ou xhigh. Laissez sur Automatique sauf si vous connaissez précisément votre endpoint, une valeur non supportée peut provoquer une erreur ou désactiver silencieusement les appels d'outils. |
disable_thinking et reasoning_effort n'apparaissent dans l'éditeur que pour les fournisseurs LLM personnalisés (configurés par le client). Les fournisseurs de la liste de modèles validés par la plateforme sont déjà réglés par Manivox, ces contrôles restent donc masqués pour eux.
Pour la liste des modèles validés (Google, OpenAI, Groq) et comment brancher votre propre fournisseur avec votre clé API, voir Modèles compatibles & clé personnelle (BYOK).
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.
| Paramètre | Description |
|---|---|
clf_llm_provider | Fournisseur pour les tâches de classification. Si non défini, le modèle de classification par défaut de la plateforme est utilisé. |
clf_llm_model | Un modèle plus léger/rapide pour la classification que le LLM principal. |
Synthèse vocale (TTS)
Le moteur TTS convertit les réponses textuelles du LLM en audio diffusé en temps réel vers l'appelant.
| Paramètre | Défaut | Description |
|---|---|---|
tts_provider | - | Le service TTS. Les fournisseurs disponibles dépendent de la configuration de l'administrateur. |
tts_model | - | Variante de modèle proposée par le fournisseur. Les différents modèles offrent un compromis qualité / latence (ex : sonic-2 pour Cartesia). |
tts_voice | - | Identifiant de voix depuis la bibliothèque du fournisseur. Parcourez et préécoutez les voix via le sélecteur de voix dans Initialisation → Synthèse vocale → Voix, ou choisissez une voix propre à un nœud dans le groupe Speaking (TTS) de son onglet Voice & AI (nœuds Welcome/Agent). |
tts_speed | 1.0 | Multiplicateur de vitesse de restitution (0.6–1.5, la plage supportée par Cartesia). Réduisez à 0.85 pour la clarté avec les appelants âgés ; augmentez à 1.15 pour les scripts sortants denses. |
Si une voix précédemment sélectionnée disparaît de la bibliothèque, l'éditeur conserve la voix assignée (tts_voice) sélectionnée et affiche un avertissement ambre « retirée — à réassigner » au lieu d'un sélecteur vide trompeur, afin que vous puissiez choisir un remplacement sans perdre la trace de ce qui était configuré. Pour Cartesia, la bibliothèque de voix cloud fait foi pour les noms de voix : les déploiements on-prem reflètent les noms du cloud, et les voix retirées sont supprimées en douceur (soft-delete) plutôt qu'effacées.
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.
| Paramètre | Défaut | Description |
|---|---|---|
take_turn_after_silence | 7 s | Secondes de silence continu (après la fin de la parole de l'agent) avant que l'agent prononce la phrase suivante de silence_messages. Le minuteur de silence ne démarre qu'après la fin de lecture du dernier audio de l'agent. Réduisez (2–3 s) pour les flux sortants automatisés, augmentez (8–10 s) pour les appelants humains qui réfléchissent. |
max_silence_repetitions | 3 | Déprécié, conservé pour les intégrations existantes. Ce champ reflète l'échelle sous la forme nombre d'entrées + 1 et est réécrit à chaque enregistrement. Il n'a jamais signifié « nombre de fois où le message est prononcé » : le runtime prononce le silence_message à chaque silence jusqu'à max_silence_repetitions - 1, puis emprunte la sortie de silence au suivant — 3 correspond donc à deux relances puis un raccrochage, avec la raison silence_timeout. C'est exactement l'échelle reconstruite pour les agents antérieurs à silence_messages. |
silence_target_node_id | aucune | Étape à laquelle un appelant silencieux poursuit une fois l'échelle épuisée, au lieu de voir l'appel se terminer : elle se choisit dans une liste déroulante des étapes du workflow, dans l'onglet Initialisation. Un nœud Welcome ou Agent peut désigner une autre destination sur son onglet Voice & AI. Laissez vide pour terminer l'appel à la place, après avoir prononcé le goodbye_message. Les étapes ainsi désignées portent une pastille ambre en forme de cloche sur le canevas, car la destination est une propriété de la conversation et non un lien que vous dessinez. Deux garde-fous : la destination est vérifiée à l'enregistrement, une étape supprimée ne peut donc pas rester référencée ; et un même appel n'emprunte la sortie de silence que trois fois au maximum avant de se terminer, une étape qui se désigne elle-même ne bouclera donc pas indéfiniment. |
spelling_patience | false | Lorsque true, le seuil EOU est augmenté pour permettre des pauses plus longues entre les caractères épelés. Activez pour les flux où les appelants épellent des adresses e-mail ou des codes de référence lettre par lettre. Notez qu'un mécanisme automatique distinct relâche déjà l'endpointing pour un seul tour chaque fois que la question de l'agent attend une réponse dictée (une adresse e-mail, une adresse postale, un numéro de téléphone, une plaque d'immatriculation, une référence épelée, un IBAN ou le nom d'une personne), ce réglage global n'est donc nécessaire que lorsque des flux entiers sont fortement axés sur la dictée. |
recording_enabled | true | Enregistre l'audio de l'appel. Les enregistrements sont stockés côté serveur en fichiers WAV et accessibles via GET /api/calls/{id}/recording. |
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 :
| Source | Libellé dans l'éditeur | Description |
|---|---|---|
http | HTTP Request | Récupérée depuis un endpoint HTTP externe au démarrage de l'appel, avant l'exécution du nœud de départ. Supporte {{variable}} dans l'URL et les en-têtes. Si la requête échoue avec stopOnError: true, l'appel se termine avec un message d'erreur configuré avant le démarrage du flux. |
connector | Connector Action | Exécute une action de connecteur (Composio) au démarrage de l'appel et mappe les champs de son résultat sur vos variables. Voir Connecteurs pour configurer l'intégration. |
sip_header | SIP Header | Mappe sur vos variables les métadonnées injectées par l'opérateur dans les en-têtes SIP de l'appel entrant. Six en-têtes sont supportés (X-MAI-Custom1 à X-MAI-Custom5 et X-MAI-User-to-User), choisis dans une liste déroulante ; la casse des noms est ignorée. Voir En-têtes SIP. |
csv_input | CSV Input | Peuplée depuis les colonnes CSV mappées du contact quand l'appel est passé par une campagne sortante, ainsi que lors d'un rappel reconnu de l'un de ses contacts. Déclarer la variable ici est optionnel : chaque colonne mappée atteint de toute façon l'agent sous forme de variable chaîne. Une déclaration ajoute un type, une valeur par défaut et une validation de champ requis, et le nom doit correspondre à celui choisi dans le mapping de colonnes de la campagne. |
demo_prospect (intégrée) | Demo prospect | Visible uniquement par les super-administrateurs (et en mode usurpation d'une organisation). Injecte des données de prospect de démonstration fournies par la plateforme et les mappe sur vos variables. Données de prospect injectées par la plateforme ; aucune URL ni aucun identifiant requis. |
Les actions de démarrage s'exécutent avant le démarrage du flux. Les actions HTTP et connecteur s'exécutent séquentiellement ; si l'une échoue avec stopOnError: true, l'appel se termine immédiatement, utile pour se prémunir contre des données client obligatoires manquantes.
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.
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.
| Paramètre | Défaut | Description |
|---|---|---|
| Wait for first word | activé | Attendre que la personne appelée parle (« allô ») avant que l'agent ne commence à parler. Désactivé, l'agent parle dès que l'appel est connecté. |
| Wait Timeout | 3 s | Combien de temps attendre ce premier mot avant d'appliquer l'action ci-dessous. Les agents créés avant septembre 2026 conservent la valeur qu'ils avaient enregistrée, typiquement 4 s. |
| If nobody speaks in time | Start speaking anyway | Start speaking anyway joue quand même le message d'accueil, de sorte qu'une personne silencieuse mais présente entend tout de même l'agent ; Hangup termine l'appel silencieusement. Les agents créés avant septembre 2026 conservent leur choix enregistré, typiquement Hangup. |
| Speak Delay | 1 s | Pause avant le premier énoncé de l'agent une fois l'appel connecté ; absorbe les bruits de connexion de l'opérateur. S'applique quand Wait for first word est désactivé. |
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}}.
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.
Le mode brouillon n'est pas nécessaire car la facturation est par canal : les appels de test dans le navigateur sont toujours économiques (pas de téléphonie), et un agent sans version live ne peut tout simplement pas être appelé. Voir Versions pour le modèle complet.