Barge-in : pourquoi pouvoir couper la parole à un agent vocal change la conversation

Le terme est déjà employé pour les serveurs vocaux interactifs. La recommandation VoiceXML 2.0 du W3C, publiée le 16 mars 2004, le décrit ainsi : si la plateforme le permet, l'auteur de l'application choisit si l'utilisateur peut interrompre une annonce par la voix ou par une touche du clavier. Le texte note que cela accélère les conversations, mais que ce n'est pas toujours souhaitable : pour un avertissement ou une mention légale qui doit être entendue en entier, le barge-in doit être désactivé.

Les plateformes conversationnelles actuelles ont repris la notion. Dans Dialogflow CX, la documentation de Google indique que, lorsque le barge-in est activé, l'utilisateur peut interrompre l'audio de la réponse : l'agent arrête alors d'envoyer l'audio et traite la nouvelle entrée. Amazon Lex V2 permet de choisir, pour chaque information demandée par le bot, si l'utilisateur peut l'interrompre pendant qu'il parle.

Entre deux personnes, on se coupe pour corriger (« non, mardi, pas mercredi »), pour répondre avant la fin de la question ou pour signaler qu'on a compris. Un agent qui déroule sa phrase jusqu'au bout pendant que l'appelant parle oblige celui-ci à répéter, et donne l'impression de parler à un mur.

La documentation d'Amazon Lex cite un cas d'usage : l'utilisateur qui connaît déjà la réponse à la question posée, par exemple lorsqu'on lui demande le code de sécurité de sa carte. La recommandation VoiceXML souligne un autre effet : arrêter l'annonce le plus tôt possible évite l'effet de « bégaiement », où l'utilisateur s'arrête au milieu de sa phrase et recommence parce qu'il ne pense pas avoir été entendu.

VoiceXML distingue deux types de barge-in. Avec le type « speech », l'annonce s'arrête dès qu'une parole ou une touche est détectée, que l'entrée corresponde ou non à ce qui est attendu. Avec le type « hotword », l'annonce continue tant qu'une expression attendue n'a pas été entièrement reconnue, et tout le reste est ignoré.

Le compromis est le même aujourd'hui : réagir vite au risque de s'interrompre pour rien, ou attendre une parole significative au risque de paraître lent. Dans l'API Realtime d'OpenAI, le paramètre interrupt_response détermine, selon la référence de l'API, si une réponse en cours est automatiquement interrompue lorsque la détection d'activité vocale signale un début de parole. Le mode semantic_vad, selon la documentation, rend le modèle moins susceptible d'interrompre l'utilisateur, et le paramètre eagerness règle l'empressement du modèle à interrompre l'utilisateur.

Pour être interrompu, l'agent doit écouter pendant qu'il parle. Or sa propre voix peut revenir dans le signal capté, par exemple quand l'appelant utilise le haut-parleur de son téléphone. Sans traitement, le système risque de prendre sa propre voix pour une interruption.

La spécification W3C Media Capture and Streams définit l'annulation d'écho comme le fait de retirer, du signal enregistré par le micro, le son qui est en train d'être joué. Côté réseaux téléphoniques, l'Union internationale des télécommunications consacre une recommandation entière, G.168, aux annuleurs d'écho des réseaux numériques. Le barge-in n'est fiable que si cette étape fonctionne.

La détection d'activité vocale (VAD) décide quand quelqu'un parle. La documentation de Deepgram reconnaît qu'un bruit de fond important, comme de la musique ou une sonnerie de téléphone, peut déclencher la VAD et empêcher la détection du silence qui marque la fin d'une phrase. Elle propose une alternative fondée sur l'écart entre les mots transcrits, qui ignore les sons non vocaux comme des coups frappés à une porte, une sonnerie de téléphone ou le bruit de la rue.

OpenAI indique de son côté qu'un seuil d'activation plus élevé exige un son plus fort pour déclencher le modèle, ce qui peut mieux fonctionner en environnement bruyant, et qu'une durée de silence plus courte fait détecter les fins de tour plus vite. Ce sont des réglages, pas des solutions universelles, et chacun a son revers : un seuil trop haut risque de faire manquer les voix faibles, un silence trop court de couper la parole à quelqu'un qui réfléchit.

Le barge-in a aussi un coût. Google précise que, dans Dialogflow CX, l'activer augmente la durée facturable de chaque tour, puisque l'agent écoute pendant qu'il parle.

Quelques essais suffisent à se faire une idée : couper l'agent au milieu d'une phrase pour corriger une date, appeler en haut-parleur, appeler avec une radio allumée, glisser un « d'accord » pendant qu'il parle, marquer une longue pause avant de finir sa phrase. Notez à chaque fois si l'agent s'arrête, s'il reprend correctement et s'il a compris la correction. Alyas répond au téléphone 24 h/24 à partir des informations que vous lui fournissez et dépose une transcription et un résumé de chaque appel dans votre espace client, ce qui permet de relire ces essais. L'essai gratuit de dix jours, sans carte bancaire, permet de mener ces tests sur vos propres scénarios.