New Relic

New Relic expose un large éventail de types d'objets : entités APM, hôtes, sessions navigateur, applications mobiles, moniteurs synthétiques, incidents d'alerte, événements de déploiement et groupes d'erreurs. Cette intégration se concentre sur deux types d'objets qui disposent d'une attribution fiable par utilisateur : les incidents d'alerte, qui enregistrent qui a acquitté et qui a résolu chaque incident, et les événements de déploiement, qui enregistrent qui a poussé chaque changement. Les entités APM, les taux d'erreur et les scores Apdex ont été considérés mais exclus, car ce sont des métriques système sans champ propriétaire — ils mesurent la santé d'un service, et non la contribution d'un individu. Quatre KPIs ont été retenus, sélectionnés selon trois critères : capacité à attribuer à un ingénieur nominatif, résistance au gaming, et équilibre entre indicateurs avancés et retardés.

Réponse aux incidents : lecture de la performance on-call par indicateurs croisés

Trois KPIs couvrent la gestion des incidents. Ils sont conçus pour être lus ensemble, car chacun pris isolément invite une forme différente de distorsion.

Réactivité et vitesse de résolution

Le Mean Time To Acknowledge mesure le délai moyen entre la création d'une alerte et le moment où un ingénieur la marque comme acquittée. Le Mean Time To Resolve mesure le délai moyen entre la création et la clôture. Les deux indicateurs sont proches des métriques DORA et couvrent des phases distinctes de la chaîne de réponse aux incidents. Le Mean Time To Acknowledge est un indicateur avancé de la culture on-call : une valeur faible signale que les ingénieurs surveillent activement leurs alertes et interviennent avant que l'escalade soit nécessaire. Le Mean Time To Resolve est son pendant retardé, mesurant si l'équipe est capable de rétablir le service une fois l'incident sous gestion active. Un écart important entre les deux — acquittement rapide combiné à une résolution longue — identifie des incidents que les ingénieurs engagent promptement mais ne peuvent résoudre sans dépendances externes ou investigation prolongée.

Responsabilité sur les incidents à haute sévérité

Critical Incidents Acknowledged comptabilise le nombre d'alertes de priorité critique qu'un ingénieur donné a acquittées durant la période. C'est un indicateur retardé de prise en charge : il identifie qui, dans l'équipe, absorbe la charge on-call la plus lourde. Ce KPI est particulièrement utile en complément du Mean Time To Resolve. Un Mean Time To Resolve élevé combiné à un nombre élevé d'incidents critiques acquittés suggère que l'ingénieur porte une part disproportionnée des incidents les plus complexes ; un faible nombre combiné à un Mean Time To Resolve favorable peut indiquer que l'ingénieur résout des incidents moins difficiles pendant que d'autres gèrent les alertes critiques. Lire les deux indicateurs ensemble fait apparaître les déséquilibres de distribution de responsabilité que les métriques agrégées au niveau de l'équipe dissimulent systématiquement.

Le Mean Time To Resolve présente également un risque de gaming : un ingénieur peut clôturer un incident prématurément et laisser le problème se retrigguer, enchaînant plusieurs résolutions courtes pour améliorer la métrique. Critical Incidents Acknowledged neutralise ce risque en se concentrant sur le volume de travail sérieux accepté plutôt que sur la vitesse de clôture. Un ingénieur manipulant le Mean Time To Resolve devrait simultanément maintenir un volume crédible d'acquittements d'incidents critiques, ce qui contraint la stratégie adversariale.

Fréquence de déploiement : un indicateur avancé de la cadence d'ingénierie

Deployment Frequency comptabilise le nombre de déploiements poussés par un ingénieur donné durant la période. C'est l'une des quatre métriques DORA et elle sert d'indicateur avancé de la cadence d'ingénierie : les équipes qui déploient fréquemment tendent à publier des changements plus petits et plus sûrs, ce qui corrèle avec des taux d'incident plus bas et une récupération plus rapide. Au niveau individuel, Deployment Frequency fait apparaître des profils de contribution invisibles dans les systèmes de suivi de tickets — les ingénieurs qui construisent et livrent, par opposition à ceux qui planifient ou relisent.

Ce KPI présente un risque de gaming modéré : un pipeline qui étiquette chaque micro-commit comme un déploiement distinct peut gonfler artificiellement le compteur sans refléter une livraison significative. Le contre-poids est le Mean Time To Resolve : une fréquence de déploiement élevée qui génère un taux d'incident accru apparaîtra immédiatement sous forme d'un temps de résolution dégradé. La combinaison empêche la tension volume-stabilité de se résoudre dans un sens ou dans l'autre — ni ralentir artificiellement les déploiements pour éviter les incidents, ni pousser des changements sans en surveiller les conséquences.

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

New Relic enregistre le comportement observable du système, et non la qualité du jugement d'ingénierie. Le Mean Time To Resolve mesure la vitesse de clôture d'un incident, et non si la cause sous-jacente a été correctement diagnostiquée et durablement corrigée. Un incident clôturé en vingt minutes peut refléter un rollback maîtrisé ou un contournement superficiel qui reporte le problème ; les données de l'API ne distinguent pas les deux. De même, Deployment Frequency comptabilise les événements dans le journal de suivi des changements sans évaluer si le changement était bien conçu, correctement relu ou accompagné d'une couverture de tests suffisante.

L'attribution repose sur deux conditions comportementales. Premièrement, le pipeline de déploiement doit alimenter le champ utilisateur avec une adresse email valide et cohérente ; les entrées en texte libre issues de configurations CI/CD utilisant des noms de comptes de service ou des identifiants génériques échoueront à correspondre aux enregistrements utilisateurs de Human Bridge. Deuxièmement, l'acquittement et la clôture des incidents doivent être effectués dans New Relic par l'ingénieur qui a réellement répondu, et non par un manager clôturant des tickets au nom d'autres. Lorsque ces conditions sont réunies, les KPIs fournissent un signal fiable par ingénieur ; dans le cas contraire, les données se dégradent silencieusement. La qualité opérationnelle de la pratique on-call et de la configuration des outils de déploiement constitue, dans cette intégration, la contrainte déterminante de la qualité de mesure.