Tableau de bord analytique GitHub

Pourquoi je l’ai construit

En explorant des dépôts sur GitHub, j’ai remarqué qu’il était facile de trouver des statistiques brutes, mais beaucoup plus difficile de comprendre la santé globale d’un projet. Un dépôt pouvait sembler actif tout en étant difficile à contribuer, mal documenté ou abandonné sous la surface.

Je voulais transformer ces données dispersées en quelque chose de lisible : des signaux clairs qui aident à comprendre un projet rapidement, plutôt que des métriques isolées.

C’était aussi l’occasion d’approfondir l’intégration d’API, l’architecture frontend, la visualisation de données et le design d’interface sur un projet concret plutôt qu’un tutoriel.

Fonctionnalités principales

• Transforme n’importe quel dépôt public en tableau de bord structuré : activité, maintenabilité, préparation et santé des issues.
• Met en avant des vérifications faciles à manquer : README, licence, guide de contribution, politique de sécurité, workflow CI et métadonnées du package.
• Analyse la santé des issues et l’élan du backlog : issues récentes et anciennes, plus ancienne issue ouverte et statut du backlog.
• Visualise l’activité des commits dans le temps : rythme de développement, périodes calmes, semaines les plus actives et tendances récentes.
• Un audit IA du dépôt qui transforme un instantané analytique en revue technique structurée, avec une sortie JSON contrainte par schéma.
• Les appels GitHub et OpenAI passent par des fonctions côté serveur : aucun jeton d’API n’est exposé dans le navigateur.

Défis et apprentissages

• Le plus difficile a été de choisir les signaux qui comptaient vraiment. Il était facile d’ajouter des données et des graphiques, beaucoup moins de garder le résultat lisible.
• Ce projet m’a fait passer de l’affichage des données à leur communication : une bonne interface aide à voir l’essentiel sans submerger.
• Le responsive a été un vrai défi. Les cartes de statistiques denses saturaient vite sur mobile, ce qui a imposé des choix précis d’espacement, de hiérarchie et de priorité.

Décisions techniques

• React et Vite ont gardé le frontend léger et rapide à faire évoluer, et ont facilité le découpage en sections réutilisables.
• La récupération des données est séparée de la présentation : appels API, états de chargement et affichage ne s’emmêlent pas quand le tableau de bord grandit.
• L’interface est organisée autour de signaux de santé regroupés plutôt que de réponses API brutes, pour une lecture sous plusieurs angles.
• Mis en production avec CI, Dependabot, licence, politique de sécurité et documentation pour les contributeurs.

Ce que je ferais différemment

Les données d’activité des commits de GitHub couvrent environ 52 semaines : les tendances plus longues ne sont pas fiables. Je concevrais cette section autour des données disponibles et j’expliquerais cette limite dans l’interface.

J’ajouterais de meilleurs états vides, des explications plus claires pour chaque signal et une meilleure logique de score, pour comprendre pourquoi un résultat compte et pas seulement s’il est validé.