Comment fonctionne un voicebot concrètement, entre le moment où l’appelant parle et celui où il entend une réponse ? Derrière une conversation qui semble simple se cache une chaîne de composants qui doivent travailler ensemble en temps réel : téléphonie, reconnaissance vocale (STT), compréhension du langage (NLU ou LLM), logique métier et intégrations, puis synthèse vocale (TTS). Chaque maillon influence la qualité perçue, et surtout la latence.
Cet article décrit ce pipeline étape par étape, avec les choix techniques qui comptent vraiment en production.
Vue d’ensemble : comment fonctionne un voicebot
Le parcours d’un tour de parole ressemble à ceci :
- Téléphonie : l’appel arrive (réseau téléphonique, trunk SIP, PBX) et le flux audio est rendu accessible au voicebot.
- Reconnaissance vocale (STT) : l’audio est converti en texte, idéalement en continu (streaming).
- Compréhension (NLU/LLM) : le texte est interprété : intention, informations utiles (date, numéro de commande), contexte de la conversation.
- Actions et intégrations : le voicebot interroge ou met à jour vos systèmes : CRM, ERP, agenda, passerelle de paiement.
- Génération de la réponse : un texte de réponse est construit (gabarit, LLM encadré ou combinaison).
- Synthèse vocale (TTS) : le texte est converti en voix et renvoyé à l’appelant.
Autour de cette boucle se greffent la gestion des interruptions (barge-in), la détection de fin de parole, la journalisation et les mécanismes de repli vers un humain.
1. La couche téléphonie
Tout commence par le raccordement au réseau. L’appel arrive généralement par un trunk SIP vers un PBX ou un serveur de communication (Asterisk, FreeSWITCH, plateformes cloud), ou directement vers une plateforme capable d’exposer l’audio en temps réel.
Points importants :
- Accès au flux audio : le voicebot a besoin de l’audio en temps réel, souvent via des sockets ou des interfaces comme ARI dans Asterisk. Voir notre article sur Asterisk AGI ou ARI.
- Codecs : l’audio téléphonique classique est en bande étroite (8 kHz, G.711). La qualité de reconnaissance en dépend directement.
- DTMF : il faut détecter les touches du clavier en parallèle de la parole.
- Transfert : la couche téléphonie doit savoir transférer l’appel vers une file ou un agent, avec des données associées.
2. La reconnaissance vocale (STT)
Le moteur de STT transforme la parole en texte. Deux modes existent :
- Par lots : on enregistre la phrase complète puis on la transcrit. Simple, mais ajoute de la latence.
- En streaming : la transcription arrive au fil de la parole, avec des résultats partiels. C’est le mode à privilégier pour la conversation.
Ce qui fait la qualité :
- Adaptation au domaine : noms de produits, termes médicaux, noms de rue. Beaucoup de moteurs acceptent des listes de vocabulaire ou des indices contextuels.
- Langues et accents : français du Québec, de France, anglais, appels bilingues. Il faut tester sur de vrais enregistrements.
- Détection de fin de parole (endpointing) : couper trop tôt interrompt l’appelant, couper trop tard ralentit tout.
Les moteurs vont des services cloud aux modèles auto-hébergés de type Whisper. Le choix dépend de la latence, du coût, de la langue et des contraintes de résidence des données. Notre page STT, TTS et NLP détaille ces arbitrages.
3. La compréhension : NLU, LLM ou les deux
Une fois le texte obtenu, il faut comprendre ce que veut l’appelant.
Approche par intentions (NLU classique)
On définit des intentions (« suivre une commande », « annuler un rendez-vous ») et des entités (numéro de commande, date). Le modèle classe chaque phrase. C’est prévisible, auditable et rapide, mais moins souple face aux formulations inattendues.
Approche LLM
Un grand modèle de langage interprète la phrase dans le contexte de la conversation, gère les reformulations, les demandes multiples et les digressions. Il peut aussi rédiger des réponses naturelles. En contrepartie, il faut l’encadrer : instructions précises, outils autorisés limités, validation des paramètres avant toute action, et garde-fous contre les réponses inventées.
L’approche hybride
En pratique, beaucoup de voicebots combinent les deux : le LLM comprend et dialogue, mais les actions sensibles (paiement, modification de dossier) passent par des fonctions structurées avec des règles strictes. Le voicebot ne « décide » pas librement ; il appelle des outils définis, avec des paramètres vérifiés.
4. Actions et intégrations
C’est ici que le voicebot crée de la valeur. Sans accès à vos données, il ne peut qu’aiguiller ; avec, il résout.
Exemples d’intégrations courantes :
- CRM (Salesforce, HubSpot, Dynamics) : identifier l’appelant, consulter son historique, journaliser l’appel.
- ERP ou système logistique (SAP ou autre) : statut de commande, retours, stocks.
- Agenda : disponibilités, prise et modification de rendez-vous.
- Paiement : encaissement sécurisé, avec saisie DTMF et masquage des données pour respecter PCI-DSS.
Bonnes pratiques : temps de réponse des API maîtrisés (avec délais d’expiration), messages d’attente si un appel prend du temps, idempotence des actions, et journalisation complète. Ces sujets sont au cœur de notre service d’intégration CRM/ERP.
5. Génération de la réponse et synthèse vocale (TTS)
La réponse peut être un gabarit fixe (« Votre commande a été expédiée le … »), un texte généré par un LLM, ou un mélange. Les gabarits restent préférables pour les informations critiques : montants, dates, consignes.
La synthèse vocale neuronale produit aujourd’hui des voix très naturelles. Points à surveiller :
- Prononciation des noms propres, sigles, montants et numéros (souvent réglable via SSML ou des lexiques).
- Streaming TTS : commencer à jouer l’audio avant que toute la phrase soit synthétisée réduit la latence perçue.
- Cohérence de la voix entre les messages préenregistrés et la synthèse.
La latence : l’ennemi numéro un
Une conversation téléphonique naturelle tolère mal les silences. L’objectif courant est de répondre en environ une seconde après la fin de la phrase. Le budget de latence se répartit entre :
- détection de fin de parole ;
- finalisation de la transcription ;
- raisonnement du modèle de compréhension ;
- appels API vers vos systèmes ;
- premier segment audio de la synthèse ;
- transport réseau aller-retour.
Leviers d’optimisation : streaming à chaque étape, moteurs hébergés près de la téléphonie, mise en cache des données fréquentes, réponses d’attente courtes (« Je vérifie votre commande… ») pendant les appels API longs, et choix de modèles adaptés à la tâche plutôt que les plus gros disponibles.
Le barge-in : laisser l’appelant interrompre
Dans une vraie conversation, on peut couper la parole. Le barge-in permet à l’appelant d’interrompre le voicebot : dès que de la parole est détectée, la synthèse s’arrête et le voicebot écoute.
Difficultés à gérer :
- Écho et bruit : la voix du bot renvoyée par le téléphone ne doit pas être prise pour l’appelant.
- Faux départs : un « hmm » ou un bruit de fond ne doit pas couper un message important.
- Messages non interruptibles : certaines mentions (consentement, conditions de paiement) doivent être jouées en entier.
Les replis vers un humain
Aucun voicebot ne comprend tout. La qualité d’un projet se juge aussi à la façon dont il échoue :
- Reformulation après une première incompréhension, puis proposition de choix ou de saisie au clavier.
- Transfert vers un agent après un nombre limité d’échecs, ou dès que l’appelant le demande.
- Transfert avec contexte : intention détectée, données collectées, transcription, affichés à l’agent pour éviter de faire répéter.
- Détection de situations sensibles : urgence, détresse, plainte, qui doivent aller directement vers un humain.
Ce qu’il faut retenir
Un voicebot est une chaîne : téléphonie, STT, compréhension, intégrations, TTS. Sa qualité dépend du maillon le plus faible et de la latence cumulée. Les projets qui réussissent soignent autant les intégrations et les replis que l’IA elle-même. Si vous hésitez encore entre SVI et voicebot, notre guide IVR ou voicebot vous aidera à cadrer le besoin.