OpenAI a publié le 4 mai des détails sur les fondations de son IA vocale — pour prendre en charge des services d’IA vocale destinés à 900 millions d’utilisateurs actifs hebdomadaires (Weekly Active Users), l’équipe a redessiné la pile WebRTC, remplacé le modèle traditionnel « un port par une session » pour la couche de connexion média, par une couche relais ultra-fine écrite en Go, et regroupé tout l’état des sessions WebRTC dans un service appelé « transceiver ». Dans un billet officiel, OpenAI explique que cette architecture prend en charge à la fois le mode vocal de ChatGPT, l’API Realtime et plusieurs projets de recherche. Pour toute équipe travaillant sur l’ingénierie de l’IA vocale, il s’agit d’une documentation technique rare sur « comment supporter une IA vocale à l’échelle mondiale ».
Trois limites techniques : la WebRTC classique bloque chez OpenAI à cette échelle
L’équipe d’ingénierie d’OpenAI indique clairement dans l’article trois limites qui « entrent en collision » après amplification à grande échelle :
La terminaison des médias par session et par port (per-session port termination) n’est pas adaptée à l’infrastructure d’OpenAI — lorsque 900 millions d’utilisateurs actifs hebdomadaires peuvent ouvrir simultanément des sessions vocales, un design qui réserve un port pour chaque session épuise les ressources réseau
Les sessions ICE (Interactive Connectivity Establishment) et DTLS (Datagram Transport Layer Security) avec état, nécessitant un propriétaire stable — dans un système distribué, si l’état de session est partagé entre plusieurs services, la tolérance aux pannes et la migration deviennent extrêmement complexes
Le routage mondial doit maintenir une faible latence du premier saut (first-hop latency) — le « ressenti naturel » de l’IA vocale dépend de la fluidité du turn-taking (enchaînement des tours de parole) ; au-delà de 100 ms pour le premier saut, on observe un net « accroc »
La liste de besoins d’OpenAI est tout aussi explicite : couverture mondiale (atteignant 900 millions+ d’utilisateurs), création rapide de sessions (l’utilisateur parle tout de suite), et temps de trajet aller-retour (round-trip time) des médias faible et stable (incluant faible gigue et pertes de paquets).
Solution : un relais ultra-fine écrit en Go + un service transceiver centralisé
L’architecture d’OpenAI se compose de deux couches :
Couche Relay — écrite en Go, et volontairement simple à mettre en œuvre. Un process Go ordinaire : lit les paquets depuis un socket, met à jour un faible nombre d’états de trafic, transfère les paquets, sans terminer WebRTC. C’est la clé permettant au relais de s’étendre horizontalement — il n’est pas nécessaire de maintenir un état WebRTC complet, la substitution entre relais est indolore, et une défaillance d’un point unique n’interrompt pas toute la session.
Couche Transceiver — le seul service qui possède l’état des sessions WebRTC, comprenant les vérifications de connexion ICE, les handshakes DTLS, les clés de chiffrement SRTP et la gestion du cycle de vie de la session. En concentrant ces états dans un seul service, l’attribution des sessions devient plus facile à raisonner, et les services backend peuvent s’étendre comme des services classiques, sans devoir chacun jouer le rôle de pair WebRTC.
Le raffinement de ce design tient à ce qu’il sépare strictement « la partie qui a besoin d’état » et « la partie sans état ». Le relay est un plan de données sans état (repliquable en masse) ; le transceiver est un plan de contrôle avec état (peu nombreux, mais état complet). Cette stratification permet aussi à OpenAI de s’étendre horizontalement au gré de la charge, sans devoir craindre une explosion du nombre de connexions WebRTC.
Pourquoi utiliser Go : la logique de choix pour une équipe d’ingénierie d’IA vocale
OpenAI explique clairement dans l’article que le relay est écrit en Go, en gardant volontairement une portée étroite. La logique d’ingénierie derrière ce choix :
Les goroutines Go supportent nativement des tâches orientées IO, comme « traiter des dizaines de milliers de connexions par port », sans avoir besoin d’une boucle d’événements complexe
Le package net de la bibliothèque standard peut lire directement les paquets UDP, sans avoir besoin de lier des bibliothèques C
Après compilation, il s’agit d’un binaire statique unique ; déploiement, conteneurisation et portage multi-architecture (x86/ARM) sont simples
La gestion mémoire de Go est favorable pour « un grand nombre de petits objets à durée de vie courte » (chaque paquet doit être interprété) ; les pauses dues au GC sont contrôlables
Cela explique aussi pourquoi l’usage de Go continue de progresser dans les couches d’infrastructure modernes (Cloudflare, Tailscale, HashiCorp, etc.) — ce n’est pas « Go est plus puissant qu’un autre langage », mais « Go est le plus direct à écrire dans des scénarios d’infrastructure orientés IO, nécessitant une extension horizontale ».
Le face-à-face avec Cloudflare : le terrain du Realtime Voice AI
Au même moment (début mai), Cloudflare a également publié un billet technique, « Cloudflare est l’endroit idéal pour construire des agents vocaux en temps réel », en proposant sa propre approche en regard d’OpenAI. Les deux trajectoires divergent :
OpenAI : construire sa propre pile WebRTC relay/transceiver, sans dépendre d’un tiers, et intégrer la couche média dans sa propre pile technique
Cloudflare : étendre le service média WebRTC comme une extension de sa plateforme Workers, afin d’offrir aux développeurs une infrastructure « clé en main »
Pour les équipes de taille moyenne et petite qui développent des applications IA, la route de Cloudflare est plus pratique : appel direct d’API, sans devoir construire sa propre infrastructure WebRTC. Pour une équipe à l’échelle d’OpenAI, construire soi-même est une voie incontournable — les SLA de services externes, la structure de facturation et la répartition géographique ne peuvent pas être parfaitement alignés.
Observations à venir : transceiver open source, ampleur de l’API Realtime, réponse des concurrents
Les points d’observation pour la prochaine étape :
Est-ce qu’OpenAI va open-sourcer la partie transceiver / relay — des concurrents comme Anthropic, Google, xAI construisent déjà leurs propres piles vocales ; si OpenAI open-source, cela pourrait devenir une norme de l’industrie
Facturation et ampleur de l’API Realtime — pour l’instant, elle dépend principalement de la monétisation des abonnements à ChatGPT ; si les revenus API augmentent, deviendra-t-elle une ligne de produit indépendante
Réponse d’Anthropic et de Google — Claude et Gemini prennent déjà en charge la voix, mais en termes de latence et d’échelle, OpenAI reste en avance ; cette divulgation technique accélérera-t-elle leur suivi d’ingénierie
Pour les développeurs d’applications IA à Taïwan, l’IA vocale est un champ de bataille clé pour la seconde moitié de 2026 — les scénarios comme le service client, l’éducation, l’automobile et l’IoT nécessitent des conversations à faible latence. La divulgation d’ingénierie d’OpenAI sert d’une des références les plus importantes pour juger « faut-il construire sa propre pile vocale ou utiliser une API tierce ».
Cet article sur la refonte par OpenAI de sa pile vocale WebRTC : 900M d’utilisateurs actifs, et le relais écrit en Go comme cœur — publié pour la première fois sur Chaine News ABMedia.
