Comment développer un agent vocal pour automatiser les appels sortants avec Twilio et Deepgram

Comment développer un agent vocal pour automatiser les appels sortants avec Twilio et Deepgram

Déployer un agent vocal capable de passer des appels sortants avec Twilio suppose de relever toute une série de défis qui ne se présentent pas avec les appels entrants. Il ne suffit pas de lancer un appel : encore faut-il déterminer si le destinataire a effectivement décroché ou si son répondeur s’est déclenché, fournir à l’agent toutes les informations nécessaires pour personnaliser la conversation, puis veiller à ce que les résultats de l’échange soient correctement enregistrés dans le système de référence une fois l’appel terminé.

L’équipe de Deepgram a développé et mis à disposition une implémentation de référence destinée aux agents vocaux de téléphonie sortante utilisant Twilio, qui couvre l’ensemble de ces besoins. Le processus repose sur le déclenchement d’un appel depuis votre système au moyen d’une API REST, suivi de l’exécution d’un scénario conversationnel prédéfini par un agent d’intelligence artificielle. Une fois la communication terminée, les résultats de l’appel sont transmis à votre système CRM dans un format structuré. Lorsqu’un répondeur est détecté, un message vocal personnalisé est diffusé à la place.

Examinons plus en détail l’architecture de cette solution et les fonctionnalités avancées qu’elle propose pour répondre à des besoins souvent négligés dans les implémentations plus simples.

Fonctionnement de l’architecture d’un agent vocal pour les appels sortants

Comme expliqué dans notre article complémentaire consacré aux agents vocaux dédiés aux appels entrants, cette architecture repose sur le même mécanisme central de transmission des flux audio. Elle s’appuie sur une application Python développée à l’aide du framework Starlette et intégrant une classe VoiceAgentSession, chargée de maintenir deux connexions WebSocket distinctes, l’une établie avec Twilio et l’autre avec l’API Voice Agent de Deepgram, afin d’assurer l’acheminement bidirectionnel des données audio entre les deux plateformes. L’API Voice Agent de Deepgram combine la reconnaissance vocale, le raisonnement des grands modèles de langage (LLM) et la synthèse vocale au sein d’une même chaîne de traitement en temps réel. Concrètement, vous lui transmettez un flux audio et récupérez directement une réponse vocale, sans avoir à assembler ni à coordonner plusieurs services distincts.

Flux, le modèle de reconnaissance vocale de Deepgram conçu spécifiquement pour les agents vocaux, gère nativement les tours de parole, afin que l’agent puisse déterminer à quel moment son interlocuteur a terminé de s’exprimer. Quant à la gestion des interruptions (barge-in), elle repose sur l’événement clear de Twilio, qui permet à l’appelant d’interrompre l’agent à tout moment.

La principale différence avec une architecture dédiée aux appels entrants réside dans l’ensemble des opérations qui précèdent l’activation de la passerelle de transmission audio.

Le scénario présenté ici concerne le suivi commercial de prospects ayant sollicité un devis d’assurance habitation. Lorsqu’un client potentiel soumet une demande de devis depuis votre site web, votre système peut déclencher ultérieurement un appel sortant destiné à vérifier les informations communiquées, à recueillir des données complémentaires, telles que l’ancienneté de la toiture ou l’existence de sinistres récents, puis à organiser un entretien avec un professionnel de l’assurance dûment habilité. Si l’appel est dirigé vers une messagerie vocale, l’agent diffuse à la place un message personnalisé.

Le déclenchement de cet appel repose sur un système externe, tel qu’une plateforme CRM, un script d’interface en ligne de commande (CLI) ou un webhook, qui adresse une requête au point de terminaison POST /make-call du serveur. Cette requête contient le numéro de téléphone du destinataire ainsi que les données contextuelles associées au prospect.

À partir de cette étape, le serveur assure l’orchestration du processus. Il invoque l’API REST de Twilio en transmettant des instructions TwiML intégrées directement à la requête <Connect><Stream>, qui établissent une liaison avec son propre point de terminaison WebSocket. Twilio procède alors à la numérotation du destinataire. Une fois la communication établie, la classe VoiceAgentSession prend le relais pour assurer la transmission bidirectionnelle des flux audio. C’est un modèle d’intégration que les clients de Twilio mettent régulièrement en œuvre : des appels vocaux sortants déclenchés depuis un CRM, avec une remontée des données structurées dans le système de référence à l’issue des échanges.

Détection intelligente des répondeurs, intégration CRM et gestion des particularités des appels sortants

Une détection des répondeurs (AMD) assurée par l’API asynchrone de Twilio Lorsqu’un appel est établi, le serveur ne peut pas encore déterminer si une personne a décroché ou si l’appel a abouti sur un répondeur. Il conserve donc temporairement le flux audio entrant en mémoire tampon, le temps que Twilio effectue la détection asynchrone des répondeurs, une opération qui prend généralement entre 2 et 4 secondes. Une fois le résultat disponible, Twilio le transmet au point de terminaison /amd-result au moyen d’une requête POST. La session adapte alors son fonctionnement en conséquence :

• Si une personne a décroché : la session établit la connexion avec l’API Voice Agent de Deepgram, transmet les données audio conservées en mémoire tampon, puis lance la conversation.
• Si un répondeur est détecté : le système génère et diffuse un message vocal personnalisé à l’aide du modèle de synthèse vocale Aura-2 de Deepgram, puis met fin à l’appel.

L’implémentation intègre également un mécanisme de gestion des détections tardives. Lorsque le système de détection automatique des répondeurs (AMD) identifie une messagerie vocale alors que l’agent a déjà engagé une conversation en supposant qu’un interlocuteur humain avait décroché, la session met fin à la connexion avec Deepgram pendant l’appel et bascule vers la procédure de diffusion d’un message vocal. Cette situation particulière, susceptible de se présenter dans le cadre d’un volume important d’appels sortants, est ainsi directement prise en charge par l’architecture proposée.

Injection des données contextuelles du prospect dans le prompt de l’agent vocal. Le prompt système de l’agent est construit dynamiquement à partir des informations sur le prospect fournies dans la requête POST /make-call. Avant le début de l’interaction, l’agent dispose donc des informations nécessaires pour identifier le destinataire, connaître les caractéristiques de son bien immobilier et comprendre l’objet de sa demande. Cette contextualisation permet à l’agent d’entamer l’échange par une formule personnalisée, telle que « Je vous contacte au sujet de votre demande de devis d’assurance habitation concernant le bien situé au 742 Evergreen Terrace », plutôt que par une introduction générique comme « Bonjour, vous recevez un appel automatisé ».

Transmission des résultats des appels au système CRM sous une forme structurée. Cette fonctionnalité constitue une étape essentielle pour faire évoluer un agent vocal d’une simple démonstration technique vers une solution intégrée aux processus opérationnels de l’entreprise. L’API Voice Agent de Deepgram prend en charge le mécanisme d’appel de fonctions (function calling), permettant au grand modèle de langage (LLM) qui pilote l’agent de déclencher des opérations spécifiques au cours des interactions, notamment la consultation des disponibilités pour un rendez-vous ou la réservation d’un créneau. Une fonction update_lead est exécutée à l’issue de chaque appel afin de consigner, dans un objet JSON structuré, le statut final de l’appel, les données vérifiées, les nouvelles informations recueillies ainsi qu’un résumé de l’interaction rédigé en langage naturel. Dans l’implémentation de référence, ces informations sont enregistrées dans les journaux de la console. Dans un environnement de production, elles seraient transmises par requête HTTP POST à un système CRM, à un webhook ou à une base de données. Le LLM détermine lui-même quand mettre un terme à la conversation et quelles informations doivent être conservées. Le serveur prend ensuite le relais pour transmettre ces données à votre système backend, où elles pourront être exploitées.

Gestion des silences grâce à l’API InjectAgentMessage de Deepgram. Un mécanisme de surveillance permet de détecter les périodes pendant lesquelles le destinataire ne répond plus. Si le silence se prolonge, l’agent lui demande par exemple : « Vous êtes toujours là ? » en utilisant l’API InjectAgentMessage de Deepgram. Il s’agit d’une commande exécutée côté serveur, qui permet de faire prononcer à l’agent vocal une phrase définie à l’avance, plutôt que de laisser le LLM générer lui-même une réponse. Si l’interlocuteur ne réagit toujours pas, le serveur finit par mettre un terme à la communication. Ce mécanisme peut sembler secondaire, mais son utilité se révèle pleinement lorsque le volume d’appels sortants augmente et que les périodes de silence prolongées finissent par représenter un coût non négligeable.

Premiers pas avec l’agent vocal pour les appels sortants

Le dépôt de code comprend un assistant de configuration qui permet de paramétrer Twilio et de déployer l’application sur Fly.io, une plateforme conçue pour héberger des serveurs applicatifs au plus près des utilisateurs. Pour commencer, vous aurez besoin de Python 3.12 ou d’une version ultérieure, d’un compte Twilio et d’une clé API Deepgram. Celle-ci peut être obtenue gratuitement, avec 200 $ de crédits offerts et sans qu’il soit nécessaire de fournir une carte bancaire.

L’assistant vous accompagne à chaque étape de la configuration, du choix d’un numéro Twilio à la génération d’une clé secrète pour sécuriser le point de terminaison /make-call, jusqu’au déploiement de l’application sur Fly.io. Une fois l’application en service, il suffit de lancer un appel de test.

Votre téléphone sonne et l’agent vocal déroule le scénario de suivi d’une demande de devis d’assurance habitation. Vous pouvez ensuite consulter les journaux du serveur pour retrouver la transcription complète de la conversation ainsi que les résultats structurés de l’appel au format JSON.

Le dépôt peut être dupliqué afin d’en adapter le contenu à d’autres cas d’usage : il suffit de remplacer le scénario d’assurance habitation par vos propres prompts, fonctions et mécanismes d’intégration avec votre système CRM. Le projet est distribué sous licence MIT.

Pour découvrir l’architecture correspondante dédiée aux appels entrants, dans laquelle un utilisateur compose votre numéro et interagit avec un agent d’accueil virtuel reposant sur l’IA, consultez l’article Développer un agent vocal pour les appels entrants avec Twilio et Deepgram.