Tests A/B

Un test A/B répartit le trafic téléphonique réel d'un agent entre deux versions enregistrées de cet agent : la version actuellement live (le champion, bras A) et n'importe quelle autre version enregistrée (le challenger, bras B). Les appels sont affectés à un bras au fil de leur arrivée, les résultats de chaque bras s'accumulent séparément, et une page de rapport compare les deux côte à côte. Quand vous en avez vu assez, vous promouvez le gagnant ou vous arrêtez le test ; l'arrêt renvoie instantanément tous les appels vers la version live.

Comment ça marche

Un test appartient toujours à un seul agent et épingle deux versions de son historique. Cet épinglage compte : une version est un instantané immuable, donc « le bras B a fait moins bien » désigne toujours une configuration qui existe encore et peut être rouverte. Pendant que le test tourne :

  • Chaque appel entrant est routé vers le bras A ou le bras B selon la répartition de trafic que vous avez choisie.
  • Le pointeur de version live n'est jamais touché. Le test possède le routage pendant qu'il tourne, et c'est exactement pourquoi l'arrêter n'exige aucun retour arrière : dès l'appel suivant, 100 % du trafic suit à nouveau la version live.
  • Avec l'option sticky recommandée, un même numéro appelant atteint toujours le même bras : un appelant qui rappelle ne remarque jamais un changement de personnalité entre deux appels. Les appels en numéro masqué retombent sur un tirage aléatoire pondéré.

Les appels entrants et les appels de campagne sont répartis. Chaque appel téléphonique entrant et chaque appel composé par une campagne est affecté à un bras, et un contact qui rappelle tombe sur le même bras que l'appel qui l'a atteint, de sorte qu'une personne entend toujours une seule version. Les appels du simulateur navigateur et les appels créés par API ne sont jamais affectés : ils n'apparaissent pas dans les chiffres du rapport et ne portent aucun badge de bras. Sur un agent qui exécute des campagnes, les deux versions testées doivent définir un nœud Start Outbound, sinon le test refuse de démarrer. Quand un bras reçoit du trafic de campagne, le rapport ajoute des lignes campagne : appels, taux de joignabilité, taux de transfert, rappels reçus, messagerie vocale, durée moyenne et objectifs atteints.

Démarrer un test

Le bouton Start A/B test se trouve dans le rail d'historique des versions de l'éditeur d'agent, juste sous la carte de la version live. Il apparaît dès que l'agent a une version live et qu'aucun test n'est déjà en cours (un seul test en cours par agent, et deux bras, toujours).

Démarrage d'un test A/B depuis le rail d'historique des versions

La fenêtre de démarrage demande :

ChampSignification
Nom du testRequis, 120 caractères maximum. Prérempli avec la date, par exemple A/B test 2026-08-24.
A, Champion (live)Lecture seule. Le champion est toujours la version live au moment où vous cliquez Start test.
B, ChallengerN'importe quelle version enregistrée autre que la version live. Par défaut, la version chargée dans l'éditeur, sinon la version non-live la plus récente.
Répartition du traficUn curseur de 1 % à 99 % pour le challenger ; le champion reçoit le reste. La valeur par défaut est un prudent 90 % A / 10 % B : une petite part sur le challenger limite les dégâts s'il s'avère moins bon.
Un même appelant reçoit toujours la même versionL'option sticky, activée par défaut et recommandée (voir plus haut).
Arrêt à une date / après N appelsLes deux sont optionnels. Laissez les deux vides pour laisser tourner le test jusqu'à un arrêt manuel ; si vous renseignez les deux, le premier atteint termine le test. Atteindre une condition d'arrêt ne promeut jamais un gagnant : vous examinez les résultats et vous décidez.

Les deux bras doivent passer les mêmes gardes que Make live : une version sans modèle LLM (quand le flux en exige un) ou sans nœud de départ ne peut pas prendre d'appels, donc pas entrer dans un test non plus.

Pendant que le test tourne

  • Le rail affiche un bandeau de test en cours : nom du test, répartition, nombre d'appels routés, plus View results et Stop test.
  • Les deux versions épinglées portent un badge de bras violet (A 50% / B 50%) dans la liste des versions, et leur action Delete disparaît : une version en cours de mesure ne peut pas être supprimée avant la fin du test.
  • Sur la liste des appels, chaque appel routé par un test A/B affiche un badge A ou B à côté du nom de l'agent, et la barre de filtres gagne un sélecteur All A/B arms / Arm A / Arm B qui filtre aussi le bandeau de KPI et l'export CSV.
  • La page de statistiques de l'agent gagne un onglet A/B Tests listant chaque test avec son statut, sa répartition, son nombre d'appels et un lien View results. Cet onglet ignore délibérément le filtre de période de la page : la fenêtre d'un test est sa propre durée de vie.

Modifier l'agent et cliquer Make live sur une troisième version pendant qu'un test tourne ne change pas ce qu'entendent les appelants : les bras sont des instantanés épinglés et le test possède le routage. La version nouvellement promue ne prend la main qu'à la fin du test.

Lire le rapport

La page de rapport (via View results) compare les deux bras métrique par métrique. La meilleure cellule est mise en avant sur chaque ligne où « meilleur » a un sens ; la durée moyenne et le taux de transfert ne sont délibérément pas jugés, car des appels plus longs ou des transferts peuvent être exactement ce que vous recherchez.

Rapport de test A/B avec les KPI des deux bras côte à côte
MétriqueCe qu'elle mesure
CallsAppels routés vers le bras. Toujours affiché : c'est la référence du plancher d'échantillon.
CompletedPart des appels du bras terminés avec le statut Completed.
Objectives reachedObjectifs atteints sur objectifs évalués, sur l'ensemble des appels du bras. Affiché seulement quand l'agent a des objectifs configurés.
Quality scoreScore de qualité moyen. Une petite note apparaît quand moins de 5 appels ont été notés.
Average lengthDurée moyenne des appels décrochés uniquement.
TransferredPart des appels terminés par un transfert.
Cost per callCoût total moyen (appel + LLM + transfert) sur les appels qui ont un coût.

Le rapport est délibérément honnête sur la taille d'échantillon :

  • Toutes les métriques sauf Calls restent masquées tant que chaque bras n'a pas au moins 10 appels ; un bandeau nomme le bras trop mince.
  • Quand les taux de complétion des deux bras sont statistiquement indiscernables, le bandeau le dit en clair : la différence est dans la marge d'erreur.
  • Pendant que le test tourne, une projection estime en combien de jours le plus petit bras atteindra 100 appels à la répartition et au volume actuels.
  • Il n'y a ni p-value ni badge « significatif », à dessein : les volumes sont modestes, les tests s'arrêtent à la main, et l'affectation sticky rend les appels d'un même appelant non indépendants. Traitez le rapport comme une aide à la décision, pas comme un moteur statistique.

Une carte Versions this arm has run apparaît sous un bras lorsqu'il a servi plus d'une version au cours du test, typiquement après un repointage (voir plus bas). C'est aussi là qu'une version inattendue apparaît si une version épinglée n'a pas pu être résolue et que la plateforme est retombée sur la version live.

Terminer un test

Un test se termine de l'une des trois façons suivantes, et atterrit toujours dans l'unique statut terminal Finished :

  1. Stop test (rail ou rapport). Tous les appels reviennent immédiatement à la version live ; les résultats restent consultables.
  2. Une condition d'arrêt est atteinte (date de fin ou plafond d'appels). Les conditions d'arrêt sont évaluées à l'arrivée de l'appel suivant : sur un agent peu appelé, la liste peut donc continuer d'afficher Running jusqu'à cet appel ; aucun appel n'est jamais réparti après que la condition est remplie.
  3. Make A live and finish / Make B live and finish sur le rapport : la seule action qui écrit la version live. Elle promeut la version de ce bras et termine le test dans le même clic.

L'arrêt ne promeut jamais, et atteindre une condition d'arrêt ne promeut pas non plus. La promotion est toujours votre décision explicite sur la page de rapport.

Corriger le challenger en cours de test

Si vous repérez un défaut dans le challenger pendant que le test tourne, ne le modifiez pas en écrasant : une version qui a déjà pris des appels doit continuer de signifier ce qu'elle signifiait. À la place :

  1. Corrigez la configuration dans l'éditeur et enregistrez-la (Save) comme nouvelle version.
  2. Sur le rapport, utilisez Point B at another version et choisissez la version corrigée.

Le bras B route les nouveaux appels vers la version corrigée à partir de ce moment. Les appels déjà routés gardent la version qu'ils ont réellement exécutée : une correction ultérieure ne peut jamais réécrire les résultats passés. Seul le bras B peut être repointé ; le champion reste épinglé sur ce qui était live au départ. La répartition, le nom, l'option sticky et les conditions d'arrêt ne se modifient pas après le démarrage : arrêtez le test et lancez-en un nouveau.

Garanties à connaître

  • Un test cassé ne coûte jamais un appel. Si quoi que ce soit dans le test ne peut pas être résolu au moment de l'appel (version épinglée supprimée, bras mal formés, erreur interne), l'appel est simplement routé vers la version live comme si aucun test n'existait. Vous perdez la mesure, l'appelant garde son appel.
  • Rôles : chaque membre de l'organisation peut ouvrir le rapport, l'onglet de liste et le filtre de bras ; démarrer, arrêter, promouvoir et repointer exigent un accès en écriture (Viewer exclu).
  • Les tests ne voyagent pas : un export/clonage d'agent n'inclut jamais ses tests A/B, c'est de l'état de routage propre à un environnement.