Call-bot.ai

Callbots & IA vocale entreprise11 min de lecture

Comment fonctionne un callbot : STT, LLM et TTS expliqués

Dans son architecture enchaînée, un callbot n'est pas un bloc unique mais une chaîne. À chaque tour de parole, un moteur de reconnaissance vocale (STT) transcrit l'appelant, un modèle de langage (LLM) décide de la réponse ou d'une action, une synthèse vocale (TTS) la prononce, le tout relié à la ligne téléphonique par un logiciel d'orchestration. Voici le rôle de chaque maillon, ses points faibles et les architectures possibles.

Microphones de table et tablettes posés sur une longue table en bois, dans une salle de réunion lumineuse

Photo : Werner Pfennig · Pexels

Quand un appelant parle à un callbot à architecture enchaînée, le son traverse le réseau téléphonique, le système décide que la phrase est finie, la parole devient du texte, un modèle de langage prépare une réponse ou une action, puis une voix de synthèse la prononce. Ces étapes restent invisibles pour l'appelant, mais c'est leur enchaînement qui détermine le temps de réponse qu'il perçoit.

La définition, la mesure des délais et la facture ont leurs pages : Qu'est-ce qu'un callbot ?, latence d'un callbot, coûts cachés d'un projet callbot. Ici, la chaîne maillon par maillon, d'après des documentations d'éditeurs consultées le 21/10/2026 : ils vendent ce qu'ils décrivent, et nous le signalons quand cela compte.

Du téléphone à l'agent : le trajet de l'appel

Un callbot ne « décroche » pas comme un poste téléphonique. L'appel arrive à une plateforme de voix par un lien SIP (SIP trunk), la liaison par laquelle un opérateur ou un standard se raccorde à un logiciel, ou par une application qui relaie l'audio : OpenAI documente ces deux voies (« SIP direct » et « pont audio » côté serveur). Chez Twilio, Media Streams livre l'audio brut par WebSocket, tandis que ConversationRelay assure reconnaissance et synthèse vocales et n'échange avec l'application que du texte et des événements.

Sur une ligne classique, la voix a la qualité du téléphone : le codec G.711 échantillonne à 8 000 Hz sur une bande de 300 à 3 400 Hz, et Google propose un modèle de reconnaissance telephony pour l'audio d'appel, typiquement enregistré à 8 kHz. La voix de synthèse subit la même contrainte : une démonstration en haute définition ne préjuge pas du rendu au bout du fil.

Le même tuyau porte les touches du clavier (DTMF), que ConversationRelay et OpenAI remontent à l'application, et le transfert vers un humain. Un message SIP REFER déplace l'appel vers un autre point ; ce transfert « à froid » met fin à la session côté plateforme (LiveKit). LiveKit documente aussi un transfert accompagné : l'agent met l'appelant en attente, briefe le conseiller, puis les met en relation. Le choix change l'expérience du conseiller comme la facture (coûts cachés).

Écouter : la reconnaissance vocale (STT)

Le STT (speech-to-text) transforme l'audio en texte, en flux : Deepgram décrit des résultats provisoires publiés pendant que l'appelant parle, puis une transcription finalisée. Dans une architecture enchaînée, le modèle ne voit que ce texte : un nom propre ou un chiffre mal transcrit se propage à toute la suite.

Le STT n'est pas forcément celui qui décide que l'appelant a fini : c'est le rôle de la détection de fin de tour, intégrée à certains moteurs de STT (LiveKit cite AssemblyAI et Deepgram Flux) ou assurée à part, qui repose le plus souvent, selon LiveKit, sur la détection d'activité vocale (VAD) pour repérer les silences. LiveKit propose aussi un modèle qui prédit la fin de tour d'après le sens de la phrase et le signal acoustique. Glossaire : endpointing.

Décider : le modèle de langage (LLM) et ses outils

Le LLM (large language model) reçoit le texte et produit une réponse ou une demande d'action. Trois points comptent.

Il n'a pas de mémoire propre. Chaque requête est isolée et sans état, indique OpenAI : l'historique est renvoyé à chaque tour, ou conservé côté plateforme par un mécanisme prévu pour cela.

Il n'exécute rien lui-même. Pour consulter un agenda ou créer une fiche, le modèle demande un appel d'outil ; votre application l'exécute et renvoie le résultat, puis le modèle formule la réponse (documentation OpenAI). La qualité de ces branchements compte aussi, et pas seulement le choix du modèle.

Il peut se tromper avec assurance. Kalai, Nachum, Vempala et Zhang (arXiv, septembre 2025) décrivent l'hallucination comme la production d'énoncés plausibles mais faux plutôt que l'aveu d'une incertitude, et la disent présente jusque dans les systèmes les plus récents. Une parade courante : ne laisser le modèle énoncer un fait vérifiable (disponibilité, tarif, statut) qu'après interrogation de la source, selon le principe du chatbot RAG, et vérifier que ce qu'il confirme à voix haute correspond à l'action exécutée, comme le recommande OpenAI.

Répondre : la synthèse vocale (TTS)

Le TTS (text-to-speech) transforme la réponse en audio, lui aussi en flux : selon Twilio, la synthèse peut démarrer dès les premiers éléments de texte reçus du modèle. La qualité de la voix se paie en temps : ElevenLabs (page consultée le 21/10/2026) décrit son modèle Flash v2.5 comme un modèle de temps réel à environ 75 ms, hors latence applicative et réseau, et indique que Multilingual v2, un modèle de génération précédente, a une latence et un coût par caractère plus élevés. Ces 75 ms sont celles du modèle seul, pas celles d'un appel.

Un tour de parole, étape par étape

De la fin de la phrase de l'appelant au début de la réponse :

  1. L'appelant parle ; l'audio part en continu vers la plateforme.
  2. Le STT publie des transcriptions provisoires ; la détection de fin de tour décide que la phrase est terminée.
  3. Le texte final et l'historique partent vers le LLM.
  4. Le LLM répond, ou demande un outil que l'application exécute avant de lui rendre le résultat.
  5. Dès les premiers mots, le TTS produit l'audio, diffusé à l'appelant.
  6. Pendant que le callbot parle, il écoute encore, pour détecter une interruption, puis le cycle recommence.

Le rythme dépend du chevauchement des étapes. Retell, qui publie ses propres chiffres (billet mis à jour le 19 octobre 2026), estime qu'un pipeline où chaque étape attend la précédente dépasse 3 secondes avant le premier son. Ordres de grandeur par étage et méthode de mesure : latence d'un callbot. Repère humain : dans des conversations filmées en dix langues, la réponse à une question fermée (oui/non) arrive en moyenne 208 ms après la fin de la question, une mesure que les auteurs jugent représentative des tours de parole en général (Stivers et al., 2009).

L'interruption (barge-in) : un réglage, pas une option

Interrompre un callbot, c'est classer un son en temps réel. Selon LiveKit, dès que l'agent détecte de la voix en entrée, il suspend sa parole et tronque automatiquement son historique. Or une prise de parole, un bruit, une toux et un « oui » d'acquiescement produisent des signaux voisins : d'où des seuils réglables. Chez Vapi (documentation consultée le 21/10/2026) : un nombre de mots (numWords), une durée de voix avant l'arrêt (voiceSeconds, 0,2 s par défaut) et un délai de reprise (backoffSeconds, 1 s par défaut). Chez LiveKit : une durée et un nombre de mots minimaux, un mode adaptatif qui sépare l'interruption volontaire de l'acquiescement, et la reprise là où l'agent s'était arrêté après une « fausse interruption » (aucun mot transcrit).

Plus les seuils sont bas, plus le callbot s'arrête au moindre bruit ; plus ils sont hauts, plus il parle par-dessus l'appelant. L'essai avec du bruit, des hésitations et de vraies interruptions permet de le vérifier. Glossaire : barge-in.

Enchaîné ou de bout en bout : trois architectures

Ce qui précède décrit une architecture enchaînée : STT, LLM, TTS, avec du texte entre les étapes. OpenAI, dont les API couvrent les trois options, en distingue trois (page consultée le 21/10/2026) :

Architecture Principe Ce que la documentation met en avant
Pipeline enchaîné Votre application gère trois étapes : reconnaissance vocale, agent, synthèse vocale Contrôle de chaque étape : texte intermédiaire inspectable, composants remplaçables
Parole à parole (API Realtime) Un seul modèle interprète l'audio, décide et répond en voix Parole, raisonnement et outils dans une même session
Voix full-duplex et agent en arrière-plan (GPT-Live) Un modèle vocal écoute et parle en même temps, et délègue raisonnement et outils à un agent distinct Conserver son flux de travail texte et choisir librement l'agent d'arrière-plan

Dans une chaîne, le texte existe à chaque étape : OpenAI cite l'enregistrement de la transcription, le contrôle par des règles avant que l'agent réponde, la synthèse seulement après validation. Dans un modèle de bout en bout, ce texte disparaît ou se reconstitue à côté : selon Deepgram, les transcriptions d'un modèle parole-à-parole viennent d'un processus parallèle.

Quelle architecture domine ? Nous n'avons pas trouvé de mesure de leur part de marché établie par un tiers. Deepgram, qui vend de la reconnaissance vocale, écrit (article du 21 mai 2026, mis à jour le 14 octobre) que la cascade reste le choix par défaut de la plupart des charges en production ; OpenAI conseille de choisir d'abord l'architecture audio. La question utile à un acheteur : où voulez-vous pouvoir lire, contrôler, auditer ? La réponse conditionne ce qui est enregistré et prouvable (RGPD et callbot).

Questions fréquentes

Quelle différence entre speech-to-text et text-to-speech ?

Le speech-to-text (STT) convertit de l'audio en texte : c'est l'oreille du callbot. Le text-to-speech (TTS) fait l'inverse, du texte vers l'audio : c'est sa voix. Un modèle « speech-to-speech » est autre chose : il traite l'audio en entrée et en sortie sans texte intermédiaire. Voir le glossaire : STT et TTS.

Un modèle de langage plus puissant donne-t-il un meilleur callbot ?

Pas à lui seul. Le modèle n'est qu'un maillon : la ligne, la reconnaissance vocale, la détection de fin de tour et la synthèse peuvent chacune dégrader l'échange. OpenAI recommande, pour son modèle GPT-Live, de tester séparément la reconnaissance de la parole de l'appelant sur des accents, du bruit, des noms et des nombres, et de comparer la médiane et le 95e centile des délais sur des appels comparables.

Pourquoi un callbot coupe-t-il la parole, ou se fait-il couper à tort ?

Deux réglages sont en cause : la détection de fin de tour (quand le callbot estime que vous avez fini) et les seuils d'interruption (ce qui suffit à le faire taire). Demandez comment ils sont réglés et testez avec du bruit réel.

Un callbot peut-il inventer une information ?

Oui : un modèle de langage peut produire une réponse plausible mais fausse au lieu de signaler qu'il ne sait pas. On réduit le risque en l'obligeant à interroger une source avant d'énoncer un fait.

En résumé

Dans une architecture enchaînée, à chaque tour de parole, un callbot enchaîne le transport de l'audio par la ligne, la détection de fin de tour, la reconnaissance vocale, un modèle de langage qui répond ou demande une action, et une synthèse vocale diffusée en flux. Ce qui fait la différence à l'usage : la qualité téléphonique de l'audio, le réglage de la fin de tour et des interruptions, le branchement du modèle aux systèmes de l'entreprise. Les architectures enchaînée, parole à parole et hybride ne donnent pas le même accès au texte, donc au contrôle. Pour examiner ces choix sur votre projet, parlons-en.

Sources

Parler de votre projet