Management par les métriques : les indicateurs qui motivent vs ceux qui démotivent
Management par les métriques : les indicateurs qui motivent vs ceux qui démotivent
Dans une équipe bancaire que j'accompagnais chez Crédit Agricole, le manager avait introduit un dashboard "tickets fermés par développeur" pour identifier les meilleurs contributeurs. L'intention était bonne. Le résultat : en 3 mois, les tickets graves étaient réassignés pour éviter la blame en cas de délai, les développeurs évitaient les tickets complexes qui "plomberaient leur score", et deux développeurs seniors avaient commencé à chercher d'autres postes. Le dashboard a été supprimé. La confiance a mis 6 mois à se reconstruire.
Ce n'était pas un problème de personnes. C'était un problème de système de mesure.
La loi de Goodhart est impitoyable : dès qu'une mesure devient un objectif, elle cesse d'être une bonne mesure. Les développeurs sont intelligents. Quand vous mesurez les commits, ils commitent plus souvent avec de petits changements. Quand vous mesurez les tickets fermés, ils ferment rapidement plutôt que correctement. Et selon les données du programme DORA de Google, les équipes managées par des métriques individuelles ont un change failure rate 2,4 fois plus élevé que les équipes managées par des métriques système.
Il existe des métriques qui mesurent réellement la santé d'une équipe engineering, et qui motivent plutôt que de démotiver.
Les métriques toxiques : pourquoi elles détruisent
Commits par jour
Cette métrique mesure l'activité visible. Ce qu'elle génère : des commits atomiques sans valeur, des rebases inutiles pour simuler une activité, et un découragement des refactorings larges qui demandent plusieurs jours de travail invisible.
Un développeur qui passe 3 jours à comprendre un problème avant d'écrire 10 lignes de solution est souvent plus productif que celui qui produit 30 commits de "fix" sur le même problème. La métrique des commits pénalise le premier et récompense le second.
Lignes de code
Cette métrique mesure le volume produit. Ce qu'elle génère : du code verbose, des abstractions prématurées pour "faire grossir" les fichiers, et une résistance au refactoring qui réduit le code. Bill Gates l'a dit il y a des décennies : "Measuring programming progress by lines of code is like measuring aircraft building progress by weight."
Tickets fermés par développeur
J'ai décrit ce pattern plus haut. Cette métrique génère de la compétition entre développeurs là où vous avez besoin de collaboration. Elle pénalise précisément les comportements que vous voulez encourager : prendre les tickets difficiles, aider un collègue bloqué, documenter au lieu de fermer vite.
Les métriques DORA : le standard de l'industrie
Le programme DORA (DevOps Research and Assessment) de Google a analysé plus de 32 000 professionnels dans des milliers d'organisations pendant plusieurs années. Il a identifié 4 métriques qui corrèlent avec la performance organisationnelle réelle, et qui résistent à la loi de Goodhart parce qu'elles mesurent des résultats système, pas des comportements individuels.
Deployment Frequency
Cette métrique mesure à quelle fréquence l'équipe déploie en production. Une fréquence élevée révèle des pratiques saines : CI/CD stable, tests fiables, confiance de l'équipe. Ce n'est pas une métrique de vitesse individuelle : c'est une métrique de santé du système de delivery.
Benchmarks 2023 : Elite performers → plusieurs fois par jour. High performers → entre 1/jour et 1/semaine. Medium performers → entre 1/semaine et 1/mois.
Lead Time for Changes
Cette métrique mesure le temps entre le premier commit d'une feature et son déploiement en production. Un lead time court révèle des pratiques de review efficaces, une CI rapide, et des processus de déploiement fluides.
Benchmarks : Elite → moins d'1 heure. High → entre 1 jour et 1 semaine. Medium → entre 1 semaine et 1 mois.
Change Failure Rate
Cette métrique mesure le pourcentage de déploiements qui causent une dégradation de service nécessitant une correction urgente. C'est la métrique de qualité systémique. Un CFR bas révèle des pratiques de test solides et une culture de review rigoureuse.
Benchmarks : Elite → 0 à 5%. High → 5 à 10%. Medium → 10 à 15%.
Mean Time to Recovery (MTTR)
Cette métrique mesure le temps moyen pour restaurer le service après un incident. Elle révèle la maturité des pratiques de monitoring, d'alerting, et de gestion des incidents. Un MTTR court n'est pas le fruit de développeurs plus rapides : c'est le fruit d'outils de diagnostic et de processus de rollback efficaces.
Benchmarks : Elite → moins d'1 heure. High → moins d'1 jour.
Vous pilotez votre équipe engineering sans les métriques DORA — ou vous les avez mais vous ne savez pas comment les améliorer ?
Vous mesurez peut-être encore des métriques individuelles qui génèrent de la compétition au lieu de la collaboration, ou vous avez les métriques DORA mais sans savoir quoi en faire. En 30 minutes, je peux définir avec vous la stratégie d'implémentation adaptée à vos outils et votre contexte, et vous donner un plan concret pour les améliorer sur 90 jours.
Les métriques de santé d'équipe complémentaires
Les métriques DORA mesurent le système de delivery. Ces métriques complémentaires mesurent la santé organisationnelle.
Cycle Time par type de travail
Le cycle time mesure le temps entre le début effectif du travail sur une story et son merge. Décomposé par type (feature, bug fix, refactoring, infrastructure), il révèle où les goulots d'étranglement se trouvent. J'utilise cette métrique systématiquement dans mes diagnostics : elle localise le problème avec une précision que les métriques globales ne permettent pas.
Work In Progress (WIP)
Le nombre de stories en cours simultanément dans l'équipe. Un WIP élevé révèle un problème de flow : l'équipe commence trop de choses et en finit peu. La loi de Little prédit mathématiquement que réduire le WIP réduit le lead time, et les équipes qui l'appliquent voient des résultats en quelques semaines.
Engineering NPS (eNPS)
Une question posée chaque mois à l'équipe : "Sur une échelle de 0 à 10, recommanderais-tu ce projet comme environnement de travail à un autre développeur ?" Le score eNPS est un indicateur précoce de turnover et de désengagement. Dans toutes les organisations où j'ai travaillé (BNP Paribas, Canal+, Agirc-Arrco), un eNPS qui descend pendant 2 mois consécutifs précède systématiquement des départs dans les 3 à 6 mois suivants.
Comment présenter ces métriques au board
Le board ne s'intéresse pas aux métriques DORA en tant que telles. Il s'intéresse à ce qu'elles signifient en termes business. Ma traduction habituelle :
- Deployment Frequency → "Nous pouvons répondre à une opportunité de marché en X jours, contre Y jours il y a 6 mois"
- Lead Time for Changes → "Le time-to-market d'une nouvelle feature est de X semaines, nous visons Y" (voir les benchmarks par niveau de maturité engineering)
- Change Failure Rate → "X% de nos déploiements causent un incident, à un coût moyen estimé de Y€ par incident"
- MTTR → "En cas d'incident, notre service est restauré en moins de X heures, nous respectons nos SLAs à 99,2%"
Ces traductions permettent au board de comprendre l'impact business des métriques techniques et de soutenir les investissements en amélioration des pratiques. Code → Système → Organisation → Valeur : c'est dans cet ordre que je présente toujours.
FAQ sur les métriques engineering
Comment implémenter les métriques DORA si nous n'avons pas les outils en place ?
Les 4 métriques DORA peuvent être calculées avec des données déjà présentes dans les outils existants. Deployment Frequency et Change Failure Rate → GitHub/GitLab Actions + PagerDuty ou OpsGenie. Lead Time → Jira (date de création vs date de fermeture, ajusté pour le temps en attente). MTTR → incidents PagerDuty. Des outils dédiés (LinearB, Jellyfish, Sleuth) automatisent ce calcul, mais l'implémentation manuelle via des requêtes API prend 1 à 2 semaines et donne le même résultat.
Les métriques DORA s'appliquent-elles aux petites équipes de moins de 5 développeurs ?
Oui, avec une nuance sur l'interprétation statistique. Sur une équipe de 3 développeurs, un seul incident peut faire exploser le Change Failure Rate ou le MTTR : la variance est élevée. Il faut regarder les tendances sur 3 mois plutôt que les valeurs ponctuelles. Le lead time et la deployment frequency restent des métriques valides quelle que soit la taille de l'équipe.
Faut-il publier les métriques individuelles en interne ?
Non. Les métriques DORA sont des métriques d'équipe : elles se publient au niveau de l'équipe, pas de l'individu. Les métriques individuelles (feedback de performance, développement de carrière) se traitent en 1-on-1 et restent confidentielles. Publier des classements individuels crée de la compétition destructrice ; publier des métriques d'équipe crée de la solidarité et une motivation collective.
Comment gérer un manager qui insiste pour avoir des métriques individuelles ?
Je propose un compromis : des métriques de contribution individuelle qui mesurent la valeur, pas l'activité. Exemples : "nombre de PR reviewées par semaine" (contribution à la qualité collective), "stories de complexité élevée terminées" (plutôt que le volume), "mentorat : nombre de 1-on-1 techniques avec des juniors". Ces métriques mesurent des comportements à valeur ajoutée sans créer les effets pervers des métriques d'activité.
Quelle est la fréquence idéale de révision des métriques avec l'équipe ?
Deux niveaux. Une revue hebdomadaire des métriques opérationnelles (lead time de la semaine, WIP actuel, incidents en cours) lors du stand-up ou d'une courte réunion dédiée. Une revue mensuelle des tendances DORA avec l'équipe complète, en incluant les actions d'amélioration décidées le mois précédent et leur impact mesuré. Ce second niveau est souvent absent : c'est pourtant lui qui génère l'amélioration continue.
Ressource gratuite : Engineering Maturity Self-Assessment
L'Engineering Maturity Self-Assessment couvre le domaine Delivery & Métriques : évaluez votre niveau de maturité sur les métriques DORA, l'outillage, et les pratiques de pilotage. Score et plan d'amélioration en 10 minutes.
