L'IA rationalise le parcours vers les agents du service clientèle humain

De nouvelles recherches révèlent que les systèmes d'IA open source de type ChatGPT peuvent potentiellement utiliser le langage naturel pour mettre les appelants en relation avec la bonne personne dans un centre d'appels, sans avoir à naviguer dans des menus frustrants et changeant fréquemment, qui semblent souvent délibérément obstructifs.

Joindre un agent en direct peut être une épreuve frustrante, car les appelants doivent passer en revue plusieurs options à choix multiples, souvent sans savoir laquelle correspond à leur problème spécifique. Lorsque aucune ne convient, les utilisateurs avertis développent souvent des astuces et des solutions de contournement pour joindre un représentant humain et échapper à ce « cauchemar des options ». Pour beaucoup, cette expérience est perçue comme hostile et peu conviviale.

Il n'est donc pas surprenant que les centres d'appels soient une cible privilégiée pour l'augmentation ou le remplacement par l'IA. Malgré la prudence recommandée par certains experts, l'automatisation des centres d'appels reste un sujet facile à traiter pour les médias technologiques et un domaine prometteur pour l'innovation basée sur l'IA, qui peut offrir un retour sur investissement exceptionnellement rapide.

Un marché fermé

Cependant, les principes de l'open source et les données accessibles au public sont rarement appliqués dans ce domaine, et pour cause. Les entreprises qui automatisent leurs systèmes de réponse à la clientèle ont peu d'intérêt à partager les données, les méthodologies ou la propriété intellectuelle qui sous-tendent leur avantage concurrentiel.

Le partage de ces ressources éroderait leur avantage concurrentiel. Plus grave encore, les systèmes d'IA pouvant être sujets à des fuites d'informations sensibles, cela comporte également des risques juridiques importants.

Cela a conduit plusieurs entreprises bien financées à développer indépendamment des systèmes de centres d'appels basés sur l'IA, ce qui a inévitablement entraîné une duplication des efforts. Cela a également alimenté une vague de start-ups B2B et d'acteurs établis visant à répondre à la demande croissante de capacités de service client basées sur l'IA.

Un assistant vocal PolyAI initie un appel au service clientèle de la société fictive « Augusta Lawn Care », en s'appuyant sur de nombreuses conversations d'entraînement pour automatiser les réponses au sein de l'infrastructure existante du centre d'appels. Source

En outre, la volonté d'éliminer la frustration liée à la complexité des menus des centres d'appels a stimulé les efforts de recherche. Cependant, la plupart des résultats ne sont pas publiés sur Arxiv ou d'autres plateformes ouvertes, ce qui reflète la nature généralement propriétaire du développement des systèmes de réponse vocale interactive (IVR).

Par conséquent, les recherches, les données et les informations commerciales liées à l'automatisation de l'IA dans le service client sont étroitement gardées. Il existe très peu d'alternatives open source, même si l'utilisation de tels systèmes avec des données juridiquement sécurisées était une option viable, ce qui est douteux.

Appel local

Dans ce contexte, un nouvel article publié en Colombie constitue une tentative bienvenue pour sortir quelque peu le développement des IVR de son coffre-fort d'entreprise. Cette étude concise, intitulée « Beyond IVR Touch-Tones: Customer Intent Routing using LLMs » (Au -delà des touches IVR : routage des intentions des clients à l 'aide de LLM), a été réalisée par un chercheur de l'Universidad Distrital Francisco José de Caldas à Bogotá. Elle prétend être le premier projet non propriétaire utilisant des modèles linguistiques à grande échelle (LLM) pour créer un schéma fonctionnel pour un système de routage des intentions des clients (CIR).

Plutôt que d'utiliser des données d'appels réels ou des structures de menu propriétaires, le projet génère tous les composants à partir de zéro à l'aide de trois modèles d'IA : l'un pour concevoir un menu de centre d'appels réaliste, un autre pour simuler des centaines de plaintes d'appelants et un troisième pour fonctionner comme un chatbot, acheminant ces requêtes vers la bonne destination.

Le résultat est un environnement de test entièrement synthétique mais convaincant, mettant en scène une entreprise de télécommunications fictive et 920 requêtes d'utilisateurs distinctes. Cette configuration permet à l'expérience d'explorer la capacité de l'IA actuelle à interpréter des discours vagues et non structurés et à diriger les appelants de manière appropriée, tout en évitant les risques juridiques.

Les tests montrent que le système peut acheminer avec précision les plaintes libres des appelants vers la bonne destination avec une précision pouvant atteindre 89,13 %, en particulier lorsqu'il dispose d'options de menu « simplifiées » plutôt que de descriptions détaillées.

L'étude a également révélé que l'IA commettait davantage d'erreurs lorsque les appelants utilisaient un langage informel ou varié. Cependant, certaines erreurs ne sont pas dues à une mauvaise compréhension de l'IA, mais à la confusion engendrée par le menu téléphonique lui-même.

Exemples d'interactions avec les clients partagés dans le cadre du nouveau projet. Source

Les données du projet ont été rendues publiques.

Méthode

L'approche tripartite a commencé par un modèle créant un menu téléphonique détaillé pour une entreprise de télécommunications fictive. Un deuxième modèle a généré des messages uniques pour les appelants, certains simples, d'autres reformulés ou plus informels, afin de simuler des schémas linguistiques réalistes. Au total, 920 exemples ont été générés.

Le troisième modèle avait pour tâche de connecter chaque appelant au bon service en se basant uniquement sur le message et une version du menu. Ce cadre a permis de rendre l'expérience entièrement reproductible sans avoir besoin de données d'appels réelles ni d'exposer les informations des clients.

Les trois systèmes sélectionnés pour l'approche tripartite. Source

Les modèles utilisés étaient respectivement gpt-3.5-turbo, gpt-4o-mini et gpt-4.1-mini.

Afin de simuler un environnement de service client authentique, un menu téléphonique complexe a dû être synthétisé à partir de zéro. En raison du manque de données pertinentes, le modèle gpt-3.5-turbo a été invité à générer une structure complète à plusieurs branches pour un fournisseur de télécommunications fictif.

Chaque branche représentait des domaines de service tels que la facturation, l'assistance technique, la gestion des comptes et les nouveaux services, avec des sous-options réalistes et des niveaux de détail variables. Deux versions du menu ont été créées à des fins de test : une hiérarchie en texte brut imitant un format lisible par l'homme et une liste de points finaux avec les séquences de boutons correspondantes.

Cela a permis de tester à la fois une version détaillée et une version simplifiée du problème de routage :

Deux versions du menu téléphonique ont été fournies à l'IA : une hiérarchie textuelle détaillée et une liste simplifiée d'options de menu directes, afin de comparer l'efficacité de chaque format pour acheminer les appelants vers le bon endroit.

Pour générer les messages des appelants test, un deuxième modèle linguistique a produit un ensemble de plaintes ou de demandes originales, avec dix exemples uniques par point final du menu.

Chacun a ensuite été reformulé en plusieurs variantes afin de refléter les différentes façons dont les personnes réelles expriment leurs problèmes, en intégrant des changements de longueur, de ton et même des erreurs mineures ou des mots de remplissage.

Les 920 messages initiaux ont été conçus pour tester la précision du système et simuler l'imprévisibilité d'une conversation naturelle.

Au cours de la troisième étape, la capacité du modèle final à associer chaque message à la bonne destination du menu a été testée à l'aide des deux formats de présentation IVR différents.

Pour la première version, l'IA a reçu un aperçu descriptif complet de l'arborescence téléphonique. Pour la seconde, elle n'a vu qu'une liste des destinations finales avec leurs séquences de boutons.

L'objectif était de déterminer si un menu simplifié aiderait le modèle à acheminer les appels plus efficacement. Dans les deux cas, le système a traité un message à la fois et a reçu pour instruction de ne renvoyer que le chemin, sans texte supplémentaire, afin de permettre une notation automatisée.

Isolement

Afin d'éviter toute contamination des résultats des tests, chaque modèle a été maintenu isolé. Le premier modèle a rédigé le menu téléphonique, mais celui-ci a été finalisé manuellement afin de rester inconnu des autres systèmes.

Les messages des appelants ont été générés séparément par gpt-4o-mini, en utilisant uniquement les noms des points de terminaison sans accès à la structure du menu. Enfin, gpt-4.1-mini, qui effectuait le routage, n'avait accès qu'au texte du menu et aux messages entrants, sans jouer aucun rôle dans leur création.

Mesures

Deux mesures standard ont permis d'évaluer les performances du système de routage : la précision, définie comme le pourcentage de cas où le modèle a fourni le chemin exact correct (par exemple, 1-2-3). Des matrices de confusion ont également été générées* afin de localiser précisément les erreurs. Les évaluations ont été réalisées en Python à l'aide des bibliothèques pandas et scikit-learn.

Résultats

Les tests ont révélé que la précision du modèle dépendait fortement de la présentation du menu. Avec une liste aplatie des chemins du menu, le système a atteint une précision de 89,13 % sur l'ensemble de données le plus simple, contre 81,30 % avec le menu descriptif complet.

La précision du routage pour le troisième modèle (LLM3), pour différents formats d'invite et types d'ensembles de données, montre que les chemins d'accès au menu aplatis ont systématiquement surpassé les descriptions hiérarchiques, et que la précision a légèrement diminué avec les entrées en langage paraphrasé ou informel.

Cette tendance s'est poursuivie avec l'ensemble de données plus important et plus diversifié sur le plan linguistique, où la version aplatie a de nouveau obtenu de meilleurs résultats, avec un score de 86,52 % contre 77,07 % pour le format descriptif.

L'article note que ces résultats suggèrent que des invites plus simples, basées sur des listes, ont aidé le modèle à faire correspondre les requêtes de manière plus fiable que les longues descriptions hiérarchiques.

La précision a également légèrement diminué lorsque des messages paraphrasés et informels ont été introduits, ce qui indique que si une plus grande variété a renforcé le réalisme, elle a également rendu la classification plus difficile.

L'article conclut :

« Nos résultats démontrent que les LLM acheminent les intentions des clients avec plus de précision lorsqu'ils sont fournis avec des chemins IVR aplatis (jusqu'à 89,13 %) par rapport à des descriptions de menu détaillées (aussi basses que 77,07 %). Cela suggère que les invites concises et structurées réduisent le bruit et sont mieux adaptées aux tâches d'acheminement.

Cela confirme l'idée que la clarté et la concision améliorent les performances des LLM dans les scénarios de classification.

De plus, la conversion des menus en chemins simplifiés est un processus simple et automatisable pour une mise en œuvre dans le monde réel. »

Conclusion

Il est encourageant de voir émerger des recherches ouvertes dans un domaine généralement caractérisé par le secret et l'exclusivité. Une question clé demeure : les futurs systèmes nécessiteront-ils des architectures de « cadrage » pour contextualiser les LLM, ou les modèles auront-ils simplement besoin d'accéder à des informations commerciales disponibles localement, éliminant ainsi la nécessité pour les entreprises de partager leurs données avec des tiers ?

En fin de compte, les principes de conception fondamentaux explorés ici semblent susceptibles d'être naturellement adoptés par les futurs systèmes d'IA, même au-delà du service client, sans nécessiter d'adaptation spécifique pour ce cas d'utilisation.

* Veuillez consulter le document source pour plus de détails.

Publié pour la première fois le mercredi 29 octobre 2025.