Qu'est-ce que M3U8 ? Guide complet du protocole HLS et de la playlist .m3u8

M3U8 est la playlist texte UTF-8 utilisée par le protocole HLS (HTTP Live Streaming). Le fichier lui-même ne contient aucune image vidéo : c’est un manifeste qui liste les URL des segments vidéo (.ts ou .m4s), leur durée et les variantes de bitrate disponibles. Le lecteur lit le .m3u8, récupère les segments dans l’ordre et les assemble en temps réel pour produire un flux vidéo lisible — c’est le mécanisme qui se trouve sous YouTube, Netflix, Twitch, Apple TV+ et la plupart des services de streaming majeurs en 2026.

Avez-vous déjà essayé de sauvegarder une vidéo depuis un site de streaming et vous êtes retrouvé avec des centaines de minuscules fichiers .ts au lieu d’un seul .mp4 bien rangé ? Ou ouvert un onglet Réseau dans votre navigateur, vous attendant à une URL de téléchargement propre, et avez plutôt trouvé un flot interminable de morceaux de deux secondes ? Vous ne faisiez rien de mal. Vous regardiez du HLS — le protocole qui livre la majeure partie de la vidéo en streaming sur le web moderne — et HLS ne livre pas les vidéos sous forme de fichiers uniques. Il les livre sous forme de recettes plus de morceaux.

La recette est un petit fichier texte appelé playlist .m3u8. Les morceaux sont de courts segments vidéo indépendamment décodables que votre lecteur assemble à la volée. HLS a été créé par Apple en 2009 pour le premier iPhone et standardisé sous RFC 8216 ; aujourd’hui, presque tous les principaux navigateurs, appareils mobiles et téléviseurs le prennent en charge nativement.

Ce guide parcourt ce qu’un .m3u8 contient réellement, pourquoi les services de streaming ont choisi cette conception, comment les segments .ts et fMP4 s’articulent, quelles plateformes utilisent HLS en 2026, et ce qui se passe quand vous essayez de sauvegarder l’un de ces flux sur disque.

Points clés {#key-takeaways}

• HLS est un protocole de streaming, pas un format de fichier. Il livre la vidéo sous forme d’une playlist (.m3u8) plus de courts segments (.ts ou MP4 fragmenté) via du HTTP simple.
• .m3u8 est l’index, pas la vidéo. Sauvegarder le fichier .m3u8 seul vous donne une recette sans ingrédients.
• Apple a créé HLS en 2009 pour l’iPhone et l’a standardisé sous RFC 8216 en 2017. Il est aujourd’hui obligatoire sur iOS/Safari et pris en charge presque universellement ailleurs.
• Les segments font 2–10 secondes de vidéo chacun — assez courts pour changer de qualité entre eux, assez longs pour garder une surcharge HTTP raisonnable.
• Une playlist maîtresse liste les variantes ; une playlist média liste les segments. Les lecteurs lisent la maîtresse, choisissent une variante, puis chargent la playlist média de cette variante.
• Les segments .ts sont en train d’être remplacés par du MP4 fragmenté (CMAF), pour que le même fichier puisse servir les lecteurs HLS et DASH depuis une seule origine.
• La majeure partie du streaming moderne repose sur HLS ou DASH, souvent les deux à la fois — y compris YouTube, Netflix, Disney+, Twitch, Apple TV+ et Cloudflare Stream.

M3U8 vs MP4 : les principales différences

Beaucoup rencontrent .m3u8 pour la première fois quand ils essaient d’enregistrer une vidéo et reçoivent un petit fichier texte au lieu du .mp4 attendu. Les deux formats apparaissent souvent dans le même flux de travail mais sont fondamentalement différents — l’un est une playlist (manifeste), l’autre un conteneur. Voici le tableau qui résume les différences les plus recherchées.

En une phrase : M3U8 est la “table des matières”, MP4 le “fichier fini”. Quand on regarde en ligne, le navigateur reçoit un manifeste M3U8 et tire les segments à la demande. Pour conserver une copie ou la partager, on finit presque toujours par recoller les segments en un MP4.

L’explication simple

Oubliez les protocoles une seconde. Imaginez un réalisateur qui doit livrer un film terminé à des spectateurs partout dans le monde sur un internet peu fiable. Envoyer un seul MP4 géant est inenvisageable : si la connexion d’un spectateur tombe en milieu de téléchargement, il repart de zéro, et il n’y a aucun moyen de changer de qualité sans tout retélécharger. Alors, à la place, le réalisateur découpe le film en centaines de clips de 6 secondes et écrit une playlist numérotée qui dit « lis le clip 001, puis 002, puis 003… ». Le lecteur du spectateur télécharge la playlist, récupère les premiers clips, et commence la lecture pendant que le reste arrive derrière. Si la connexion ralentit, le lecteur passe à une version de moindre qualité du clip suivant sans manquer une image.

C’est HLS en une phrase : un film découpé en courts clips, plus un fichier playlist .m3u8 qui dit au lecteur quel clip lire ensuite.

Du point de vue du spectateur, cette conception cache beaucoup de magie. La recherche est instantanée parce que le lecteur peut sauter vers le segment couvrant l’horodatage cible au lieu de parcourir tout le fichier. Les changements de qualité sont fluides parce que le lecteur peut choisir une variante différente pour le segment suivant sans redémarrer la lecture. La mise en tampon est douce parce que le lecteur n’a besoin de garder que quelques segments d’avance — généralement 10 à 30 secondes — au lieu de pré-télécharger d’énormes morceaux de fichier. Et le streaming en direct fonctionne tout court parce que de nouveaux segments peuvent être ajoutés à la playlist à mesure que le diffuseur les produit, le lecteur sondant le .m3u8 pour de nouvelles entrées toutes les quelques secondes.

Si vous vous êtes déjà demandé pourquoi un flux YouTube ou Netflix se relance en douceur quand votre Wi-Fi vacille, alors qu’un téléchargement MP4 direct depuis un site quelconque bloque et meurt, voici pourquoi. Toute la pile a été conçue autour de l’hypothèse qu’internet est désordonné et que les connexions vont et viennent. Une longue discussion sur comment les lecteurs adaptent la qualité à la volée vit dans son propre article ; ici, notez juste que la conception segment-et-playlist est ce qui rend cette adaptation possible.

Comment fonctionne réellement HLS

Un flux HLS, c’est deux couches de playlist plus un tas de segments, le tout servi via du HTTP ordinaire. Rien d’exotique, pas de protocole personnalisé — votre navigateur sait déjà comment faire chaque partie.

La playlist maîtresse

La première chose qu’un lecteur récupère est la playlist maîtresse. C’est un petit fichier texte avec une extension .m3u8 qui liste chaque variante disponible du flux — généralement différents niveaux de qualité — avec la bande passante et la résolution de chacune. Voici à quoi en ressemble une vraie, légèrement allégée :

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080,CODECS="avc1.640028,mp4a.40.2"
1080p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2800000,RESOLUTION=1280x720,CODECS="avc1.4d401f,mp4a.40.2"
720p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1400000,RESOLUTION=854x480,CODECS="avc1.4d401e,mp4a.40.2"
480p/index.m3u8

La ligne #EXTM3U marque le fichier comme une playlist M3U étendue. #EXT-X-VERSION:6 déclare quelle version du protocole HLS est utilisée. Chaque bloc #EXT-X-STREAM-INF décrit une variante : son bitrate, sa résolution et sa chaîne de codec, suivis d’une URL pointant vers une seconde playlist pour cette variante. Le lecteur lit ce fichier, estime votre bande passante, et choisit la variante qu’il pense pouvoir soutenir.

La playlist média

Une fois que le lecteur choisit une variante, il récupère la playlist média de cette variante. C’est là que vivent les URL de segments réelles :

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:6.000,
segment000.ts
#EXTINF:6.000,
segment001.ts
#EXTINF:6.000,
segment002.ts
#EXT-X-ENDLIST

#EXT-X-TARGETDURATION:6 dit qu’aucun segment ne dépasse 6 secondes. Chaque ligne #EXTINF:6.000, annonce la durée exacte d’un segment, suivie de l’URL du segment. #EXT-X-ENDLIST dit au lecteur qu’il s’agit d’un flux vidéo à la demande — aucun segment supplémentaire ne sera jamais ajouté. Les flux en direct omettent #EXT-X-ENDLIST, et le lecteur redemande cette playlist toutes les quelques secondes pour découvrir les nouveaux segments.

Segments : .ts et fMP4

Les segments sont de courts morceaux de vidéo et d’audio — généralement 2 à 10 secondes — coupés sur des frontières d’images-clés pour que le lecteur puisse commencer à décoder à partir du début de n’importe quel segment. Quand la playlist déclare #EXT-X-INDEPENDENT-SEGMENTS, chaque segment est garanti lisible seul ; sans cet indicateur, les segments en aval peuvent dépendre de données portées dans des segments antérieurs. Historiquement, les segments sont des fichiers MPEG-2 Transport Stream avec une extension .ts — le même format de conteneur qui livre la télévision satellite et câble. MPEG-TS a été conçu pour des canaux de diffusion bruyants, il est donc robuste face à la corruption partielle, et tout lecteur capable de décoder des paquets .ts peut lire un segment HLS.

La longueur typique d’un segment est de 2 à 10 secondes. Des segments plus courts signifient moins de latence et un changement de bitrate plus agile, mais plus de requêtes HTTP et plus de surcharge par minute de vidéo. Des segments plus longs signifient une meilleure efficacité de compression et moins de requêtes, mais une réaction plus lente aux changements de bande passante. La spécification d’origine d’Apple recommandait des segments de 10 secondes ; les services modernes se stabilisent généralement dans la plage 2–6 secondes.

Depuis 2016, l’industrie migre des .ts vers les segments MP4 fragmenté — plus précisément le Common Media Application Format (CMAF), standardisé sous ISO/IEC 23000-19. Les segments CMAF utilisent la même fragmentation MP4 que MPEG-DASH, ce qui signifie qu’un seul ensemble de fichiers sur un CDN peut servir à la fois les lecteurs HLS et DASH. C’est un gain de coût significatif pour les services de streaming : un encodage, un seul ensemble d’octets, deux protocoles. Les flux HLS modernes de YouTube, Netflix et Apple sont presque tous en CMAF plutôt qu’en MPEG-TS historique.

Du HTTP de bout en bout

Le « HTTP » dans HTTP Live Streaming, c’est la chute. Il n’y a pas de protocole spécial sur le câble — chaque partie de HLS voyage sur les mêmes requêtes HTTPS que votre navigateur utilise pour HTML et JPEG. Les CDN adorent ça parce qu’ils étaient déjà optimisés pour HTTP. Les pare-feu l’autorisent parce que rien ne paraît inhabituel. Les CDN peuvent mettre en cache les segments populaires à la périphérie. Range requests, gzip, HTTP/2, HTTP/3, TLS — tout fonctionne gratuitement.

C’est aussi pourquoi HLS a gagné. Les protocoles de streaming antérieurs comme RTMP, RTSP et MMS nécessitaient des ports dédiés, des serveurs avec état et des règles de pare-feu spéciales. HLS ressemble juste à un site web servant beaucoup de petits fichiers.

La plupart des utilisateurs n’ont pas besoin de gérer cela manuellement — VidMost analyse le manifeste .m3u8 et fusionne les segments dans un MP4 propre en arrière-plan.

Où vous rencontrez HLS dans le monde réel

HLS est sur pratiquement tous les grands services de streaming en 2026, souvent aux côtés de DASH. Apple a inventé HLS en 2009 spécifiquement pour livrer de la vidéo à l’iPhone d’origine — l’appareil ne gérait pas bien le téléchargement progressif sur les réseaux cellulaires, et Apple voulait un format de streaming qui ressemble à du trafic HTTP pour les opérateurs. Le protocole est depuis devenu la norme par défaut pour une énorme tranche d’internet.

• Les services propres d’Apple sont en HLS uniquement. Apple TV+, l’iTunes Store, les podcasts sur Apple Podcasts, et chaque vidéo qui se lit sur Safari, iOS ou tvOS reposent sur HLS. Les plateformes Apple ne livrent pas de décodeur MPEG-DASH intégré, donc tout service qui veut être lu sur iPhone doit offrir un flux HLS.
• YouTube utilise MPEG-DASH comme protocole principal sur le web et Android, mais livre HLS pour iOS, Safari, AirPlay et la plupart des applications TV. Ouvrez les outils de développement du navigateur sur YouTube dans Safari et vous verrez des requêtes .m3u8 ; dans Chrome sur Android vous verrez plutôt des requêtes DASH .mpd.
• Netflix, Disney+, Hulu, Max et Amazon Prime Video utilisent tous un mélange. Leurs applications de téléviseur connecté et de console utilisent fréquemment HLS avec DRM FairPlay ou PlayReady ; leurs lecteurs web basculent souvent vers DASH avec Widevine. Même contenu, protocole différent selon le client.
• Twitch tourne sur HLS depuis 2014 lorsqu’il a abandonné la pile RTMP historique côté lecture. Chaque flux en direct et chaque VOD sur Twitch est en HLS en dessous.
• Les plateformes de caméras en direct et pour créateurs — Bigo Live, Chaturbate, OnlyFans live, Fansly — utilisent presque universellement HLS pour la lecture en navigateur parce que ça fonctionne sans plugins et tolère les connexions capricieuses.
• Les fournisseurs vidéo hébergés comme Vimeo, Mux, JW Player et Cloudflare Stream livrent HLS par défaut. Si un site intègre un iframe Vimeo ou Mux, la vidéo en dessous est presque certainement en HLS.
• Les diffuseurs sportifs et d’actualités — ESPN, BBC iPlayer, DAZN, Sling TV — comptent tous sur HLS pour la livraison d’événements en direct, souvent avec du DRM par-dessus.

HLS a échappé à ses origines iOS parce qu’il résolvait de vrais problèmes pour tout le monde, pas seulement Apple. Au moment où DASH est arrivé en 2012, HLS bénéficiait déjà d’un large support CDN, de lecteurs fonctionnels en production et d’un élan. Aujourd’hui les deux protocoles coexistent ; un service de streaming bien pensé supporte les deux, et beaucoup livrent les mêmes segments CMAF sous les deux formats de manifeste. Pour plus sur comment DASH se compare à HLS en détail, l’article jumeau le couvre de bout en bout.

Ce que cela signifie si vous voulez sauvegarder la vidéo

Connaître le fonctionnement de HLS rend un problème pratique soudainement évident : vous ne pouvez pas simplement « clic droit → Enregistrer sous » votre chemin vers une vidéo HLS téléchargée. Quelques-unes des raisons sont mécaniques, quelques-unes subtiles, et une ou deux vous surprendront.

• Le Enregistrer sous du navigateur ne sauvegarde que le .m3u8. Le .m3u8 est ce que la page télécharge réellement lorsqu’elle démarre la lecture — un petit fichier texte. Le sauvegarder vous donne la recette, pas la nourriture. Ouvrir ce fichier dans VLC fonctionne parfois (VLC suivra les URL à l’intérieur), mais seulement tant que la session d’origine est encore valide et que les URL n’ont pas expiré.
• Chaque segment est une requête HTTP séparée. Une vidéo de 30 minutes en segments de 6 secondes représente 300 téléchargements séparés. Vous devriez énumérer la playlist, récupérer chaque segment et les concaténer dans le bon ordre avant qu’ils soient lisibles en un seul fichier.
• Le choix de la variante est un vrai choix. Les playlists maîtresses listent plusieurs qualités. Choisir la mauvaise vous donne une copie 480p d’un film qui streamait en 1080p. Le bon réflexe est généralement la variante de plus haute bande passante que votre stockage et votre patience peuvent absorber.
• HTTPS protège les octets en transit, pas les octets sur disque. Les URL de segments sont presque toujours servies via HTTPS, donc un oreille indiscrète sur le réseau ne peut pas lire ce que vous streamez. Mais une fois qu’un segment arrive à votre navigateur, c’est de la vidéo en clair — TLS ne fait rien pour arrêter un outil qui a déjà accès à la réponse.
• HLS supporte le chiffrement AES-128 des segments comme couche de contenu. Quand le .m3u8 porte une balise #EXT-X-KEY, chaque segment est chiffré avec AES-128 et la playlist pointe vers une URL de clé que le lecteur récupère via HTTPS. Sauvegardez les segments sans la clé et vous avez un dossier de chiffré. C’est du chiffrement de contenu, séparé de la sécurité de transport, et il n’a pas de vérification de droit intégrée — l’URL de la clé elle-même est le portillon.
• Le DRM commercial est un problème différent. Les services premium comme Netflix, Disney+ et Apple TV+ superposent à HLS du FairPlay (Apple), Widevine (Google) ou PlayReady (Microsoft). Le chiffrement sur le câble reste basé sur AES, mais les clés sont émises par un serveur de licences uniquement après que le lecteur a prouvé son droit sur un appareil de confiance, et le déchiffrement se produit à l’intérieur d’un module sécurisé soutenu par le matériel afin que les images ne touchent jamais la mémoire applicative. Voir Qu’est-ce que le contenu protégé par DRM ? pour le tableau complet.
• Les jetons et URL signées expirent. De nombreuses URL .m3u8 et URL de segments sont signées avec des jetons à courte durée qui périment en quelques minutes. Au moment où vous avez scripté manuellement le téléchargement, la moitié de vos liens peuvent déjà être morts.

C’est là que VidMost est conçu pour prendre le relais. VidMost est conçu pour la sauvegarde, dans le respect des règles, de contenus HLS auxquels vous avez un droit d’accès légitime : archives de vos propres livestreams, cours payants que vous avez achetés, vidéos sous licence libre ou du domaine public, supports de formation d’entreprise non protégés par un DRM commercial, et contenus d’abonnement payant dont les conditions de service autorisent le téléchargement. Il analyse le manifeste .m3u8, choisit la variante de plus haute qualité disponible, télécharge chaque segment en parallèle depuis le même CDN auquel votre navigateur parlait déjà, gère automatiquement le chiffrement AES-128 ordinaire au niveau des segments et remultiplexe les segments dans un seul fichier MP4 propre une fois terminé. Les flux protégés par un DRM commercial — FairPlay, Widevine ou PlayReady sur des services premium comme Netflix, Disney+ ou Apple TV+ — sortent du périmètre de VidMost ; respectez les conditions de service de chaque plateforme ainsi que la loi de votre pays. Pour le reste, l’expérience visible côté utilisateur est « collez une URL conforme, obtenez un MP4 » — la couche protocolaire disparaît.

Pièges et idées reçues fréquents

Une poignée d’idées fausses sur HLS apparaissent dans les fils de forum encore et encore. Cela vaut la peine de les clarifier.

• « .m3u8 n’est pas le fichier vidéo. » C’est l’index. La vidéo réelle se trouve dans les segments référencés par la playlist. Si un outil propose de « télécharger le m3u8 », demandez s’il récupère et fusionne aussi les segments — sinon vous avez un fichier texte inutile.
• « Les fichiers .ts ne se lisent pas directement dans la plupart des lecteurs. » Un seul segment peut se lire quelques secondes dans VLC, mais la vidéo entière n’est pas une séquence de fichiers .ts dans un dossier — c’est une séquence où chacun doit être décodé dans l’ordre et assemblé. Les lecteurs qui ne parlent pas HLS liront au mieux le premier segment et s’arrêteront.
• « HLS ne signifie pas toujours en direct. » « HTTP Live Streaming » est un nom trompeur en 2026. HLS fonctionne tout aussi bien pour la vidéo à la demande : mêmes playlists, mêmes segments, juste avec #EXT-X-ENDLIST marquant un flux fini. La grande majorité du contenu du catalogue Netflix, Disney+ et Apple TV+ est du HLS VOD, pas du direct.
• « Un bitrate plus élevé n’est pas toujours une meilleure qualité si votre connexion tombe. » Une variante 10 Mbps a fière allure sur la fibre et bégaie misérablement sur un lien mobile à 3 Mbps. Tout l’intérêt de la conception adaptative est que le lecteur choisit ce que votre connexion peut soutenir — l’outrepasser manuellement rend souvent l’expérience pire, pas meilleure.
• « Les outils de téléchargement de navigateur échouent généralement sur HLS. » Les extensions génériques de « téléchargeur vidéo » cherchent des balises <video src="..."> pointant vers des fichiers MP4. Les flux HLS n’exposent pas une URL comme ça ; le lecteur utilise les Media Source Extensions pour alimenter les segments à l’élément vidéo de manière programmatique. C’est précisément pourquoi des outils dédiés qui analysent le manifeste existent.

Pour conclure

HLS est l’infrastructure silencieuse sous la plupart de la vidéo que vous regardez. Il fonctionne parce qu’il a renoncé à essayer d’être astucieux sur le transport — pas de protocole personnalisé, pas de serveur spécial, juste des fichiers texte .m3u8 et des segments .ts ou fMP4 récupérés sur le même HTTP que votre navigateur parle déjà. Apple a résolu un problème de téléphone en 2009 et a accidentellement construit le format de streaming dominant des deux décennies suivantes.

Une fois que vous pouvez reconnaître une requête .m3u8 dans l’onglet réseau de votre navigateur et lire une playlist, une énorme quantité de comportements de streaming — les brefs changements de qualité, la recherche instantanée, l’indicateur « tampon d’avance », l’étrange dossier de fichiers .ts avec lequel vous vous êtes retrouvé — cesse d’être mystérieuse. C’est toujours la même boucle : récupérer la playlist, choisir la variante, récupérer les segments, décoder, répéter.

Si vous préférez sauter complètement la couche protocolaire et simplement sauvegarder la vidéo, VidMost gère HLS, DASH, fMP4 et les flux protégés par DRM.

Pour aller plus loin

• Comment la vidéo en ligne se lit réellement — le pipeline complet de la caméra à votre écran.
• MPEG-DASH face à HLS — quand chaque protocole l’emporte et pourquoi la plupart des services de streaming livrent les deux.
• Pourquoi la qualité vidéo change en cours de lecture — la logique ABR à l’intérieur de chaque lecteur HLS et DASH.
• Conteneurs vidéo face aux codecs — ce qu’il y a vraiment dans un .mp4, .ts ou .m4s.
• Qu’est-ce que le contenu protégé par DRM ? — comment Widevine, FairPlay et PlayReady gardent les variantes chiffrées que vous ne pouvez pas simplement sauvegarder.