Méthode

Un chiffre « vérifié » ne vaut que si on montre comment on vérifie.

Ce qu'on compte

Un jour actif est un jour calendaire (UTC) avec au moins un commit humain sur la branche par défaut du repo. Dix commits le même jour comptent pour un jour. Un commit à 23 h 59 et un autre à 0 h 01 comptent pour deux. C'est le seul chiffre qui classe.

• Commits : le total des commits humains lus.
• Série max : le plus grand nombre de semaines d'affilée (lundi à dimanche) avec au moins un jour actif.
• Durée de vie : les mois entre le premier et le dernier commit.
• Auteurs : les personnes distinctes trouvées dans l'historique, robots exclus. Et la part du maker : les commits signés de son compte GitHub. Quand elle tombe sous 80 %, la fiche le dit. Une fiche peut avoir jusqu'à deux co-makers, ajoutés par leur login GitHub et visibles dès qu'ils se sont connectés une fois : leurs commits comptent dans cette part.
• Étoiles GitHub : affichées, jamais utilisées pour classer. Elles disent qui n'a pas encore été vu.

Ce qu'on exclut

• Les robots : dependabot, renovate, github-actions, semantic-release, snyk, imgbot, copilot et tout compte marqué « Bot » par GitHub. Leurs commits ne font ni un jour ni un auteur.
• Les autres branches : on ne lit que la branche par défaut. Le travail sur une branche jamais fusionnée n'apparaît pas.
• Le contenu : jamais une ligne de code, jamais un message de commit. Seulement des dates et des noms d'auteurs.
• Les apps payantes : elles peuvent avoir une fiche, elles ne sont pas dans le classement.

Comment on lit

Un repo public est lu comme n'importe qui peut le lire sur github.com, avec le jeton du site, sans rien demander au maker : la liste des commits de la branche par défaut, page par page, jusqu'à 5 000 commits. Chaque fiche est relue chaque nuit. La ligne « lu le » sur la fiche est la date de cette dernière lecture.

Un repo privé est lu par ses statistiques, avec la seule permission « métadonnées » de la GitHub App : les commits par semaine et par auteur depuis le début, le détail par jour sur les 52 dernières semaines, et les pushes récents. Les jours plus vieux qu'un an ne sont connus qu'à la semaine ; on les note au dimanche de la semaine. Un registre garde chaque jour vu, et grandit nuit après nuit. Le premier passage sur un repo dont GitHub n'a pas encore calculé les statistiques remonte la branche commit par commit, jusqu'à 400.

App Store et notarisation

Avant de télécharger une app Mac d'un inconnu, on regarde une chose : est-elle passée par l'App Store, ou signée et notarisée par Apple ? La fiche répond quand elle peut, et dit d'où vient la réponse.

• App Store : le maker colle le lien de sa fiche App Store, et on le vérifie chez Apple à chaque lecture, par l'API publique de recherche. Un lien qui ne mène à aucune app n'est pas gardé. On affiche le nom et l'éditeur tels qu'Apple les renvoie. C'est une vérification, pas une déclaration.
• Notarisation : sur un repo public d'app Mac, on lit les fichiers de `.github/workflows`, douze au plus, et on y cherche l'outil qui envoie le binaire à la notarisation d'Apple (`notarytool`, `stapler staple`, `altool --notarize-app`, une action de notarisation, des identifiants de notarisation). Trouvé, la fiche le dit et donne le lien vers le fichier : chacun peut aller voir.
• Signée seulement : un certificat Developer ID sans notarisation trouvée (`codesign --sign`, `CSC_LINK`, un certificat dans les secrets). Depuis macOS 10.15, ça ne suffit plus à passer Gatekeeper : la fiche le distingue.

Ce que ça ne prouve pas : qu'un workflow notarise ne dit pas que le fichier que tu télécharges, aujourd'hui, est notarisé. Le seul contrôle qui tranche, c'est ton Mac au moment de l'ouvrir — ou `spctl -a -vv` sur le binaire. On ne télécharge aucun binaire et on n'en vérifie aucun ticket : il faudrait un Mac, notre serveur n'en est pas un, et Apple n'expose rien de public là-dessus. Rien de lu ne veut pas dire non signée : beaucoup de makers signent depuis leur machine, sans que ça passe par un workflow. C'est une absence de preuve, pas une preuve d'absence, et la fiche l'écrit comme ça. Les repos privés ne sont pas lus du tout : la permission « métadonnées » ne donne pas accès aux fichiers.

Ce que le chiffre ne dit pas

• Un jour actif ne dit pas combien d'heures. Un commit d'une ligne et une journée entière pèsent pareil.
• L'historique peut venir d'ailleurs. Un repo créé à partir d'un autre projet hérite de ses commits. C'est pour ça que la fiche montre le nombre d'auteurs : à plus d'un, le chiffre n'est pas celui d'une seule personne, et on le dit sur la fiche.
• On ne détecte pas les commits réécrits, les dates falsifiées ou les commits vides. Un maker qui veut tricher le peut ; il triche alors devant tout le monde, sur son propre repo.
• Les repos privés lus par les statistiques comptent tous les auteurs pour le détail par jour, robots compris : GitHub ne permet pas de les distinguer à ce niveau.

Le code

Tout ce qui est écrit ici est dans le code du site, ouvert : work.ts pour les calculs et la liste des robots, metrics.ts pour la lecture GitHub, signing.ts pour l'App Store et la notarisation. Si tu trouves une erreur, ouvre une issue.

Dernière mise à jour : 18 septembre 2026.