La conception d’IA conversationnelle consiste à décider ce que dit un agent IA, quand il le dit et ce qui se passe quand la conversation déraille. La plupart des guides sur le sujet sont écrits pour les chatbots. Celui-ci s’adresse aux agents vocaux, où l’appelant ne peut pas revenir en arrière, où chaque pause s’entend et où la reconnaissance vocale entendra parfois « quinze » quand quelqu’un a dit « cinquante ».
Nous développons les modèles vocaux et la plateforme sur lesquels tournent les agents vocaux ; ce guide indique donc le réglage Cartesia qui traite chaque problème. Les idées valent pour n’importe quelle stack. En résumé : concevez pour la tâche, écrivez pour l’oreille et consacrez l’essentiel de vos efforts aux moments où les choses tournent mal. Personne n’a jamais aimé entendre « Désolé, je n’ai pas compris » trois fois de suite.
La voix et le chat sont deux problèmes de conception différents
Une bonne partie des conseils de conception conversationnelle valent pour le chat comme pour la voix. Beaucoup d’autres, non.
| Chat | Voix | |
|---|---|---|
| Lecture | L’utilisateur peut relire, survoler et remonter | L’appelant entend chaque mot une fois, dans l’ordre |
| Longueur | Un paragraphe avec une liste convient | Deux phrases, c’est déjà un tour long |
| Choix | Boutons et liens | L’appelant doit retenir les options |
| Silence | Personne ne remarque une attente de deux secondes | Une pause d’une seconde donne l’impression que la ligne a coupé |
| Erreurs de saisie | L’utilisateur voit ses fautes de frappe | Les erreurs de reconnaissance restent invisibles jusqu’à ce que l’agent les répète |
| Interruptions | Rares | Constantes, et l’agent doit se taire |
La recherche en ergonomie le dit depuis un moment. Quand Nielsen Norman Group a testé des assistants vocaux en 2018, le cabinet a constaté qu’ils ne fonctionnaient bien que pour des questions simples à réponse courte. Les LLM ont rendu les agents bien meilleurs pour comprendre la question. Ils n’ont pas changé ce qu’une personne peut retenir pendant qu’elle écoute.
Partez de la tâche, pas du personnage
Avant d’écrire une salutation ou de choisir une voix, notez les deux ou trois tâches que l’agent doit accomplir et ce que « terminé » signifie pour chacune. « Déplacer un rendez-vous » est terminé quand le nouveau créneau est dans l’agenda et que l’appelant l’a entendu relu. « Répondre aux questions de facturation » n’est pas une tâche. « Expliquer un montant de la dernière facture et proposer un remboursement s’il s’agit d’un doublon » en est une.
Pour chaque tâche, listez les informations dont l’agent a besoin, leur provenance (l’appelant, votre CRM, un outil) et ce que l’agent n’a pas le droit de faire. Cette liste devient les instructions de l’agent et les descriptions de ses outils. Le personnage peut venir ensuite. Un agent sympathique qui ne trouve pas la commande reste le mauvais agent.
Écrivez pour l’oreille
Les réponses parlées demandent d’autres habitudes que les réponses écrites :
- Une question par tour. « Quelle est votre date de naissance et le code postal du compte ? » n’obtient qu’une demi-réponse. Demandez l’un, puis l’autre.
- La réponse d’abord. « Votre commande est partie mardi et arrive vendredi » vaut mieux qu’une phrase qui commence par le suivi et n’arrive à la date qu’à la fin.
- Peu d’options. En règle générale, trois au maximum : à la quatrième, l’appelant a oublié la première. S’il y en a davantage, posez une question ouverte et laissez le modèle de langage interpréter la réponse.
- Pas de mise en forme. Le markdown, les puces et les emojis sont lus à voix haute ou disparaissent. Dites au modèle qu’il écrit pour la voix.
Les nombres, les codes et les noms demandent le plus de soin. Sonic lit correctement de lui-même les formes écrites courantes : des prix comme $19.99, des dates comme 04/20/2025, des numéros comme (415) 555-1212. Pour un code de confirmation à lire caractère par caractère, entourez-le d’une balise <spell>. Si le modèle prononce mal un nom de produit ou de lieu, ajoutez-le une fois pour toutes à un dictionnaire de prononciation au lieu de le corriger dans chaque prompt. Nos conseils de prompting proposent un prompt système de départ pour la voix rédigée par un LLM qui couvre ces règles ; c’est un bon premier jet pour le vôtre.
Testez les chaînes que vos appelants entendent vraiment. Un agent qui lit très bien une salutation peut quand même massacrer « votre solde est de $1,204.50, à régler le 11/03 ».
Concevez le rythme
Dans une conversation, les gens se passent la parole en environ 200 millisecondes (Stivers et al., 2009). Un agent qui attend une seconde entière pour être sûr que l’appelant a fini paraît lent. Un agent qui saute sur chaque pause coupe la parole à ceux qui réfléchissent encore.
Cette décision revient à la détection des tours de parole, pas à une minuterie de silence fixe. Ink, notre modèle de reconnaissance vocale, détecte les tours à partir du sens de ce qui a été dit, et pas seulement à partir de l’audio. Il peut émettre un signal anticipé quand l’appelant a probablement fini, pour que votre agent commence à préparer sa réponse, puis le retirer si l’appelant continue. Notre guide sur la détection d’activité vocale et des tours de parole va plus loin.
Deux autres décisions de rythme relèvent de la conception, pas de l’ingénierie :
- Dire quelque chose avant une opération lente. Si un appel d’outil prend trois secondes, trois secondes de silence ressemblent à une panne. Une courte phrase, « Je cherche cette commande », indique à l’appelant que l’agent l’a entendu. Dans Managed Agents, les outils ont un réglage
pre_tool_speechpour cela. - Décider de ce qui peut être interrompu. Les appelants interrompent sans cesse, et en général l’agent doit se taire et écouter. Une mention légale ou la relecture d’un montant de paiement font exception : terminez-la, puis prenez la question.
Confirmez ce qui compte, et seulement cela
Tout confirmer est fastidieux. Ne rien confirmer, c’est ainsi qu’un agent réserve un rendez-vous chez le dentiste le mauvais mardi. Classez chaque information selon le coût d’une erreur :
- Coût faible : le nom de l’appelant dans la salutation, l’objet de l’appel. Confirmez implicitement en l’utilisant : « Bien sûr, je vous aide pour votre commande. »
- Coût élevé : dates, montants, adresses, numéros de compte, tout ce qui déclenche une action irréversible. Relisez-le et attendez un oui : « C’est jeudi 8 octobre à 14 h 30. Je le réserve ? »
Les erreurs de reconnaissance se concentrent sur les mêmes mots : noms de produits, noms de rues, codes de compte. Si vous les connaissez à l’avance, donnez-les au système de reconnaissance sous forme de keyterms pour qu’il les entende correctement dès le départ. Corriger une transcription fausse après coup est plus difficile que de l’éviter.
Donnez une suite à chaque échec
L’essentiel du travail de conception se trouve dans les cas qui tournent mal. Prévoyez ceux-ci avant le lancement :
| Situation | Ce que l’agent doit faire |
|---|---|
| N’a pas compris | Reformuler la question, de façon plus précise. Ne pas la répéter mot pour mot. |
| N’a pas compris deux fois | Proposer une personne ou un autre canal. Au troisième « pardon ? », les appelants commencent à marteler le zéro. |
| Silence | Relancer une fois, puis proposer de rappeler ou conclure poliment. |
| Hors périmètre | Dire ce pour quoi l’agent peut aider et proposer un transfert. |
| Un outil a échoué | Dire que le système est indisponible et donner l’étape suivante. Ne jamais inventer de réponse. |
| L’appelant demande à l’agent d’ignorer ses instructions | Refuser et poursuivre la tâche. Testez-le avant le lancement. |
Inscrivez explicitement la règle des deux tentatives dans les instructions de l’agent. Les LLM ont une patience infinie, et une patience infinie au téléphone donne l’impression d’être piégé.
Rendez le transfert facile à obtenir
Tout agent doit pouvoir passer la main à une personne, et l’appelant doit pouvoir la demander à tout moment. Dans Managed Agents, l’outil système transfer_to_number envoie l’appel vers un numéro de téléphone ou une adresse SIP, avec une condition en langage naturel pour chaque destination, par exemple « The caller has a billing or payment question ».
Sachez quel type de transfert vous utilisez. Lors d’un transfert à froid, l’appel part directement vers la destination et l’agent se retire. Lors d’un transfert à chaud, quelqu’un met la personne qui décroche au courant avant que l’appelant ne la rejoigne. Les transferts que Cartesia documente aujourd’hui sont à froid ; la documentation SIP trunking les décrit comme des transferts SIP REFER. Concevez en conséquence : faites dire à l’agent à qui l’appelant va être mis en relation et pourquoi et, si la personne qui décroche a besoin de contexte, écrivez un court résumé dans votre CRM avec un outil webhook avant le transfert, pour que personne n’ait à demander « et c’est à quel sujet ? ».
Testez avec de vrais appels
Un script lu à voix haute par l’équipe qui l’a écrit passe toujours. Les vrais appelants ne liront pas le script. Avant d’envoyer du trafic :
- Rassemblez 20 à 50 enregistrements ou transcriptions réels de la file que vous automatisez et faites-les passer par l’agent.
- Incluez les cas difficiles : bruit de fond, accents, personnes qui changent d’avis en pleine phrase, personnes qui demandent un humain dans les cinq premières secondes.
- Notez les résultats, pas les impressions. Managed Agents peut évaluer les appels terminés avec des métriques personnalisées, qui sont des juges LLM que vous définissez (« Le problème de l’appelant a-t-il été résolu ? »). Il enregistre aussi le temps jusqu’au premier octet audio lors du premier tour de l’agent, pour chaque appel.
- Écoutez vous-même un échantillon chaque semaine après le lancement. Les transcriptions masquent le ton, les longues pauses et les moments où l’agent parle par-dessus l’appelant.
Le guide pour piloter un centre d’appels avec l’IA transforme tout cela en grille d’évaluation pour une file. Pour créer un agent que vous pourrez tester de cette façon, commencez avec Managed Agents et un compte gratuit dans le playground Cartesia.