AIREITERUn agent vocal qui attend le silence avant de réfléchir peut être rapide tout en donnant une impression très mécanique. GPT-Live s’attaque à cette limite directement au niveau de l’architecture : il écoute et parle en continu, tandis que la recherche, les outils et le raisonnement approfondi s’exécutent à côté de la boucle audio, et non à l’intérieur. L’interaction gagne en naturel, mais le système devient aussi nettement plus complexe à exploiter.
L’architecture full-duplex de l’API GPT-Live en une minute
GPT-Live n’est pas simplement un endpoint speech-to-speech plus rapide. OpenAI le présente comme un système vocal full-duplex capable de traiter l’audio entrant tout en générant l’audio sortant, de prendre des décisions d’interaction plusieurs fois par seconde et de déléguer les tâches plus complexes à un modèle frontier. Selon le retour d’expérience technique d’OpenAI, le système repose sur l’inférence en streaming, une conversation avec état, le transport WebRTC et l’exécution asynchrone des tâches en dehors du chemin média.
Le modèle pratique se résume ainsi :
| Couche | Responsabilité | Conséquence d’architecture |
|---|---|---|
| Chemin média | Transporter les trames audio entre le client et le modèle vocal | Le garder court, prévisible et indépendant des API métier |
| Modèle vocal full-duplex | Écouter, parler, faire des pauses, gérer les interruptions et le rythme de la conversation | Ne pas faire de la détection des tours par le silence le contrôleur principal |
| Couche de délégation | Exécuter la recherche, le raisonnement et les outils de façon asynchrone | Traiter chaque tâche déléguée comme un job d’arrière-plan sensible à la latence |
| Couche applicative | Valider les outils, les autorisations, les confirmations et les règles métier | Ne jamais laisser une réponse vocale fluide autoriser seule une action aux conséquences importantes |
| Historique produit | Conserver les transcriptions, les statistiques et les messages de l’interface | Séparer les vues provisoires et finalisées de la conversation |
Le changement essentiel concerne la gestion du temps. Dans un agent vocal classique, l’application attend que l’utilisateur ait fini, envoie son intervention au modèle, puis diffuse la réponse. Avec GPT-Live, la session vocale reste active pendant que plusieurs types de tâches s’exécutent en parallèle.
Le modèle requête-réponse doit passer au second plan
Les systèmes vocaux en cascade enchaînent la reconnaissance vocale, le modèle de langage et la synthèse vocale. Les modèles speech-to-speech natifs suppriment certains relais, mais un détecteur d’activité vocale distinct peut toujours décider que l’utilisateur a terminé avant de lancer l’inférence. Une courte pause de réflexion peut alors être prise pour une fin de tour, tandis qu’un bruit de fond peut être interprété comme une nouvelle prise de parole.
L’approche full-duplex de GPT-Live déplace ce problème de timing dans le modèle vocal. Celui-ci peut continuer à écouter pendant qu’il parle, détecter une interruption, mettre sa réponse en pause, la reprendre ou produire un bref acquiescement. Les frontières entre les tours ne disparaissent pas complètement. Elles ne peuvent simplement plus bloquer la boucle audio en direct.
Ce que GPT-Live change sur le chemin temps réel
L’inférence continue remplace le verrouillage par tour
Dans une session full-duplex, l’entrée et la sortie sont des flux, et non des blocs audio qui s’alternent. Le modèle peut recevoir de nouvelles paroles alors que sa réponse précédente est encore diffusée. Il peut déterminer si l’audio entrant correspond à une véritable interruption, à un bref acquiescement ou à un bruit de fond.
La logique côté client doit donc évoluer. Un client doit pouvoir envoyer, recevoir, annuler et remplacer des événements audio simultanément. Une abstraction unique du type await response() convient mal à ce fonctionnement, car elle masque précisément les événements les plus importants : début de la parole, début de l’audio de l’assistant, interruption détectée, outil demandé, réponse annulée et fin de session.
Les développeurs doivent néanmoins conserver les signaux d’activité vocale pour l’interface, les statistiques et la sécurité. L’erreur d’architecture consiste à utiliser le VAD comme seule autorité pour décider du moment où l’inférence du modèle peut commencer.
Garder l’audio rapide et sortir le reste du chemin critique
Dans son retour d’expérience technique, OpenAI sépare le chemin audio dédié de la logique applicative. L’audio circule directement entre le client et le modèle vocal, tandis que les appels d’outils, les contrôles de politique, la persistance et les opérations backend franchissent une frontière asynchrone.
Cette séparation impose une règle simple : une recherche lente dans un CRM peut retarder sa propre réponse, mais elle ne doit pas empêcher l’arrivée des trames audio à temps. WebRTC assure le transport média à faible latence ; les services applicatifs ne doivent pas s’intercaler de façon synchrone entre chaque trame du microphone et le modèle.
La couche vocale peut prononcer une phrase courte pendant l’exécution d’une tâche déléguée, mais les paroles de remplissage ne remplacent pas un job encadré. Définissez pour chaque outil une échéance, des règles d’annulation et un état de résultat sûr.
La délégation sépare réactivité et intelligence
GPT-Live peut déléguer une recherche, un raisonnement approfondi ou une tâche complexe à un modèle frontier. Les communications de lancement et les articles techniques d’OpenAI identifient GPT-5.5 comme modèle délégué au lancement. Le modèle vocal reste responsable de l’interaction immédiate ; le modèle frontier prend en charge les tâches qui s’intègrent mal dans une boucle vocale à faible latence.
En production, la délégation doit être traitée comme un pipeline à part entière :
- Détecter que la demande nécessite une recherche, un raisonnement ou un outil.
- Accuser réception ou marquer une pause sans bloquer le chemin média.
- Lancer le job en arrière-plan avec le contexte pertinent de la conversation.
- L’annuler si l’utilisateur change de direction ou met fin à la session.
- Valider le résultat dans l’application.
- Injecter un résultat concis dans la session en direct.
Préinitialiser la session d’inférence déléguée, conserver l’affinité de session et mettre en cache le contexte répété peut réduire le délai avant l’arrivée d’un résultat utile. Le budget de bout en bout inclut le routage, le traitement du prompt, l’inférence du modèle, les appels d’outils et chaque aller-retour entre le modèle et les outils, pas uniquement la latence liée aux tokens.
Les sessions avec état exigent une deuxième architecture
Un long appel vocal n’est pas une suite de requêtes jetables. Le contexte s’étoffe, les workers du modèle changent et la session peut nécessiter une compaction. OpenAI décrit un mécanisme qui consiste à préchauffer une nouvelle instance du modèle, à lui transmettre le contexte courant, puis à basculer uniquement lorsqu’elle est prête. La transition d’infrastructure reste ainsi inaudible pour l’appelant.
La compaction du contexte pose un problème comparable. Résumer les échanges précédents modifie le contexte qui alimente le cache clé-valeur du modèle. Reconstruire ce cache au premier plan provoquerait une pause. Une approche plus sûre consiste à compacter le contexte en parallèle, à préparer une instance de remplacement et à laisser l’ancienne servir les requêtes jusqu’à ce que le relais soit prêt.
Pour un backend d’agent vocal, l’état de session doit donc contenir bien plus qu’une transcription :
- État courant de l’audio et de la réponse
- Appels d’outils actifs et jetons d’annulation
- Affinité avec l’instance du modèle ou le worker
- Messages provisoires et finalisés
- État de la compaction du contexte
- État de reconnexion et de récupération
- État des contrôles de sécurité et des confirmations
Le contrat d’API est un système d’événements, pas du requête-réponse
Le full-duplex modifie le protocole interne, même si l’API externe finit par proposer des méthodes familières dans ses SDK. L’application doit distinguer explicitement des événements souvent confondus :
| Événement | Signification | Réaction attendue |
|---|---|---|
| Annulation | Arrêter une opération en attente | Annuler le job et libérer les ressources |
| Interruption | L’utilisateur parle par-dessus la sortie en cours | Arrêter ou réviser l’audio de l’assistant sans mettre fin à la session |
| Fin de session | L’appel ou la conversation est terminé | Fermer l’état du média, des outils, de la persistance et de la facturation |
| Échec d’un outil | Une action déléguée n’a pas abouti | L’expliquer prudemment et proposer une solution de repli |
| Reconnexion | Le chemin média a été interrompu | Restaurer l’état sans dupliquer les actions |
GPT-Live peut fonctionner en continu, mais le reste du produit a toujours besoin de messages pour l’interface, les statistiques et les systèmes de sécurité. OpenAI décrit le maintien d’une vue spéculative, révisable à mesure que les transcriptions arrivent, ainsi que d’un historique de référence finalisé plus tard. C’est un schéma utile : afficher des sous-titres réactifs sans considérer chaque transcription partielle comme un fait immuable.
Ce que les équipes d’agents vocaux doivent repenser
Séparer l’adaptateur média de l’orchestration de l’agent
Placez le transport propre à chaque fournisseur et la gestion des événements derrière un adaptateur. L’application doit consommer des événements normalisés comme user_audio_started, assistant_interrupted, tool_requested, confirmation_required et response_completed.
Conservez l’identifiant du modèle, la voix, les prompts, les schémas d’outils et les limites de coût dans la configuration. Ce n’est pas seulement une assurance contre les migrations. Cela permet à une équipe de tester dès aujourd’hui un modèle Realtime documenté tout en gardant une cible explicite pour les sémantiques GPT-Live à venir.
Pour les outils, le modèle propose et l’application valide. Les paiements, modifications de compte, annulations, changements d’adresse, opérations de triage médical, actions financières et parcours d’identité doivent être soumis à des règles de confirmation situées en dehors de l’assurance vocale du modèle.
Choisir le transport selon l’endroit où l’audio est contrôlé
WebRTC est le choix naturel pour les clients web et mobiles qui capturent et diffusent directement l’audio. WebSocket peut rester pertinent pour les pipelines média contrôlés côté serveur, mais les équipes ne doivent pas supposer que tous les modèles temps réel acceptent la même forme de session sur tous les transports.
Un ticket d’intégration OpenClaw illustre le problème concret : traiter gpt-live-1 comme une session WebSocket Realtime GA classique a produit une réponse invalid_model, tandis que le parcours GPT-Live proposé dans le navigateur utilisait une forme de session WebRTC distincte. Ce ticket constitue un retour d’implémentation, et non un contrat d’API OpenAI, mais il confirme une règle de conception : détecter la famille du modèle et négocier explicitement le type de session pris en charge.
Mesurer les trames à l’heure, pas seulement la latence des tokens
Dans son article technique, OpenAI indique qu’un composant de flux auxiliaire a atteint sa limite avant la capacité GPU lors des tests en production. L’unité de capacité utile était le nombre de sessions concurrentes pouvant être maintenues avec une livraison des trames à temps, et non le nombre de requêtes par GPU.
Suivez au minimum :
- Retard et pertes des trames audio
- Délai avant le premier audio lisible
- Temps entre l’interruption et l’arrêt
- Nombre de sessions simultanées par région
- Reconnexions et appels d’outils en double
- Durée d’exécution des délégations
- Taux d’expiration et d’annulation des outils
- Corrections entre les transcriptions provisoires et finales
- Sessions abandonnées et coût par session
Le naturel de l’échange pose aussi un problème de réglage. Les utilisateurs peuvent apprécier les interruptions et les acquiescements dans un contexte, puis les trouver intrusifs dans un autre. Un premier retour d’utilisateur résume brutalement le risque : « It's literally cutting her off constantly lmao » (@AutismCapital). Prenez-le comme un rappel : la politique de prise de parole simultanée doit être ajustée sur de vraies conversations, pas sur des démonstrations scénarisées.
GPT-Live ou Realtime actuel : quelle décision d’architecture ?
Le catalogue officiel des modèles OpenAI positionne désormais GPT-Live 1 pour les conversations vocales naturelles et expressives, en mettant notamment en avant la gestion fluide des interruptions. Ce catalogue ne constitue pas pour autant un contrat d’intégration complet : la page dédiée à l’API GPT-Live examinée ici reste un formulaire de notification, sans détails sur les endpoints, les limites de débit ou les plafonds. Avant de figer un plan de lancement, les équipes doivent vérifier la documentation développeur actuelle et l’accès accordé à leur compte.
| Besoin | Choix pratique |
|---|---|
| Lancer dès maintenant un agent vocal documenté | Utiliser la pile Realtime documentée derrière un adaptateur |
| Faire du chevauchement naturel et de la gestion des tours par le modèle une exigence forte | Concevoir pour le modèle d’événements full-duplex de GPT-Live et valider d’abord l’accès |
| Audio web ou mobile | Privilégier le chemin WebRTC pris en charge par le fournisseur |
| Actions métier complexes | Conserver des outils asynchrones et une confirmation côté application |
| Appels longs | Construire avant le lancement la gestion des relais, de la compaction, des reconnexions et de l’état durable |
Cette architecture mérite d’être adoptée avant même que le modèle soit disponible pour tous les comptes. Le média continu, les événements normalisés, les outils asynchrones et l’annulation explicite améliorent aussi un agent vocal construit sur un modèle temps réel classique.
FAQ sur l’API full-duplex GPT-Live
GPT-Live est-il identique à GPT-Realtime ?
Non. OpenAI présente GPT-Live comme une famille distincte de modèles dédiés aux conversations vocales, tandis que GPT-Realtime correspond à la famille d’API temps réel documentée. Des capacités audio similaires ne garantissent pas des sémantiques de session, des transports ou des identifiants de modèle identiques.
Le full-duplex signifie-t-il que le modèle n’attend jamais ?
Non. Cela signifie que le système peut écouter et parler simultanément. Le modèle peut toujours faire une pause, rester silencieux, demander une précision ou retarder un résultat délégué lorsque cette décision est plus sûre ou plus utile.
Les développeurs ont-ils encore besoin du VAD ?
Oui, pour l’expérience audio, les statistiques, les sous-titres et les signaux de sécurité. Le VAD ne doit pas être le seul mécanisme qui impose une séquence rigide entre le tour de l’utilisateur et celui de l’assistant.
Quel transport choisir pour un agent vocal ?
Utilisez le transport pris en charge par le client et le modèle concernés. WebRTC convient généralement à l’audio directement géré dans un navigateur ou sur mobile ; les pipelines média backend peuvent utiliser WebSocket lorsque cela est documenté. Ne déduisez pas la compatibilité d’un transport à partir du seul nom du modèle.
Que faut-il construire avant d’avoir confirmé l’accès ?
Construisez l’adaptateur, le schéma d’événements normalisés, la couche de validation des outils, le modèle d’annulation, la télémétrie des coûts, les solutions de repli et la récupération des sessions longues. Ces composants resteront utiles si le contrat final de l’API GPT-Live évolue.
Choisissez l’architecture, pas le nom du modèle
La décision qui durera consiste à ne plus traiter la voix comme une simple enveloppe requête-réponse autour d’un modèle de texte. Maintenez le chemin audio disponible en continu, déportez les tâches lentes derrière des frontières asynchrones, faites des interruptions et des annulations des événements de premier ordre, et conservez une transcription révisable avant sa finalisation.
Le compromis de GPT-Live est limpide : un chevauchement plus naturel et la délégation exigent davantage d’état, d’observabilité et moins de contrôle au moyen de frontières simples entre les tours. Les équipes prêtes à accepter cette complexité peuvent concevoir dès maintenant pour le contrat full-duplex ; celles qui ont besoin d’un endpoint de production documenté peuvent lancer leur produit avec Realtime tout en conservant les mêmes points d’intégration orientés événements.