WebSocket et WebRTC gardent tous deux une connexion ouverte pour que l’audio circule dans les deux sens sans nouvelle requête à chaque segment. La différence, c’est ce qui se passe quand le réseau flanche. Un WebSocket fonctionne sur TCP : chaque octet arrive dans l’ordre, quitte à attendre. WebRTC fonctionne généralement sur UDP et il est conçu pour les médias : il abandonne ou masque un paquet en retard et continue la lecture.
Pour un agent vocal, cette différence décide de la place de chacun. WebRTC sert au tronçon entre l’appareil d’une personne et vos serveurs, là où le Wi-Fi et les réseaux mobiles perdent des paquets. WebSocket sert aux tronçons entre serveurs, où ils n’en perdent pas, et à tout ce qui demande un flux de messages simple et ordonné. La plupart des agents vocaux en production utilisent les deux.
Ce guide s’adresse aux ingénieurs qui choisissent le transport d’un agent vocal ou d’une fonction vocale en temps réel. Il explique le fonctionnement de chaque protocole, la comparaison qui compte pour l’audio et les architectures que les équipes mettent réellement en production.
WebRTC et WebSocket en un coup d’œil
| WebSocket | WebRTC | |
|---|---|---|
| Ce que c’est | Un canal de messages bidirectionnel | Une pile de protocoles pour les médias en temps réel |
| Transport | TCP (avec TLS pour wss://) | Généralement UDP ; TCP ou TLS via un relais TURN en repli |
| Livraison | Tous les messages, dans l’ordre | Des paquets peuvent être abandonnés ; l’audio en retard est masqué |
| En cas de perte de paquets | Le flux se fige jusqu’à la retransmission | L’audio continue, avec de brefs artefacts |
| Gestion de l’audio | Aucune. Vous choisissez le format, le tampon et la lecture | Codec Opus, tampon de gigue et masquage des pertes intégrés |
| Établissement | Une requête HTTP d’upgrade | Signalisation, candidats ICE, souvent des serveurs STUN et TURN |
| Côté serveur | N’importe quel serveur web ou langage | Généralement un serveur média ou une plateforme hébergée |
| Idéal pour | Serveur à serveur, API, messages texte et de contrôle | Audio navigateur et mobile sur des réseaux que vous ne contrôlez pas |
Comment fonctionne un WebSocket
Un WebSocket commence par une requête HTTP ordinaire avec un en-tête Upgrade. Si le serveur accepte, la même connexion TCP reste ouverte et chaque côté peut envoyer des messages à tout moment. Le protocole est défini dans la RFC 6455, et tous les navigateurs ont une API WebSocket.
WebSocket ne connaît rien à l’audio. Un message est une trame texte ou binaire, et l’application décide de son contenu. Les API vocales envoient généralement des événements JSON avec du PCM encodé en base64, ou des trames binaires brutes. Votre code capte le micro, encode les segments, les envoie et, à l’autre bout, met l’audio reçu en file d’attente pour la lecture.
Cette simplicité fait son intérêt. Un WebSocket passe la plupart des proxys et des répartiteurs de charge, fonctionne depuis n’importe quel langage et se débogue facilement : on peut lire les messages. Le prix à payer, c’est la garantie de livraison de TCP. Quand un paquet se perd, TCP le retransmet, et rien de ce qui suit n’atteint l’application avant. Pour télécharger un fichier, c’est exactement ce qu’il faut. Pour de la voix en direct, une retransmission de 200 millisecondes, c’est 200 millisecondes de silence, puis une rafale d’audio qui arrive d’un coup.
Comment fonctionne WebRTC
WebRTC est un ensemble de standards (la vue d’ensemble est la RFC 8825) pour envoyer de l’audio, de la vidéo et des données entre pairs en temps réel. Le navigateur se charge de l’essentiel du travail sur les médias :
- Codecs. Les navigateurs doivent prendre en charge Opus et G.711 pour l’audio (RFC 7874). Opus compresse bien la voix et adapte son débit au réseau.
- Transport. Les médias passent par SRTP (RFC 3711), généralement sur UDP, avec des clés négociées via DTLS. Le chiffrement est obligatoire.
- Tampon de gigue et masquage des pertes. Le récepteur garde quelques dizaines de millisecondes d’audio pour lisser les arrivées irrégulières, et comble les petits trous au lieu de s’arrêter.
- Traversée de NAT. ICE essaie d’abord les chemins directs, utilise STUN pour découvrir les adresses publiques et se replie sur un relais TURN quand rien d’autre ne passe.
- Annulation d’écho et suppression du bruit. Les navigateurs les appliquent par défaut aux appels WebRTC.
Ce que WebRTC ne définit pas, c’est la signalisation : la façon dont deux pairs échangent la description de session et les candidats réseau avant que les médias circulent. Cette partie, vous la construisez vous-même, et c’est très souvent un WebSocket. C’est pourquoi « WebRTC ou WebSocket » est une comparaison un peu bancale. Beaucoup d’applications WebRTC contiennent un WebSocket.
L’autre difficulté, c’est le côté serveur. WebRTC a été conçu pour les appels de navigateur à navigateur. Quand l’autre « pair » est votre agent vocal, il vous faut un serveur qui parle WebRTC : un serveur média (une SFU) comme LiveKit, ou une plateforme hébergée comme Daily. Exploiter vos propres serveurs TURN et serveurs média représente un vrai travail d’infrastructure.
Lequel compte pour l’IA vocale
Un agent vocal a au moins trois tronçons réseau, et ils n’ont pas besoin du même transport.
De l’appareil de l’utilisateur à vos serveurs. C’est le tronçon qui passe par le Wi-Fi domestique, les réseaux de bureau et les téléphones dans le train. La perte de paquets et la gigue y sont normales. WebRTC a été conçu pour ce tronçon : l’audio continue malgré un paquet perdu, Opus baisse son débit quand la bande passante chute, et le navigateur retire la voix de l’agent du micro de l’utilisateur. Si vos utilisateurs parlent à un agent depuis un navigateur ou une application mobile, c’est là que WebRTC justifie son coût de mise en place.
De vos serveurs aux modèles vocaux. Votre agent envoie de l’audio à un modèle de transcription et du texte à un modèle de synthèse vocale. Ces connexions relient des centres de données, où la perte de paquets est rare, donc la livraison ordonnée de TCP ne coûte presque rien. Vous voulez aussi ce que WebSocket apporte : des événements texte et de contrôle ordonnés à côté de l’audio, des contextes de requête et une authentification simple. C’est pourquoi les API vocales, y compris celle de Cartesia, diffusent en WebSocket.
Les appels téléphoniques. Un appelant sur une ligne téléphonique vous parvient par le réseau téléphonique, puis SIP et RTP, ou par le flux média d’un opérateur. Twilio Media Streams, par exemple, transmet l’audio de l’appel à votre serveur par un WebSocket en μ-law à 8 kHz. Ni WebRTC ni WebSocket ne se trouvent côté appelant. Si vous choisissez un transport pour des agents téléphoniques, lisez plutôt notre guide sur le trunk SIP.
La question utile est donc de savoir où se trouve le réseau peu fiable. Mettez WebRTC sur ce tronçon et utilisez WebSocket partout ailleurs.
Quand un WebSocket suffit côté client
WebRTC n’est pas indispensable pour chaque fonction vocale dans le navigateur. Un WebSocket direct depuis le client est un choix raisonnable quand :
- Le réseau est prévisible. Outils internes, bornes, applications de bureau sur des réseaux d’entreprise et démos.
- Vous prototypez. Une seule connexion, pas de serveur média, pas de TURN, et vous pouvez journaliser chaque événement.
- L’audio n’est pas conversationnel. Synthèse vocale en streaming pour la lecture à voix haute, ou dictée où un court blocage ne casse pas une conversation.
- Le client est un serveur. Un backend ou une fonction edge qui relaie l’audio d’ailleurs.
Dans ce cas, envoyez de petits segments audio, gardez un tampon de lecture court et arrêtez la lecture dès que l’utilisateur interrompt. Testez sur un réseau avec pertes avant de livrer. Les outils de développement du navigateur peuvent limiter la bande passante et la latence, mais pas abandonner des paquets : utilisez un conditionneur réseau au niveau du système ou un partage de connexion mobile.
Les architectures qui fonctionnent
Front end WebRTC, back end WebSocket. La configuration de production la plus courante. Le navigateur ou l’application de l’utilisateur rejoint une salle WebRTC sur LiveKit ou Daily. Votre agent tourne sur un serveur, rejoint la même salle et diffuse vers les modèles vocaux en WebSocket. LiveKit Agents et Pipecat fonctionnent ainsi, et leurs plugins Cartesia ouvrent un WebSocket vers Cartesia depuis le serveur. LiveKit et Daily, l’entreprise derrière Pipecat, sont tous deux clients de Cartesia. Le PDG de Daily, Kwindla Hultman, le résume ainsi : « Cartesia Sonic is the best voice model today for real-time multimodal use cases. »
WebSocket de bout en bout. Le navigateur envoie l’audio à votre serveur par un WebSocket, et votre serveur parle aussi aux modèles vocaux en WebSocket. C’est la pile la plus simple, et elle convient bien aux prototypes et aux réseaux maîtrisés. Les Cartesia Managed Agents acceptent aussi une connexion WebSocket directe : un serveur de confiance ou un navigateur muni d’un jeton d’accès de courte durée peut parler à un agent hébergé sans exécuter de code d’agent.
Téléphone en entrée, WebSocket à l’intérieur. Pour les agents téléphoniques, l’appel arrive par SIP ou par un opérateur de téléphonie, et les connexions de l’agent aux modèles vocaux restent en WebSocket. Les Managed Agents gèrent la partie téléphonique pour vous, avec des numéros Cartesia, Twilio ou votre propre trunk SIP.
Diffuser de l’audio vers Cartesia en WebSocket
Les API temps réel de Cartesia diffusent en WebSocket :
- Synthèse vocale :
wss://api.cartesia.ai/tts/websocketreçoit le texte au fil de votre LLM et renvoie des segments audio. Une connexion peut porter plusieurs contextes, et les continuations permettent à Sonic de prononcer une phrase avant que le LLM ait fini sa réponse. - Transcription : Ink-2 transcrit un flux de PCM brut en WebSocket et gère nativement la détection de fin de tour.
- Managed Agents :
wss://api.cartesia.ai/v1/agents/websocket/{agent_id}relie une application à un agent hébergé. Vous envoyez des événementsaudio_inputavec de l’audio en base64, par segments de 20 à 100 millisecondes, et vous lisez les événementsaudio_output. Quand l’utilisateur parle par-dessus l’agent, Cartesia envoieaudio_output_clearet votre client arrête la lecture.
Le WebSocket de l’agent accepte de l’audio mono sans en-tête en pcm_16000, pcm_24000, pcm_44100 ou mulaw_8000, et renvoie l’audio dans le même format :
{
"type": "session_create",
"audio": {
"input_format": "pcm_16000",
"output_delivery": "speaking_pace"
}
}Depuis un navigateur, ne mettez jamais de clé API dans le code client. Les navigateurs ne peuvent pas définir d’en-têtes WebSocket : votre serveur génère donc un jeton d’accès de courte durée, que le client passe en paramètre de requête. Le guide de l’API WebSocket contient un exemple de session complet.
Pour essayer, créez un agent dans le playground Cartesia, ou obtenez une clé API et diffusez votre premier audio avec le démarrage rapide de la synthèse vocale.