Les 4 métriques Accelerate : mesurer sans devenir esclave des chiffres

Accelerate repose sur quatre métriques principales qui permettent d'évaluer la performance de votre organisation en matière de delivery logiciel. Ces métriques sont simples à comprendre, mais les mesurer correctement et surtout les interpréter avec recul demande un peu plus de finesse qu'il n'y paraît.

Les 4 métriques en un coup d'œil

Deployment Frequency : livrez-vous de la valeur régulièrement ?

La fréquence de déploiement mesure la capacité de votre organisation à mettre régulièrement en production des incréments de produit. Est-ce que vous livrez plusieurs fois par jour, une fois par semaine, une fois par mois, ou une fois par trimestre ? Plus cette fréquence est élevée, plus vous êtes en mesure de réagir rapidement aux retours de vos utilisateurs.

Attention cependant : pousser uniquement sur l'accélération de cette fréquence sans regarder les autres métriques peut être dangereux. Vous risquez de stresser vos équipes ou de les amener à faire de la sous-qualité pour tenir la cadence. C'est pour cette raison que les quatre métriques doivent être lues ensemble, jamais isolément.

Lead Time to Change : êtes-vous vraiment agiles ?

C'est la durée entre le moment où une idée est validée et celui où elle arrive en production. Cette métrique est souvent la plus révélatrice car elle ne mesure pas seulement la vitesse de développement, mais l'ensemble de la chaîne : conception, développement, tests, déploiement.

Chez Wizbii, c'est cette métrique qui a été la plus utile. En la mesurant précisément, on s'est rendu compte qu'on avait trop de backlog "en stock". Les Product Owners passaient beaucoup de temps à rédiger des user stories en avance, ce qui créait un embouteillage dans le pipe. Les nouvelles idées mettaient parfois des semaines à arriver en production, non pas parce que les développeurs étaient lents, mais parce que le temps d'attente en amont était trop long.

La solution a été contre-intuitive : au lieu de demander aux POs de travailler encore plus vite sur les spécifications, on leur a demandé de moins anticiper. Ils se sont recentrés sur la recherche utilisateur en amont du process et sur les tests en aval, plutôt que sur la rédaction massive de stories. Résultat : un backlog plus lean, des idées qui arrivent plus vite en production, et des POs qui apportent plus de valeur à l'équipe en étant au contact des utilisateurs.

Change Failure Rate : allez-vous trop vite ?

Cette métrique mesure la proportion de mises en production qui sont en réalité des corrections de problèmes introduits précédemment. En d'autres termes : est-ce que vos déploiements apportent de la valeur à vos utilisateurs, ou est-ce que vous passez votre temps à corriger des bugs que vous avez vous-même créés ?

C'est une métrique cruciale car elle est le contrepoids naturel de la Deployment Frequency. Une entreprise qui déploie très souvent mais dont la moitié des déploiements sont des correctifs a un problème de qualité évident. Elle va peut-être vite sur le papier, mais dans les faits elle avance beaucoup moins qu'elle ne le croit.

Chez Wizbii, on avait déjà un focus très fort sur la qualité, donc le Change Failure Rate n'était pas notre principale préoccupation. Par contre, on a rencontré un problème intéressant avec sa mesure. L'approche classique en versioning sémantique (SemVer) consiste à compter le nombre de patch levels : plus vous en avez par rapport aux versions mineures et majeures, plus votre taux d'échec est élevé. Sauf que certains développeurs se sont mis à publier des versions mineures pour de simples corrections de bugs, faussant ainsi la métrique. C'est un rappel important : dès que vous mesurez quelque chose, les comportements s'adaptent, parfois de manière inattendue. Définissez bien vos conventions de mesure en amont et assurez-vous que toute l'équipe les comprend et les applique uniformément.

Mean Time to Restore : la qualité est-elle non négociable ?

Cette dernière métrique mesure le temps nécessaire pour corriger un problème après sa découverte. Elle traduit la maturité opérationnelle de votre organisation. Est-ce que la qualité est prise en compte comme quelque chose de non négociable, ou est-ce que les bugs critiques traînent pendant des jours ?

Un Mean Time to Restore très court suppose plusieurs choses : une bonne capacité de détection des problèmes (monitoring, alerting), des process clairs sur qui intervient et comment, et surtout un haut degré d'automatisation qui permet de déployer un correctif rapidement. Si votre déploiement prend une demi-journée parce qu'il est manuel et risqué, votre MTTR ne pourra jamais être bon.

Chez Wizbii, tout étant déjà très automatisé, cette métrique était naturellement bonne. Paradoxalement, on avait trop peu de bugs critiques pour en tirer une évaluation statistiquement fiable, ce qui est plutôt un bon signe. C'est d'ailleurs un cas intéressant : toutes les métriques ne sont pas pertinentes pour toutes les entreprises à tous les stades. Si vous n'avez quasiment jamais de bugs critiques, investir du temps à optimiser votre MTTR n'est probablement pas la meilleure utilisation de votre énergie.

Lire les métriques ensemble, pas séparément

Le point le plus important avec ces quatre métriques, c'est qu'elles forment un système. Optimiser l'une au détriment des autres est non seulement inutile, mais potentiellement dangereux. Augmenter votre Deployment Frequency sans regarder votre Change Failure Rate, c'est aller plus vite dans le mur. Réduire votre Lead Time to Change en supprimant les phases de test, c'est acheter de la dette que vous paierez plus tard.

Il faut aussi résister à la tentation de piloter son business uniquement avec ces métriques. Pour les startups qui n'ont pas encore trouvé leur marché, il peut être nécessaire d'aller très vite en acceptant consciemment de la dette technique. C'est un choix valide, à condition qu'il soit conscient et temporaire. Les métriques Accelerate vous aident à mesurer le prix de cette dette, pas à vous interdire de la prendre.

La vérité absolue pour votre entreprise reste la satisfaction de vos utilisateurs, la baisse de votre churn, et la croissance de vos ventes. Les métriques DORA sont un moyen d'y arriver, pas une fin en soi. Elles vous aident à voir si votre machine tourne bien, mais c'est la direction que vous lui donnez qui détermine si vous arrivez au bon endroit.

Pour aller plus loin et comprendre comment améliorer ces métriques concrètement, le prochain article explore les capabilities Accelerate : les leviers concrets sur lesquels agir.