Sentry

Sentry expose plusieurs types d'objets : issues (groupes d'erreurs), événements, releases, projets, équipes et membres. Cette intégration se concentre sur deux d'entre eux — les issues et les releases — qui couvrent ensemble les deux axes du pilotage de la fiabilité en production : la réponse aux erreurs existantes et la qualité du code mis en production. Les autres objets, comme les événements ou les équipes, sont utiles pour le contexte opérationnel mais ne produisent pas d'indicateurs attribuables de manière fiable à des contributeurs individuels. Cinq KPIs ont été retenus, sélectionnés selon trois critères : capacité d'attribution à un responsable identifiable par e-mail, résistance au gaming, et équilibre entre indicateurs avancés et retardés.

Gestion des incidents : lire le cycle de résolution

Trois KPIs suivent la façon dont un ingénieur gère les issues qui lui sont assignées. Ils sont délibérément conçus pour se contraindre mutuellement, empêchant qu'un seul indicateur soit optimisé de manière isolée.

Volume et vitesse

Issues Resolved comptabilise le nombre de groupes d'erreurs qu'un développeur a amenés au statut résolu durant la période, à l'exclusion des résolutions par le bouton ignorer, qui suppriment la visibilité sans corriger la cause sous-jacente. Mean Time to Resolution mesure le temps moyen écoulé entre le moment où une issue apparaît pour la première fois en production et le moment où elle est résolue. Lus isolément, chaque indicateur est incomplet : un nombre élevé d'issues résolues obtenu par des clôtures rapides peut signaler des corrections superficielles, tandis qu'un temps moyen de résolution court sur un faible volume peut simplement refléter que seules les issues faciles ont été sélectionnées. Lus ensemble, ils révèlent si l'ingénieur traite un volume significatif à une vitesse soutenable, ou concentre ses efforts soit sur la quantité soit sur la facilité.

Contrepoids qualité

Regression Rate mesure la proportion d'issues marquées résolues puis rouvertes comme régressées — c'est-à-dire que l'erreur est réapparue en production après le déploiement du correctif. Cet indicateur est le principal contrepoids qualité de Issues Resolved. Il est difficile à manipuler : un taux de régression élevé signale directement que les clôtures étaient prématurées, indépendamment de la rapidité avec laquelle elles ont été enregistrées. Le couple Issues Resolved et Regression Rate crée un système auto-correcteur : une pression à augmenter le volume résolu qui débouche sur des correctifs insuffisants se manifestera immédiatement dans la métrique de régression. Un nombre minimal d'issues résolues est nécessaire avant que le ratio soit statistiquement significatif, ce qui limite son utilité pour les ingénieurs traitant moins de dix issues par période.

Pression du backlog

Critical Open Issues compte les issues non résolues de niveau fatal ou de priorité critique actuellement assignées à l'ingénieur. Contrairement aux autres indicateurs de ce bloc, c'est un indicateur avancé : il reflète l'état actuel du backlog avant toute action. Sa valeur managériale est directionnelle plutôt que rétrospective — une hausse signale une pression croissante qui fera probablement augmenter le Mean Time to Resolution dans les périodes suivantes si elle n'est pas résorbée. Ce KPI est le plus utile comme signal opérationnel quotidien et comme point d'entrée dans les discussions sur la charge de travail, plutôt que comme mesure de performance à long horizon.

Qualité des releases : attribuer les nouvelles erreurs à leur source

New Issues Introduced mesure le nombre total de nouveaux groupes d'erreurs apparus en production à la suite de releases dont l'ingénieur est listé comme auteur. Cet indicateur relie l'événement de déploiement à son effet en aval : plutôt que de suivre uniquement si des bugs ont été corrigés, il suit si de nouveaux bugs ont été introduits. La combinaison de Issues Resolved et New Issues Introduced crée une vue de fiabilité nette — un développeur qui résout dix issues et en introduit trois produit un résultat différent de celui qui en résout dix sans en introduire aucune, et cette différence est managérialement significative.

Cet indicateur comporte une réserve d'attribution qu'il convient de rendre explicite. Dans les équipes qui utilisent des squash merges ou des pipelines de déploiement automatisés, l'auteur du commit enregistré sur une release peut être un bot CI ou un release manager plutôt que l'ingénieur qui a écrit le code. Dans ces configurations, New Issues Introduced sera soit vide pour la plupart des ingénieurs, soit concentré sur un seul compte d'automatisation, rendant l'indicateur analytiquement non fiable au niveau individuel. Les équipes utilisant des workflows standard basés sur des branches avec une attribution de commits individuelle trouveront l'indicateur pertinent ; les équipes avec des pipelines automatisés devraient le traiter comme un signal d'équipe plutôt que comme une mesure par ingénieur.

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

Sentry enregistre l'occurrence des erreurs, l'assignation et le statut de résolution, mais ne mesure pas la qualité du correctif mis en œuvre. Une issue marquée résolue peut correspondre à une analyse précise de la cause racine et à une solution permanente, ou à un contournement qui supprime temporairement l'erreur. L'indicateur Regression Rate compense partiellement ce manque en faisant remonter les clôtures prématurées après coup, mais il le fait avec un délai et seulement lorsque l'erreur réapparaît selon le même schéma.

Une limite structurelle de cette intégration tient au modèle d'assignation. De nombreuses issues dans Sentry ne sont pas assignées, en particulier dans les équipes sans processus de triage formalisé, ou sont assignées à une équipe plutôt qu'à un individu. Les issues non assignées et assignées à des équipes sont exclues par construction de tous les calculs de KPIs par utilisateur, ce qui signifie que l'intégration ne capture qu'une fraction du volume total d'erreurs dans les environnements où la discipline d'assignation est faible. La fiabilité de ces KPIs dépend donc directement de la pratique de l'équipe consistant à assigner chaque issue à un individu nommé : les équipes qui trient et assignent systématiquement verront des indicateurs individuels précis ; les équipes qui laissent les issues non assignées verront des métriques systématiquement sous-estimées qui ne reflètent pas la charge de travail réelle.