Linear

Linear expose plusieurs types d'objets : issues, cycles, projets, équipes, états de workflow et étiquettes. Cette intégration se concentre exclusivement sur les issues, qui représentent l'unité atomique de travail et le seul type d'objet où l'attribution à un contributeur individuel est fiable. Les cycles et les projets exposent des agrégats utiles au niveau de l'équipe, mais ne permettent pas une attribution par utilisateur pertinente pour la gestion des OKR. Six KPIs ont été retenus, sélectionnés selon trois critères : capacité d'attribution à un responsable via la résolution directe par email, résistance au gaming, et équilibre entre indicateurs avancés et retardés.

Débit de livraison et vélocité individuelle

Issues Completed comptabilise le nombre d'issues qu'un développeur ferme au cours d'une période. Average Cycle Time mesure le nombre moyen de jours entre le début du traitement actif d'une issue et son achèvement. Ces deux indicateurs fonctionnent comme un contrepoids délibéré l'un de l'autre. Issues Completed crée une incitation à livrer du volume ; Average Cycle Time contraint cette incitation en pénalisant la pratique consistant à faire passer des issues petites ou triviales pour gonfler le débit. Un développeur affichant un nombre élevé d'issues complétées avec un cycle time très court peut ne fermer que des issues de faible complexité, tandis qu'un développeur avec un nombre modéré et un cycle time stable absorbe peut-être les travaux les plus exigeants. Lire les deux ensemble révèle la qualité réelle du débit, et pas seulement sa quantité.

High Priority Issues Completed ajoute une troisième dimension à ce groupe. Il filtre le comptage des issues complétées sur les seules priorités urgentes et hautes, isolant la fraction du débit orientée vers ce que l'équipe a déclaré le plus important. Un Issues Completed élevé combiné à un High Priority Issues Completed faible révèle un écart de priorisation : le développeur est productif mais pas focalisé sur ce qui compte. Cette combinaison est l'un des signaux de désalignement les plus forts que l'intégration puisse faire remonter.

Fiabilité des engagements et santé du flux

Cycle Carryover comptabilise le nombre d'issues qu'un développeur avait en cours ou non démarrées à la fin d'un cycle sans les avoir achevées. C'est la mesure la plus directe de la fiabilité des engagements disponible dans Linear : elle ne mesure pas l'effort ou l'intention, uniquement le résultat face au plan que l'équipe avait établi en début de cycle. Un carryover soutenu sur plusieurs cycles peut indiquer un périmètre mal défini, des changements de contexte fréquents, ou des issues systématiquement plus volumineuses qu'estimé. Stale Issues mesure le nombre d'issues en cours qui n'ont pas été mises à jour depuis cinq jours. Il opère un niveau plus tôt dans le processus que le carryover : plutôt que de confirmer qu'un travail n'a pas été complété, il signale en temps réel que le travail s'est arrêté. Ensemble, Stale Issues (avancé) et Cycle Carryover (retardé) forment une chaîne de détection : la stagnation prédit le carryover avant que la fin du cycle ne le rende visible.

Alimentation du backlog

Issues Opened comptabilise le nombre d'issues qu'un utilisateur crée au cours d'une période, attribué au créateur et non à l'assigné. Il mesure la contribution active au pipeline : les développeurs qui créent des issues bien cadrées investissent dans la capacité future de l'équipe à livrer. Cet indicateur comporte un risque Goodhart s'il est lu isolément — créer une issue est peu coûteux et non vérifiable en termes de qualité — mais ce risque est neutralisé lorsqu'il est associé à Issues Completed : un créateur affichant un Issues Opened élevé et un Issues Completed personnel faible signale quelqu'un qui alimente un travail qu'il ne prend pas en charge lui-même. La relation entre les deux taux est le signal pertinent.

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

Linear enregistre les transitions d'états et les horodatages, mais ne mesure pas la qualité du travail produit. Une issue marquée comme complétée peut correspondre à une implémentation robuste et bien testée ou à un correctif partiel qui génèrera des régressions en aval ; les données de l'API ne permettent pas de distinguer les deux. Average Cycle Time dépend en particulier de l'utilisation cohérente des états de workflow Linear par les équipes : si les développeurs marquent les issues comme démarrées de façon irrégulière ou seulement au moment de la complétion, le cycle time calculé s'effondre à une valeur proche de zéro et perd sa valeur diagnostique. High Priority Issues Completed dépend de l'application disciplinée et standardisée des champs de priorité ; les équipes qui utilisent les étiquettes de priorité de façon lâche ou incohérente produiront une métrique non comparable d'un individu à l'autre.

Plus généralement, cette intégration ne capture que ce qui est documenté dans Linear. Le travail coordonné en dehors de l'outil — dans des fils Slack, des documents partagés, des sessions de débogage directes — reste invisible. La fiabilité des six KPIs dépend directement de la discipline de l'équipe à maintenir Linear à jour comme source de vérité de son travail.