Architecture d'un agent vocal avec GPT-Live-1 : connecter la parole et la logique d'arrière-plan

La conception d’un assistant vocal a longtemps consisté à enchaîner trois briques distinctes : la reconnaissance vocale (STT), un grand modèle de langage (LLM) et la synthèse vocale (TTS). En pratique, cette cascade engendre une latence perceptible et complique la gestion d’une conversation en direct. Lorsqu’un interlocuteur marque une pause, change d’avis ou interrompt l’assistant, les développeurs doivent suivre manuellement l’état, réinitialiser le flux audio et synchroniser le contexte entre trois services différents.

Le 10 septembre 2026, OpenAI a ouvert l’accès au modèle GPT-Live-1 dans son API (annonce officielle). Au lieu d’assembler des services étape par étape, ce modèle propose une couche audio full-duplex : il est capable de recevoir simultanément le flux sonore entrant et de générer une réponse vocale.

Séparation de la parole et des calculs

Lorsque l’exécution des tâches sur le back-end prend du temps, celles-ci sont dissociées de la couche vocale afin de maintenir une interaction vocale continue. Une architecture pratique articulée autour de GPT-Live-1 repose sur une séparation des responsabilités :

1. Front-end vocal. Le modèle traite simultanément l’audio entrant et sortant. D’après les développeurs, cette approche tolère mieux les bruits de fond, les pauses et les interruptions qu’une cascade STT–LLM–TTS, tout en prenant en charge la détection native des tours de parole (turn detection).
2. Back-end d’arrière-plan. Les analyses de données complexes, les requêtes en base et les appels d’outils (tool calling) sont délégués à des modèles textuels dédiés ou à des agents externes.

Cette configuration est pensée pour permettre à l’interface de maintenir le contact avec l’interlocuteur sans rester figée dans le silence pendant que le service d’arrière-plan prépare une réponse de fond. Pour autant, la latence réelle et la fluidité des transitions doivent toujours être vérifiées sur votre environnement technique spécifique.

Le fonctionnement de la délégation de tâches

La voix et le back-end fonctionnent de manière asynchrone. Quand un utilisateur demande le statut d’une commande ou une recherche dans un dépôt, l’application orchestre l’envoi de la tâche vers son back-end.

La documentation officielle fournit un exemple conceptuel d’une telle coordination à l’aide du Codex SDK :

import { Codex } from "@openai/codex-sdk";

const thread = new Codex().startThread({
  workingDirectory: "./repo",
  sandboxMode: "read-only",
  approvalPolicy: "never",
});

async function answer(live, delegationId, context) {
  const { finalResponse } = await thread.run(
    `Answer the latest question using this repo.
     Reply in two short spoken sentences.\n${context}`
  );

  live.send({
    type: "session.commentary.append",
    delegation_id: delegationId,
    content: finalResponse,
  });
}

Le code ci-dessus n’est qu’un extrait officiel d’intégration : l’initialisation de la connexion et le traitement des événements de délégation sont omis, il n’est donc pas conçu pour être exécuté de manière autonome.

Cet extrait illustre le principe général d’interaction : l’application transmet le contexte de la réplique au thread de travail de l’outil, puis réinjecte la réponse obtenue dans la session audio via un événement session.commentary.append. Le canal vocal reste actif, ce qui permet à l’agent de prononcer au besoin une courte phrase d’introduction pendant que le back-end termine ses calculs.

Critères de choix de l’architecture

À la date de publication, le coût de la couche vocale s’élève à $0.05 par minute, ce qui n’inclut pas les dépenses liées aux modèles d’arrière-plan ni aux appels d’outils. Cette architecture est pertinente dans les scénarios où la continuité du dialogue est essentielle :

• Appels téléphoniques et prise de rendez-vous. Processus dans lesquels toute pause artificielle entre les répliques incite le client à demander si on l’entend toujours.
• Assistance aux échanges spontanés. Dialogues où les interlocuteurs hésitent fréquemment, reformulent leurs phrases en cours de route ou s’expriment par bribes.
• Travail en binôme guidé par la voix. Collaboration interactive sur du code ou des documents, lorsque la personne réfléchit à voix haute et ne souhaite pas attendre la fin de chaque échange.

Si la tâche se limite à la saisie de commandes strictes, à la dictée de notes ou au remplissage de formulaires standards, il est judicieux de comparer cette solution avec une cascade classique basée sur STT.

Par quoi commencer pour valider un prototype

Les étapes ci-dessous constituent des recommandations pour la validation d’un prototype et non un rapport de tests finalisés. Avant de migrer un flux de travail vers cette nouvelle architecture, il est utile de suivre ces étapes préalables :

• Mesurez le temps de réponse du back-end. Si l’interrogation de votre base de données ou d’un modèle externe demande du temps, configurez la couche vocale pour qu’elle confirme le lancement de l’opération par une phrase brève et naturelle au lieu de garder le silence.
• Vérifiez le comportement en milieu bruyant. Testez le prototype en conditions réelles : bruits de rue, conversations en arrière-plan ou microphone instable.
• Limitez le format des réponses du modèle d’arrière-plan. Dans le prompt système du back-end, indiquez explicitement que les réponses doivent tenir en une ou deux phrases concises, faciles à appréhender à l’oreille.
• Définissez des limites de durée de session. Au tarif de $0.05 par minute pour la couche vocale, il est utile de plafonner par programmation la durée maximale d’un appel de test afin d’éviter des frais inutiles si un client reste bloqué.

Cette séquence d’étapes permet d’identifier en amont les latences réelles des outils et d’ajuster les prompts avant de déployer le système à plus grande échelle.