Comment fonctionnent les agents téléphoniques IA : guide de l’architecture et du déroulement des appels

La plupart des articles qui expliquent les agents téléphoniques IA commencent et s’arrêtent à « c’est une IA qui parle au téléphone ». Ce qui est exact, bien sûr. Mais le plus intéressant se joue entre le moment où quelqu’un ouvre la bouche et celui où il entend une réponse. Il s’y passe beaucoup de choses, en réalité, et le tout en moins de 2 secondes.

Imaginons un instant qu’un client appelle son dentiste pour reporter un rendez-vous du jeudi à la semaine suivante. Côté client, c’est un échange simple de trente secondes. Côté système, en revanche, c’est bien plus complexe : l’appel est analysé, compris, vérifié dans l’agenda, confirmé, puis restitué à voix haute à l’appelant avant qu’il n’ait le temps de raccrocher ou de demander à être transféré. Tout au long de cet article, nous nous appuierons sur cet exemple pour décortiquer chaque étape du processus.

Au passage, c’est précisément le type de problème que la plateforme d’agents téléphoniques de telli est conçue pour résoudre. Les entreprises utilisent couramment des agents téléphoniques IA pour des tâches comme la qualification de leads et la prise de rendez-vous, où les conversations doivent se dérouler naturellement tout en s’intégrant aux systèmes de l’entreprise. Nous utiliserons donc cet exemple pour montrer comment un système réel comme telli gère chaque étape du processus, plutôt que d’en parler en termes purement théoriques.

La chaîne de traitement d’un agent téléphonique IA

Au fond, tous les agents téléphoniques IA suivent plus ou moins la même série d’étapes :

L’appelant parle → Reconnaissance vocale → Compréhension du langage → Raisonnement du LLM → Récupération des connaissances → Appels d’outils → Synthèse vocale → L’appelant entend une réponse

Chacune est indispensable au bon fonctionnement de la chaîne, et toutes dépendent étroitement les unes des autres. Un excellent modèle de langage, par exemple, ne servira pas à grand-chose si votre moteur de transcription est approximatif et n’entend pas correctement ce que dit le client. Une qualité audio irréprochable aura peu d’effet si votre moteur vocal est lent et fait attendre le client une seconde ou deux. Chaque maillon de cette chaîne compte autant que les autres.

Voici, dans les grandes lignes, le rôle de chaque maillon de la chaîne :

Suivons notre exemple de report de rendez-vous à travers les étapes de la chaîne.

Étape 1 : convertir la parole en texte

Dès que l’appelant prononce « Je dois déplacer mon rendez-vous de jeudi », un moteur de transcription de la parole (speech-to-text, STT), aussi appelé reconnaissance automatique de la parole (ASR), est déjà à l’œuvre en coulisses. Des fournisseurs comme Deepgram, Speechmatics, Whisper ou les modèles vocaux de Google le mettent en œuvre de mille façons, mais tous visent le même résultat : produire une transcription ponctuée de la parole, aussi proche du temps réel que possible.

Tous les composants en aval héritent des erreurs commises lors de la transcription : une erreur qui transforme « déplacer mon rendez-vous de jeudi » en « effacer mon rendez-vous de jeudi » change complètement ce que veut dire le client et peut créer des frictions inutiles.

Les accents, le bruit de fond, les mauvaises connexions téléphoniques, ou simplement le fait de marmonner, rendent cette étape complexe, mais décisive. C’est pourquoi la plupart des systèmes en temps réel combinent réduction du bruit et reconnaissance vocale multilingue, au lieu de se contenter d’un seul passage.

Les facteurs qui influent réellement sur la précision de la transcription, d’après les recherches sur les performances de l’ASR, sont les suivants :

Ce n’est pas un écart anodin. Une étude de 2020, largement citée par les chercheurs, a montré un écart important de taux d’erreur des modèles d’ASR selon qu’ils écoutaient des locuteurs afro-américains ou des locuteurs américains blancs, principalement en raison des limites des données plutôt que de problèmes technologiques. C’est un bon rappel : la qualité de la transcription varie selon les locuteurs, et des chiffres de précision fondés sur un éventail restreint d’accents ne reflètent pas forcément les performances en conditions réelles.

Étape 2 : comprendre ce que l’appelant veut vraiment dire

Saisir les bons mots ne veut pas dire saisir le bon sens. C’est là qu’interviennent la compréhension du langage naturel (NLU) et la détection d’intention. Par exemple, « Pouvez-vous m’envoyer la facture ? » et « Pouvez-vous me renvoyer la facture ? » sont presque identiques sur le plan grammatical, mais appellent des actions différentes.

Pour les besoins de l’exercice, notre appelant dit : « Je dois déplacer mon rendez-vous de jeudi. » Le système doit déterminer l’intention (reporter, et non annuler), identifier la bonne entité (ce rendez-vous de jeudi précisément), se souvenir des informations données plus tôt dans l’appel (qui est l’appelant, s’il a été authentifié) et cerner son ressenti (agacé, enthousiaste, etc.).

Étape 3 : comment le LLM décide quoi dire

C’est généralement l’étape la plus mal comprise. Le LLM qui pilote un agent téléphonique n’improvise pas ses réponses comme il le ferait dans une démo de chatbot. Il opère dans un cadre défini : un prompt système qui fixe les règles de l’entreprise, l’historique de la conversation, les informations récupérées dans la base de connaissances de l’entreprise et des actions d’outils autorisées à l’avance.

Quand l’appelant veut reporter son rendez-vous de jeudi, le LLM n’invente pas une réponse plausible sur les reports. Il se pose plutôt des questions comme : « Acceptons-nous les reports dans la même semaine ? », « L’outil d’agenda est-il accessible ? », « Quelles informations supplémentaires (une nouvelle date, par exemple) faut-il pour agir ? »

Ce n’est qu’une fois qu’il dispose de suffisamment d’informations qu’il répond, soit en demandant à l’appelant des informations supplémentaires, soit en déclenchant la fonction appropriée. C’est une différence fondamentale entre générer du texte et accomplir des tâches de raisonnement à l’aide d’outils. C’est aussi la différence entre dire quelque chose de plausible et faire réellement ce qui doit être fait.

Selon le LLM sous-jacent (GPT, Claude, Gemini, Llama, etc.), le risque d’hallucination augmente nettement lorsque le modèle peut répondre librement à partir de ses données d’entraînement plutôt qu’à partir d’informations vérifiées et récupérées. Les bons systèmes s’efforcent activement d’éviter ces situations.

Étape 4 : récupérer les informations propres à l’entreprise

Ce n’est pas parce qu’un LLM sait générer un texte intelligent qu’il « connaît » les tarifs de votre cabinet, les subtilités de vos conditions d’annulation ou vos horaires d’ouverture. Les agents pilotés par un LLM doivent aller chercher ces informations à la demande.

C’est le rôle de la génération augmentée par récupération (RAG), une approche décrite dans un article scientifique de 2020, qui complète les connaissances existantes (ou « paramétriques ») d’un LLM par des informations externes, récupérées au moment où le LLM en a besoin. Au lieu de s’appuyer sur ce que le LLM a appris pendant son entraînement (des connaissances générales, parfois inexistantes pour les détails propres à l’entreprise), le système va chercher les documents pertinents, comme les FAQ, les documents internes, les CRM ou les règles internes, dans la base de connaissances de l’entreprise, transforme ces données et les injecte dans l’étape de génération du langage.

Toute la différence tient à l’endroit où se trouvent les connaissances. Un modèle entraîné les a intégrées une fois pour toutes : pour les mettre à jour, il faut le réentraîner ou l’affiner (fine-tuning), et ses réponses sur votre activité sont souvent génériques, voire tout simplement fausses. La récupération va chercher ces mêmes informations en direct dans vos propres documents et bases de données, se met à jour dès que vous mettez à jour votre base de connaissances, et ancre chaque réponse dans des faits réels plutôt que dans une hallucination du modèle.

Dans notre exemple, l’agent doit vérifier si notre appelant devra payer des frais pour un report dans la même semaine, car ce détail ne fait pas partie des connaissances du LLM générique.

Il faut aller le chercher dans les documents où le cabinet consigne ses propres règles. C’est un domaine où la pratique s’écarte de la théorie.

Les agents de telli, par exemple, peuvent accéder à un ensemble de documents importés (FAQ, grilles tarifaires, règles internes) et choisir eux-mêmes, pendant l’appel, d’utiliser la recherche sémantique, la recherche par mots-clés ou les deux. Si la règle se trouve dans un PDF, par exemple, l’agent la lit et l’applique directement au lieu de la deviner. S’il ne la trouve pas, il s’en remet au prompt plutôt que d’inventer une réponse.

Étape 5 : faire appel aux systèmes externes

À quoi bon une IA qui parle si elle ne sait rien faire d’autre ? Les entreprises veulent des agents IA capables d’agir : consulter leur CRM, créer des fiches clients, vérifier des informations ou transférer des appels. Toutes ces tâches reposent sur des intégrations, des API et des webhooks.

Dans notre scénario, une fois l’appelant authentifié, l’agent interrogerait l’agenda pour trouver des créneaux libres le jeudi, déplacerait le rendez-vous, mettrait à jour la fiche client et s’assurerait que tout est consigné dans le CRM, le tout sans intervention humaine.

telli y parvient en permettant aux agents de déclencher des « appels d’outils » (tool calls) en pleine conversation. Il peut s’agir de fonctions qui mettent fin à l’appel ou qui appellent un endpoint HTTP personnalisé pour vérifier les disponibilités de l’agenda. L’appelant ne sait pas si des appels d’outils sont en jeu : il entend simplement « Je vérifie ça pour vous. »

Étape 6 : convertir le texte en parole

Enfin, une fois que le LLM a déterminé ce qu’il doit dire, la synthèse vocale (text-to-speech, TTS) transforme cette réponse en la voix qu’entend l’appelant. Les systèmes modernes proposent des voix neuronales sophistiquées, bien loin des voix robotiques d’il y a dix ans, faites de syllabes mises bout à bout, ce qui change la façon dont les agents rythment leur discours, articulent et font passer le ton.

Les facteurs qui distinguent une voix proche de l’humain d’une voix artificielle sont les suivants :

• Prosodie : une intonation qui monte et descend naturellement, pas un débit monocorde
• Prononciation : prononcer correctement les noms, les chiffres et les abréviations
• Débit : ni précipité ni anormalement lent
• Latence : une réponse en moins d’une seconde, pour que l’échange reste vivant
• Streaming : l’audio démarre avant même que la réponse complète ait fini d’être générée

La latence compte ici plus qu’à presque toute autre étape de la chaîne. Une voix parfaite, mais qui arrive avec deux secondes de retard, donne l’impression d’un système en panne. Au téléphone, chacun attend une réponse au même rythme qu’avec un interlocuteur humain. Quelle que soit la langue, on attend en moyenne 200 ms entre la fin d’une phrase et le début de la suivante.

L’IA vocale, qui assemble plusieurs fournisseurs pour la reconnaissance vocale, le modèle de langage et la synthèse vocale, met généralement entre 600 ms et 1 700 ms de bout en bout. Dans les tests comparatifs du secteur, tout ce qui dépasse 800 ms est en général déjà perçu comme un retard.

L’expérience de telli illustre bien l’importance de réussir cette étape. telli conçoit des agents IA conversationnels pour les appels commerciaux B2C avec des leads et des clients, où une voix guindée et peu humaine ne se contente pas de mal sonner : elle fait activement baisser la conversion, car les interlocuteurs raccrochent dès qu’elle franchit le seuil de ce qui paraît « humain ». C’est pourquoi telli privilégie un fournisseur de synthèse vocale à faible latence, compatible avec le clonage vocal, plutôt que de reléguer la qualité de la voix au second plan, derrière le LLM.

Comment les agents téléphoniques IA gèrent les interruptions

Les vraies conversations ne fonctionnent pas au tour par tour comme un chat écrit. On se coupe la parole, on fait une pause pour réfléchir, on laisse une phrase en suspens. Cette caractéristique des vraies conversations porte un nom, le barge-in (gestion des interruptions), et c’est l’un des problèmes les plus difficiles à résoudre dans le secteur de l’IA vocale.

Si notre appelant lance soudain « En fait, attendez, annulons plutôt » au milieu de la confirmation du report, le système doit détecter cette interruption immédiatement, se taire et traiter la nouvelle demande, au lieu de finir sa phrase et de ne remarquer qu’ensuite que l’appelant a changé d’avis. Pour détecter correctement ces changements d’intention et ces interruptions, le système a besoin d’une détection continue de l’activité vocale en temps réel, et pas seulement au début et à la fin de chaque prise de parole.

Comment fonctionne le transfert vers un conseiller

Les meilleures conversations avec une IA ne se terminent d’ailleurs pas toutes avec l’agent IA. Si l’IA ne peut pas traiter la demande, ou si l’appelant demande explicitement à parler à une personne, l’appel doit être transféré vers un conseiller : l’appelant est mis en relation avec le bon conseiller, qui reçoit un résumé de ce qui a déjà été dit, pour que le client n’ait pas à tout répéter.

C’est une étape où échouent de nombreux systèmes d’IA vocale pourtant performants. Si le transfert a lieu mais que la transcription ou le contexte se perd entre l’IA et le conseiller, cela revient à reprendre l’appel de zéro, comme avec un appelant dont on ne sait rien. L’intention, les données du CRM et les informations déjà confirmées doivent toutes suivre l’appel jusqu’au conseiller.

L'approche de telli pour le transfert vers un conseiller consiste à mettre l’appelant en attente, à informer le conseiller grâce à un résumé automatique de la conversation, puis à mettre en relation l’appelant et le conseiller. Si le transfert n’aboutit pas dans le délai imparti ou tombe sur une messagerie vocale, l’appel revient à l’agent IA.

Les défis techniques courants

L’IA vocale peut réellement échouer, et de plusieurs façons. Voici à quoi cela ressemble en pratique, plutôt que l’habituelle liste générique d’avantages et d’inconvénients :

• La latence vient du traitement séquentiel STT → LLM → TTS. On y remédie avec une architecture en streaming et une inférence parallélisée.
• Les hallucinations surviennent quand le modèle répond à partir de connaissances générales au lieu de faits récupérés. On y remédie avec un ancrage strict dans les sources et des prompts qui donnent la priorité à la récupération.
• Le bruit de fond de l’environnement de l’appelant dégrade la qualité du signal reçu. On y remédie avec la suppression du bruit et des seuils de confiance.
• Une documentation insuffisante se traduit par une base de connaissances maigre ou obsolète. On y remédie avec des audits réguliers de la base de connaissances.
• Les pannes d’API viennent de délais d’attente dépassés ou d’erreurs dans les intégrations tierces. On y remédie avec une logique de nouvelles tentatives et des messages de repli soignés.
• Les questions inattendues surviennent quand l’appelant sort du scénario prévu. On y remédie avec des réponses de repli et des procédures d’escalade définies.

Ce qui distingue les agents téléphoniques IA pour les grandes entreprises

Les besoins d’une petite entreprise qui teste son premier standard téléphonique IA sont assez différents de ceux d’une grande entreprise qui généralise l’IA dans ses échanges téléphoniques. En bref, voici ce qui distingue généralement les déploiements en grande entreprise des structures plus modestes :

• Conformité : enregistrement des appels, localisation des données, réglementations propres à chaque secteur (services financiers, santé, etc.)
• Observabilité : une visibilité sur la manière dont chaque décision a été prise pendant l’appel, au-delà de la simple transcription.
• Analyses : suivi des conversions, analyse des abandons, suivi des tendances sur l’ensemble des appels.
• Versionnage des prompts : des déploiements structurés, avec la possibilité d’annuler les modifications.
• Tests : des tests par appels simulés avant toute mise en production.
• Supervision : des alertes en temps réel en cas de pic de latence ou de taux d’erreur.
• Gestion des connaissances : un cadre qui garantit que la couche de récupération reste à jour quand les règles évoluent

C’est ce qui fait la différence entre une démo qui fonctionne et un système qui tient la charge sur dix mille appels par mois.

Par exemple, la fonction d’observabilité de telli repose sur le concept de « champs structurés automatiquement ». Pendant un appel, le système décompose chaque échange en champs clés définis pour chaque agent, comme une valeur booléenne, une catégorie, un nombre ou un champ de texte libre. Ces valeurs sont extraites directement de la transcription, en respectant strictement le schéma. Si aucune valeur ne peut être identifiée dans la transcription pour un champ donné, celui-ci reste vide (null). Des milliers d’appels désordonnés et non structurés deviennent ainsi consultables et exploitables, car ils sont transformés en données structurées et comparables. C’est là tout l’enjeu d’une solution vraiment « prête pour les grandes entreprises ».

Les idées reçues

Quelques points méritent d’être rectifiés sans détour :

• « Les LLM mémorisent les données de votre entreprise. » Ce n’est pas le cas : ils les récupèrent grâce au RAG dans les sources de l’entreprise, comme les FAQ, les PDF, les bases de connaissances, etc.
• « L’IA vocale, c’est juste de la reconnaissance vocale avec un chatbot derrière. » La reconnaissance vocale n’est qu’un des nombreux rouages que les agents téléphoniques IA doivent gérer, et généralement pas le plus difficile.
• « Un modèle plus puissant donne automatiquement un meilleur agent téléphonique. » Les modèles ne cessent de progresser, mais un meilleur modèle n’améliorera pas les performances globales de l’agent téléphonique IA s’il lui manque une récupération fiable des données et un accès aux outils pour exécuter correctement les actions.

Récapitulons

Si l’on retire toutes les couches entre chaque étape du processus d’IA vocale, le système n’a qu’une seule mission : prendre une demande orale et produire un résultat adapté, dans le délai d’une conversation normale. Tout commence par la reconnaissance vocale, qui transforme l’audio en texte. La compréhension du langage interprète ensuite ces mots. Un grand modèle de langage décide quoi faire en fonction de ces mots et de l’intention. La récupération fournit les faits propres à l’entreprise. Les appels d’outils exécutent ensuite les actions, et la synthèse vocale reconvertit enfin la réponse écrite en parole. Chacun de ces composants peut faire échouer toute la chaîne, même si tous les autres fonctionnent parfaitement.

Sources utilisées

1. researchgate.net - Les défis de la reconnaissance vocale en environnement bruyant
2. pnas.org - Disparités raciales dans la reconnaissance automatique de la parole
3. arxiv.org - Génération augmentée par récupération (RAG)
4. docs.telli.com - Présentation de la base de connaissances
5. docs.telli.com - Présentation des appels d’outils (tool calls)
6. researchgate.net - Les universaux de l’alternance des tours de parole dans la conversation
7. telnyx.com - Comparatif de latence de l’IA vocale
8. cartesia.ai - L’intégration vocale à faible latence de telli
9. telli.com - Barge-in et gestion des interruptions des agents téléphoniques IA
10. docs.telli.com - Transfert d’appel
11. docs.telli.com - Analyse des appels