Comment suivre les versions GitHub dans un lecteur RSS

Chaque dépôt possède un flux de versions

GitHub publie un flux de versions pour chaque dépôt public. Ajoutez /releases.atom à la fin de l'adresse du dépôt :

https://github.com/OWNER/REPO/releases.atom

Pour GitHub CLI, dont le dépôt est cli/cli, cela donne :

https://github.com/cli/cli/releases.atom

Le flux est au format Atom, un format que les lecteurs RSS gèrent de la même façon que RSS. Chaque entrée correspond à une version, avec son titre, un lien vers la page de version, la date de publication et les notes de version telles que les mainteneurs les ont rédigées sur GitHub. Le flux contient les 10 versions les plus récentes. Vous n'avez besoin ni d'un compte GitHub, ni d'un jeton, ni d'un service tiers pour l'utiliser.

Ajouter un flux de versions à SereneReader

1. Ouvrez le dépôt sur GitHub et copiez la partie OWNER/REPO de l'adresse, par exemple cli/cli.
2. Construisez l'URL du flux : https://github.com/cli/cli/releases.atom.
3. Dans SereneReader, cliquez sur Ajouter un flux en bas de la barre latérale et collez l'URL dans URL du flux.
4. Renseignez le Titre personnalisé. GitHub nomme le flux d'après le dépôt uniquement, donc le flux GitHub CLI apparaît sous la forme « Release notes from cli ». Un titre tel que « GitHub CLI releases » est plus facile à retrouver dans la barre latérale.
5. Choisissez un Dossier si vous en avez un pour les versions, puis cliquez sur Ajouter un flux.

Les nouvelles versions arrivent alors avec vos autres articles, et les notes de version s'ouvrent dans le lecteur comme n'importe quel autre article.

Regrouper les flux de versions dans un dossier

Si vous suivez plus de quelques projets, créez un dossier pour les regrouper. Cliquez sur Nouveau dossier dans la barre latérale, donnez-lui un nom tel que « Versions », et sélectionnez-le lors de l'ajout de chaque flux. Ouvrez le dossier quand vous souhaitez voir ce qui a changé dans les outils que vous utilisez, et laissez-le fermé le reste du temps.

Autres flux publiés par GitHub

Le même principe fonctionne pour quelques autres pages. Nous avons vérifié chacun de ces flux sur de vrais dépôts le 3 novembre 2026.

Quelques exemples à copier-coller :

https://github.com/cli/cli/tags.atom
https://github.com/cli/cli/commits/trunk.atom
https://github.com/cli/cli/commits.atom
https://github.com/cli/cli/discussions.atom
https://github.com/vitejs/vite/commits/main/packages/vite/CHANGELOG.md.atom
https://github.com/torvalds.atom

Quelques précisions utiles :

• /commits.atom sans branche suit la branche par défaut du dépôt. Pour cli/cli, cela retourne les mêmes entrées que /commits/trunk.atom.
• Une branche inexistante retourne une erreur 404 ; vérifiez le nom de la branche si un lecteur indique qu'il ne trouve pas le flux.
• Le flux de fichier est utile pour les journaux de modifications. Certains projets rédigent leurs notes dans un fichier CHANGELOG.md plutôt que dans les versions GitHub. Suivre les commits de ce fichier vous informe de chaque modification du journal, comme dans l'exemple Vite ci-dessus.
• Les projets qui taguent des versions sans publier de versions GitHub disposent tout de même d'un flux de versions fonctionnel. Linux et Go ne publient pas de versions GitHub, et leurs flux releases.atom listent leurs tags à la place. Le texte de l'entrée est le message de commit, donc il est court.

Qu'en est-il d'une organisation entière ?

GitHub ne publie pas de flux de versions couvrant l'ensemble d'une organisation. https://github.com/ORG.atom retourne un flux valide, mais il contient des événements d'organisation tels que l'ajout de personnes à des dépôts. Pour les organisations cli et github, il était vide. https://github.com/orgs/ORG.atom retourne une page web, pas un flux.

Pour suivre tous les dépôts d'une organisation, abonnez-vous au flux de versions de chaque dépôt. Vous n'avez pas besoin de le faire à la main : le script ci-dessous interroge l'API GitHub pour obtenir les dépôts publics de l'organisation et génère un fichier OPML, le format utilisé par les lecteurs pour importer une liste de flux. Il nécessite curl et jq, lit jusqu'à 100 dépôts et ignore les dépôts archivés.

ORG=cli

curl -s "https://api.github.com/orgs/$ORG/repos?per_page=100&type=public" \
  | jq -r --arg org "$ORG" '
      "<?xml version=\"1.0\" encoding=\"UTF-8\"?>",
      "<opml version=\"2.0\">",
      "  <head><title>\($org) releases</title></head>",
      "  <body>",
      "    <outline text=\"\($org) releases\">",
      (.[] | select(.archived | not) | "      <outline type=\"rss\" text=\"\(.full_name)\" xmlUrl=\"https://github.com/\(.full_name)/releases.atom\"/>"),
      "    </outline>",
      "  </body>",
      "</opml>"' > "$ORG-releases.opml"

Remplacez ORG par l'organisation souhaitée, exécutez le script, puis importez le fichier : dans SereneReader, cliquez sur Ajouter un flux, puis sur Importer OPML. Les flux se retrouvent dans un dossier, nommé « cli releases » dans cet exemple. Les grandes organisations peuvent avoir des centaines de dépôts, vérifiez donc le fichier avant de l'importer. Avec le plan Gratuit, une importation s'arrête à la limite de 150 flux.

Peut-on exclure les pré-versions ?

Pas dans le flux lui-même. Le flux de versions inclut les pré-versions, et rien dans une entrée ne les identifie comme telles. Nous avons vérifié avec TypeScript : GitHub marque « TypeScript 7.1 Beta » comme pré-version, mais son entrée dans le flux est identique à celle d'une version stable. Ajouter ?prerelease=false à l'URL du flux ne change pas ce que GitHub retourne.

Ce sur quoi vous pouvez filtrer, c'est le titre de la version. De nombreux projets indiquent « beta », « rc » ou « alpha » dans les noms de leurs pré-versions. Dans SereneReader, ajoutez une expression dans Paramètres > Données > Expressions masquées, ou ouvrez une version, cliquez sur Masquer l'article, et choisissez Masquer par expression. Les articles dont le titre ou le résumé contient l'expression sont masqués, y compris ceux qui arrivent par la suite. Par exemple, l'expression -rc masque les candidats à la version de Linux tels que v7.4-rc1.

Choisissez l'expression avec soin. Les expressions masquées s'appliquent à tous les flux que vous suivez, et elles correspondent au résumé autant qu'au titre. Une expression comme beta masque également une version stable dont les notes mentionnent une version bêta, ainsi que les articles de vos autres flux qui utilisent ce mot.

Un autre point à surveiller : un dépôt qui héberge plusieurs paquets publie souvent des versions pour chacun d'eux dans le même flux. Le flux TypeScript liste également les versions de son extension VS Code, intitulées vscode-typescript/v1.0.1. Une expression masquée telle que vscode-typescript/ permet de les exclure.

Lire les versions avec un agent IA

Si vous suivez de nombreux projets, vous préférerez peut-être un résumé plutôt que chaque ensemble de notes. L'API de SereneReader retourne vos articles au format JSON, y compris ceux provenant des flux de versions, ce qui permet à un agent ou à un court script de lire les versions de la semaine écoulée et de vous indiquer celles qui vous concernent. Comment connecter vos flux RSS à des agents IA explique la procédure étape par étape. L'API fait partie des plans Pro et Team.

Quand un flux ne suffit pas

Un flux de versions est une façon discrète de rester informé des logiciels que vous utilisez. Il a ses limites :

• Les notes valent ce que vaut la version. Le flux transporte uniquement le texte de la version. Les entrées de Linux ne contiennent qu'une ligne telle que « Linux 7.4-rc1 », et l'entrée bêta de TypeScript est un lien vers un article de blog. Les fichiers joints à une version ne sont pas non plus listés. Pour ces projets, suivez également le flux du blog du projet ou son fichier de journal de modifications.
• Les dépôts privés ne fonctionnent pas. Le flux d'un dépôt privé retourne une erreur 404 sauf si vous êtes connecté à GitHub, et un lecteur RSS récupère les flux sans votre session GitHub. Utilisez plutôt les notifications natives de GitHub pour ceux-là (voir ci-dessous).
• Les nouvelles versions arrivent selon le calendrier du lecteur. Un lecteur vérifie chaque flux périodiquement, donc une version apparaît à la prochaine vérification, pas au moment de sa publication. C'est suffisant pour la lecture. Ce n'est pas le bon outil quand quelque chose doit se produire immédiatement.
• Les flux très actifs peuvent manquer des entrées. Le flux ne contient jamais plus de 10 versions récentes. Un dépôt qui publie plus de 10 versions entre deux vérifications — comme un grand monorepo le jour d'une sortie — peut en perdre certaines avant qu'un lecteur ne les voie.

Lorsque ces limites posent problème, utilisez l'une des alternatives suivantes :

• Le menu Watch de GitHub. Sur la page du dépôt, cliquez sur Watch, choisissez Custom, et sélectionnez Releases. GitHub envoie alors une notification — et un e-mail si vous l'avez activé — pour chaque nouvelle version. Cela fonctionne également pour les dépôts privés auxquels vous avez accès.
• Un webhook. Si une version doit déclencher quelque chose automatiquement, comme une compilation ou un déploiement, un webhook de dépôt avec l'événement de version appelle votre serveur lors de la publication. Vous ne pouvez ajouter des webhooks qu'aux dépôts que vous administrez.
• Des outils de mise à jour des dépendances. Si l'objectif est de maintenir les dépendances d'un projet à jour, un outil tel que Dependabot ou Renovate ouvre des pull requests lorsque de nouvelles versions sont disponibles.

Pour rester informé des outils dont vous dépendez, sans gérer une nouvelle boîte de réception, le flux est généralement suffisant.

Les URL des flux et leur contenu ont été vérifiés sur GitHub le 3 novembre 2026. Si un flux cesse de se mettre à jour, ouvrez son URL dans un navigateur pour vérifier que GitHub le sert toujours.