Métriques d'ingénierie sans Jira
Pas besoin de Jira pour mesurer ce qui compte. Comment suivre la santé de votre équipe depuis Git, CI et les outils que vous utilisez déjà.
By Ellis Keane · 2026-03-23
Les petites équipes qui obtiennent la meilleure visibilité en ingénierie sont souvent celles qui ont arrêté de courir après les métriques que Jira veut qu'elles suivent.
Je réalise que ça ressemble à de la simple contradiction pour le plaisir de contredire – et honnêtement, peut-être un peu. Mais j'ai passé près de trois ans à maintenir consciencieusement des tableaux de sprint, à affiner des backlogs et à mettre à jour des estimations sur des tickets déjà à moitié terminés avant que quelqu'un ouvre Jira ce matin-là. Toutes les deux semaines, on s'asseyait dans une salle (enfin, un Zoom – c'était 2023) et on regardait un graphique de velocity qui ne nous apprenait strictement rien qu'on ne sût déjà en se parlant. Les métriques d'ingénierie sans Jira, ce n'est pas quelque chose que j'ai cherché. C'est ce qui s'est passé quand j'ai cessé de prétendre que les graphiques de velocity m'apprenaient quoi que ce soit d'utile.
Si votre équipe est assez petite pour s'asseoir autour d'une seule table, vous n'avez probablement pas besoin de Jira pour savoir comment vous vous en sortez. Vous avez besoin de meilleurs signaux provenant des outils que vous utilisez déjà.
Ce n'est pas un article "Jira c'est mauvais". Jira est un bon outil pour les organisations qui ont besoin d'un suivi à la façon Jira (et à une certaine échelle, elles en ont genuinement besoin). Mais si vous êtes engineering manager dans une startup de 10 à 40 personnes et que vous payez Jira uniquement pour produire des graphiques de velocity, c'est un peu comme acheter un four industriel pour réchauffer votre déjeuner.
"Payer pour Jira uniquement pour produire des graphiques de velocity, c'est un peu comme acheter un four industriel pour réchauffer son déjeuner." attribution: Chris Calo
Ce que mesurent réellement les métriques Jira
Soyons directs : la plupart des métriques Jira mesurent l'utilisation de Jira, pas la production d'ingénierie. Les story points mesurent la capacité de l'équipe à estimer des story points. La velocity mesure la régularité avec laquelle l'équipe remplit les sprints à peu près à la même capacité. Les burndown charts mesurent si quelqu'un a pensé à faire glisser des tickets sur le tableau le jeudi après-midi.
Aucune de ces métriques n'est totalement inutile. Mais ce sont des métriques de processus déguisées en métriques de productivité des développeurs, et c'est dans cet écart que les engineering managers perdent le fil.
J'ai été cet EM qui passe près d'une heure avant une réunion avec des parties prenantes à manipuler des données Jira pour une présentation montrant "nous sommes dans les temps". La partie prenante hoche la tête, pose une question sur le bug de connexion de mardi dernier, et la réunion se termine. L'heure était pour la présentation. La vraie réponse était "demandez à l'ingénieur".
Si vos métriques demandent plus de maintenance que le travail qu'elles mesurent, les métriques sont le problème.
Le temps de cycle depuis Git, pas depuis les tableaux de tickets
Pour les petites équipes produit, le temps de cycle est généralement la métrique avec le plus de signal que vous pouvez suivre. Il mesure la durée du premier commit au déploiement en production, et vous pouvez le dériver entièrement de votre historique Git et de votre pipeline CI – sans tableau de tickets.
Les composantes :
- Horodatage du premier commit sur une branche ou une PR
- Horodatage du merge de la PR
- Horodatage du déploiement (depuis votre CI/CD – GitHub Actions, CircleCI, ou ce que vous utilisez)
Le delta entre 1 et 3 est votre temps de cycle. Décomposez-le en segments – temps de codage (du 1 à l'ouverture de la PR), temps de révision (ouverture de la PR au merge) et file d'attente de déploiement (merge à la production) – et vous avez un diagnostic qui vous dit où le travail s'enlise vraiment.
Quand j'ai fait ça pour la première fois pour notre équipe, les chiffres étaient vraiment surprenants. J'avais supposé que le temps de révision était notre goulot d'étranglement (tout le monde suppose toujours que c'est le temps de révision, non ?). Il s'est avéré que notre phase de codage jusqu'à la PR était correcte, les révisions étaient correctes, et nous perdions en moyenne deux jours entre le merge et le déploiement parce que notre environnement de staging était instable et personne n'avait priorisé sa correction. Un graphique de velocity n'aurait jamais fait remonter ça.
Comment le mesurer
Si vous utilisez GitHub, vous pouvez l'obtenir avec la CLI :
```bash
Récupérer les PRs fusionnées au cours des 30 derniers jours
gh pr list – state merged – limit 50 – json number,createdAt,mergedAt,headRefName ```
Pour les horodatages de déploiement, la plupart des systèmes CI les exposent via une API ou un webhook. Associez les SHAs de merge de PR aux événements de déploiement, et vous avez le temps de cycle segmenté par phase.
Conseil : Si votre CI n'expose pas les horodatages de déploiement proprement, une approche très simple est un bot Slack qui publie dans un canal #deploys avec le SHA du commit. Vous obtenez des horodatages, un journal lisible par un humain et – comme effet secondaire – un canal qui vous indique à quelle fréquence vous livrez.
Débit de révision de code
Le débit de révisions – le nombre de PRs révisées par ingénieur par semaine, et le temps médian entre l'ouverture d'une PR et la première révision – en dit plus sur la santé de l'équipe que n'importe quelle métrique de sprint. Il est sous-estimé.
Pourquoi ? Parce que le comportement lors des révisions est un indicateur avancé. Quand les temps de révision augmentent, ça signifie généralement que les ingénieurs sont surchargés, font trop de changements de contexte, ou – et c'est celui qui met mal à l'aise – évitent le code des autres. Chacun de ces scénarios mérite d'être connu avant qu'il n'apparaisse comme une deadline manquée deux semaines plus tard.
GitHub vous fournit ces données via son API. Les champs clés sont createdAt sur la PR et submittedAt sur le premier événement de révision.
Le chiffre que je surveille est les heures médianes avant la première révision. D'après notre expérience dans plusieurs petites équipes, une cadence de révision saine se situe généralement en dessous d'environ 8 heures. Quand elle dépasse une journée de façon constante, quelque chose de structurel a changé – et quoi que ce soit, c'est invisible dans Jira.
Le ratio réunions-à-décisions
Ce n'est pas une métrique d'ingénierie traditionnelle, et je dois être transparent : c'est une heuristique approximative, pas un KPI. Mais pour les petites équipes, je la trouve étonnamment révélatrice.
Comptez les réunions que votre équipe a eues cette semaine. Comptez les décisions concrètes qui en sont sorties (pas "nous devrions nous pencher sur X" – de vraies décisions avec des responsables et des prochaines étapes). Divisez le second par le premier.
Si moins de la moitié de vos réunions ont produit une décision, il vaut la peine de se demander si ces réunions méritent leur temps. Certaines réunions existent pour réduire les risques ou partager le contexte, et c'est légitime – tout n'a pas besoin de se terminer par une résolution. Mais quand vous commencez à suivre ça même informellement (j'ai littéralement tenu un décompte dans mon carnet), vous développez un sens pour savoir quelles réunions sont génératives et lesquelles ne sont que des rituels que personne n'a remis en question.
J'ai suivi ça pendant environ un mois, et ça a changé la façon dont je planifiais les réunions plus que n'importe quel article de productivité. Quand vous pouvez voir que votre standup du lundi n'a produit exactement zéro décision pendant trois semaines consécutives, l'annuler cesse de sembler radical.
Construire des métriques d'ingénierie sans Jira : un tableau de bord léger
Vous n'avez pas besoin d'un outil de BI pour ça. Une page Notion, une feuille Google ou un post Slack hebdomadaire avec quatre chiffres suffit :
- Temps de cycle médian (depuis Git/CI) – livrons-nous plus vite ou plus lentement ?
- Temps médian avant la première révision (depuis GitHub) – l'équipe révise-t-elle rapidement ?
- Fréquence de déploiement (depuis CI ou canal #deploys) – à quelle fréquence livrons-nous ?
- Ratio réunions-à-décisions (décompte manuel) – nos réunions méritent-elles leur temps ?
Quatre chiffres, tous dérivables des outils que vous avez déjà, aucun ne nécessitant de maintenir un tableau Jira. Mettez-les à jour chaque semaine. Si un chiffre va dans la mauvaise direction deux semaines de suite, investiguez. S'il reste stable, laissez-le tranquille.
L'objectif n'est pas de construire un système de surveillance (s'il vous plaît, ne le faites pas – vos ingénieurs vous en voudront, et ils auront raison). La visibilité de l'équipe d'ingénierie devrait venir du travail lui-même, pas de demander aux gens de faire des rapports sur le travail.
Les meilleures métriques d'ingénierie sont peu coûteuses à collecter, difficiles à manipuler et vous disent quelque chose sur lequel vous pouvez agir. Les story points échouent sur ces trois critères.
Quand vous avez vraiment besoin d'un tableau de tickets
J'ai dit que ce n'est pas un article "Jira c'est mauvais", et je le pensais. Il y a des situations légitimes où suivre les métriques sans outil de gestion de projet devient genuinement irresponsable :
- Les secteurs à forte contrainte de conformité où les pistes d'audit sur le statut des tâches sont légalement requises
- Les organisations d'ingénierie plus grandes où les dépendances entre équipes rendent la coordination informelle intenable
- Les organisations avec des fonctions de gestion de projet dédiées qui ont besoin d'une source de vérité canonique entre les équipes
Si c'est votre situation, Jira (ou Linear, ou Shortcut) est le bon choix. Ce que j'argumente, c'est que pour les petites équipes, maintenir un outil lourd uniquement pour les métriques est un mauvais compromis. Vous finissez par optimiser pour le modèle de travail de l'outil plutôt que pour le travail réel de votre équipe.
Et honnêtement ? Même les équipes qui utilisent Jira bénéficieraient de compléter leurs données de tableau avec les métriques dérivées de Git mentionnées ci-dessus. Jira vous dit ce que les gens disent qu'ils font. Git vous dit ce qu'ils font réellement. Les deux sont utiles, mais un seul est immunisé contre le théâtre des mises à jour de statut.
Si la question des métriques revient sans cesse dans votre startup, essayez le tableau de bord à quatre chiffres pendant un mois. Les métriques d'ingénierie sans Jira peuvent sembler être comme travailler sans filet de sécurité – mais une fois que vous voyez combien de signal vit dans votre historique Git et votre pipeline CI, vous vous demanderez ce qu'apportait le tableau de tickets.
Découvrez automatiquement le temps de cycle, les PRs bloquées et les goulots d'étranglement dans les révisions – sans scripts personnalisés ni tableau Jira.
Q: Peut-on obtenir des métriques d'ingénierie pertinentes sans outil de gestion de projet ? A: Oui. Le temps de cycle (premier commit jusqu'au déploiement), le débit de révisions et la fréquence de déploiement se trouvent tous dans votre historique Git et votre pipeline CI. Pour les équipes de moins de 40 ingénieurs, ils ont tendance à être plus précis et plus difficiles à manipuler que ce que produit un tableau de tickets – et ils ne nécessitent pas que quelqu'un fasse glisser des cartes sur un tableau pour rester exacts.
Q: Sugarbug affiche-t-il automatiquement les métriques d'ingénierie ? A: Sugarbug se connecte à GitHub, Linear, Slack et aux calendriers pour construire un graphe de connaissances de l'activité de votre équipe. Il signale des schémas comme les PRs bloquées, les goulots d'étranglement dans les révisions et les décisions non résolues – ce qui couvre beaucoup des signaux décrits ici sans vous demander d'écrire et de maintenir des scripts personnalisés contre l'API GitHub.
Q: Comment obtenir l'adhésion pour arrêter d'utiliser Jira pour les métriques ? A: Présentez-le comme une expérience, pas une révolution. Faites tourner des métriques dérivées de Git en parallèle de vos tableaux de bord Jira existants pendant quatre semaines, puis comparez quels chiffres ont provoqué de vrais changements. Si les métriques Git s'avèrent plus actionnables (et d'après notre expérience, elles le sont), l'argument se fait tout seul.
Q: Quelle est la différence entre métriques de processus et métriques de performance ? A: Les métriques de processus (story points, velocity, burndown) mesurent la régularité avec laquelle une équipe suit un flux de travail. Les métriques de performance (temps de cycle, fréquence de déploiement, débit de révisions) mesurent ce que l'équipe livre réellement et à quelle vitesse. Les petites équipes obtiennent presque toujours plus de signal des secondes, parce que les métriques de performance sont dérivées du travail lui-même plutôt que de mises à jour de statut manuelles.