WebRTC : ce que c'est, architecture et principe de fonctionnement

Qu'est-ce que WebRTC

WebRTC (Web Real-Time Communication) est un projet open source initié par Google en 2011 et standardisé par le W3C (JavaScript API) et l'IETF (protocoles). Son objectif principal est de fournir une communication à faible latence entre navigateurs et applications sans installer de plugins ou de logiciels tiers.

Contrairement aux solutions traditionnelles (RTMP, HLS) où la vidéo passe par un serveur, WebRTC utilise une architecture peer-to-peer : les données sont transmises directement entre les participants. Cela offre une latence de 200-500 ms contre 3 à 10 secondes pour HLS — une différence cruciale pour les appels vocaux et vidéo, le streaming de jeux et la chirurgie à distance.

Selon Google WebRTC Team (2025), la technologie est utilisée dans des applications comptant plus de 5 milliards d'installations au total : Google Meet, WhatsApp, Discord, Telegram, Zoom (partiellement). Plus de 85% des startups financées par capital-risque dans les secteurs de la télésanté et de l'edtech choisissent WebRTC comme transport de base en temps réel.

Le développement mobile a bénéficié du support complet de WebRTC en 2013 avec la sortie de libjingle_peerconnection — une implémentation native pour Android et iOS. Aujourd'hui, les deux plateformes disposent de SDK stables avec prise en charge du codage matériel H.264 et VP8, de la caméra, du microphone et des haut-parleurs de l'appareil.

Architecture et protocoles WebRTC

L'architecture WebRTC se compose de trois couches. La couche supérieure est la JavaScript API (ou API native pour les plateformes mobiles), la couche intermédiaire est constituée des protocoles de transport, la couche inférieure concerne les codecs et la sécurité. Chaque couche résout sa propre tâche, mais toutes sont nécessaires à l'établissement de la connexion.

API principales de WebRTC

MediaStream (getUserMedia) — capture l'audio et la vidéo du microphone et de la caméra de l'appareil. RTCPeerConnection — gère la connexion P2P : codage, transport, adaptation du débit. RTCDataChannel — transmet des données arbitraires (texte, fichiers, messages binaires) sur le même canal.

// API JavaScript WebRTC (exemple de navigateur)
const pc = new RTCPeerConnection({
    iceServers: [
        { urls: "stun:stun.l.google.com:19302" }
    ]
});

pc.onicecandidate = (event) => {
    if (event.candidate) {
        sendToPeer(JSON.stringify(event.candidate));
    }
};

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

Protocoles en temps réel

WebRTC utilise SRTP (Secure Real-Time Transport Protocol) pour l'audio et la vidéo — une version sécurisée de RTP avec chiffrement AES-128. La gestion de session s'effectue via SCTP (Stream Control Transmission Protocol) sur DTLS. Chaque flux de données est obligatoirement chiffré : WebRTC n'a pas de mode non sécurisé.

• SRTP/SRTCP — transmission chiffrée des flux médias avec protection contre les attaques par rejeu
• DTLS-SRTP — établissement des clés de chiffrement via Datagram TLS sur UDP
• SCTP — livraison de données fiable ou partiellement fiable pour DataChannel
• ICE (Interactive Connectivity Establishment) — framework pour trouver un chemin réseau entre pairs
• Trickle ICE — version incrémentale d'ICE où les candidats sont envoyés au fur et à mesure de leur découverte, accélérant l'établissement de la connexion

NAT traversal : ICE, STUN et TURN

Le principal défi technique de WebRTC est d'établir une connexion P2P entre des appareils situés derrière un NAT (Network Address Translation). Sans mécanismes spéciaux, les appareils ne peuvent pas se joindre directement car leurs adresses IP locales ne sont pas visibles depuis Internet.

STUN — détermination de l'adresse publique

STUN (Session Traversal Utilities for NAT) — un serveur qui répond à la question « Quelle est mon adresse IP publique et mon port ?‬». Le client envoie une requête au serveur STUN, le serveur voit son adresse publique et la renvoie au client. Google maintient publiquement le serveur STUN stun:stun.l.google.com:19302.

// WebRTC sur iOS — configuration des serveurs ICE
import WebRTC

let config = RTCConfiguration()
config.iceServers = [
    RTCIceServer(
        urlStrings: ["stun:stun.l.google.com:19302"]
    ),
    RTCIceServer(
        urlStrings: ["turn:turn.example.com:3478"],
        username: "user",
        credential: "password"
    )
]

let pc = RTCPeerConnection(configuration: config)

TURN — connexion par relais

TURN (Traversal Using Relays around NAT) — un serveur relais pour les cas où STUN ne suffit pas (NAT symétrique ou pare-feu d'entreprise). Dans ce mode, toutes les données passent par le serveur TURN — cela réduit la vitesse et augmente la latence, mais garantit une connexion dans 99% des cas.

TURN est le composant le plus coûteux de l'infrastructure WebRTC, car le serveur fait passer tout le trafic médiatique à travers lui. Selon Coturn Project (2025), un serveur TURN typique avec 8 vCPU et 16 Go de RAM traite environ 200 appels audio simultanés ou 40 appels vidéo en HD.

Processus ICE

ICE collecte tous les candidats possibles (IP locale, IP publique via STUN, relais via TURN) et tente d'établir une connexion par ordre de priorité. Dès qu'au moins une paire de candidats (local-distant) réussit le test de connectivité, la connexion est considérée comme établie.

• Host candidates — adresse IP locale de l'appareil dans le sous-réseau (la plus rapide, mais ne fonctionne pas derrière un NAT)
• Server Reflexive candidates — IP publique obtenue via un serveur STUN
• Relay candidates — adresse du serveur TURN via lequel le relais s'effectue (la plus lente, la plus fiable)

WebRTC dans les applications mobiles

Pour le développement mobile, Google maintient libWebRTC — une bibliothèque native pour Android (AAR) et iOS (XCFramework). La bibliothèque inclut l'ensemble de la pile protocolaire, les codecs (VP8, VP9, H.264, AV1) et l'accélération matérielle pour le codage/décodage.

WebRTC sur Android

Le SDK Android fournit les classes PeerConnectionFactory, PeerConnection, MediaStream. L'application crée une fabrique, configure les codecs vidéo, capture le flux de la caméra via VideoCapturer et établit la connexion pair-à-pair via SDP offer/answer.

// WebRTC sur Android — initialisation
import org.webrtc.*;

PeerConnectionFactory.Initialize(PeerConnectionFactory.InitializationOptions
    .builder(context)
    .setFieldTrials("WebRTC-H264-HighProfile/Enabled/")
    .createInitializationOptions());

PeerConnectionFactory factory =
    PeerConnectionFactory.builder()
        .setVideoDecoderFactory(new DefaultVideoDecoderFactory(eglBase))
        .setVideoEncoderFactory(new DefaultVideoEncoderFactory(eglBase, true, true))
        .createPeerConnectionFactory();

WebRTC sur iOS

Le SDK iOS utilise une API Objective-C avec les wrappers RTCPeerConnectionFactory, RTCCameraVideoCapturer, RTCVideoTrack. Le codage matériel H.264 est disponible via VideoToolbox. Pour l'affichage vidéo, on utilise RTCMTLVideoView (Metal) ou RTCVideoRenderer.

// WebRTC sur iOS — capture vidéo depuis la caméra
let factory = RTCPeerConnectionFactory()
let capturer = RTCCameraVideoCapturer(delegate: factory)

// Sélection de la caméra (avant/arrière)
guard let device = RTCCameraVideoCapturer
    .captureDevices().first(where: {
        $0.position == .front
    }) else { return }

// Démarrer la capture avec FPS maximal
capturer.startCapture(
    with: device,
    format: RTCCameraVideoCapturer
        .supportedFormats(for: device).last!,
    fps: 30
)

Pour les appels vidéo en production, les applications mobiles utilisent généralement des wrappers SDK autour de libWebRTC : Twilio Video, Agora, Daily.co. Ces SDK simplifient la signalisation, la gestion des salles et fournissent des composants d'interface prêts à l'emploi pour afficher la grille vidéo des participants.

Signalisation et établissement de connexion

WebRTC ne spécifie pas de protocole de signalisation — l'échange de messages SDP (Session Description Protocol) entre pairs. Le développeur choisit le transport pour la signalisation : WebSocket, MQTT, SIP, XMPP ou API REST. La signalisation achemine l'offer, l'answer et les candidats ICE d'un pair à l'autre.

Échange SDP Offer/Answer

Le processus commence par la création d'une offer (l'initiateur décrit ses capacités médiatiques), transmise via la signalisation au second pair, qui répond par un answer. Après l'échange SDP, chaque pair démarre ICE et lance DTLS-SRTP pour le chiffrement du flux.

// Android — création et envoi d'offer
private fun startCall(peerConnection: PeerConnection) {
    val constraints = MediaConstraints().apply {
        mandatory["OfferToReceiveAudio"] = "true"
        mandatory["OfferToReceiveVideo"] = "true"
    }

    peerConnection.createOffer(object : SdpObserver {
        override fun onCreateSuccess(sdp: SessionDescription) {
            peerConnection.setLocalDescription(this, sdp)
            // Envoyer sdp.description au serveur de signalisation
            sendSdpOffer(sdp.description)
        }
    }, constraints)
}

Protocoles de signalisation

Pour les applications mobiles, la signalisation la plus courante est via WebSocket — un canal bidirectionnel sur TCP qui maintient une connexion persistante avec le serveur. Le serveur de signalisation est souvent un microservice distinct (Node.js, Golang, Elixir) qui achemine les messages entre les participants d'une salle.

• WebSocket — connexion bidirectionnelle persistante, surcharge minimale, choix standard pour la signalisation
• SIP sur WebSocket — protocole VoIP standard, s'intègre à l'infrastructure téléphonique existante
• MQTT — protocole pub/sub léger pour l'IoT et les réseaux faibles, mais avec une latence plus élevée
• Matrix / XMPP — protocoles décentralisés pour les applications axées sur la confidentialité

Après la fin d'ICE et DTLS-SRTP, la signalisation ne participe plus à la transmission des données — tout le trafic médiatique circule directement en P2P (ou via un relais TURN). Le serveur de signalisation peut être arrêté sans interrompre les appels actifs. C'est l'avantage clé de l'architecture décentralisée de WebRTC.