DORA Metrics : La science qui fait du mal

La promesse d’une ingénierie mesurable

Les DORA metrics — fréquence de déploiement, délai de mise en production, taux d’échec des changements, temps moyen de restauration — sont devenues les stars des organisations DevOps modernes. Popularisées par Accelerate [1], elles ont donné un cadre clair pour parler de performance technique. Elles ont surtout redonné confiance à des équipes noyées dans la complexité logicielle : enfin, un moyen concret de mesurer le progrès.

Et il faut le reconnaître : c’est une avancée. La donnée permet de sortir du flou, d’objectiver des conversations, et d’ancrer la culture de l’amélioration continue dans les faits plutôt que dans les croyances.

Mais il existe une ironie historique que peu rappellent : l’Agilité n’a pas attendu DORA pour mesurer et apprendre.

Chez AgilBee, notre parcours nous ramène bien avant les dashboards colorés et les rapports Google Cloud. L’histoire de l’Agilité est née d’une quête d’automatisation et de feedbacks rapides — et bien plus tôt que ce que prétendent les vendeurs de logiciels qui réinventent l’eau tiède sous l’étiquette DevOps.

Dans les années 1990, avant même que le mot Agile n’existe, les équipes de Kent Beck et Ward Cunningham prônaient déjà l’intégration continue, les tests automatisés, la livraison fréquente et la responsabilisation des équipes.
L’eXtreme Programming (XP) fut le premier véritable laboratoire DevOps avant l’heure : déploiements multiples par jour, pair programming, refactoring continu [4].

Les DORA metrics ne font que quantifier ce que XP incarnait déjà.
Ce n’est pas la mesure qui a créé la performance, mais la confiance et la responsabilité.

Les entreprises d’aujourd’hui adorent mesurer. Mais mesurer n’est pas comprendre.

Presque cinquante ans plus tard, cette loi s’applique encore tristement dans nos organisations.

Les tableaux de bord DORA sont devenus des trophées.

On célèbre la fréquence des déploiements, on traque la baisse du Lead Time… sans toujours se demander si ce que l’on livre a du sens.

• Les boucles de feedback courtes améliorent la qualité.
• L’automatisation libère l’humain.
• La responsabilisation crée la performance durable.

Ces constats empiriques ont été validés a posteriori par les analyses DORA [1].
Autrement dit, la science est arrivée après la pratique.

Mais cette validation a aussi produit un effet pervers : elle a donné à certains dirigeants l’illusion qu’il suffisait de mesurer pour être agile.
Or, la mesure n’est qu’un miroir.
Elle ne crée pas la transformation.

Le Toyota Production System (TPS) ne reposait pas sur des chiffres,
mais sur cinq apprentissages humains fondamentaux :

1. Satisfaction du client, comme boussole du sens.
2. Satisfaction des employés, comme condition de la qualité.
3. Jidoka — arrêter pour apprendre.
4. Just-In-Time — fluidité sans précipitation.
5. Hansei — réflexion critique [3].

Le TPS n’était pas une machine à indicateurs, mais une école du discernement.
Les DORA metrics, en isolant la technique de la culture,
répètent la même erreur que le Lean « mécanisé » :
confondre le flux de production avec le flux d’apprentissage.

L’Agilité, comme le sport de haut niveau, repose sur une tension féconde entre rigueur et intuition.
On s’entraîne, on observe, on ajuste.
Mais on ne confond jamais la métrique avec le mouvement.

Les chercheurs de Microsoft Research l’ont montré avec le cadre SPACE [6] : la satisfaction, la communication et l’efficience sont des leviers essentiels de performance durable.

Chez AgilBee, nous défendons une conviction simple : la mesure est un outil de discernement, jamais un instrument de contrôle.

Les DORA metrics sont utiles, oui.
Mais sans conversation d’équipe,
elles deviennent muettes.

La performance technique n’a de valeur
que si elle renforce la performance humaine.

On ne devient pas performant en mesurant mieux, mais en apprenant plus vite.

Si vous voulez accélérer, pensez Agilité d’abord.

Auteur : Patrice Petit