Trendshift : repérer les projets GitHub qui montent, et trier les bons

En 2026, trois des outils dont j'ai parlé sur ce blog avaient le même badge en haut de leur README : un petit encart « Trendshift » avec un rang. Voicebox, optimizerDuck, VoiceStudio. Trois projets passés de zéro à plusieurs dizaines de milliers d'étoiles en quelques mois, repérés par des milliers de développeurs au même moment, au même endroit.

Trendshift est un site qui classe chaque jour les dépôts GitHub en forte progression. Il se présente comme une alternative à la page GitHub Trending, avec une promesse : repérer les projets pendant qu'ils montent, pas après leur pic. Il revendique plus de 180 000 visiteurs par mois, ce qui en fait l'une des principales portes d'entrée vers les nouveaux projets open source.

Il est utile pour la veille. Il ne suffit pas pour décider d'adopter un projet.

Ce que propose Trendshift

La différence la plus utile avec GitHub, c'est l'historique. La page Trending de GitHub n'a pas de mémoire : ce qui était en tête la semaine dernière a disparu. Trendshift conserve les classements, ce qui permet de voir si un projet a tenu plusieurs semaines ou s'il n'a brillé qu'un jour.

La formule exacte du classement n'est pas publiée. On sait qu'il repose sur la dynamique de popularité, mais pas comment les étoiles, les forks ou les mentions sont pondérés. C'est une limite à garder en tête : on lit un classement dont on ne connaît pas les règles.

Les autres outils de la boîte

Trendshift n'est pas seul. Chaque outil répond à une question différente :

Star History, maintenu par Bytebase, trace la courbe d'étoiles d'un dépôt depuis sa création. Comparer deux projets concurrents sur le même graphique dit beaucoup : une courbe régulière sur trois ans ne raconte pas la même histoire qu'une falaise verticale en deux semaines.

OSS Insight, développé par PingCAP (l'éditeur de la base TiDB), va au-delà des étoiles. Il s'appuie sur GH Archive, l'archive publique de tous les événements GitHub, et analyse l'activité réelle d'un dépôt : qui contribue, à quel rythme les tickets sont traités, combien de pull requests sont fusionnées. C'est l'outil le plus utile pour juger de la santé d'un projet, et le moins utilisé.

Le problème des étoiles

Tous ces classements reposent en grande partie sur un même chiffre : les étoiles. Or une étoile coûte un clic, et elle s'achète.

Une étude de chercheurs de l'université Carnegie Mellon et de Socket, publiée fin 2024, a identifié environ 4,5 millions d'étoiles suspectes sur GitHub, issues de campagnes de faux comptes. Le phénomène touchait en particulier des dépôts éphémères liés aux cryptomonnaies, et des dépôts qui servaient à diffuser des logiciels malveillants. Les étoiles achetées font remonter un dépôt dans les classements, ce qui lui apporte de vraies visites, et donc de vraies étoiles.

Même sans fraude, la popularité mesure l'attention, pas la qualité. Un projet qui passe en tête de Trendshift attire des milliers de visiteurs en une journée, souvent grâce à une démo spectaculaire ou une vidéo virale. Ça ne dit rien de la qualité du code, de sa sécurité, ni de ce que le projet deviendra dans un an.

Et la popularité attire les imitateurs. Quand j'ai écrit sur optimizerDuck pour optimiser Windows, des dépôts aux noms presque identiques existaient déjà sur GitHub, avec des descriptions du type « Download optimizerDuck ». Un projet en tendance est une cible : ses copies profitent des recherches de ceux qui l'ont vu passer.

Les signaux à vérifier avant d'adopter un projet

Repérer un projet sur Trendshift, c'est le début. Avant de l'installer, et surtout avant d'en dépendre, je vérifie six choses :

Le dernier point compte pour les applications à télécharger. Un exécutable publié dans une release doit pouvoir être relié au code source, idéalement parce qu'il est compilé par une CI publique. Les règles pour éviter les dépôts piégés et les dépendances compromises sont détaillées dans la cybersécurité pour les développeurs.

La plupart de ces informations se récupèrent en une commande avec la CLI GitHub :

gh api repos/OWNER/REPO --jq '{
  cree: .created_at,
  dernier_push: .pushed_at,
  etoiles: .stargazers_count,
  forks: .forks_count,
  tickets_ouverts: .open_issues_count,
  licence: .license.spdx_id,
  archive: .archived
}'

# Nombre de contributeurs (une page de 100 suffit pour se faire une idée)
gh api "repos/OWNER/REPO/contributors?per_page=100" --jq 'length'
 
# Les 5 dernières releases et leur date
gh release list --repo OWNER/REPO --limit 5

Un projet sain a généralement plusieurs contributeurs actifs, des tickets traités, des releases régulières et une licence claire. Un projet à 50 000 étoiles avec un seul contributeur et aucune release n'est pas forcément mauvais. Il est fragile.

Faire sa propre veille

On peut aussi chercher soi-même les projets récents qui décollent, sans passer par un classement dont on ne connaît pas la formule :

# Dépôts créés depuis le 1er septembre, triés par étoiles
gh search repos --created ">2026-09-01" --sort stars --limit 20
 
# Même chose, limité à un langage et un sujet
gh search repos --created ">2026-09-01" --language go --topic self-hosted --sort stars

Le résultat est brut, mais les critères sont les vôtres.

Pour suivre les projets qu'on a retenus, RSS reste imbattable. GitHub publie un flux Atom pour les releases de chaque dépôt, sans compte ni API :

https://github.com/OWNER/REPO/releases.atom
https://github.com/OWNER/REPO/commits/main.atom
https://github.com/OWNER/REPO/tags.atom

Il suffit d'ajouter ces adresses à un lecteur de flux. On est prévenu de chaque nouvelle version sans retourner sur GitHub. La méthode complète, des sources aux lecteurs, est expliquée dans la veille technologique avec RSS. Et pour réunir ces flux dans sa propre interface, j'ai détaillé la construction d'OpenRss, un agrégateur RSS en Next.js.

Ma routine tient en trois temps :

1. Découvrir : un passage rapide sur Trendshift en vue hebdomadaire, plutôt que quotidienne, pour éviter le bruit.
2. Trier : pour chaque projet intéressant, la vérification des six signaux. La plupart sont éliminés à cette étape.
3. Suivre : le flux releases.atom des survivants dans le lecteur RSS, et un nouveau regard dans trois mois.

Le délai de trois mois est le filtre le plus efficace que je connaisse. Une bonne partie des projets en tendance ont déjà ralenti ou cessé d'évoluer à ce stade. Ceux qui sont encore actifs, avec des releases et des contributeurs, méritent qu'on s'y intéresse vraiment.

Pour les auteurs de projets

Trendshift propose des badges à intégrer dans un README, qui affichent le classement du projet. C'est une preuve sociale efficace, et la raison pour laquelle on les voit partout en 2026.

Si vous publiez un projet, un badge ne remplace pas ce que les visiteurs vérifient vraiment : un README qui explique le projet en trois lignes, une licence, des releases compilées par une CI publique, et des tickets qui reçoivent une réponse. Les projets qui durent sont ceux qui transforment une journée en tête de classement en contributeurs réguliers, pas ceux qui accumulent le plus de badges.

Trendshift est un excellent radar : il montre ce qui monte, plus tôt et avec plus de mémoire que GitHub Trending. Mais un radar repère, il ne juge pas. Une courbe d'étoiles mesure l'attention d'un jour, alors que la valeur d'un projet se mesure en mois de commits, de tickets traités et de releases. Laissez Trendshift vous montrer quoi regarder, et faites le tri vous-même.