Construire un Assistant Vocal Interactif

Du prototype à l’assistant vocal en production

Vous savez configurer une session Voice Agent et produire de l’audio avec le TTS. Reste à assembler ces briques dans un produit qui tient devant de vrais utilisateurs. Trois architectures reviennent constamment — le navigateur, le mobile, la borne interactive — et chacune impose ses contraintes techniques bien avant que la qualité du modèle n’entre en jeu.

L’assistant web dans le navigateur

C’est le point de départ le plus fréquent : un bouton micro dans une application existante, l’utilisateur parle, l’assistant répond à voix haute. Le cycle technique se déroule ainsi :

1. L’utilisateur clique sur le bouton : vous démarrez la capture audio via MediaRecorder ou AudioWorklet
2. L’audio capturé est converti en PCM base64 et envoyé au Voice Agent via WebSocket
3. Le VAD serveur détecte la fin de la parole et génère une réponse
4. Les chunks audio de réponse arrivent via response.output_audio.delta
5. Vous les décodez et les jouez via AudioContext

Les difficultés viennent rarement de cette boucle, mais du navigateur lui-même. Safari exige que l’AudioContext soit créé à l’intérieur d’un gestionnaire d’événement utilisateur : instanciez-le au premier clic sur le bouton micro, pas au chargement de la page, sinon vous obtenez un contexte suspendu et un silence complet. La politique d’autoplay va dans le même sens : aucune lecture audio ne démarrera sans interaction préalable, ce qui interdit le message d’accueil joué automatiquement à l’arrivée sur la page. Côté format, restez sur PCM ou MP3 en sortie, car mulaw et alaw ne sont pas lisibles nativement par le navigateur. Et la clé API ne descend jamais dans le code client : elle reste sur votre serveur, remplacée côté navigateur par un token éphémère (leçon 13).

La capture mérite aussi son réglage :

const stream = await navigator.mediaDevices.getUserMedia({
  audio: {
    sampleRate: 24000,
    channelCount: 1,
    echoCancellation: true,
    noiseSuppression: true
  }
});

L’annulation d’écho et la suppression de bruit ne sont pas des raffinements. Sans elles, le micro réentend la réponse de l’assistant sortant des haut-parleurs, le VAD interprète cela comme une prise de parole de l’utilisateur, et l’agent se coupe lui-même en boucle. Testez toujours sans casque : c’est dans cette configuration que l’effet Larsen apparaît.

L’assistant mobile

Sur React Native ou Flutter, le principe reste identique mais l’environnement se durcit. Passez par les API natives de capture — AVAudioEngine sur iOS, AudioRecord sur Android — plutôt que par une abstraction générique : la qualité du signal d’entrée conditionne directement la reconnaissance. Prévoyez une reconnexion automatique, car le WebSocket tombe dès que l’application passe en arrière-plan, ce qui arrive à la première notification reçue pendant une conversation.

Deux points échappent souvent aux tests en salle. Le routage audio d’abord : haut-parleur ou écouteur, le comportement attendu diffère selon que l’utilisateur tient le téléphone à l’oreille ou le pose sur une table. Le Bluetooth ensuite, dont la latence propre s’empile sur celle du réseau et du modèle ; une conversation fluide avec le micro intégré devient parfois hachée avec des écouteurs sans fil.

La borne interactive

Pour un kiosque en magasin, un comptoir d’hôtel ou une salle de musée, la contrainte dominante devient l’environnement sonore. Un micro cardioïde, directionnel, limite la captation à la personne qui se tient devant la borne. Dans le même esprit, montez le threshold du VAD à 0,9 ou au-delà pour que le brouhaha ambiant ne déclenche pas de tour de parole fantôme. Quand le lieu est vraiment bruyant — un hall de gare, un salon professionnel —, le mode push-to-talk avec un bouton physique reste plus fiable que n’importe quel réglage de détection automatique.

Pensez enfin à fermer les sessions après deux à trois minutes d’inactivité : un visiteur qui s’éloigne sans conclure laisse sinon une session ouverte qui consomme vos ressources et occupe un de vos créneaux simultanés.

Les patterns communs aux trois architectures

Le Voice Agent conserve l’historique de la conversation pendant toute la session. Vous pouvez l’amorcer avant le premier mot en injectant le contexte utile — identité du client connecté, commande en cours — avec conversation.item.create :

{
  "type": "conversation.item.create",
  "item": {
    "type": "message",
    "role": "system",
    "content": [
      {
        "type": "text",
        "text": "Le client connecte est Marie Dupont, numéro client C-4521. Elle a une commande en cours CMD-8834."
      }
    ]
  }
}

L’agent cesse alors de demander à l’utilisateur des informations que votre application possède déjà, ce qui raccourcit chaque conversation d’une bonne dizaine de secondes.

Pour que l’assistant prenne la parole en premier, insérez un message initial puis déclenchez la réponse :

{
  "type": "conversation.item.create",
  "item": {
    "type": "message",
    "role": "user",
    "content": [{ "type": "text", "text": "Bonjour" }]
  }
}

Un { "type": "response.create" } envoyé dans la foulée provoque le message d’accueil.

Reste le retour visuel, traité en dernier alors qu’il pèse lourd sur la perception. Affichez un indicateur pendant que l’agent parle — onde sonore, avatar animé — et un autre pendant la capture. Sans ce signal, l’utilisateur ignore s’il doit parler, si on l’entend ou si l’application a planté, et il finit par parler en même temps que l’agent.

Points clés à retenir

• Trois architectures principales : web, mobile et kiosque, chacune avec ses contraintes spécifiques
• La gestion audio dans le navigateur nécessite des précautions (Safari AudioContext, autoplay policy)
• Pré-remplissez le contexte conversationnel avec conversation.item.create pour personnaliser l’expérience
• Un message d’accueil et du feedback visuel améliorent significativement l’expérience utilisateur