Top des KPIs à suivre en tant que CTO

Pour mener à bien son travail, un CTO doit pouvoir mesurer sa performance. Pour cela, il va définir les KPIs les plus pertinents compte tenu de la maturité de la société dans laquelle il évolue.

Vous trouverez ci-dessous les KPIs qui paraissent être les plus pertinents à suivre.

Métriques financiers

Les métriques financiers permettent au CTO de suivre les dépenses de son service. Il est important d’examiner les dépenses afin de respecter le budget fixé tout au long de l’année.

Dépenses IT vs Plan

Le but de cet indicateur est d’avoir une vision macro des dépenses du service IT par rapport au budget qui a été défini. Il permet de détecter et corriger les problèmes avant qu’ils ne deviennent critiques et de responsabiliser chaque collaborateur aux dépenses du service.

Il permet de répondre aux questions suivantes :

• Est-ce que je dépense ce que j’avais prévu ?
• Quels sont les domaines de dépenses que j’ai surestimés ou sous-estimés ?

Le suivi doit se faire mensuellement ou trimestriellement.

Coût total des applications et services

Cet indicateur va permettre d’avoir une vision détaillée par service. C’est la version détaillée du KPI précédent. Il répond donc aux mêmes questions et doit avoir la même cadence.

Métriques d’équipe

Comme nous l’avons vu dans l’article sur le Servant Leadership, le CTO est au service de l’entreprise et de ses collaborateurs. Par conséquent, les KPIs qu’il va suivre vont tourner autour du bien-être.

Niveau de satisfaction

Le niveau de satisfaction de vos équipes est un indicateur essentiel à suivre. Il va vous permettre de prendre la température du moral de vos équipes et ainsi agir rapidement si vous détectez une perte d’intérêt.

Il permet de répondre aux questions suivantes :

• Est-ce que mes collaborateurs sont heureux d’être là ?
• Est-ce que le moral de certain d’entre eux peut affecter celui d’autres ?

Le suivi doit se faire au fil de l’eau. Vous devez échanger avec eux directement et les écouter.

Vélocité

La mesure de la vélocité doit être faite avec précaution. Nous voyons encore bien trop souvent cette KPI être utilisée pour comparer les équipes les unes avec les autres. La vélocité doit être utilisée pour aider à la planification et non pour mesurer l’efficacité.

Il permet de répondre aux questions suivantes :

• Combien de temps me faudra-t-il pour réaliser cette fonctionnalité ?
• Est-ce que la baisse de la vélocité cache une problématique plus profonde dans mon équipe ?

Le suivi doit se faire mensuellement.

Turnover

La baisse de vélocité peut cacher un problème sous-jacent qui peut ensuite entrainer du turnover. Le turnover est la pire chose qui puisse arriver à votre équipe. Recruter, intégrer et former est un long processus qui doit être limité autant que possible.

Il permet de répondre aux questions suivantes :

• Est-ce que j’ai un turnover d’origine naturelle ?
• Est-ce que le turnover va affaiblir le fonctionnement de mes équipes ?

Le suivi doit se faire mensuellement ou trimestriellement.

Métriques de performance

Il existe des dizaines de métriques de performance des applications. Nous allons voir les plus pertinentes pour toutes les tailles de société.

Disponibilité de l’application

Cette KPI est un incontournable et assurément la première à laquelle on pense en tant que CTO. Elle permet de calculer le SLA de son application. Un SLA supérieur à 99.9% voir 99.95% réduit le risque de perdre des données, de la productivité et des clients.

Le suivi doit se faire mensuellement, trimestriellement et annuellement.

Mean Time to Failure (MTTF)

MTTF représente la moyenne du temps qui s’est écoulé entre deux indisponibilités successives sous des conditions normales d’exploitation. C’est une métrique vitale car elle permet aux développeurs de comprendre si l’application devient instable dans le temps.

Il permet de répondre aux questions suivantes :

• Combien de temps mon application fonctionne normalement entre deux pannes ?
• Est-ce que ce temps diminue ?

Le suivi doit se faire à chaque panne.

Mean Time to Repair (MTTR)

MTTR mesure la moyenne de temps nécessaire pour trouver la cause et fixer le problème. Les développeurs utilisent cette métrique pour évaluer leur procédure et leur capacité à réparer un système. Avec plus de recul, il permet également d’être une source d’information du temps nécessaire pour les prochaines résolutions.

Il permet de répondre aux questions suivantes :

• Combien de temps mets mon équipe à résoudre un problème ?
• Est-ce que ce temps s’allonge ou diminue ?
• Dans des cas similaires, quelle sera le temps nécessaire à la résolution ?

Le suivi doit se faire à chaque panne.

Temps de chargement & temps de réponse

Concernant les pages web, il est intéressant de mesurer le temps de chargement. Du côté des APIs, nous allons plutôt nous concentrer sur le temps de réponse. Ces métriques permettent de suivre les évolutions qui améliorent ou dégradent l’expérience utilisateur.

Il permet de répondre aux questions suivantes :

• En combien de temps répond mes pages web et mes APIs ?
• Est-ce que ce temps s’allonge ou diminue ?

Le suivi doit se faire mensuellement et trimestriellement.

Métriques de qualité

Couverture de test

La couverture de test est une métrique importante. Attention toutefois à ne pas tester du code trivial pour artificiellement augmenter la couverture de code. Il est bien plus pertinent de se concentrer sur les zones critiques de code.

Il permet de répondre aux questions suivantes :

• Est-ce que mon code critique est correctement couvert par des tests ?
• Est-ce que ma couverture augmente ou diminue ?

Le suivi doit se faire mensuellement et trimestriellement.

Nouveaux bugs dans le temps

Le nombre de nouveaux bugs dans le temps doit être également suivi. Les développeurs peuvent s’appuyer sur cette métrique afin de vérifier de la qualité de leurs commits. Plus il y a de bugs, plus cela crée des allers-retours entre les équipes de tests et de développements.

Il permet de répondre aux questions suivantes :

• Est-ce que mon nombre de bugs augmente ou diminue dans le temps ?

Le suivi doit se faire mensuellement et trimestriellement.

Temps de résolution des bugs

Le temps de résolution des bugs donne des informations aux développeurs sur le temps perdu à résoudre le problème. Si le temps est en hausse, cela peut vouloir dire que la qualité d’écriture des demandes est en baisse et engendre plus d’aller-retours pour arriver au résultat attendu. Cela peut aussi vouloir dire que l’application est de plus en plus complexe à maintenir et que de la dette technique s’est peut-être accumulée.

Il permet de répondre aux questions suivantes :

• Est-ce que le temps de résolution des bugs augmente ou diminue dans le temps ?
• Est-ce que c’est le signe d’un problème de complexité de mon application ?

Le suivi doit se faire mensuellement et trimestriellement.

Nous avons fait le tour des principales KPIs à suivre en tant que CTO. Elles vous donneront une bonne vision de la situation.

Comment je peux vous aider ?

Sélectionner et mettre en place les bonnes KPIs pour suivre votre service informatique peut-être une tâche difficile.

N’hésitez pas à me contacter si vous rencontrez des difficultés.