GPT-Live-1 : décider et tester un agent vocal métier

Un agent vocal GPT-Live-1 devient intéressant lorsque parler et agir se chevauchent : la personne peut préciser une demande pendant qu’un système cherche une information, corriger une date sans recommencer tout l’échange et entendre une réponse adaptée à l’état réel du travail. La fluidité de la voix ne suffit pourtant pas à valider une action métier. Un assistant peut dire « c’est fait » alors qu’aucun dossier n’a été créé, ou continuer à travailler sur une ancienne demande après une correction orale.

La décision tient donc en deux questions. Avez-vous besoin d’une conversation continue, avec une personne qui peut interrompre l’assistant, plutôt que d’un simple enregistrement suivi d’une réponse ? Et pouvez-vous relier chaque confirmation vocale à un état vérifié dans votre application ? Si la première réponse est non, une interface texte ou une chaîne transcription, traitement, synthèse vocale sera souvent plus simple à piloter. Si la seconde est non, le pilote doit rester sans action réelle.

Réponse en bref

GPT-Live-1 est un modèle vocal qui écoute et parle simultanément. Il peut déléguer le raisonnement et l’usage d’outils à un agent en arrière-plan. Pour un pilote métier, dessinez trois responsabilités distinctes : la conversation orale, la tâche déléguée et l’application qui possède les droits et les données. Choisissez ensuite un cas court, réversible et vérifiable. Testez les silences, les interruptions, les corrections en cours de tâche, l’échec d’un outil et la confirmation finale.

La prochaine action utile est de remplir le contrat de tâche ci-dessous pour une seule opération. Exemple fictif : ouvrir une demande d’intervention sur un équipement partagé après avoir vérifié son identifiant et obtenu l’accord de la personne. La preuve de réussite est l’enregistrement retrouvé dans le système métier, avec les bons champs. Une phrase prononcée par l’assistant, un appel d’outil ou une transcription ne remplacent pas cette preuve.

Choisir la voix pour une raison précise

Une équipe peut vouloir de la voix parce qu’elle travaille les mains occupées, accueille des appels, se déplace entre plusieurs postes ou aide une personne qui lit difficilement un long formulaire. Ce sont des hypothèses de produit à confirmer avec les utilisateurs concernés. Le mot « vocal » ne dispense pas d’une interface lisible, d’un moyen de corriger une transcription ni d’une sortie vers une personne.

La documentation OpenAI sur les agents vocaux distingue trois architectures. GPT-Live maintient une conversation continue avec un backend séparé ; la Realtime API réunit voix, raisonnement et outils dans une même session ; une chaîne vocale traite séparément reconnaissance, workflow et synthèse. Le bon choix dépend du contrôle nécessaire et du parcours, pas d’un classement abstrait des modèles.

Besoin dominant	Point de départ à examiner	Contrôle à garder
La personne interrompt, hésite et ajoute des détails pendant une recherche	GPT-Live avec backend séparé	Vérifier ce qui reste actif après une correction orale
Une seule session doit interpréter l’audio et utiliser des outils	Realtime API	Examiner les droits des outils et la traçabilité des actions
Chaque étape texte doit être inspectée ou remplacée	Chaîne transcription, agent, synthèse	Mesurer les délais et erreurs entre les trois étapes
La tâche se termine sans échange oral continu	Formulaire ou interface texte	Éviter une couche vocale qui allonge le parcours

Cette matrice est une méthode de choix, pas une comparaison de performances observées. Avant de retenir GPT-Live-1, faites jouer à quelques personnes un scénario complet sur leur matériel réel. La capacité du modèle à écouter pendant qu’il parle ne prouve pas que votre microphone, votre réseau, votre backend et votre application conserveront correctement l’intention.

Trois responsabilités dans une conversation

Le premier bloc est la voix. GPT-Live-1 gère le rythme oral, les réponses courtes, les pauses et les interruptions. Son instruction doit expliquer le rôle de l’assistant, la manière de parler et le moment où demander de l’aide au backend. La documentation de démarrage décrit cette séparation : la voix peut continuer pendant qu’un autre composant recherche, raisonne ou utilise un outil.

Le deuxième bloc est le backend. Il reçoit les tâches qui réclament une source, un calcul, une règle métier ou un outil. Deux modes existent. En délégation Responses, GPT-Live fournit le contexte à un modèle Responses configuré pour cette session ; l’application exécute toujours ses propres fonctions. En délégation client, votre application prépare elle-même le contexte, lance son workflow et décide ce qu’elle renvoie à la voix. Le guide de délégation recommande notamment le second mode lorsque vous devez filtrer ou valider un résultat avant qu’il soit dit.

Le troisième bloc est l’application métier. Elle connaît l’utilisateur, ses droits d’accès, l’identifiant d’une demande, le contenu autorisé et l’état durable des opérations. Elle demande les confirmations nécessaires avant une action, conserve la progression utile et vérifie ce qui a réellement été enregistré. La voix ne devient jamais une autorité supplémentaire parce qu’elle sonne convaincante.

Sur navigateur, la documentation propose WebRTC pour transporter le microphone, la sortie audio et les événements ; WebSocket convient aux intégrations audio côté serveur. Une connexion serveur supplémentaire peut surveiller une session existante. Le serveur garde la clé du projet OpenAI : elle ne doit pas partir dans la page ou dans l’appareil de l’utilisateur. Le choix du transport doit être éprouvé sur les réseaux et appareils du public visé, y compris lors d’une perte de connexion.

Un exemple métier assez simple pour échouer clairement

Imaginons un assistant interne qui aide une équipe à ouvrir une demande d’intervention pour un appareil partagé. C’est un scénario de recette, pas le récit d’un déploiement. La personne dit : « Le scanner de la salle trois ne fonctionne plus, je voudrais signaler la panne. » L’assistant vérifie le bon équipement, demande le symptôme et lit à voix haute le résumé avant création.

L’objectif n’est pas de reconnaître parfaitement toute phrase. Il est d’obtenir un dossier contenant le bon équipement, le symptôme formulé par la personne, le bon site et un statut initial. Si deux équipements portent des noms voisins, la suite attendue est une question de clarification. Si l’annuaire est indisponible, la suite attendue est un état d’échec compréhensible, avec une autre voie de signalement. Si la personne dit « non, c’est le scanner de l’accueil », l’ancienne recherche ne doit pas créer un dossier pour la salle trois.

Le contrat de tâche tient sur une fiche :

Champ	Décision pour cet exemple
Entrée	Équipement, lieu et symptôme donnés oralement ou corrigés à l’écran
Lecture autorisée	Annuaire des équipements accessibles à cette équipe
Action autorisée	Création d’une demande après résumé et confirmation explicite
Preuve de fin	Identifiant de demande et champs relus depuis le système propriétaire
États visibles	En clarification, en vérification, en attente d’accord, créé, échec, état incertain
Arrêt	Équipement ambigu, permission absente, outil indisponible ou retrait du consentement
Reprise	Contrôler l’état existant avant toute nouvelle tentative de création

Remplacez ce scénario par votre opération réelle avant de coder. Un appel de support, une prise de rendez-vous ou un suivi de commande n’ont pas les mêmes droits ni la même définition de « terminé ». La fiche oblige à nommer cette différence.

Une interruption de parole n’annule pas une tâche

La particularité d’un agent vocal continu rend deux événements faciles à confondre. Interrompre la parole signifie que l’assistant doit cesser de parler et écouter. Modifier ou annuler la demande signifie que le backend doit changer son travail, parfois après une opération déjà engagée. La documentation de prompting GPT-Live demande de traiter ces deux cas séparément. Une interruption orale ne coupe pas automatiquement la tâche déléguée.

Dans notre exemple, « attends » pendant la lecture d’un résumé doit interrompre la phrase. « Finalement, ne crée rien » exige de vérifier que l’application n’a encore rien créé, d’empêcher une action en attente et d’indiquer l’état réel. Si une création a déjà réussi, l’assistant ne peut pas annoncer une annulation simplement parce qu’il a entendu le mot. Il doit vérifier si l’opération peut être retirée, puis dire le résultat.

Le même principe s’applique aux corrections. Quand la personne remplace « salle trois » par « accueil », l’application marque l’ancien travail comme dépassé. Un résultat tardif sur le premier équipement peut encore arriver ; il doit être ignoré pour la tâche active. Le guide de délégation insiste aussi sur la vérification d’un effet avant toute relance : si la réponse d’un outil s’est perdue, un second appel aveugle pourrait créer un doublon.

Une politique de conversation courte peut alors tenir en trois règles : laisser la personne finir, céder la parole dès qu’elle intervient et ne confirmer qu’un résultat vérifié. Les consignes détaillées sur les permissions, l’idempotence et les outils appartiennent au backend et à l’application. Dire « je vérifie » peut être utile pendant l’attente ; dire « votre demande est créée » avant la lecture du système propriétaire est une erreur de produit.

Déléguer sans faire disparaître la responsabilité

Avec une délégation Responses, le service prépare les appels vers le modèle backend configuré et restitue ses résultats à la conversation. Cette option raccourcit le chemin de démarrage lorsque l’on accepte ce cadre de contexte et d’exécution. Avec une délégation client, l’application gère le contexte, choisit ses services, vérifie les réponses et peut ne transmettre à la voix qu’un résultat validé. La comparaison officielle des deux modes précise que le mode est choisi à la création de la session ; en changer implique une nouvelle session.

Pour une équipe métier, posez quatre questions avant ce choix :

1. Le backend doit-il appeler un système où une erreur peut créer, modifier ou supprimer une donnée ?
2. Faut-il masquer une information dans le résultat avant qu’elle soit prononcée ?
3. Un responsable doit-il approuver un effet avant exécution ?
4. Une même demande peut-elle survivre à une coupure de la conversation ?

Une réponse positive ne force pas mécaniquement le mode client, mais elle exige un dessin explicite des contrôles applicatifs. Dans les deux modes, les outils qui agissent restent soumis aux permissions et confirmations de votre application. Une instruction disant « ne fais jamais d’erreur » n’est pas un contrôle d’accès. Une réponse du backend n’est pas non plus une preuve que l’effet s’est produit.

La voix peut recevoir un progrès vérifié à annoncer, par exemple « je cherche l’équipement », puis « j’ai trouvé deux scanners ». Les événements de progression prévus par la documentation permettent aussi de conserver un travail silencieux. Ils ne doivent pas transporter une donnée que l’utilisateur n’est pas autorisé à entendre. Si le backend n’a pas encore un résultat stable, mieux vaut une attente claire qu’une hypothèse énoncée comme un fait.

Faire confirmer la bonne chose au bon moment

Une confirmation vocale doit porter sur une action identifiable. « Oui » tout seul est fragile après plusieurs échanges ou une interruption. L’interface peut présenter le résumé à l’écran et l’assistant peut demander : « Je crée une demande pour le scanner de l’accueil, avec le symptôme que vous venez de décrire. Je confirme ? » Le backend associe cet accord à la version courante de la tâche. Une nouvelle correction invalide l’accord précédent.

Pour une action sensible, ajoutez un mécanisme de confirmation adapté au risque : bouton, authentification ou revue humaine. Le choix dépend du service et des droits, pas de la capacité du modèle à reformuler. La partie vocale peut recueillir l’intention ; l’application décide si cette intention suffit juridiquement et opérationnellement pour l’acte visé.

Après l’accord, l’outil peut renvoyer trois familles d’état : réussite confirmée, échec confirmé, issue inconnue. Dans le premier cas, la voix peut lire l’identifiant et la prochaine étape. Dans le deuxième, elle explique ce qui n’a pas été fait. Dans le troisième, elle dit que l’état reste à vérifier et propose un contrôle, sans répéter immédiatement l’action. Cette distinction évite que l’aisance orale masque un problème de réseau ou une réponse perdue.

Une recette qui teste le dialogue et la tâche

L’évaluation doit écouter l’échange et regarder le système métier. La méthode OpenAI pour les agents vocaux recommande de vérifier la réussite de la tâche, les appels d’outils, les permissions, l’état final, les interruptions, les silences et la fiabilité de la session séparément. Une conversation agréable peut échouer à créer la bonne demande ; une demande créée peut avoir été annoncée de façon incompréhensible.

Préparez au moins les scénarios suivants avec un état initial connu :

Scénario	Ce qu’il faut observer	Verdict attendu
Demande simple	L’équipement est identifié, l’accord est obtenu, un seul dossier apparaît	Succès si les champs relus correspondent
Nom ambigu	Deux équipements correspondent	Question de clarification avant toute création
Pause de réflexion	La personne s’arrête quelques secondes	Pas de supposition ni de relance intrusive
Interruption de l’assistant	La personne parle pendant le résumé	La voix cède sans perdre les faits utiles
Correction pendant la recherche	Le lieu change avant le résultat	L’ancien résultat ne pilote pas la création
Refus de confirmation	La personne dit non au résumé	Aucun dossier créé
Échec de lecture	L’annuaire ne répond pas	État d’échec clair, sans équipement inventé
Réponse de création perdue	L’outil peut avoir agi sans accusé de réception	Vérification avant tout nouvel essai
Coupure audio	Le canal se ferme pendant une tâche	État conservé, reprise sans doublon
Demande hors périmètre	La personne demande une action interdite	Refus par l’application, pas seulement par le texte
Bruit et accent	L’entrée est partiellement comprise	Confirmation des noms et nombres utiles
Sortie de session	La personne termine l’échange	Ressources libérées et usage final relevé

Pour chaque essai, conservez ce qui permet de trancher : audio ou extrait autorisé, événements de session, résultat d’outil, version de la tâche, état final et décision de revue. Définissez la durée de conservation avant l’essai. Les fragments de transcription arrivent progressivement, avec des temps approximatifs ; ils peuvent contenir des erreurs et ne signalent pas à eux seuls la fin d’un tour. Ils servent à comprendre le dialogue, pas à remplacer l’identifiant et l’état du dossier.

Répétez les scénarios avec les mêmes conditions avant de comparer deux configurations. Mesurez séparément le temps avant un premier son utile et le temps avant la réponse qui résout la tâche. Un « je regarde » rapide peut améliorer la perception d’attente sans accélérer la création. Écoutez aussi si l’assistant coupe les hésitations, parle pendant une correction ou répète un résultat déjà donné. Un taux de réussite doit toujours indiquer combien d’essais l’ont produit.

Mesurer le coût d’une tâche terminée

Le coût de GPT-Live comprend la session vocale et les appels du backend. La fiche modèle officielle affichait le 26 septembre 2026 un prix de 0,05 dollar par minute de session vocale, facturée à la seconde ; le modèle backend et les outils sont facturés séparément. Cette valeur sert à construire un devis de pilote, puis doit être relue au moment de l’achat.

La formule est simple : durée vocale facturable en secondes ÷ 60 × tarif vocal par minute + modèles et outils du backend + autres services utilisés. La durée comprend les moments où la personne parle, où l’assistant parle, où personne ne parle et où le backend travaille. Couper seulement le microphone ne clôt pas la session. Le guide de coût recommande de prendre la durée finale rapportée par l’API et de rapprocher ce total de l’usage backend, sans additionner les mises à jour cumulatives de durée.

À titre de calcul, une session de six minutes au tarif vocal indiqué représente 0,30 dollar de voix, avant backend, téléphonie éventuelle et autres coûts. Ce n’est ni un prix de revient constaté ni le coût d’une demande réussie. Pour décider, additionnez également les sessions échouées, les reprises et les interventions humaines, puis divisez par le nombre de tâches effectivement terminées. La méthode de calcul du budget d’un pilote agentique complète ce poste vocal. Un modèle backend moins cher par appel peut coûter davantage par tâche s’il multiplie les échanges ou les erreurs.

Fermez la session lorsque la conversation se termine et attendez son événement final pour connaître l’usage confirmé. Si la connexion tombe avant cette confirmation, conservez le dernier usage observé comme provisoire et vérifiez l’état des actions côté application. La gestion des sessions GPT-Live distingue précisément la fin de la connexion, la fermeture de session et la reprise d’un travail encore actif.

Décider du passage au service réel

Fixez les conditions d’acceptation avant la démonstration. Pour l’exemple du scanner, aucun dossier ne doit être créé sans équipement identifié et accord valide ; une correction ne doit jamais laisser agir une recherche ancienne ; une réponse perdue ne doit pas produire deux dossiers ; l’assistant ne doit annoncer un numéro qu’après lecture du système métier. Ajoutez vos seuils de délai, de coût et de compréhension orale selon les utilisateurs et leur environnement.

Une revue courte peut classer chaque scénario dans trois états : accepté, à corriger puis rejouer ou inacceptable pour l’usage visé. Une démonstration convaincante ne compense pas un échec sur une permission ou sur la preuve d’action. Un pilote peut aussi montrer que la voix n’apporte pas assez face au formulaire existant. Cette conclusion est utile si elle évite un parcours plus lent et plus difficile à maintenir.

Le dossier de décision doit tenir en quelques pièces lisibles : architecture choisie, fiche de tâche, corpus d’essais, résultats par scénario, coût par tâche aboutie, défauts restants et responsable de la décision. La question finale est concrète : une personne peut-elle corriger la demande, comprendre ce qui a été fait et retrouver la même vérité dans le système métier ?

Questions fréquentes

GPT-Live-1 remplace-t-il le modèle qui utilise les outils ?

Pas nécessairement. Il assure la conversation vocale et peut déléguer le raisonnement et les outils à un backend distinct. Ce backend peut évoluer sans obliger à changer toute la couche vocale, sous réserve de vérifier à nouveau les résultats et les délais.

Peut-on se fier à la transcription pour valider un « oui » ?

La transcription aide à lire l’échange, mais ses fragments peuvent être incomplets ou erronés. Une confirmation d’action doit être reliée au résumé courant, à l’identité et aux droits de la personne, puis contrôlée selon le risque de l’opération. Un mot isolé dans un flux audio ne prouve pas qu’une action précise a été autorisée.

Que faire si l’utilisateur interrompt pendant que le backend travaille ?

L’assistant doit écouter et l’application doit décider ce que devient la tâche : continuer, réviser ou annuler. Ne déduisez jamais l’annulation du seul fait que la parole a été interrompue. Après une correction, écartez les résultats de l’ancienne version.

Quelle preuve montre qu’une tâche est terminée ?

Une réponse relue dans le système propriétaire : dossier créé, bon identifiant, bons champs et statut cohérent. La phrase prononcée par l’assistant doit correspondre à cette preuve. Si le système ne peut pas confirmer son état, la réponse doit rester en attente de vérification.

Limites

La voix continue est surtout utile quand la personne doit pouvoir parler, écouter et corriger pendant qu’un travail avance. Elle dépend du microphone, du réseau, du bruit ambiant, de la langue et de l’accès au système métier. Les délais et les coûts changent avec la durée des échanges, les outils et le modèle backend choisi. Une tâche avec droit sensible ou conséquence difficile à annuler exige des confirmations et des contrôles proportionnés ; un résultat oral fluide ne suffit jamais à attester son exécution.

Historique des mises à jour

• 26 septembre 2026 : publication de la fiche de décision, du scénario de tâche et de la matrice de recette.

Articles liés

• Agents API d’OpenAI : décider et recetter un premier pilote
• Évaluer un assistant IA avant son déploiement
• Prévoir un mode dégradé pour un agent IA