GitHub restaure l’historique des étoiles sans révéler qui les attribue

Le 4 septembre 2026, GitHub a publié un endpoint REST qui restitue l’historique des étoiles d’un dépôt public sans fournir l’identité des personnes qui les ont attribuées. Dans son annonce du nouvel endpoint, GitHub le présente comme une solution destinée aux outils de suivi de croissance affectés par les restrictions appliquées aux listes de stargazers.

La nouvelle route est GET /repos/{owner}/{repo}/stargazers/history. Elle renvoie des nombres d’étoiles regroupés par semaine et ventilés par jour, mais aucun identifiant, nom de compte, avatar ou profil individuel. Les mainteneurs peuvent donc reconstruire une série temporelle; ils ne récupèrent pas la liste des utilisateurs à l’origine de chaque étoile.

Une route distincte pour remplacer les listes dans les graphiques

L’ancien endpoint GET /repos/{owner}/{repo}/stargazers répond à une autre question: il dresse la liste des personnes ayant ajouté une étoile. Avec le type de média prévu à cet effet, il pouvait aussi joindre l’heure de création de chaque étoile à l’objet représentant son auteur. Les restrictions introduites en 2026 ont limité l’accès à ces listes aux administrateurs et collaborateurs des dépôts.

Le nouvel endpoint ne constitue donc pas un remplacement champ par champ. Il remplace la liste individuelle comme source des tableaux historiques portant sur des dépôts publics. Une fonction qui dépend d’un login, d’un avatar ou d’une URL de profil ne peut pas migrer vers cette réponse sans changer de finalité.

Cette séparation correspond précisément au compromis annoncé par GitHub: conserver le moment et le volume nécessaires à l’analyse, tout en supprimant le lien entre une étoile et une personne. Elle permet de mesurer une évolution ou de rapprocher une hausse d’un événement connu, mais pas de constituer un fichier de nouveaux stargazers.

Des semaines ordonnées, chacune détaillée sur sept jours

La documentation REST de GitHub indique que la réponse est ordonnée de la semaine la plus récente à la plus ancienne. Chaque entrée contient week, l’horodatage Unix du début de la semaine, total, le nombre d’étoiles créées pendant cette semaine, et days, sept nombres correspondant aux jours à partir du dimanche.

L’exemple officiel se présente ainsi: [{"week": 1754784000, "total": 19, "days": [0, 12, 7, 0, 0, 0, 0]}]. Le total est ici une variation hebdomadaire, et non le nombre cumulé d’étoiles du dépôt. Pour produire une courbe cumulative, une application doit donc additionner les valeurs récupérées depuis la création du dépôt.

Les semaines sans nouvelle étoile restent dans la série avec des valeurs nulles. La pagination remonte vers la semaine de création du dépôt, avec au maximum 30 semaines par page et 100 pages. GitHub avertit par ailleurs que les frontières des semaines et des jours ne sont pas garanties comme alignées sur UTC; un client doit conserver les repères fournis par l’API plutôt que leur imposer sa propre définition du début de journée.

Les dépôts publics peuvent être interrogés sans authentification. Si un jeton à permissions fines est utilisé, la lecture des métadonnées du dépôt suffit. La référence indique une réponse HTTP 200 en cas de succès et 422 pour une requête invalide ou considérée comme abusive.

Le coût dépend désormais de l’âge du dépôt, pas de sa popularité

Pour un tableau de croissance, l’unité de collecte passe de l’événement individuel au compartiment temporel. Une liste d’utilisateurs s’allonge avec chaque étoile, tandis que l’historique agrégé croît principalement avec le nombre de semaines écoulées depuis la création du dépôt. Le volume de pagination devient ainsi plus prévisible pour les projets très populaires.

Le service tiers Star History décrit son adoption de la nouvelle API dès le 5 septembre 2026 et affirme que les graphiques des dépôts publics concernés fonctionnent de nouveau. Son retour précise aussi que la précédente collecte s’arrêtait après 40 000 stargazers, alors que la nouvelle pagination temporelle lui permet de restituer la fin des courbes des grands dépôts.

Ce rétablissement ne change toutefois pas la nature de l’indicateur. Une étoile signale un intérêt approximatif pour un dépôt; elle ne démontre ni son utilisation effective, ni sa qualité, ni son déploiement en production. Le nouvel endpoint rend l’évolution de ce signal observable sans restaurer les données personnelles supprimées.

Migrer sans recréer un fichier d’utilisateurs

La migration d’un tableau historique consiste à remplacer la collecte des stargazers par la lecture des compartiments hebdomadaires. Elle impose aussi de retirer du modèle local les champs individuels devenus inutiles, afin que le nouveau traitement reste conforme à la finalité agrégée de l’endpoint.

1. Appeler /repos/{owner}/{repo}/stargazers/history avec le propriétaire et le nom du dépôt, puis parcourir les pages jusqu’aux semaines les plus anciennes nécessaires.
2. Associer chaque tableau days à son entrée week et conserver les semaines à zéro, qui représentent une absence d’étoiles plutôt qu’une lacune de collecte.
3. Inverser l’ordre des entrées avant un traitement chronologique, puisque GitHub renvoie les données les plus récentes en premier.
4. Additionner les valeurs quotidiennes pour obtenir une courbe cumulative, ou les conserver comme variations pour afficher les ajouts par jour, semaine ou mois.
5. Supprimer les dépendances aux logins, identifiants, avatars et URL de profils, sans tenter de les reconstituer par croisement avec des événements publics ou d’anciennes captures.

Une route complémentaire, GET /repos/{owner}/{repo}/stargazers/count, fournit le nombre actuel d’étoiles. Elle peut servir à afficher un compteur ponctuel, mais elle ne remplace pas l’historique nécessaire à une courbe et ne transforme pas les totaux hebdomadaires en cumuls.

La situation est désormais claire: GitHub fournit un historique agrégé pour les dépôts publics, et un outil comme Star History l’a déjà intégré. Ce que l’API ne rétablit pas — et que la migration ne doit pas chercher à reconstruire — est l’association entre chaque étoile et un compte utilisateur.

À lire aussi:

• Pandora commence sa science : 20 atmosphères pour corriger l’effet des étoiles
• Anthropic finance 5 M$ de tests sur le bien-être, avec des résultats ouverts
• Recruter avec une IA peut refroidir les candidats sans paraître plus compétent