Pourquoi les Métriques DORA Comptent Plus que la Vélocité
Chaque sprint planning auquel j'ai assisté a le même rituel. Quelqu'un affiche le graphique de vélocité, l'équipe débat pour savoir si les 42 points du dernier sprint étaient « bons », et tout le monde s'engage à atteindre 45 cette fois. Deux semaines plus tard, le cycle se répète. Personne ne pose la question qui compte : sommes-nous en train de nous améliorer dans la livraison de logiciels ?
La vélocité mesure l'activité. Elle ne dit rien sur si ces points se sont traduits en valeur, si le code était stable, ou si l'équipe s'améliore. J'ai vu des équipes avec une vélocité en flèche qui ne pouvaient pas livrer une fonctionnalité fiable pour sauver leur vie. Et des petites équipes avec un throughput modeste qui déployaient en confiance plusieurs fois par jour avec presque zéro incident.
La différence ? Le second groupe suivait les métriques DORA.
Que Sont les Métriques DORA ?
En 2018, Nicole Forsgren, Jez Humble et Gene Kim ont publié Accelerate: The Science of Lean Software and DevOps. Le livre a distillé des années de recherche en quatre métriques qui prédisent les performances de livraison logicielle. Pas des opinions — des indicateurs validés par les données à travers des milliers d'organisations.
Fréquence de déploiement — à quelle fréquence votre équipe déploie en production. Les équipes d'élite déploient à la demande, plusieurs fois par jour. Les faibles performers déploient mensuellement ou moins. Cela capture votre capacité à livrer des changements petits et incrémentiels plutôt que de grandes versions risquées.
Lead time pour les changements — le temps depuis le commit de code jusqu'à ce qu'il tourne en production. Élite : moins d'une heure. Faible performer : un à six mois. Chaque goulot d'étranglement dans votre pipeline — revue de code, CI/CD, tests, approbations — apparaît ici.
Temps moyen de restauration (MTTR) — quand la production tombe, combien de temps pour la rétablir ? L'élite restaure en moins d'une heure. Les faibles performers prennent une semaine ou plus. Cela reflète directement votre monitoring, vos alertes et votre réponse aux incidents.
Taux d'échec des changements — quel pourcentage de déploiements cause un incident en production. L'élite reste entre 0-15%. Les faibles performers dépassent 46%. Cela capture la qualité du code, la couverture des tests et la fiabilité du pipeline.
La découverte contre-intuitive : vitesse et stabilité ne sont pas des compromis. Les équipes les plus performantes sont à la fois les plus rapides et les plus stables. Elles déploient plus fréquemment, se rétablissent plus vite et cassent moins.
Pourquoi la Vélocité Vous Laisse Tomber
C'est un nombre relatif et interne. Les story points signifient des choses différentes pour des équipes différentes. Une vélocité de 60 ne vous dit rien sans un contexte profond sur ce que représentent ces points. Il n'y a pas de benchmark externe.
Elle incite au mauvais comportement. Quand le management surveille la vélocité, les équipes l'optimisent. Elles gonflent les estimations, divisent les stories pour augmenter les comptages, et évitent le refactoring parce qu'il ne produit pas de points « visibles ». La métrique devient une cible, et une fois qu'une métrique devient une cible, elle cesse d'être une bonne métrique — la Loi de Goodhart.
Elle mesure l'output, pas les outcomes. Un sprint où l'équipe brûle 50 points mais casse la production pendant deux jours ? La vélocité dit excellent sprint. DORA dit désastre.
Comment Commencer à Suivre
Vous n'avez pas besoin d'une plateforme. Commencez simple.
Fréquence de déploiement. Comptez les déploiements en production par semaine depuis vos logs CI/CD. Si vous déployez moins d'une fois par semaine, vos releases sont trop grandes, vos branches vivent trop longtemps, ou votre processus de déploiement est trop douloureux.
Lead time pour les changements. Timestamp du merge commit moins le premier commit sur la branche. Si c'est plus d'une semaine, trouvez la contrainte : délais de revue de code ? CI lent ? Goulot de QA manuel ?
MTTR. Suivez les incidents de production : quand détectés, quand résolus. Même une feuille de calcul fonctionne. Ciblez moins de 24 heures initialement ; moins d'une heure c'est l'élite.
Taux d'échec des changements. Déploiements ayant causé des incidents divisé par le total des déploiements. En dessous de 15% c'est l'élite. Au-dessus de 30% signifie que votre pipeline de test a des trous.
La Conversation Change
Quand les équipes passent aux métriques DORA, les conversations évoluent. Au lieu de « avons-nous rempli notre engagement de sprint ? », elles demandent « pourquoi notre lead time a-t-il augmenté la semaine dernière ? » Au lieu de débattre 3 points contre 5, les ingénieurs enquêtent pourquoi le déploiement du jeudi a échoué.
Les métriques DORA sont des indicateurs avancés. Un taux d'échec des changements qui monte vous avertit avant la prochaine interruption. Un lead time qui augmente signale un goulot d'étranglement avant qu'il ne devienne une crise. La vélocité est un indicateur retardé de l'effort au mieux — une métrique de vanité au pire.
Les story points peuvent encore être utiles pour la planification du sprint au sein d'une équipe. Mais ils ne devraient jamais être la métrique que vous rapportez au leadership, utilisez pour comparer les équipes, ou traitez comme la santé de l'ingénierie. C'est pour ça que DORA existe.
Pour que ça Dure
Suivez les quatre métriques chaque semaine. Mettez-les sur un tableau de bord visible. Discutez des tendances en rétros. Fixez des objectifs directionnels : « lead time sous 3 jours ce trimestre » est utile. « Augmenter la vélocité de 20% » ne l'est pas.
Pour la recherche plus approfondie, lisez Accelerate de Forsgren, Humble et Kim. C'est le livre le plus fondé sur les données sur la livraison logicielle que j'ai trouvé, et assez court pour un week-end.
Chez Conectia, quand nous intégrons des ingénieurs senior dans l'équipe d'un client, l'une des premières choses que nous regardons ensemble est comment l'équipe mesure sa propre performance. Les ingénieurs qui comprennent les métriques DORA n'écrivent pas juste du code — ils améliorent le système qui livre le code. C'est ce qui sépare un développeur qui occupe un siège d'un qui élève la capacité de l'équipe.
Vous cherchez des ingénieurs qui se soucient des performances de livraison, pas seulement des lignes de code ? Parlez à un CTO — nos ingénieurs senior LATAM apportent les pratiques et l'état d'esprit qui font évoluer vos métriques DORA dans la bonne direction.
