Les métriques DORA : mesurer (vraiment) la performance d'une équipe tech
Quatre indicateurs, issus d'années de recherche, qui prédisent la performance des équipes logicielles — sans tomber dans le piège de compter les lignes de code.
Comment savoir si une équipe de développement est performante ? Compter les lignes de code, les commits ou les heures est non seulement absurde, mais contre-productif (on obtient du code verbeux et des développeurs qui « jouent » la métrique). Le programme de recherche DORA (DevOps Research and Assessment, aujourd'hui porté par Google Cloud), popularisé par le livre Accelerate de Forsgren, Humble et Kim, a proposé une réponse solide, validée sur des années d'études auprès de milliers d'équipes.
Les quatre clés historiques
DORA a d'abord identifié quatre indicateurs qui, ensemble, capturent la vitesse et la stabilité de la livraison :
- Fréquence de déploiement — à quelle cadence livrez-vous en production ?
- Délai de livraison des changements (lead time for changes) — combien de temps entre un commit et sa mise en production ?
- Taux d'échec des changements (change fail rate) — quelle proportion de déploiements provoque un incident nécessitant une intervention ?
- Temps de rétablissement — combien de temps pour se remettre d'une défaillance ?
Les deux premières mesurent le débit (throughput), les deux dernières l'instabilité.
Un modèle qui évolue : de 4 à 5 métriques
Le modèle n'est pas figé : il a suivi l'évolution des pratiques. DORA décrit désormais cinq métriques, en affinant l'instabilité — le « MTTR » a laissé place au temps de rétablissement après déploiement raté (failed deployment recovery time), et un taux de reprise (rework rate) a été ajouté. Peu importe le compte exact : l'esprit reste le même, mesurer débit et stabilité ensemble.
Le résultat contre-intuitif
Vitesse et stabilité ne s'opposent pas : pour la plupart des équipes, elles sont corrélées. Les meilleures excellent sur les deux à la fois.
On croit souvent qu'aller vite dégrade la qualité. La recherche DORA montre l'inverse : les équipes « élite » déploient beaucoup plus souvent ET tombent en panne moins souvent, en se rétablissant plus vite. La clé tient en un principe : travailler en petits lots. De petits changements fréquents sont plus faciles à relire, moins risqués, et bien plus faciles à corriger qu'un gros déploiement trimestriel.
Le bon usage (et le piège)
Les métriques DORA servent à l'équipe pour s'améliorer, pas à la direction pour classer ou comparer les développeurs. Dès qu'on transforme une métrique en objectif chiffré (« tout le monde déploiera 5 fois par jour d'ici décembre »), on déclenche la loi de Goodhart : la mesure cesse d'être fiable car les gens la « jouent ». Autres pièges documentés par DORA : comparer des applications très différentes, ou n'utiliser qu'une seule métrique isolée. Utilisées comme boussole d'équipe, elles sont précieuses ; utilisées comme bâton, elles sont nuisibles.