GPT-Live peut lancer des appels téléphoniques via l’API d’OpenAI
L’ouverture figure dans le journal du 2 novembre. Elle concerne une intégration téléphonique par API et conserve des limites de durée et des événements de connexion.
OpenAI indique depuis le 2 novembre 2026 que les appels sortants SIP sont disponibles pour toutes les organisations via l’API Live. Une application peut ainsi demander à GPT-Live de joindre un numéro par l’intermédiaire de son fournisseur de téléphonie. Il s’agit d’une capacité destinée aux développeurs. Elle ne correspond pas à un bouton d’appel ajouté à la conversation vocale de ChatGPT.
Une passerelle vers le réseau téléphonique
SIP est un protocole utilisé pour établir des appels sur Internet. Un fournisseur compatible assure la liaison avec le numéro de téléphone. GPT-Live prend en charge la conversation vocale tandis que l’application gère la configuration et ses propres fonctions. Le dispositif associe donc le modèle et une infrastructure téléphonique. L’accès à l’API ne remplace pas cette dernière.
La documentation exige une signalisation chiffrée avec TLS et un transport audio SRTP. Le fournisseur doit prendre en charge ces mécanismes. Le numéro appelé doit respecter le format international prévu. L’application transmet également la configuration de sa passerelle. Les clés de l’API et les identifiants téléphoniques doivent rester du côté du serveur. Ces exigences ne constituent pas une promesse de confidentialité de bout en bout entre tous les participants.
L’API Live et l’API Realtime ne sont pas interchangeables
Le guide distingue explicitement les appels sortants de l’API Live et les fonctions de l’API Realtime. L’ouverture annoncée concerne la première. Un développeur ne peut donc pas transposer les adresses techniques d’un exemple à l’autre sans vérifier le parcours concerné. Le guide conserve aussi des instructions pour les appels entrants. Ceux-ci nécessitent une réception et une décision d’acceptation différentes.
Créer une session ne prouve pas que quelqu’un a décroché
L’application lance un appel sortant en créant une session configurée pour SIP. Cette étape ne nécessite pas le message de réception utilisé pour un appel entrant. Une réponse technique réussie confirme l’initialisation de la session. Elle ne signifie pas que le destinataire a répondu. La distinction évite de compter comme conversation un simple lancement d’appel.
Le système émet ensuite des événements pour signaler la sonnerie ou la réponse. Il peut aussi annoncer un échec après une initialisation réussie. Une connexion séparée permet au serveur de suivre ces événements pendant que SIP transporte l’audio. La documentation demande de dédupliquer les événements pour éviter de déclencher plusieurs fois une même action. Cette logique concerne notamment les outils qui effectuent une opération pendant la conversation.
Des limites de durée et un rôle conservé pour l’application
La sonnerie est limitée à trois minutes. Un appel connecté est limité à deux heures. Ces durées ne se modifient pas dans la demande de création. L’application peut transférer ou terminer un appel actif. Le fournisseur téléphonique reste impliqué dans le transfert. Une confirmation technique d’envoi ne démontre donc pas à elle seule que toute la chaîne a abouti.
L’ouverture à toutes les organisations décrit une disponibilité de l’API. Elle ne démontre pas la qualité des échanges dans chaque langue ou chaque situation. Elle ne fournit pas non plus une mesure indépendante du taux d’appels correctement traités. Aucun appel n’a été effectué pour cet article. Les éléments présentés viennent du parcours documenté par OpenAI.
Une capacité distincte de la voix dans ChatGPT
Le journal de changements date cette ouverture et le guide SIP de l’API Live décrit ses conditions. Notre article sur GPT-Live dans la conversation vocale de ChatGPT concerne une autre expérience. Le partage d’une famille de modèles ne rend pas identiques les accès et les fonctions de ces deux produits.
Je vois surtout un changement dans la manière de relier une IA vocale au téléphone. L’évaluation devrait suivre tout le parcours depuis le lancement jusqu’à la résolution de la demande. Le nombre de sessions créées ne suffit pas. Ça oblige à regarder la connexion et les actions réellement accomplies autant que la fluidité de la voix.