RSS ou Atom : ce que révèle le recensement des flux réellement suivis (93 % contre 5 %)
La question « RSS ou Atom ? » n'a plus vraiment lieu d'être, et les chiffres sont sans appel. Sur les adresses de flux réellement suivies par les utilisateurs de Proofite, recensées et téléchargées le 23 août 2026 : 93 % déclarent <rss version="2.0">, 5 % sont en Atom 1.0, 1 % utilisent la syntaxe RDF de RSS 1.0, et 1 % ne sont plus des flux du tout — ils renvoient une page HTML ou ne répondent plus. Dix-huit flux RSS pour un flux Atom. Mais le détail qui change tout : 88 % des flux RSS 2.0 déclarent le namespace Atom, et 89 % déclarent Dublin Core — soit 82 % et 90 % si l'on rapporte le calcul à l'ensemble des flux valides, Atom et RDF compris. Autrement dit, les formats ne se disputent pas le terrain, ils s'emboîtent. Ce qu'il faut publier ? Ce que votre CMS produit déjà.
Atom a gagné la bataille technique et perdu celle des chiffres
Atom est un standard au sens strict : RFC 4287, publiée par l'IETF en décembre 2005. Modèle de données propre, dates dans un seul format, langue déclarable élément par élément, distinction explicite entre texte brut et HTML, type MIME enregistré dans les règles. RSS, lui, n'est jamais passé devant un organisme de normalisation. Netscape publie la première version en mars 1999, UserLand reprend la branche XML en juin 2000, et la spécification circule ensuite de main en main.
Résultat : 5 % contre 93 %. Le format rigoureux est marginal, le format bricolé est partout. Ce n'est pas une anomalie du Web, c'est sa règle habituelle — l'antériorité et l'implémentation par défaut pèsent plus lourd qu'un document de l'IETF.
La guerre des formats s'est terminée par une fusion
Regardez l'en-tête d'un flux de presse française — Le Monde, Les Échos, Numerama — et vous y trouverez presque toujours la même chose : une balise <rss version="2.0"> suivie d'une demi-douzaine de déclarations de namespaces, dont xmlns:atom.
Dans le recensement, 82 % des flux valides déclarent ce namespace Atom. La raison est presque toujours la même : <atom:link rel="self">, qui déclare l'adresse canonique du flux. RSS 2.0 seul ne sait pas faire ça. Un agrégateur qui reçoit le document par un autre chemin — un copier-coller, un proxy, un export — n'a aucun moyen de savoir où revenir le chercher. Atom fournit la pièce manquante, RSS fournit le contenant.
Huit flux sur neuf sont donc les deux à la fois. Choisir entre RSS et Atom, dans ce corpus, c'est un arbitrage que quasiment personne n'effectue réellement.
RSS 1.0 : perdant en syntaxe, vainqueur en vocabulaire
C'est la partie de l'histoire qu'on raconte rarement. RSS 1.0, publié le 6 décembre 2000 par le RSS-DEV Working Group — un groupe indépendant, pas le W3C, contrairement à ce qu'on lit souvent — a construit son flux sur RDF. Une syntaxe lourde, incompatible avec la branche UserLand. UserLand a répliqué dix-neuf jours plus tard avec RSS 0.92, puis RSS 2.0 en août 2002.
Aujourd'hui, 1 % des flux utilisent encore la syntaxe RDF. Mais 90 % des flux valides déclarent xmlns:dc : Dublin Core, le vocabulaire de métadonnées que RSS 1.0 avait adopté. dc:creator pour l'auteur, dc:date pour la date. La branche perdante de la scission de décembre 2000 survit en pièces détachées, à l'intérieur du format qui l'a battue.
Et non, RSS 1.0 n'est pas plus récent que RSS 2.0. C'est la confusion la plus fréquente. Ce sont deux branches parallèles ; le numéro le plus élevé n'indique pas la version suivante. version="2.0" signifie « branche UserLand », pas « deuxième version » — cette même chaîne de caractères recouvre onze révisions de la spécification entre 2002 et 2009.
Ce qui ressemble à un choix éditorial est un réglage d'usine
Le classement des extensions par diffusion, sur les flux valides : dc 90 %, atom 82 %, content 75 %, sy 49 %, slash 48 %, wfw 46 %, media 35 %, itunes 7 %.
Les six premières sont exactement les namespaces que WordPress émet par défaut. content:encoded pour le texte intégral, sy pour la fréquence de mise à jour, slash pour le nombre de commentaires, wfw pour le flux de commentaires d'un article donné. Personne n'a délibéré. La structure de la majorité des flux du Web francophone est la sortie standard d'un CMS installé sans y toucher.
Les 35 % de media (Media RSS : vignettes, durées, licences) correspondent, eux, à un choix plus assumé — souvent celui des sites d'actualité qui veulent voir leurs images apparaître dans les lecteurs.
Le type MIME est faux dans plus d'un tiers des cas
63 % des flux valides sont servis avec le bon content-type : 61 % en application/rss+xml, 2 % en application/atom+xml. Le reste se rabat sur un type générique — 22 % en application/xml, 14 % en text/xml, un cas en text/html. Soit 37 % d'erreurs.
L'explication est historique. application/rss+xml n'a jamais été enregistré auprès de l'IANA : deux Internet Drafts déposés, puis laissés expirer, faute d'un organisme reconnu derrière RSS. application/atom+xml, lui, est enregistré normalement via la RFC 4287. Le format dominant utilise donc un type MIME officieux.
Conséquence pratique : à peu près nulle pour les agrégateurs, qui regardent le contenu du document et pas l'en-tête HTTP. Sérieuse pour les navigateurs, en revanche. Beaucoup, en recevant application/rss+xml, téléchargent le fichier au lieu de l'afficher. C'est pour cette raison que certains éditeurs reviennent délibérément à text/xml : le flux reste lisible dans un onglet.
Détail à corriger sans discuter : 2 % des flux suivis sont encore servis en HTTP non chiffré.
L'audio est la partie de RSS qui n'a jamais vacillé
21 % des flux contiennent au moins une balise <enclosure>, et 7 % déclarent le namespace itunes — ce sont les podcasts au sens strict, avec catégorie, durée, jaquette.
<enclosure> apparaît dans RSS 0.92, en décembre 2000, proposée par Tristan Louis et poussée par Adam Curry. Elle est restée sans public pendant trois ans. Puis le podcast est arrivé, et cette balise est devenue l'infrastructure d'une industrie entière : Apple Podcasts, Spotify, Deezer n'hébergent pas les épisodes, ils indexent des flux RSS publics.
La panne la plus grave ne déclenche aucune erreur
Un flux qui répond en HTTP 200, avec un XML impeccable, mais dont l'item le plus récent date de plus de six mois, est une source éteinte. Aucun validateur ne le signalera. Aucun lecteur n'affichera d'alerte. Dans un agrégateur, le silence se lit comme « pas d'actualité », pas comme « source morte ».
C'est le vrai risque de l'agrégation, et il se cumule avec un autre. Un lecteur actif type suit 70 sources chez Proofite : 30 flux RSS, 20 recherches web, 19 newsletters, 1 profil social, réparties dans 8 dossiers thématiques. À ce volume, personne ne remarque qu'une source a cessé de publier. Le seul contrôle qui fonctionne, c'est de regarder la date du dernier item — pas l'absence de nouveautés.
Le même volume produit deux autres effets, mesurés en juillet 2026 sur les emails et les digests réels. Sur 4 digests (37 entrées), 27 % des entrées viennent de deux rédactions ou plus qui racontent le même fait : un tour de financement couvert simultanément par Coindesk, Wired et un quotidien généraliste ; un incident de sécurité IA repris par Import AI, TLDR AI et deux titres économiques. Et sur 40 newsletters analysées, 12 (30 %) contiennent au moins un bloc sponsorisé déclaré — dans une édition de PetaPixel, l'encart pesait 959 caractères, soit 18 % du texte utile ; 624 caractères dans TLDR AI. Le flux RSS, lui, ne vous envoie pas de publicité.
Ce qu'il faut vérifier sur votre propre flux
Regardez la première balise. Si ce n'est pas <rss, <rdf:RDF ou <feed, vous ne publiez pas un flux. C'est ce test qui a écarté 1 % des adresses du recensement.
Cherchez <atom:link rel="self">. Sans elle, un agrégateur qui obtient votre document autrement qu'en le téléchargeant ne sait pas où le recharger.
Donnez un <guid> à chaque item, avec isPermaLink="true" s'il coïncide avec l'URL de l'article. C'est ce qui évite les doublons quand vous corrigez un titre après publication.
Placez l'autodiscovery dans le <head> : <link rel="alternate" type="application/rss+xml" title="RSS" href="...">. Formalisée par le RSS Advisory Board en 2006, elle permet aux lecteurs de trouver le flux depuis la page d'accueil.
Passez le tout dans validator.w3.org/feed. Il signale aussi les défauts qui dégradent la lecture sans l'empêcher — typiquement les dates dans un format ambigu.
Et publiez ce que votre CMS génère. Si en revanche vous écrivez un générateur à partir de zéro, prenez Atom : modèle de données plus précis, type MIME enregistré, moins de décisions arbitraires à prendre.
Questions fréquentes
RSS ou Atom : lequel choisir pour mon site ?
Celui que votre CMS produit déjà. Tous les lecteurs répandus lisent les deux, et dans le recensement du 23 août 2026, 88 % des flux RSS 2.0 déclarent déjà le namespace Atom — la question ne se pose donc presque jamais en pratique. Si vous développez un générateur de flux à partir de zéro, choisissez Atom : dates dans un format unique, langue par élément, distinction explicite texte/HTML, et type MIME enregistré auprès de l'IANA.
RSS 1.0 est-il plus récent que RSS 2.0 ?
Non. RSS 1.0 date du 6 décembre 2000, RSS 2.0 d'août 2002, et ce sont deux branches issues d'une scission, avec des syntaxes incompatibles. RSS 1.0 repose sur RDF et a été produit par le RSS-DEV Working Group, un groupe indépendant — pas par le W3C. Le numéro le plus élevé n'indique pas la version suivante.
Que signifie exactement version="2.0" dans un flux ?
« Branche UserLand », et rien de plus précis. Cette même chaîne recouvre onze révisions de la spécification entre 2002 et 2009. Elle ne vous dit pas quels éléments le flux contient réellement : pour le savoir, il faut lire les namespaces déclarés.
Mon flux est servi en text/xml au lieu de application/rss+xml. C'est grave ?
Presque pas. Les agrégateurs analysent le contenu du document, pas l'en-tête HTTP. Dans le recensement, 37 % des flux valides sont servis avec un type MIME incorrect et fonctionnent normalement. Le seul vrai symptôme est côté navigateur : application/rss+xml déclenche souvent un téléchargement au lieu d'un affichage, ce qui pousse certains éditeurs à revenir volontairement à text/xml.
Pourquoi existe-t-il autant de versions de RSS ?
Parce que le format a été développé en parallèle par des groupes en désaccord, et qu'aucune version n'est jamais passée devant un organisme de normalisation. Netscape publie RSS en mars 1999, UserLand reprend la branche XML en juin 2000, le RSS-DEV Working Group publie RSS 1.0 en décembre 2000, UserLand répond dix-neuf jours plus tard avec RSS 0.92. Atom, en décembre 2005, est la seule tentative aboutie de standardisation formelle.
Comment savoir si un flux que je suis est mort ?
Regardez la date de l'item le plus récent. Un flux qui répond correctement mais dont la dernière publication a plus de six mois est une source éteinte, et aucun lecteur ne vous le signalera : dans un agrégateur, le silence ressemble à une absence d'actualité.
Les podcasts utilisent-ils encore RSS ?
Oui, de bout en bout. 21 % des flux du recensement contiennent au moins une balise <enclosure> et 7 % déclarent le namespace itunes. Les plateformes d'écoute n'hébergent pas les épisodes, elles indexent des flux RSS publics — la balise <enclosure>, apparue en décembre 2000, est l'infrastructure de tout le secteur.
---
Note de méthode. Les pourcentages de formats, de namespaces et de types MIME proviennent du recensement des adresses de flux distinctes réellement suivies par les utilisateurs de Proofite, téléchargées et classées le 23 août 2026 en lisant l'élément racine et les namespaces déclarés dans chaque document. Mesure répétée, pourcentages mis à jour. Ce n'est pas un échantillon représentatif du Web : ce sont les sources qu'une communauté de lecteurs actifs a choisi de suivre, donc déjà filtrées vers des sites vivants et entretenus — d'où seulement 1 % de flux injoignables, part qui serait bien plus élevée sur un tirage aléatoire. Les chiffres sur les newsletters et les digests (publicité, redondance entre sources, nombre de sources par utilisateur) viennent d'une analyse automatique du corps des emails reçus et des digests générés en juillet 2026 — pas de déclarations d'éditeurs ni de sondages. Données brutes, une ligne par flux, disponibles sur demande.