Qu'est-ce que le RSS podcast ? De `<enclosure>` à Podcasting 2.0, pourquoi la distribution ouverte reste essentielle | Mr. XYZ Downloader

Qu'est-ce que le RSS podcast, et pourquoi certains flux utilisent itunes:, content:encoded ou podcast: ? Ce guide explique l'histoire du RSS podcast, les différences entre formats de feed et pourquoi RSS reste central pour une distribution ouverte du podcast.

xyzdownloader a commencé comme un side project au second semestre de l'année dernière. L'idée de départ était très simple : me faciliter, à moi et à ma famille, l'écoute des podcasts, tout en faisant un peu de gestion d'information / de connaissances autour des podcasts.

Ce qui est intéressant, c'est que le projet a attiré de plus en plus d'utilisateurs cette année. Merci beaucoup.

En répondant aux retours des utilisateurs, en améliorant le produit et en ajoutant de nouvelles fonctions, j'ai commencé à étudier sérieusement les standards techniques derrière le Podcast RSS. Et plus j'avançais, plus cela devenait fascinant. Derrière ces balises XML apparemment froides se cache en réalité une longue histoire de guerres de standards, de rapports de force commerciaux et de vieux conflits de geeks.

Cet article reprend cette ligne principale et en propose une version blog, plus rapide à lire.

Si vous voulez lire directement la version longue complète, vous pouvez aller ici :

👉 « Scissions de RSS, contrôle d'Apple et offensive de Spotify : la guerre des standards jamais terminée derrière le podcast »

Toute republication non autorisée est interdite. Pour une republication, une citation ou une collaboration, merci de contacter l'auteur via son compte WeChat ou son compte X.

À l'époque des recommandations algorithmiques, de la distribution par plateformes, des écosystèmes d'apps et des jardins clos du contenu, il est presque surprenant que le podcast n'ait pas encore été entièrement réinventé par une seule plateforme. Quand vous vous abonnez dans Apple Podcasts, XiaoYuZhou, Pocket Casts ou même Spotify, ce qui fonctionne en dessous n'est souvent pas un protocole privé de plateforme, mais un flux XML publiquement accessible.

C'est précisément pour cela que le podcast est très différent de la vidéo courte, des flux sociaux ou du streaming musical. Au niveau de l'infrastructure, la logique n'est pas : « la plateforme possède votre distribution ». C'est plutôt : « le créateur possède son feed, et les plateformes le lisent ».

C'est pourquoi RSS mérite encore d'être compris aujourd'hui.

Le RSS podcast n'est pas une relique, c'est la base d'une distribution ouverte

Beaucoup de gens découvrent le RSS podcast lorsqu'ils essaient d'analyser un lien d'épisode, d'utiliser un outil de téléchargement ou d'ouvrir un vrai feed.

Et les questions arrivent aussitôt :

Pourquoi certains feeds sont-ils très propres, avec seulement des balises de base ?
Pourquoi d'autres sont-ils remplis de itunes:, atom:, content: et dc: ?
Pourquoi les feeds plus récents ajoutent-ils podcast:transcript, podcast:chapters et podcast:value ?

La réponse est simple :

Le RSS podcast n'a jamais été un standard unique fixé une fois pour toutes. C'est un écosystème qui a grandi grâce à la compatibilité dans le temps, aux négociations entre plateformes et à l'innovation portée par la communauté.

Il ressemble à un vieil arbre. Le tronc était là très tôt, mais de nouvelles branches ont continué à pousser.

Pourquoi le podcast s'est-il construit sur RSS ?

Le podcast n'a pas commencé avec les apps. Il a commencé avec la distribution.

Ce qui l'a rendu possible, c'est qu'autour de l'an 2000, RSS a obtenu une capacité décisive : attacher des fichiers média à un flux d'abonnement.

La balise clé ressemble à ceci :

XML

<enclosure url="http://www.example.com/episode.mp3"
           length="12345678"
           type="audio/mpeg" />

<enclosure> paraît banal, mais il a accompli quelque chose de décisif :

il a transformé les « mises à jour d'articles » en « distribution automatique de médias ».

RSS ne servait plus seulement à transmettre des titres et des résumés de blog. Il pouvait aussi livrer des fichiers audio. Ensuite, Adam Curry a utilisé des scripts pour télécharger automatiquement ces fichiers et les synchroniser avec un iPod. C'est à ce moment-là que le podcast a cessé d'être « de l'audio sur une page web » pour devenir un média abonnable, auto-mis à jour et écoutable hors ligne.

En bref : sans <enclosure>, il n'y aurait pas de podcast moderne.

Pourquoi des podcasts différents ont-ils des flux RSS si différents ?

Parce que le RSS podcast n'est pas simplement « un format ». C'est :

un noyau RSS 2.0 + des extensions par namespaces.

Le noyau RSS gère les éléments les plus essentiels :

le titre de l'émission
la description de l'émission
la date de publication
l'URL du fichier audio
l'identifiant unique

Mais dès que le podcast a commencé à grandir, cela n'a plus suffi. Les plateformes ont vite compris qu'il leur fallait aussi :

une image de couverture
des catégories
des métadonnées d'hôte
des indicateurs de contenu explicite
une numérotation par saison et épisode
des show notes plus riches
des chapitres
des transcriptions
des mécanismes de monétisation

C'est là que les extensions ont commencé.

Les 4 namespaces les plus fréquents

Si vous ouvrez quelques vrais flux de podcast, vous verrez le plus souvent ceux-ci :

1. `itunes:` : le standard de fait défini par Apple

C'est probablement la famille de balises la plus influente du podcast.

Elle répond à la question : comment une émission doit-elle être correctement affichée dans les principaux lecteurs de podcast ?

Par exemple :

<itunes:image>
<itunes:author>
<itunes:category>
<itunes:duration>
<itunes:episode>
<itunes:season>

Techniquement, RSS est ouvert. Mais dans la pratique, pendant longtemps, les exigences de compatibilité d'Apple Podcasts ont presque fait office de standard industriel.

Cela a créé une situation un peu étrange :

la base restait ouverte
les règles d'affichage étaient fortement modelées par Apple

C'est aussi l'une des raisons pour lesquelles Podcasting 2.0 a ensuite repris de l'élan.

2. `content:encoded` : pour de vraies show notes lisibles

La balise <description> de base ne suffit souvent pas.

Si vous voulez y mettre :

des références avec liens
des listes de timecodes
des introductions en texte enrichi
des images et notes complémentaires

alors vous avez souvent besoin de content:encoded.

La façon la plus simple de le comprendre est :

cela permet à RSS de transporter du HTML complet, et pas seulement un résumé.

C'est pourquoi les flux de médias traditionnels ou de plateformes d'hébergement plus professionnelles sont souvent bien plus riches.

3. `atom:link` : dire au client qui est réellement le feed

Beaucoup de flux modernes contiennent une ligne comme celle-ci :

XML

<atom:link href="https://feeds.example.com/podcast.xml"
           rel="self"
           type="application/rss+xml" />

Son rôle est discret, mais essentiel :

déclarer l'identité canonique du feed lui-même.

Cela est particulièrement utile lors d'une migration d'hébergement, d'un changement de domaine ou d'une mise à niveau du feed, car le client comprend plus fiablement quelle source il suit réellement.

4. `podcast:` : la nouvelle couche d'extension de Podcasting 2.0

Si itunes: représente la structure de pouvoir de l'ancien monde du podcast, podcast: ressemble davantage à la réponse d'une nouvelle génération de bâtisseurs de podcast ouvert.

Ces balises cherchent à ajouter des capacités longtemps absentes, par exemple :

<podcast:transcript> : transcription
<podcast:chapters> : chapitres
<podcast:person> : métadonnées des participants
<podcast:soundbite> : extraits marquants
<podcast:value> : pourboires Value4Value

La logique ici n'est pas de « remplacer RSS ».

C'est plutôt :

conserver la compatibilité de l'ancien écosystème tout en permettant à RSS d'acquérir de nouvelles capacités.

C'est l'une des plus grandes différences entre le podcast et les plateformes plus fermées. L'évolution ne passe pas par une migration forcée vers un tout nouveau protocole, mais par la rétrocompatibilité et l'extension progressive.

Pourquoi les plateformes donnent-elles l'impression d'appartenir à des « écoles » différentes ?

Si l'on classe grossièrement les vrais feeds de podcast, on retrouve généralement trois styles.

Style médias traditionnels

Chez des organisations comme NPR, on voit souvent :

moins de namespaces
une structure plus propre
une discipline plus forte vis-à-vis des standards
des show notes bien structurées

L'avantage : plus de stabilité, de clarté et une analyse plus simple.

Style plateformes d'hébergement

Des plateformes comme Simplecast, Buzzsprout ou Captivate sont souvent plus complètes :

itunes est là
atom est ajouté
content est pris en charge
les balises plus récentes sont suivies autant que possible

Comme ces services servent beaucoup de créateurs, leur objectif n'est pas la pureté, mais la compatibilité la plus large possible.

Style geek indépendant

Les podcasts techniques, les sites indépendants et les hébergeurs plus favorables aux créateurs expérimentent souvent davantage avec :

des show notes HTML plus riches
des métadonnées plus complètes
une adoption plus rapide de Podcasting 2.0

Ces feeds sont souvent le meilleur endroit pour observer où pourraient aller les standards ouverts du podcast.

Pourquoi RSS reste-t-il important aujourd'hui ?

Parce que RSS ne décide pas seulement comment un fichier est écrit, mais qui contrôle la distribution.

Si le podcast devient un contenu entièrement natif aux plateformes, que se passe-t-il ?

les créateurs ne peuvent plus migrer librement leurs abonnements
les auditeurs ne peuvent plus choisir librement leurs lecteurs
les plateformes peuvent décider unilatéralement de la recommandation, de la distribution et de la disparition
l'existence continue d'une émission dépend de la politique de la plateforme, pas du fait que le créateur possède encore un feed accessible

RSS représente un autre ordre :

les créateurs peuvent posséder leur propre feed
les auditeurs peuvent choisir leur propre lecteur
les clients peuvent se remplacer les uns les autres
les plateformes lisent, mais ne sont pas l'unique porte d'entrée

Voilà pourquoi RSS garde un poids particulier dans le podcast.

Ce n'est peut-être pas la technologie la plus à la mode, mais c'est une structure de distribution antifragile.

En quoi est-ce utile pour un auditeur ?

Plus qu'on ne l'imagine.

1. Vous comprenez mieux pourquoi certaines émissions peuvent être téléchargées et d'autres non

La présence d'un vrai flux RSS, d'un enclosure standard, ou au contraire l'enfermement dans une plateforme fermée, influence directement le téléchargement et la migration.

2. Vous comprenez pourquoi tous les liens de podcast ne sont pas aussi faciles à parser

Certaines plateformes ne sont au fond qu'un habillage web autour de RSS.

D'autres évoluent déjà vers des systèmes de contenu fermés, natifs à l'app.

En surface, les deux ressemblent à des pages d'épisodes. En profondeur, ce n'est pas du tout la même chose.

3. Vous pouvez mieux juger si une plateforme respecte vraiment créateurs et utilisateurs

Expose-t-elle un RSS ? Permet-elle la migration ? Reste-t-elle compatible avec les balises courantes ? Suit-elle les standards ouverts ? Ce ne sont pas de petits détails d'implémentation : ce sont des indices sur les valeurs de la plateforme.

Pour les créateurs, RSS compte encore davantage

Beaucoup de créateurs ne prêtent pas beaucoup d'attention à leur feed au début. Ils le confient à une plateforme d'hébergement en la laissant « tout gérer automatiquement ».

Mais à partir du moment où une émission devient un véritable actif de contenu, RSS devient l'une des choses les plus importantes à comprendre en dessous.

Vous devriez au minimum savoir :

quelle est l'URL de votre feed
quels namespaces votre hébergeur prend en charge
si la migration du feed est possible
si les extensions transcript / chapters / person / value sont prises en charge
si vos métadonnées sont complètes

Car sur le long terme, les épisodes sont l'actif, et le feed est la canalisation de distribution de cet actif.

Beaucoup d'outils de plateforme donnent l'impression de « vous aider à distribuer ». Mais ce qui détermine réellement votre marge de contrôle, c'est votre capacité à emporter cette relation de distribution ailleurs.

Un critère plus concret : RSS n'est pas de la nostalgie, il définit les frontières des capacités

Beaucoup de gens voient RSS comme un symbole sentimental du vieux web. Dans le podcast, c'est bien plus concret.

Il détermine :

si plusieurs clients peuvent lire votre émission
si elle peut être recherchée, migrée et sauvegardée
si vos relations d'abonnement survivent à un changement de politique de plateforme
si votre contenu peut passer de « page de plateforme » à « source de données sous votre contrôle »

La vraie question n'est donc jamais : « RSS est-il encore vivant ? »

La vraie question est :

tant que le podcast voudra préserver une distribution ouverte, RSS, ou un protocole ouvert équivalent, restera important.

Enfin : si vous voulez la version complète

Cette version blog sert surtout de guide rapide pour construire une bonne grille de lecture.

Si vous voulez la version longue, y compris :

l'histoire complète de Netscape à Dave Winer
la scission entre RSS 1.0, RSS 2.0 et Atom
comment le namespace itunes: d'Apple est devenu le standard de fait
pourquoi la stratégie de jardin clos de Spotify a provoqué un rejet
ce que Podcasting 2.0 a concrètement ajouté

vous pouvez continuer ici :