Créer des agents vocaux durables : quelques leçons tirées de l’ingénierie déployée sur le terrain

Dans la plupart des organisations, les solutions ponctuelles pour le support sont souvent évaluées selon leur capacité à réduire le nombre d’appels et à limiter les échanges avec des agents en direct. Mais réduire les contacts ne résout pas forcément les problèmes, et c’est dans cet écart que l’expérience client se détériore. Pour combler ce fossé, il faut que les agents aient accès non seulement aux données, mais aussi aux systèmes qui leur permettent d’agir. Ainsi, ils peuvent traiter des remboursements, accompagner les clients lors du paiement, ou transférer la demande à un agent humain avec tout le contexte nécessaire, selon la situation. Cela permet aux entreprises de gérer les interactions clients à grande échelle, de réduire la charge sur les équipes de support tout en améliorant l’expérience des deux côtés de l’appel.déploiement récent avec Revolut, une fintech qui sert 70 millions de clients dans le monde, cela s’est traduit par une résolution 8 fois plus rapide et un taux de réussite des appels de 99,7 %. 

Les organisations doivent aborder ces changements de façon itérative, en restant alignées sur la mission principale de l’entreprise et avec un fort soutien de la direction. Sur le plan technique, raisonner dans un environnement non structuré comporte des risques qu’il faut gérer avec soin. Donner à un agent la capacité d’agir sur le CRM, de modifier une commande dans le système de caisse ou d’escalader un dossier implique que le modèle de gouvernance est aussi important que le modèle technique lui-même. L’enjeu n’est donc plus de savoir si les agents peuvent gérer des tâches réelles, mais quels mécanismes sont nécessaires pour les déployer de façon sûre et répétée.

Dans cet article, nous partageons notre expérience sur ce qui fait le succès des agents, du premier déploiement à la montée en charge sur l’ensemble des opérations clients.

Déployer des agents vs. déployer des logiciels

Avant d’entrer dans le détail de la création d’agents, il est utile de comparer le déploiement d’agents vocaux à celui de logiciels traditionnels, une pratique courante en entreprise depuis des décennies. Sous cet angle, on peut distinguer deux grandes composantes : le logiciel traditionnel et l’orchestrateur central.

Logiciel :

Logiciel : observabilité et gouvernance

Orchestrateur central

Les composants de l’Orchestrateur principal sont par nature plus difficiles à anticiper, mais ils déterminent la performance de l’agent en temps réel, tant sur la qualité des réponses que sur la latence perçue. Contrairement aux logiciels classiques, ces composants traitent le langage naturel et l’audio, où l’espace d’entrée est quasiment infini et où de petits changements de formulation, de contexte, de bruit de fond ou de comportement utilisateur peuvent produire des résultats très différents au fil du temps. Les tests classiques ne suffisent donc pas : un agent peut réussir des centaines de cas de test et pourtant échouer en production de façon imprévisible.la gestion des versions, l’A/B testing, la téléphonie et la configuration du premier message, entre autres. Ces composants évoluent peu après le déploiement, ce qui les rend très prévisibles. Grâce à de bonnes pratiques d’ingénierie, les organisations peuvent s’appuyer rapidement sur ces fonctionnalités et garder une vision claire de leur performance en production via des métriques, traces et logs précis. Les améliorations de latence à ce niveau suivent des schémas connus : cache, pool de connexions, montée en charge de l’infrastructure et optimisation des protocoles sont des leviers fiables avec des résultats déterministes.

La latence à ce niveau est aussi moins prévisible, influencée par le temps d’inférence des modèles, l’apparition d’artefacts sonores, les chaînes d’appels d’outils et la variabilité propre aux systèmes génératifs. Bien gérer ces composants demande une autre approche, centrée sur des cadres d’évaluation, une surveillance en production et une volonté d’itérer en continu à partir de vraies conversations, plutôt que sur des hypothèses faites avant le déploiement.

Cette distinction influence la façon dont les organisations doivent aborder l’adoption : commencer par des cas d’usage pertinents mais peu risqués, puis élargir progressivement à mesure que la confiance dans le système grandit.

Cycle de publication

Choisir les bons cas pilotes

Pour les équipes qui débutent avec les agents vocaux, choisir les bons cas pilotes est l’une des décisions les plus importantes au départ. Et cela dépend moins de la technologie qu’on ne le pense. Les équipes qui obtiennent rapidement des résultats et évitent de rester bloquées en phase de POC ont un point commun : elles savent répondre clairement aux questions suivantes.

Pour les équipes qui débutent avec les agents vocaux, choisir les bons cas pilotes est l’une des décisions les plus importantes au départ. Et cela dépend moins de la technologie que ce qu’on imagine. Les équipes qui réussissent rapidement et évitent de s’enliser dans des POC interminables ont un point commun : elles savent répondre clairement aux questions suivantes.

• Comment ce cas d’usage apporte-t-il une valeur mesurable à l’entreprise ? Le bon cas d’usage pour commencer n’est pas le plus technique, mais celui qui a le plus de chances d’avoir un impact sur un objectif déjà prioritaire pour l’entreprise. Cela se mesure par l’impact sur le chiffre d’affaires, la réduction des coûts, la satisfaction client ou d’autres indicateurs déjà suivis par les responsables. Sans ce lien direct avec la valeur métier, il devient difficile de justifier les cycles d’itération nécessaires pour bien calibrer l’agent, et l’élan risque de retomber avant que la technologie ait pu faire ses preuves.
• Est-ce que les utilisateurs comprennent tout de suite le rôle et le périmètre de l’agent ? L’ambiguïté sur le périmètre est l’une des principales causes de dérive entre développement et production. Si les utilisateurs ne savent pas ce que l’agent peut ou ne peut pas faire, ils vont tester ses limites d’une façon que la suite de tests n’aura pas anticipée. Un agent bien cadré pose les attentes dès le premier message et gère les demandes hors périmètre avec clarté.
• À quoi ressemblent de bonnes ou de mauvaises interactions, et peut-on les traduire en critères d’évaluation concrets ? Une bonne interaction n’est pas seulement celle où l’agent accomplit la tâche, mais aussi celle où l’utilisateur se sent écouté, où l’escalade se fait au bon moment, et où le résultat est aligné avec l’objectif métier. Les critères d’évaluation se divisent en deux catégories : des métriques quantitatives suivies par la plateforme (taux de réussite, taux d’escalade), et des critères basés sur l’analyse des conversations. Définir ces critères dès le départ donne à l’équipe un objectif clair. Ils servent aussi de seuil naturel pour le passage en production. Quand l’agent valide régulièrement ses critères et que les métriques sont stables, on peut avancer sereinement. Sans critères définis, la mise en production devient une question de ressenti.
• Quels sont les compromis entre performance et contrôle, et lequel est prioritaire à ce stade ? Plus un agent est autonome, plus les interactions sont naturelles et flexibles, mais plus il risque de sortir du cadre validé. Un contrôle strict via des instructions limitées et une logique d’escalade rigoureuse réduit ce risque, mais peut rendre l’agent rigide. Aucun extrême n’est idéal. Les organisations trop restrictives finissent avec un simple SVI amélioré. Celles qui vont trop vite sans établir la confiance créent une charge de support qui annule les bénéfices. Savoir où placer le curseur à chaque étape va influencer la configuration du modèle, la logique d’escalade, et la répartition des connaissances de l’agent entre le prompt et les sources structurées ou récupérées.

Cadrer la première version

Pour passer à l’exécution, les équipes peuvent s’appuyer sur des méthodes éprouvées. Le Test Driven Development (TDD) sert de cadre pour garder l’agent aligné sur les métriques clés tout au long du développement.

Pour passer à l’exécution, les équipes peuvent s’appuyer sur des méthodes presque aussi anciennes que le logiciel lui-même. Le Test Driven Development (TDD) sert de cadre pour garder les agents alignés sur les indicateurs clés tout au long du développement.

Avec une première série de tests en place, le développement de l’agent commence par le prompt système. C’est là que sont définis les règles, le ton et l’approche de l’agent : ce qu’il doit faire, ce qu’il ne doit pas faire, et comment il doit réagir aux limites de son rôle. Un prompt bien conçu est aussi structuré que précis. Séparer les instructions en sections claires, regrouper les consignes liées et éviter les formulations conditionnelles font une vraie différence sur la cohérence de l’agent. À ce stade, nous revenons souvent au guide de prompt.Tests d’agent, qui vérifient de façon répétée les comportements attendus de l’agent. Les critères de réussite s’appuient sur l’analyse d’appels humains réels. Les tests d’agent se construisent progressivement, en partant d’un premier jeu de comportements attendus, puis en les enrichissant au fil des nouveaux cas et des situations limites rencontrées.

En parallèle du prompt système, les composants principaux de l’agent sont configurés : le LLM, le modèle Text to Speech (TTS) et la voix. Le choix du LLM est un compromis entre latence et performance : les modèles optimisés pour la rapidité sacrifient souvent un peu de raisonnement, et inversement. Pour le TTS, le choix dépend des besoins du cas d’usage : expressivité, faible latence ou support multilingue. La voix, elle, est autant une décision de marque que technique. Elle façonne la perception de l’organisation à chaque appel, ce qui en fait une décision qui concerne autant les équipes marketing que les ingénieurs. Le choix de la voix peut donc se faire en parallèle du reste du développement, sans devenir un blocage. ElevenAgents donne accès à plus de 10 000 voix, et si aucune ne convient, les équipes peuvent cloner ou créer la leur.

À partir de là, l’agent peut être enrichi avec une base de connaissances, des

Avec ces bases en place, l’agent est prêt à être testé.base de connaissances, des outils, et des configurations de canaux. Chaque ajout apporte de nouvelles capacités, mais élargit aussi la surface à tester. Qu’il s’agisse d’intégration téléphonique, d’accès à des bases de données externes ou de la capacité à agir pour le client, il est important de tester ces choix face aux critères d’évaluation avant d’élargir le périmètre. Lorsqu’on ajoute des outils, le prompt système et la description de l’outil donnent des instructions explicites sur quand et comment les utiliser, pour garantir leur usage cohérent et adapté.

Vers la mise en production

Avec les tests et critères d’évaluation définis lors du cadrage, le développement devient un cycle court : ajouter des tests, identifier les échecs, mettre à jour le prompt système ou la configuration, et recommencer. La plupart des échecs à ce stade ne viennent pas du modèle, mais du prompt. Une instruction qui semblait claire isolément devient ambiguë en situation réelle. Des cas limites apparaissent que la suite de tests initiale n’avait pas anticipés. Chacun devient un nouveau test Next Turn, créé à partir de la conversation elle-même. La question de savoir quand arrêter les itérations a une réponse concrète : quand l’agent valide régulièrement ses critères d’évaluation sur plusieurs cycles, et que les métriques comme le taux de réussite ou d’escalade sont stables dans les plages acceptables. C’est pourquoi il est si important de définir ces critères avant de commencer. Sans eux, la notion de « prêt » reste floue et la ligne d’arrivée recule sans cesse.

En pratique, la plupart des équipes constatent qu’un petit nombre de schémas d’échec récurrents expliquent la majorité des problèmes. Les plus courants sont l’ambiguïté du prompt (l’agent reçoit des instructions contradictoires ou incomplètes et adopte un comportement imprévisible), la mauvaise utilisation des outils (l’agent utilise un outil au mauvais moment ou oublie de l’utiliser), et la dérive d’escalade (l’agent escalade trop vite ou garde la main alors qu’il devrait passer la conversation). Chacun de ces cas se corrige au niveau du prompt : préciser l’instruction, ajouter un exemple explicite ou ajuster le seuil d’escalade suffit généralement. Le risque, c’est de ne pas les détecter avant la mise en ligne.

L’erreur la plus fréquente à ce stade est de considérer qu’une suite de tests réussie est une garantie, alors que ce n’est qu’un signal. Une suite qui ne couvre que les cas idéaux passera facilement mais ne prouvera rien. Il faut aussi tester les refus, les changements de sujet, les entrées ambiguës et les interactions complexes avec des outils pour donner du poids aux résultats. De même, les équipes qui sautent les tests de simulation et se contentent de tests au tour par tour passent à côté de certains échecs qui n’apparaissent que sur une conversation complète, comme la perte de contexte ou l’accumulation d’erreurs. Une fois les schémas d’échec récurrents corrigés et l’agent capable de gérer la majorité des cas limites de façon satisfaisante (pas parfaite), la valeur ajoutée de nouvelles itérations en préproduction diminue. À ce stade, les vraies informations viennent des conversations réelles.

Passer en production ne signifie pas que l’itération s’arrête. Cela veut dire que l’apprentissage se fait désormais sur les conversations réelles. Les critères d’évaluation qui ont servi de seuil pour la mise en ligne deviennent la base pour mesurer la performance en production, et le cycle continue.

Boucles de retour, évaluation et savoir quand arrêter d’itérer

Une fois les tests définis et lancés, les lacunes du pipeline apparaissent vite. Grâce à l’

La discipline la plus importante à ce stade est de valider chaque changement, pas de le supposer acquis. Une correction qui règle un problème peut en introduire un autre sans qu’on s’en rende compte. ElevenAgents prend en charge la gestion des versions, ce qui permet de tester de nouvelles itérations sur un petit pourcentage d’utilisateurs avant de les déployer plus largement. Cela permet de vérifier que les améliorations apportent réellement un bénéfice, et non un déplacement du problème.

Ce qui peut mal tournerla gestion des versions, ce qui permet de tester de nouvelles itérations sur un petit pourcentage d’utilisateurs avant de les déployer à grande échelle. Cela permet de vérifier que les améliorations sont réelles et n’introduisent pas de nouveaux problèmes ailleurs.

La plus grosse erreur à ce stade est de sauter les déploiements progressifs et de pousser les changements directement à tous les utilisateurs. Sans déploiement par étapes, il devient impossible d’isoler l’impact de chaque modification, et à grande échelle, il est presque impossible de comprendre ce qui améliore ou dégrade réellement les métriques de la plateforme. Utiliser l’ensemble des utilisateurs comme environnement de test n’est pas seulement risqué : cela supprime la visibilité nécessaire pour prendre des décisions éclairées.

Au-delà de la stratégie de déploiement, deux autres pièges sont à éviter. Le premier est de sur-réagir aux derniers échecs. Quand une conversation problématique survient, il est tentant de la corriger immédiatement et massivement, mais des modifications réactives du prompt sans repasser toute la suite de tests provoquent souvent des régressions sur des comportements auparavant stables. Chaque changement, même mineur, doit être traité comme une nouvelle itération et testé en conséquence. Le second est la dérive des critères d’évaluation. Avec le temps, sous la pression, les équipes peuvent baisser inconsciemment le niveau d’exigence pour valider un test. Les critères définis au cadrage doivent rester la référence. S’ils semblent trop stricts, il faut les revoir de façon délibérée, pas laisser les standards baisser sans s’en rendre compte.

Monter en charge en toute confiance

Augmenter le trafic est une décision de confiance, pas une question de calendrier. Le bon signal pour élargir, c’est quand l’agent valide régulièrement ses critères d’évaluation sur plusieurs cycles, que les métriques sont stables et que les déploiements progressifs n’ont montré aucune régression significative par rapport au groupe témoin.

Une question fréquente à ce stade est : combien d’appels faut-il pour tirer une conclusion ? Moins de 100 appels par branche produisent trop de variance pour évaluer les résultats de façon fiable. Un taux de réussite de 60 % sur 25 appels et sur 100 appels n’ont pas la même valeur. Au-delà du nombre, l’échantillon doit aussi être assez large pour couvrir toute la diversité des entrées réalistes, y compris les cas limites, les intentions rares et les échecs qui n’apparaissent qu’à grande échelle.

Plus de trafic amplifie à la fois ce qui fonctionne et ce qui ne fonctionne pas. Élargir avant d’avoir corrigé les principaux schémas d’échec crée une charge de support difficile à rattraper.

Répéter le processus

Savoir quand s’arrêter est aussi important que savoir quoi corriger. L’itération a des rendements décroissants, et le bon signal pour faire une pause, c’est quand l’agent atteint régulièrement les critères d’évaluation définis au cadrage. Au-delà, chaque changement comporte plus de risques que de bénéfices.

Ce que « valider régulièrement les critères » signifie dépend du contexte. Les équipes avec un accès limité aux données ou des intégrations incomplètes peuvent considérer qu’un taux d’escalade autour de 50 % est un plafond réaliste tant que ces contraintes ne sont pas levées. Quand l’accès aux données est bon, les meilleurs déploiements visent généralement plus de 80 % de réussite et moins de 20 % d’escalade. Plus important que le chiffre, c’est la stabilité : des performances constantes sur plusieurs semaines de trafic réel, sans régression notable sur les tests, sont le vrai signal. Quand le gain marginal d’une nouvelle itération est inférieur au risque de régression, il est temps d’arrêter.

Cela ne veut pas dire que le travail est fini. Quand de nouveaux besoins apparaissent, le processus recommence depuis le début. Les questions de cadrage de la première version restent aussi pertinentes pour la suivante. La différence, c’est qu’à la deuxième itération, l’équipe dispose déjà d’une suite de tests, d’une base d’évaluation et d’une expérience opérationnelle acquise lors du premier cycle. Cet avantage cumulatif fait la différence entre les organisations qui tirent une vraie valeur des agents vocaux et celles qui restent bloquées au stade du POC.

Conclusion

Les équipes qui réussissent à passer de la simple déviation à la résolution sont celles qui définissent ce qu’est une bonne interaction avant de commencer, gardent le cap pendant l’itération et considèrent chaque déploiement comme la base du suivant. Les agents conversationnels ne sont pas un déploiement unique : les vraies conversations font toujours émerger des cas limites qu’aucun test n’avait anticipés, et l’amélioration ne s’arrête pas à la mise en production.

ElevenAgents est conçu autour de cette réalité. Les tests d’agent, l’analyse des conversations et les déploiements progressifs sont la base qui transforme un POC en un système qui résout vraiment les problèmes clients à grande échelle – pas seulement qui les détourne. C’est cet écart qu’il faut combler.

ElevenAgents est conçu autour de cette réalité. Les tests d’agent, l’analyse de conversation et les déploiements progressifs sont les fondations qui transforment un POC en un système qui résout vraiment les problèmes clients à grande échelle – pas seulement qui les détourne. C’est cet écart qui mérite d’être comblé.