Comment les tests A/B renforcent l'intelligence des agents

Pour les équipes qui déploient des agents vocaux, le schéma est bien connu : on change de modèle, on redéploie, on écoute quelques appels et on décrète que c'est une amélioration. Se fier au ressenti est un raccourci tentant, surtout quand les changements semblent mineurs. C'est aussi ainsi que des régressions passent inaperçues jusqu'en production.

La première vague de l'ère agentique consistait à faire fonctionner les agents. Nous sommes désormais dans la deuxième vague, celle où les agents pilotent de véritables processus économiques, et la question n'est plus peuvent-ils faire le travail mais quelle version le fait le mieux. Cette question a une réponse bien établie dans le reste de l'industrie logicielle : les expériences contrôlées.

Cet article explique comment nous menons des expériences chez HappyRobot, et certains des défis qui apparaissent précisément lorsque l'objet de l'expérience est un agent. Nous détaillerons une expérience réelle de bout en bout : un changement de voix Text-to-Speech (TTS) ayant produit une hausse relative de 20 % sur un indicateur métier principal pour un grand opérateur télécoms, puis nous aborderons les défis statistiques qui surgissent à mesure que les agents deviennent plus difficiles à améliorer.

Pourquoi c'est plus difficile qu'il n'y paraît

Un agent vocal n'est pas un modèle unique que l'on soumet à un test A/B. C'est une pile technique : un transcripteur qui convertit l'audio en texte, un LLM qui décide quoi dire et quels outils appeler, un moteur TTS qui reconvertit la réponse en audio, un ensemble de prompts et de règles qui encadrent le tout, et un orchestrateur qui relie ces couches à la téléphonie. Modifier n'importe quelle couche peut faire évoluer les résultats par des chemins que le changement lui-même ne laisse pas deviner.

Les résultats qui comptent découlent aussi de conversations longues et ramifiées. Un indicateur typique, «⁠ le client a-t-il accepté de payer la montée en gamme ?⁠ » est binaire au niveau de l'appel, mais conditionné par des dizaines de décisions en amont : l'authentification a-t-elle réussi, l'appelant est-il resté en ligne, l'agent a-t-il présenté la bonne offre au bon moment. Chacun de ces éléments introduit une variance sans aucun rapport avec le changement testé. Le signal est réel, mais il est noyé dans le bruit, et plus votre indicateur agrège de sous-événements en amont, plus il vous faudra d'échantillons pour le lire correctement.

Et chaque expérience consomme du trafic de production réel. Une expérience mal exécutée n'est pas seulement statistiquement fausse : elle vous coûte dans la monnaie même qui mesure votre succès. Mises bout à bout, ces caractéristiques signifient que l'expérimentation sur les agents vocaux doit être rigoureuse d'une manière qui n'est pas toujours évidente de l'extérieur, et que cette rigueur doit s'exercer au rythme de l'activité.

Comment fonctionnent les expériences dans la plateforme HappyRobot

La fonctionnalité d'expérimentation de la plateforme HappyRobot vous permet de configurer un test A/B sur n'importe quel workflow déjà créé : définissez une variante de contrôle et une variante de traitement, choisissez une répartition du trafic et lancez. La randomisation s'effectue au niveau de l'appel. Lorsqu'un appel arrive, l'orchestrateur lui attribue une variante, et cette attribution reste valable pendant toute la durée de l'appel. Le workflow exécute la variante assignée de bout en bout et, à la fin de l'appel, le résultat est inscrit dans le Contexte du client, sa couche de données : le client a-t-il accepté de payer, un chargement a-t-il été réservé, un rendez-vous a-t-il été planifié avec succès. Ce résultat est l'unité sur laquelle porte la mesure de l'expérience.

Le même mécanisme fonctionne quel que soit le canal : appels vocaux, fils d'e-mails, conversations WhatsApp / SMS ou chatbot. Tout ce que l'agent peut exécuter peut faire l'objet d'une répartition du trafic. Dans cet article, nous nous concentrons sur la voix, mais les primitives d'expérimentation restent les mêmes.

Vous désignez à l'avance un indicateur principal, et c'est sur celui-ci que vous prenez la décision. Tout le reste est diagnostique. Nous expliquerons plus loin pourquoi cette distinction est importante.

Une expérience réelle : 20 % de montées en gamme en plus

Nous avons soumis à un test A/B la voix Text-to-Speech (TTS) utilisée par un agent opéré pour un grand opérateur télécoms. L'agent appelle les clients existants qui dépensent trop avec leur forfait actuel et paient régulièrement des frais de dépassement, par exemple sur les données, afin de leur présenter un forfait mieux adapté et d'obtenir leur accord pour la montée en gamme, par téléphone, par lien web ou par tout autre canal pris en charge par le workflow.

• Contrôle : Voix A (la voix propriétaire en production au début de l'expérience)
• Traitement : Voix B et Voix C (deux voix propriétaires que nous souhaitions évaluer)
• Durée : Trois semaines
• Indicateur principal : upgrade_accepted

Voix B

Choisir le bon indicateur principal

La tentation, lorsqu'on évalue un changement de TTS, est de mesurer ce qui semble lié à la voix : interruptions, latence, notes de naturel, mots par minute. Ce sont tous des indicateurs réels et nous les suivons. Mais aucun d'eux n'est celui sur lequel vous devriez fonder votre décision.

Le bon indicateur principal est le plus proche possible du résultat économique réel qui vous importe. Pour ce client, ce résultat est le montant effectivement payé. Nous ne pouvons pas observer directement le paiement au moment où l'appel se termine — les paiements se règlent plus tard, parfois plusieurs jours après — nous utilisons donc le meilleur indicateur indirect disponible pendant l'appel : le client a-t-il accepté de payer au cours de l'appel. Nous disposons de sous-indicateurs qui détaillent ce résultat (upgrade_accepted_by_phone, upgrade_accepted_by_web), mais la décision se prend sur l'agrégat. La répartition par canal est intéressante ; c'est le résultat global qui compte.

Les indicateurs secondaires (nous avons suivi customer_engaged_with_agent et plusieurs autres) ne déterminent pas la décision. Ils déterminent l'expérience suivante. Si l'indicateur principal évolue, les indicateurs secondaires nous aident à comprendre pourquoi. S'il n'évolue pas, ils nous aident à concevoir la prochaine tentative.

Résultats

Deux enseignements, pas un. Le plus évident : la Voix B est nettement meilleure que la voix en production. Une hausse de 2,67 points de pourcentage sur une base de 13,01 % représente une amélioration relative de 20 % sur l'indicateur qui compte réellement pour l'entreprise, maintenue sur trois semaines de trafic de production réel. Au volume de ce client, c'est un chiffre significatif.

L'enseignement moins évident : la Voix C aurait coûté à l'entreprise environ 7 % de ses montées en gamme si nous l'avions déployée à l'intuition. Le risque du pilotage au ressenti n'est pas de passer à côté des gagnants. C'est de déployer des perdants sans jamais le découvrir.

Pourquoi la Voix B l'a emporté

L'indicateur secondaire que nous suivions en parallèle de upgrade_accepted était customer_engaged_with_agent, c'est-à-dire si l'appelant s'engageait réellement avec l'agent plutôt que de décrocher dès le début. Il raconte une histoire cohérente :

L'engagement évolue dans le même sens que la métrique principale, et la Voix B obtient l'essentiel de son gain en début d'appel, avant même que le contenu propre à l'offre ne soit énoncé. C'est un indice fort que la première impression produite par la voix compte : son degré de naturel dans les premières secondes détermine si l'appelant reste en ligne assez longtemps pour entendre la suite.

En examinant un échantillon de transcriptions et d'enregistrements d'appels au regard des métriques secondaires, deux facteurs se dégagent comme moteurs probables :

• Naturel sans théâtralité. La Voix B occupe un juste milieu : conversationnelle et proche d'une voix humaine, sans la prosodie sur-expressive que recherchent certaines voix TTS modernes. Le gain d'engagement, concentré sur les premières secondes de l'appel, va dans ce sens : si une voix sonne clairement comme un bot ou clairement comme une performance théâtrale, les appelants décrochent avant que l'agent n'arrive au fond du sujet.
• Prononciation des entités. La Voix B s'est révélée nettement meilleure pour prononcer les chaînes complexes : numéros de compte, montants en dollars, adresses e-mail, codes de référence. Pour un cas d'usage où l'agent énonce les frais de dépassement exacts et le prix de la nouvelle offre, ce n'est pas cosmétique. Des chiffres mal lus amènent les appelants à demander une répétition, ce qui coûte du temps et augmente le risque de raccrochage précoce.

Le second facteur est celui qui échappe à qui ne mesure pas la bonne chose. Il n'apparaît pas dans une note de naturel. Il apparaît dans upgrade_accepted.

Les défis statistiques de l'optimisation des agents

Tout ce qui précède décrit une expérience propre et à fort signal. La question intéressante est ce qui se passe une fois les gains faciles épuisés, lorsque vos agents sont déjà optimisés et que les gains visés sont de 1 à 2 % au lieu de 20 %. C'est dans ce régime que se concentre l'essentiel du travail technique.

Estimer la durée d'une expérience

Avant de lancer une expérience, il vaut la peine d'estimer sa durée nécessaire. Les paramètres sont classiques : le taux de référence de la métrique que vous cherchez à faire évoluer (p), la taille d'effet minimale qui vous intéresse (δ, la MDE), la puissance statistique visée et le seuil de signification. Pour un résultat binaire comparé entre deux variantes de taille égale, un calcul d'ordre de grandeur utile est :

Insérez les valeurs et vous obtenez la taille d'échantillon requise par variante ; divisez par votre volume d'appels quotidien et vous obtenez la durée de l'expérience.

Des MDE plus petites exigent beaucoup plus de données. Diviser par deux l'effet détectable quadruple la taille d'échantillon requise (notez le δ² au dénominateur). Détecter un gain de 1 pp sur la même base de 22 % aurait exigé environ 10 fois la taille d'échantillon nécessaire pour détecter un gain de 3 pp. Ce n'est pas une bizarrerie propre à un dispositif particulier : c'est la géométrie de la puissance statistique. Mais cela a une conséquence : à mesure que les agents s'améliorent, le coût de chaque expérience suivante augmente, et vite.

Le problème de la MDE, et pourquoi la réduction de variance compte

Voici la boucle dans laquelle nous voulons que chaque client s'inscrive : déployer un agent, mener des expériences pour l'améliorer, déployer les gagnantes, mener d'autres expériences, recommencer. Plus cette boucle tourne vite, plus la courbe est raide.

Ce qui ralentit la boucle, c'est la puissance statistique. Une équipe opérant à fort volume sur des gains importants peut itérer chaque semaine. Une équipe travaillant sur de faibles gains — disons une amélioration de 1 % sur une métrique déjà optimisée — peut avoir besoin de plusieurs mois par expérience au même niveau de trafic. Ce n'est plus de l'itération. C'est de l'attente.

Vous disposez de trois leviers. Vous pouvez augmenter le trafic (limité par le nombre de clients réels existants). Vous pouvez allonger la durée (limitée par le nombre d'expériences qui tiennent dans un trimestre). Ou vous pouvez réduire la variance de votre estimateur, afin que les mêmes données portent davantage d'information sur le véritable effet du traitement.

Le troisième levier est celui où se trouvent les techniques intéressantes. L'intuition est simple : une partie de la variance de votre métrique de résultat n'est pas causée par votre traitement, mais par des éléments déjà vrais au sujet de l'appel avant l'affectation du traitement. Le comportement antérieur du client, l'heure de la journée, la langue de l'appel, le modèle LLM. Si vous parvenez à expliquer cette variance préexistante, ce qui reste se rapproche d'une lecture propre de l'effet du traitement, et vos intervalles de confiance se resserrent gratuitement.

Quelques-unes des techniques auxquelles nous recourons, par ordre de complexité croissante :

Régression multivariée. La démarche la plus simple. Au lieu de comparer les moyennes brutes entre contrôle et traitement, vous régressez le résultat sur l'indicateur de traitement et un ensemble de covariables dont vous savez qu'elles prédisent le résultat : langue, heure de la journée, segment client, taux de conversion antérieur. Le coefficient de l'indicateur de traitement est votre estimation d'effet et, tant que les covariables ne sont pas elles-mêmes affectées par le traitement, l'estimation est sans biais et de variance plus faible que la simple différence de moyennes.

CUPED. Controlled-experiment Using Pre-Experiment Data. La covariable est le résultat de la même unité mesuré sur une période antérieure à l'expérience. Par exemple, le taux de réservation historique du transporteur de fret précis que vous appelez. L'intuition est simple : si un appel convertit ou non, c'est en partie simplement parce que vous parlez à ce transporteur, qui réserve déjà à un certain taux quelle que soit la voix utilisée par l'agent. CUPED soustrait cette variation préexistante, laissant une lecture plus nette de l'effet du traitement. La méthode est asymptotiquement équivalente à une régression avec cette seule covariable, et c'est le cheval de bataille de la réduction de variance dans la plupart des grands programmes d'expérimentation. Facile à mettre en œuvre, difficile à rater, elle procure souvent 20 à 50 % de réduction de variance gratuitement lorsque le comportement historique est prédictif.

CUPAC. Control Using Predictors as Covariates. Même idée que CUPED, mais la covariable est la prédiction d'un modèle de ML entraîné sur des données antérieures à l'expérience plutôt qu'une simple moyenne historique. CUPED peut être vu comme le cas particulier où ce modèle de ML est une simple moyenne par unité ; CUPAC le généralise à tout prédicteur que vous pouvez ajuster sur des données pré-expérimentales. Lorsque la relation entre covariables et résultat est non linéaire — ce qui est souvent le cas pour les agents vocaux, où les résultats dépendent d'interactions entre les caractéristiques de l'appelant, le moment et l'historique — un prédicteur flexible (des arbres à gradient boosté, par exemple) peut apporter une réduction de variance supplémentaire significative par rapport à CUPED.

L'écueil commun à toutes ces méthodes : la covariable ne doit pas être affectée par le traitement. Si elle l'est, vous introduisez un biais dans l'estimation. Les données pré-expérimentales sont la source la plus sûre. Tout ce qui est observé pendant l'expérience est suspect, sauf si vous pouvez démontrer que l'affectation n'a pas pu l'influencer. Par exemple : la durée d'appel est tentante comme covariable — elle est prédictive des résultats et facile à mesurer — mais une meilleure voix TTS qui maintient l'engagement des appelants plus longtemps décalera mécaniquement la durée d'appel dans le bras de traitement. L'ajustement sur cette variable annulerait en partie l'effet que vous cherchez à mesurer.

Pour l'exposé de référence de ces méthodes, incluant une simulation claire les comparant dans des scénarios linéaires, non linéaires et antagonistes, nous recommandons l'article de Bouzas et Masip sur le blog Glovo Engineering.

Les métriques bruitées exigent plus de données qu'on ne le croit

Certaines métriques sont bien sages. La latence par énoncé ou le nombre de mots par minute, par exemple, présentent une distribution resserrée : vous échantillonnez quelque chose de proche d'une grandeur physique stable, et la variance reste bornée.

Les métriques qui comptent vraiment ne sont généralement pas celles-là. Une métrique principale comme upgrade_accepted est binaire à l'échelle de l'appel, mais le chemin vers ce résultat binaire agrège de nombreux sous-événements : l'interlocuteur a-t-il décroché, l'authentification a-t-elle réussi, l'agent a-t-il présenté la bonne offre, l'interlocuteur est-il resté engagé assez longtemps pour l'entendre. Chacun de ces éléments est une loi de Bernoulli avec sa propre variance, et plus votre métrique se situe en aval de l'entonnoir, plus elle hérite de la variance en amont. Les métriques de résultat business agrégées sont plus bruitées que les métriques instantanées qui semblent « plus scientifiques » — mais ce sont aussi les seules directement liées à l'économie de l'activité.

La bonne décision n'est pas de les abandonner. C'est de prévoir les données qu'elles exigent : des expériences plus longues, un ajustement des covariables plus rigoureux, et la discipline de ne pas jeter un œil aux chiffres cumulés lorsque les chiffres quotidiens sont encourageants.

Pourquoi cela se cumule

Un agent humain qui passe des appels de recouvrement s'améliore avec le temps, mais de façon linéaire. Il apprend le script, intègre les objections, puis plafonne. Un système agentique optimisé par des expériences contrôlées n'a pas cette limite. Chaque expérience mise en production relève définitivement le plancher pour tous les appels suivants. L'expérience suivante se mesure à la Voix B devenue le nouveau témoin, et les améliorations se cumulent.

Ce qui détermine la vitesse d'ascension de cette courbe n'est ni la taille du modèle ni l'ingéniosité d'une intervention isolée. C'est le rythme auquel vous pouvez mener des expériences fiables. L'intelligence cumulative n'est que le nom de ce qui se produit lorsque cette boucle tourne proprement, semaine après semaine : le trafic de production cesse d'être un coût d'exploitation pour devenir l'intrant d'un système qui s'améliore de manière monotone sur ce que l'entreprise paie réellement.

Références :

• Réduction de la variance dans les expériences par des techniques d'ajustement des covariables — Bouzas et Masip, Glovo Engineering.
• Autoresearch - Andrej Karpathy