GitLab

GitLab expose un large éventail d'objets : issues, merge requests, pipelines, déploiements, commits, jobs, projets et groupes. Cette intégration couvre quatre types d'objets — merge requests, issues, pipelines et déploiements — qui ensemble couvrent la chaîne de valeur d'ingénierie complète, de l'écriture du code à la mise en production. Les commits ont été évalués et exclus : les métriques de fréquence de commit et de nombre de lignes échouent au critère de résistance au gaming et n'ont aucun lien causal avec la qualité de livraison. Six KPIs ont été retenus, sélectionnés selon trois critères : capacité à attribuer à un responsable, résistance au gaming, et équilibre entre indicateurs avancés et retardés.

Livraison de code : lire le volume de merge requests au regard du cycle time

MRs Merged comptabilise le nombre de merge requests qu'un auteur a intégrées dans la base de code. MR Cycle Time mesure le temps moyen écoulé entre la création d'une merge request et sa fusion. Ces deux indicateurs maintiennent une tension explicite. Un volume élevé de MRs Merged confirme le débit de livraison, mais ne dit rien sur la qualité du processus de revue : un développeur qui fusionne de nombreuses requêtes petites et mal revues affiche un bon score en volume tout en accumulant de la dette technique et en introduisant des risques de régression. MR Cycle Time contrebalance cela : un cycle time court reflète un travail bien délimité, susceptible d'être relu, et une boucle de revue efficace — deux conditions structurellement difficiles à simuler. Un développeur qui découpe artificiellement son code en MRs minimales pour réduire le cycle time atteint l'objectif d'ingénierie sous-jacent plutôt que de tricher sur l'indicateur. Lire les deux indicateurs ensemble identifie un schéma distinct dans chaque quadrant : volume élevé avec cycle time court caractérise un développeur travaillant à un rythme sain ; volume élevé avec cycle time long peut révéler un glissement de périmètre ou des goulots d'étranglement dans la chaîne de revue ; volume faible avec cycle time court suggère une livraison peu fréquente mais bien exécutée ; volume faible avec cycle time long pointe vers des difficultés d'exécution ou des éléments de travail mal formulés.

Débit de travail : clôture des issues et backlog en retard comme signaux couplés

Issue Cycle Time mesure la durée moyenne entre la création d'une issue et sa clôture pour un assigné donné. C'est le principal indicateur retardé de débit de travail individuel, l'équivalent en ingénierie de la durée d'un cycle de vente. Un Issue Cycle Time long, maintenu sur plusieurs périodes, révèle l'une de deux conditions systémiques : soit les issues sont mal délimitées et croissent en complexité pendant l'exécution, soit l'assigné jongle entre trop d'éléments en parallèle pour maintenir un flux de travail. L'Issue Cycle Time seul ne permet pas de distinguer ces deux causes.

Overdue Issues fournit le pendant avancé. Il compte les issues ouvertes dont la date d'échéance est dépassée, signalant des engagements en glissement avant que le signal retardé du cycle time ne se déclenche. Une issue en retard isolée porte un signal limité. Une accumulation soutenue d'issues en retard, notamment dans une période où l'Issue Cycle Time s'allonge également, confirme un problème structurel de backlog plutôt qu'une anomalie de planification. L'assigné peut agir directement sur Overdue Issues — en repriorisant, en redécoupant ou en escaladant — tandis que l'Issue Cycle Time n'est lisible qu'a posteriori. La combinaison des deux indicateurs distingue la dérive opérationnelle corrigeable en temps réel de l'échec de livraison structurel visible seulement après coup.

Pipeline et déploiement : le couple fiabilité CI et cadence de mise en production

Pipeline Success Rate mesure la proportion de pipelines déclenchés par un développeur qui se terminent avec succès. C'est un indicateur avancé de la qualité du code au moment de l'intégration : un développeur dont les pipelines échouent fréquemment livre du travail qui casse la suite de tests ou viole des contraintes de build — deux conditions qui imposent des coûts à toute l'équipe. Cet indicateur est attribuable au niveau individuel parce que GitLab enregistre l'utilisateur qui a déclenché chaque pipeline, permettant une vue par contributeur de la santé CI. Le risque de gaming est faible : un développeur ne peut pas facilement améliorer son taux de succès sans améliorer réellement la qualité du code soumis.

Deployment Frequency, la quatrième métrique DORA suivie dans cette intégration, comptabilise les déploiements réussis attribuables à un utilisateur sur une période donnée. Là où Pipeline Success Rate mesure la capacité à livrer, Deployment Frequency confirme que la livraison se produit effectivement. Les deux indicateurs combinés révèlent le tableau CI/CD complet : un Pipeline Success Rate élevé associé à une Deployment Frequency faible peut indiquer que le processus d'intégration de l'équipe est sain mais que les releases sont bloquées au stade du déploiement par des facteurs non techniques tels que des processus de gestion du changement ou des fenêtres de release imposées. À l'inverse, une Deployment Frequency élevée associée à un Pipeline Success Rate en baisse signale que la cadence de release est maintenue en abaissant la barre de qualité à l'intégration — un schéma courant sous la pression de fin de sprint.

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

GitLab enregistre les transitions d'état et les attributions d'utilisateurs, mais ne mesure pas la qualité du travail produit. Une merge request fusionnée peut représenter un changement bien architecturé ou un contournement rapide qui accumule de la dette technique ; les données de l'API ne font pas la distinction. Pipeline Success Rate mesure la conformité aux tests existants, non l'exhaustivité de la suite de tests elle-même : un développeur avec un taux de succès élevé dans un projet à faible couverture de tests reçoit un signal de qualité plus faible que ce que l'indicateur suggère dans une base de code bien testée. Deployment Frequency n'est significative que dans les contextes où l'équipe contrôle son processus de déploiement ; dans les organisations où les releases sont soumises à des processus d'approbation externes, l'indicateur reflète autant la politique organisationnelle que la performance individuelle.

L'attribution par utilisateur présente également une limitation structurelle sur GitLab.com : les adresses e-mail peuvent être définies comme privées, ce qui contraint l'appariement des utilisateurs GitLab avec les comptes Human Bridge. L'intégration résout l'attribution via les identifiants d'utilisateurs disponibles dans l'API, mais la fiabilité de cette résolution dépend d'une configuration cohérente des e-mails au sein de l'équipe. Plus largement, ces KPIs ne capturent que ce qui est enregistré dans GitLab : les conversations de revue de code menées hors de la plateforme, les décisions d'architecture prises en réunion et l'activité de mentorat ne laissent aucune trace dans les données. La fiabilité de l'ensemble des six indicateurs dépend directement de la discipline de l'équipe à utiliser GitLab comme registre de référence du travail d'ingénierie.