GitHub

GitHub expose un ensemble riche de types d'entités : pull requests, issues, commits, exécutions de workflows, revues de pull requests, releases et discussions. Cette intégration couvre quatre de ces types d'entités — les pull requests, les revues de pull requests, les issues et les exécutions de workflows — qui ensemble couvrent l'intégralité de la chaîne de valeur, de l'écriture du code jusqu'au déploiement. Les commits et les releases ont été exclus : le comptage brut de commits est le piège de Goodhart canonique en ingénierie, et la fréquence des releases, bien que métrique DORA, est un signal d'équipe plutôt qu'un signal individuel. Sept KPIs ont été retenus sur ces quatre types d'entités, sélectionnés selon trois critères : capacité d'attribution à un propriétaire nommé, résistance au gaming lorsqu'ils sont lus en combinaison, et équilibre entre indicateurs avancés qui anticipent les problèmes et indicateurs retardés qui confirment les résultats.

Vélocité de livraison : débit des pull requests et taux d'acceptation du code

PR Cycle Time mesure le temps moyen écoulé entre le moment où un développeur ouvre une pull request et le moment où elle est fusionnée. C'est l'équivalent technique du cycle commercial : plus il est court et régulier, plus le pipeline de livraison est fluide. Un développeur présentant un cycle time durablement élevé constitue un signal à investiguer — il peut indiquer des pull requests trop volumineuses et difficiles à relire, des critères d'acceptation flous, ou une disponibilité insuffisante des relecteurs.

PR Merge Rate mesure la proportion de pull requests ouvertes qui aboutissent finalement à une fusion. Cet indicateur est le contrepoids indispensable au cycle time. Sans lui, un développeur pourrait optimiser sa vélocité apparente en n'ouvrant que des changements triviaux assurés de passer la revue, ou en fermant et rouvrant des pull requests pour réinitialiser le compteur. Un taux de fusion élevé confirme que la rapidité observée dans le cycle time correspond à du travail genuinement accepté, et non à un contournement de la métrique. Les deux indicateurs combinés définissent la forme du schéma de livraison d'un développeur : rapide-et-accepté, lent-et-accepté, ou rapide-mais-rejeté.

Santé de la collaboration : participation aux revues et réactivité

Review Turnaround Time mesure la rapidité avec laquelle un relecteur répond après l'ouverture d'une pull request. C'est l'indicateur de collaboration le plus directement actionnable de cet ensemble : un relecteur conscient de son délai de réponse peut modifier son comportement immédiatement, alors que les métriques mesurant la qualité du code ou les décisions d'architecture nécessitent des boucles de rétroaction plus longues. Lorsque cet indicateur augmente pour un développeur spécifique, il devient un problème de débit au niveau de l'équipe : chaque pull request en attente chez ce relecteur accumule du temps de file d'attente, qui se répercute ensuite dans le cycle time de chaque auteur.

Reviews Submitted comptabilise le nombre de revues auxquelles un développeur participe en tant que relecteur. Cet indicateur capture la dimension collaborative du travail d'ingénierie que le cycle time et le taux de fusion ne peuvent pas révéler : un développeur peut livrer son code efficacement tout en contribuant peu à la capacité collective de revue de l'équipe. Le risque de Goodhart est réel ici — un relecteur sous pression peut soumettre des approbations superficielles pour gonfler son compteur. C'est pourquoi Reviews Submitted est lu en parallèle du Review Turnaround Time : un nombre élevé de soumissions combiné à un délai de réponse inhabituellement court est la signature comportementale de la revue de complaisance, et la combinaison la rend visible.

Débit des issues : livraison des tâches et gestion du backlog

Issues Closed comptabilise le nombre d'issues GitHub résolues par assigné. C'est un indicateur avancé du volume de livraison individuel lorsqu'il est suivi à cadence hebdomadaire, et il capture les tâches d'ingénierie qui ne génèrent pas nécessairement de pull request — investigations, documentation, changements de configuration et coordination transversale. L'attribution est robuste : les issues sont créées par d'autres acteurs (chefs de produit, responsables techniques, collègues), donc un développeur ne peut pas gonfler le dénominateur sans coopération externe.

Issue Resolution Time mesure le temps moyen écoulé entre l'assignation d'une issue et sa clôture. Associé à Issues Closed, il prévient la dérive la plus courante dans les mesures basées sur les issues : clôturer rapidement en marquant prématurément comme terminé, ou accumuler les clôtures en fin de sprint. Un développeur qui ferme de nombreuses issues rapidement est dans une situation différente de celui qui en ferme peu sur de longues durées — mais un développeur qui ferme de nombreuses issues avec des temps de résolution extrêmement courts mérite le même examen que celui qui en ferme peu. La combinaison volume et vélocité révèle la qualité réelle du débit.

Fiabilité du pipeline : taux d'échec CI comme proxy de qualité

CI Failure Rate mesure la proportion d'exécutions de workflows qui se terminent en échec pour un acteur donné. C'est l'approximation la plus proche disponible du taux d'échec des changements DORA au niveau individuel. Un taux d'échec durablement élevé pour un développeur spécifique révèle un schéma — couverture de tests locale insuffisante, recours à la CI comme environnement de test principal, ou intégration répétée de travaux insuffisamment spécifiés. Il est exprimé en ratio plutôt qu'en comptage brut car les comptages bruts pénaliseraient systématiquement les contributeurs à fort volume : un développeur qui déclenche cinquante exécutions avec cinq échecs est dans une situation fondamentalement différente de celui qui déclenche cinq exécutions avec cinq échecs.

L'indicateur est également un signal avancé de risque de livraison au niveau de l'équipe : lorsque le CI Failure Rate augmente simultanément chez plusieurs développeurs, cela suggère un problème d'infrastructure ou de configuration en amont plutôt qu'un comportement individuel, et la distinction importe pour la réponse managériale.

Périmètre et limites de l'intégration

GitHub enregistre les transitions d'état et les horodatages, mais ne mesure pas la qualité du travail que ces transitions représentent. Une pull request fusionnée peut contenir une implémentation robuste et bien relue, ou un raccourci accepté sous la pression du calendrier ; les données de l'API ne font pas la distinction. La clôture d'une issue n'indique pas si la solution était correcte, seulement que quelqu'un l'a marquée comme terminée. Le CI Failure Rate capture les échecs de pipeline mais pas les problèmes de qualité plus subtils qui passent les tests automatisés — régressions introduites silencieusement, décisions d'architecture créant une dette de maintenance future, ou suites de tests gonflées pour atteindre des seuils de couverture.

L'attribution comporte également une limite structurelle : la résolution du login GitHub vers un email dépend du fait que les utilisateurs aient renseigné une adresse email publique dans leur profil. Pour les équipes dont les membres utilisent des emails privés, le processus de correspondance nécessite de maintenir une carte login-vers-email au niveau de l'organisation. Au-delà de cette contrainte technique, GitHub ne capture que le travail qui transite par la plateforme. Les revues de code informelles, la collaboration directe, la conception d'architecture et le mentorat restent invisibles pour cette intégration. La fiabilité de ces KPIs dépend du fait que les équipes utilisent GitHub comme surface de collaboration principale, avec des pratiques cohérentes d'assignation des issues et une couverture du pipeline CI. Une utilisation partielle ou incohérente de ces fonctionnalités dégrade le signal proportionnellement.