RTMP vs WebRTC : deux protocoles, deux philosophies du temps réel

La première fois que j'ai streamé sur Twitch, j'ai ouvert deux fenêtres côté à côté : OBS d'un côté, le lecteur de mon propre stream de l'autre. Le décalage était d'environ 25 secondes. Je ne voyais pas ce que je faisais en temps réel — je regardais le passé.

C'est le propre de RTMP. Et c'est précisément pourquoi WebRTC existe. Ces deux protocoles font du "temps réel", mais leur définition du mot n'est pas la même. L'un tolère 30 secondes de délai, l'autre vise 200 millisecondes. Ce n'est pas une différence de degré, c'est une différence de nature.

RTMP — le protocole des streamers

RTMP signifie Real-Time Messaging Protocol. Adobe l'a développé à l'origine pour Flash Player, pour transporter de l'audio et de la vidéo entre un serveur et un client Flash. Le nom "temps réel" vient de l'époque où la concurrence, c'était le téléchargement progressif — télécharger une vidéo avant de la lire. Par rapport à ça, 30 secondes de latence, c'était révolutionnaire.

Le protocole fonctionne sur TCP, ce qui explique une partie de ses caractéristiques. TCP garantit l'ordre et la livraison de chaque paquet — si un paquet se perd, le protocole attend qu'il soit retransmis avant de continuer. Pour comprendre pourquoi ça compte, l'article sur TCP vs UDP explique le mécanisme en détail. Dans le contexte vidéo, cette fiabilité a un coût : la latence s'accumule chaque fois que le réseau perd un paquet.

En pratique, RTMP s'est imposé comme le protocole d'ingest universel : c'est ce qu'OBS envoie à Twitch, YouTube, ou n'importe quel serveur de diffusion. Le flux arrive au serveur, qui le transcode, le segmente en HLS (pour les navigateurs), et le distribue. Le spectateur ne voit jamais du RTMP — il voit du HLS dans son navigateur, avec encore quelques secondes de latence supplémentaires dues à la segmentation.

Ce que RTMP fait bien :

• Supporté nativement par tous les logiciels de capture (OBS, Streamlabs, XSplit)
• Stable sur des connexions variables grâce à TCP
• Simple à configurer côté émetteur
• Infrastructure mature — nginx-rtmp, Wowza, AWS IVS, tous le parlent

Ce qu'il ne fait pas :

• Latence incompressible de 3 à 30 secondes selon la chaîne de transcoding
• Pas de communication bidirectionnelle native
• Pas de chiffrement intégré (RTMPS existe, mais c'est RTMP dans TLS, pas une vraie solution)
• Mort côté navigateur — sans plugin Flash, impossible de lire du RTMP directement

WebRTC — le protocole des visioconférences

WebRTC est une technologie open source que Google a rachetée en 2010 (en acquérant Global IP Solutions) et publiée comme standard ouvert. L'objectif était différent dès le départ : communication en temps réel directement dans le navigateur, sans plugin.

La différence fondamentale avec RTMP est dans la couche transport : WebRTC utilise UDP, pas TCP. Quand un paquet se perd, WebRTC ne l'attend pas — il continue avec les données disponibles et laisse le codec vidéo gérer la dégradation. Une image un peu floue pendant une fraction de seconde est préférable à un gel pendant 500ms en attendant la retransmission. Pour un appel vidéo, ce choix est évident.

WebRTC va plus loin que le simple choix UDP. Le protocole inclut DTLS pour la négociation de clés, SRTP pour chiffrer l'audio et la vidéo, et ICE pour traverser les NAT. Ce dernier point est important : la sécurité est intégrée par défaut, pas optionnelle. Il est impossible de faire du WebRTC non chiffré — la spec l'interdit.

La latence résultante est de l'ordre de 100 à 500ms. Pas zéro, mais assez peu pour qu'une conversation soit naturelle.

Ce que WebRTC fait bien :

• Latence sub-seconde, souvent sous 200ms en conditions normales
• Natif dans tous les navigateurs modernes — zéro plugin
• Chiffrement de bout en bout obligatoire
• Bidirectionnel — conçu pour que les deux parties parlent en même temps

Ce qu'il ne fait pas :

• Scale difficilement en natif — la connectivité P2P fonctionne pour 2-3 participants, au-delà il faut un SFU (Selective Forwarding Unit)
• Configuration réseau complexe (STUN, TURN, ICE candidates)
• Pas de support universel dans les outils de capture grand public
• Consommation CPU plus élevée — chiffrement + codec + traversée NAT à chaque paix

Ce que la mort de Flash a changé

Flash a été officiellement arrêté fin 2020. En pratique, les navigateurs l'avaient tué bien avant. Cet événement a forcé une réorganisation complète de la stack vidéo live.

Avant 2015, le workflow type d'un stream regardé dans un navigateur était : RTMP ingest → serveur → Flash Player → spectateur. Le spectateur avait Flash installé, le navigateur lisait le flux RTMP directement. La latence totale pouvait descendre à 5-8 secondes.

Sans Flash, ce pipeline s'est cassé. Les plateformes ont adopté HLS comme format de sortie, acceptant au passage une latence supplémentaire due à la segmentation (chaque segment HLS dure 2 à 10 secondes). RTMP reste en entrée — l'ingest — mais disparaît côté spectateur.

Parallèlement, WebRTC a comblé le vide pour les cas d'usage interactifs. Les outils de e-learning, de gaming interactif, de live shopping, qui avaient besoin de latence vraiment faible, ont migré vers WebRTC. Des solutions comme Agora, Livekit, Daily.co ont construit des infras SFU WebRTC qui permettent de scaler à des milliers de spectateurs avec moins d'une seconde de délai.

Deux outils pour deux besoins

La question "lequel choisir" n'est pas la bonne question. Les deux résolvent des problèmes différents.

Tu diffuses un stream Twitch, une émission YouTube, un webinar sans interaction ? RTMP reste le choix par défaut. Ton logiciel de capture le parle nativement, toutes les plateformes le supportent en ingest, l'infrastructure est mature. La latence de 30 secondes n'est pas un problème si personne ne s'attend à interagir en dessous.

Tu construis une visioconférence, un cours interactif, un système de live shopping où l'hôte répond aux questions en direct ? WebRTC est indispensable. Pas parce que RTMP ne pourrait pas techniquement transporter le flux, mais parce qu'une latence de 30 secondes rend toute interaction impossible. Quelqu'un pose une question, tu vois la réponse 30 secondes plus tard — la conversation est brisée.

Ce que la mort de Flash a vraiment changé, ce n'est pas le protocole de streaming — c'est la clarification des rôles. RTMP reste le protocole d'ingest, robuste et universel. WebRTC a pris la place de Flash pour tout ce qui demande de la réactivité. La compréhension de comment les données circulent sur internet aide à voir que ces deux protocoles occupent des couches différentes d'un même pipeline.

Si tu construis quelque chose qui mêle les deux — un stream public avec une couche d'interaction en temps réel — la réponse technique est souvent d'utiliser les deux. RTMP pour la large diffusion, WebRTC pour le canal interactif. C'est exactement ce que font les plateformes de live commerce asiatiques depuis cinq ans. On commence seulement à voir ça arriver en Europe.