Agents vocaux GPT-Live-1 : sessions, modes de délégation et coûts réels liés aux lignes téléphoniques.

Tout ceux qui ont appelé un restaurant et atterri sur un bot vocal connaissent bien ce moment. Vous dites quelque chose, il y a une pause, puis le bot commence à répondre à la question que vous avez posée cinq secondes plus tôt, juste au moment où vous essayez de vous corriger. La plupart des gens finissent par appuyer sur 0 pour parler à un humain.

Ce rythme gênant fait partie intégrante du design habituel. Un bot vocal classique attend que vous arrêtiez de parler, convertit l’audio en texte, réfléchit, convertit la réponse en parole et la diffuse. Personne ne peut parler par-dessus l’autre.

GPT-Live-1 est la tentative d’OpenAI pour une approche différente. C’est le modèle à l’origine de ChatGPT Voice, proposé via une API, et il écoute en même temps qu’il parle. Cette page explique ce qui le distingue, comment se déroule une session, comment il transmet les questions complexes à un modèle backend, et combien coûterait une ligne téléphonique dédiée.

Qu’est-ce que GPT-Live-1 ?

C’est un modèle vocal full-duplex. Full-duplex signifie que les deux parties peuvent parler en même temps, comme lors d’un appel téléphonique ordinaire. Si un appelant intervient en disant « en fait, ce sont quatre personnes », le modèle s’arrête, s’adapte et reprend.

Le modèle laisse également le travail de réflexion complexe à quelqu’un d’autre. Chaque fois qu’une demande nécessite un effort réel, qu’il s’agisse d’une recherche, d’une consultation d’un système de réservation ou d’un raisonnement minutieux, la tâche est confiée à un modèle backend distinct. Les documents de lancement d’OpenAI indiquent un délai de passage de parole d’environ 0,8 seconde, contre environ 1,4 seconde pour le modèle vocal précédent. Considérez cela comme une valeur fournie par le fournisseur.

La conséquence pratique est que la voix et le traitement logique deviennent des tâches séparées. La voix gère la conversation, tandis que le backend s’occupe du raisonnement et des outils.

Délégation : une voix qui parle et un cerveau qui pense

Le transfert de responsabilités est ce que OpenAI appelle la délégation. En permanence, en quelques fractions de seconde, le modèle vocal évalue s’il doit rester silencieux et écouter, s’arrêter, parler, ou transférer une tâche au système backend. L’appel ne se bloque jamais pendant l’exécution de cette tâche, car la voix peut dire rapidement « laissez-moi vérifier » et continuer la conversation.

Imaginez un appelant qui demande à la file d’attente d’un restaurant s’il y a une table pour quatre disponible à 19h30 le vendredi. Le modèle répond « laissez-moi vérifier », envoie la demande de vérification de disponibilité au backend, et informe l’appelant du résultat dès que celui-ci est disponible.

Cette séparation résout également un problème lié aux connaissances. Selon sa page dédiée au modèle, les connaissances du modèle vocal s’arrêtent au 31 juillet 2025, donc tout ce qui est d’actualité doit provenir du backend.

Démarrer une session vocale

Les options de connexion sont WebRTC pour les applications navigateur, WebSockets pour l’audio provenant d’un serveur, et la téléphonie SIP pour des numéros de téléphone réels. Quelle que soit votre choix, les événements sont similaires, c’est pourquoi les étapes suivantes s’appliquent à tous les cas.

Étape 1 : conserver la clé API sur un serveur

Gardez la clé éloignée des navigateurs. Votre propre serveur de confiance crée la session, tandis que le navigateur ne gère que le micro et le haut-parleur. Un compte payant est nécessaire, car le plan gratuit n’est pas pris en charge, et les limites de fréquence tiennent compte du nombre de sessions en direct simultanées et augmentent en fonction de votre niveau d’utilisation.

Étape 2 : démarrer la session

Une fois connecté, vous envoyez un seul événement session.start contenant vos paramètres.

{
  "type": "session.start",
  "session": {
    "model": "gpt-live-1",
    "instructions": "Be concise and ask before taking an external action.",
    "audio": { "output": { "voice": "marin" } },
    "delegation": { "type": "client" }
  }
}

Cet événement choisit le modèle, fournit les instructions, sélectionne une voix et détermine qui effectue le travail en arrière-plan. Attendez que session.started renvoie une valeur avant de parler. Le modèle, les instructions et la voix sont figés une fois la session lancée, de sorte que les règles ultérieures sont ajoutées via session.instructions.append au lieu de remplacer le texte initial.

Étape 3 : diffuser de l’audio dans les deux sens

Avec WebRTC, le navigateur s’occupe de l’audio. Avec WebSockets, vous envoyez de petits fragments via les événements session.input_audio.append. Le format est strict : PCM mono brut de 16 bits, encodé en base64, sans en-tête WAV, à la fréquence d’échantillonnage que vous avez configurée au démarrage (24 kHz par défaut). La voix du modèle est renvoyée de la même manière, via les événements session.output_audio.delta. Si votre audio source utilise une fréquence différente, reéchantillonnez-le vous-même, car modifier la configuration du format ne convertit pas vos octets.

Étape 4 : lire les transcriptions

Le texte en direct pour les deux parties arrive sous forme d’événements session.input_transcript.delta et session.output_transcript.delta. Il n’y a pas d’événement « tour terminé », car les deux parties peuvent parler simultanément. Si votre application a besoin de tours bien structurés pour les journaux, regroupez les fragments de votre côté.

Étape 5 : fermer proprement

Envoyez session.close et continuez à lire jusqu’à ce que session.closed apparaisse. Cet événement final indique les données d’utilisation sur lesquelles vous serez facturé. Si la connexion se termine avant son arrivée, vous n’obtenez pas de confirmation d’utilisation, ce qui est important lors du rapprochement des factures.

La étape que les gens oublient le plus souvent est la quatrième : créer des extraits lisible à partir de fragments de transcription.

Transfert du travail au backend

Ici, GPT-Live-1 cesse d’être une voix agréable pour devenir un agent utile. L’un des deux modes de délégation est choisi au démarrage de la session et ne peut pas être modifié en cours de route. Pour changer, il faut démarrer une nouvelle session.

Option A : Délégation des réponses

Vous indiquez le nom du modèle Responses que la voix doit appeler ainsi que les outils qu’elle peut utiliser. La configuration se trouve dans l’objet de session aux côtés du nom du modèle.

"delegation": {
  "type": "responses",
  "responses": {
    "model": "gpt-5.5",
    "instructions": "Use tools when current information is required.",
    "tools": [{ "type": "web_search" }],
    "tool_choice": "auto"
  }
}

Dès lors, les questions des appels nécessitant une recherche sont traitées par le backend, et les résultats sont intégrés à la conversation en cours. Les fonctions personnalisées sont différentes : une fonction comme check_table n’est pas exécutée par le backend. Votre application reçoit l’appel, le met en œuvre, renvoie le résultat, puis indique au backend de poursuivre.

Imaginez qu’un appelant demande s’il pleuvra vendredi soir, car le groupe pourrait s’asseoir dehors. Le backend effectue une recherche sur Internet, la voix indique qu’une pluie légère est attendue après six heures, ce qui rendrait l’intérieur plus sûr, et l’appelant n’est jamais confronté à un long silence.

Option B : délégation au client

Ici, c’est votre propre application qui agit en tant que backend. Lorsque le modèle a besoin d’aide, vous recevez un événement session.delegation.created contenant un ID. Vous effectuez le travail comme vous le souhaitez et envoyez la réponse en utilisant ce même ID.

{
  "type": "session.commentary.append",
  "delegation_id": "item_delegation_123",
  "content": "Table for 4 is confirmed at 7:30 pm Friday."
}

Un message de commentaire signifie que le modèle doit prononcer le texte à haute voix. Si le modèle doit connaître quelque chose en silence, session.thinking.append s’en charge à la place. Chaque message peut contenir environ 500 tokens. En principe, un gestionnaire de client pourrait transmettre la tâche à un framework d’agent de votre choix, bien que cette combinaison nécessite des tests propres avant de pouvoir s’y fier.

Une approche sensée consiste à commencer avec la délégation des réponses gérées et à passer à la délégation côté client une fois que vous avez besoin d’un contrôle plus grand sur les permissions, les confirmations ou le flux de travail lui-même.

Le coût

La couche vocale coûte 0,05 $ par minute, facturée au second. Cela revient à 3 $ par heure, ou 72 $ par jour pour une ligne restée active 24 heures sur 24. Les modèles et outils backend sont facturés séparément, donc le montant total dépend de la fréquence à laquelle les appels ont besoin d’aide.

Un exemple concret, avec des chiffres fictifs :

• Supposons qu’une file d’attente dans un restaurant reçoive 2 000 appels par mois, d’une durée d’environ 3 minutes chacun. Cela représente 6 000 minutes, soit 6 000 fois 0,05 $, soit 300 $ rien que pour la voix.
• Ensuite, supposons deux transferts par appel, chacun impliquant environ 3 000 tokens d’entrée et 300 tokens de sortie, avec un coût de 10 $ par million de tokens d’entrée et 50 $ par million de tokens de sortie. Un seul transfert coûte 0,03 $ plus 0,015 $, soit 0,045 $. Deux transferts coûtent donc 0,09 $ par appel, ce qui représente 180 $ pour 2 000 appels.
• Le total s’élève à environ 480 $ par mois, soit environ 24 cents par appel.

Les chiffres relatifs aux tokens et les tarifs du système backend sont des estimations pour un flux de réservation simple ; mesurez donc votre propre volume d’activité avant de vous fier à eux. La partie liée à la voix est prévisible, tandis que c’est la partie backend qui nécessite une attention particulière.

Détails omis dans les articles de lancement

Interrompre ne annule pas le travail

D’après la documentation, couper le discours de l’assistant n’arrête pas automatiquement le travail en arrière-plan. Une personne qui dit « Laissez tomber » peut encore voir sa recherche ou sa réservation finalisées, à moins que votre application ne l’interrompe. Cela est inoffensif pour une recherche météo, mais grave dans le cas d’une demande de réservation suivie de « Attendez, non. »

Le message reçu n’est pas entendu

L’ajout d’un résultat génère une confirmation, mais cela ne signifie pas que le modèle l’a réellement prononcé ni que quelqu’un l’a entendu. La finalisation d’une réponse en arrière-plan est un événement, tandis que l’écoute par la personne qui appelle en est un autre. Pour tout ce qui doit être confirmé, comme l’heure de la réservation, cherchez le texte dans la transcription de sortie.

Les valeurs de référence varient selon la source

Les scores de référence publiés pour ce modèle dans des tâches de service client diffèrent selon les articles publiés par OpenAI et les comptes rendus de presse. Dans tous les cas, l’amélioration par rapport au modèle précédent est significative, mais il s’agit de résultats fournis par le fournisseur, et les tests indépendants sont rares. Les témoignages de clients, tels que celui d’une entreprise d’apprentissage des langues indiquant beaucoup moins d’interruptions pendant les pauses de réflexion des apprenants, ne constituent que des anecdotes et non des études scientifiques.

Un contexte calme n’est pas un endroit sûr pour les secrets

Tout ce qui est entré via session.thinking.append peut encore influencer les paroles prononcées par la suite. Évitez d’y inclure des numéros de compte ou des notes privées.

Quand c’est adapté et quand ce n’est pas le cas

Cela convient :

• aux lignes téléphoniques pour les réservations, les commandes et un support simple
• aux applications d’apprentissage, où les utilisateurs s’arrêtent pour réfléchir entre les phrases
• aux équipes souhaitant remplacer une chaîne de traitement composée de trois modèles distincts

Réfléchissez à deux fois avant de :

• Effectuer des appels où une action erronée a de lourdes conséquences, comme les paiements
• Utiliser des produits nécessitant des voix personnalisées immédiatement, car celles-ci passent par un processus d’approbation distinct
• Intégrer des éléments d’image ou de vidéo, que le modèle ne prend pas en charge

Une approche risquée consiste à laisser le système backend confirmer la réservation dès que l’appelant dit « d’accord », sans vérifier ce qu’il a dit par la suite. Une méthode plus sûre consiste à relire la confirmation, à attendre une réponse claire affirmative et à permettre à votre application d’annuler les tâches en attente si l’appelant change d’avis. La voix peut être excellente, mais ce sont toujours vos contrôles de sécurité qui comptent.

Points clés

• Les appelants peuvent interrompre ou changer de sujet au milieu d’une phrase, car le modèle continue d’écouter pendant qu’ils parlent.
• Les tâches complexes sont traitées par un modèle backend, que ce soit géré par OpenAI ou par votre propre application.
• Chaque session suit cinq étapes : démarrer, attendre session.started, diffuser l’audio, assembler les interventions à partir de fragments de transcription et terminer proprement.
• Le traitement de la voix coûte 0,05 $ par minute, ce qui représente environ 480 $ par mois pour une ligne d’attente de 2 000 appels, en supposant un système backend léger comme indiqué ci-dessus.
• L’interruption d’un appelant fait en sorte que le travail du backend continue, donc votre application doit gérer elle-même le cas de « attendre, non ».