Votre équipe ferme des tickets, mais les mises en production restent rares. Ou elle déploie souvent, au prix de correctifs urgents qui mobilisent tout le monde. Dans les deux cas, compter les fonctionnalités livrées ne suffit pas. Les métriques DORA permettent d'observer la capacité d'un service à faire passer des changements en production rapidement et sans instabilité excessive. Le référentiel actuel compte cinq métriques, pas quatre. Il ne mesure ni la valeur produit ni la performance individuelle. Bien utilisé, il révèle les frictions du système de delivery. Mal utilisé, il devient un classement qui pousse l'équipe à optimiser les chiffres.
Ce que mesurent vraiment les cinq métriques DORA
DORA regroupe désormais cinq indicateurs de performance du delivery logiciel. Le guide officiel mis à jour en janvier 2026 les sépare en deux familles : le débit des changements et l'instabilité créée par ces changements.
Le délai de changement mesure le temps entre le commit dans le contrôle de version et le déploiement réussi en production. Il ne commence pas lorsque le développeur ouvre son ticket. Cette définition volontairement précise observe la partie du flux que les outils techniques peuvent tracer de manière cohérente.
La fréquence de déploiement indique combien de fois une application est déployée sur une période donnée, ou le temps qui sépare deux déploiements. Elle aide à voir si les changements circulent par petits lots réguliers ou s'accumulent dans de grosses livraisons plus risquées.
Le temps de récupération après un déploiement échoué mesure le délai nécessaire pour rétablir le service lorsqu'une mise en production demande une intervention immédiate. Il a remplacé l'ancien « MTTR », trop large. Une panne de centre de données et une régression introduite par un déploiement ne racontent pas le même problème.
Le taux d'échec des changements représente la part des déploiements qui imposent un rollback, un hotfix ou une autre intervention urgente. Il met la vitesse en tension avec la stabilité. Déployer souvent n'est pas un progrès si chaque livraison déclenche un incident.
Enfin, le taux de reprise des déploiements mesure la part des mises en production non planifiées destinées à corriger un incident. Cette cinquième métrique a été ajoutée en 2024. L'historique publié par DORA explique le passage des quatre indicateurs historiques au modèle actuel à cinq métriques.
Ces indicateurs ne répondent pas à la question « mes développeurs travaillent-ils assez ? ». Ils répondent à une question plus utile : « notre système transforme-t-il un changement validé en production de manière fluide et stable ? »
Les mauvais usages donnent de mauvaises décisions
Le premier piège consiste à utiliser DORA pour comparer des personnes. Un délai de changement appartient à un flux collectif : cadrage, développement, revue, tests, déploiement et exploitation. L'attribuer au développeur qui a réalisé le commit ignore tout ce qui l'entoure.
Le deuxième piège consiste à comparer des applications très différentes. Un service interne simple, une plateforme de paiement et un logiciel soumis à des validations réglementaires ne portent pas les mêmes risques. DORA recommande de suivre une application ou un service dans son propre contexte, puis d'observer son évolution dans le temps.
Le troisième piège consiste à transformer un indicateur en objectif. Exiger plusieurs déploiements quotidiens peut pousser l'équipe à découper artificiellement ses changements. Fixer un taux d'échec maximal peut encourager à requalifier certains incidents. Dès qu'une métrique devient une cible individuelle ou contractuelle, elle devient plus facile à jouer et moins utile pour apprendre.
Les anciens classements « Elite », « High », « Medium » et « Low » ont beaucoup contribué à populariser DORA. Ils ne doivent pas devenir une norme universelle. Une équipe ne progresse pas parce qu'elle copie le seuil d'une autre entreprise. Elle progresse quand elle réduit une friction mesurable sans dégrader la stabilité, le produit ou les conditions de travail.
DORA ne mesure pas non plus la valeur créée. Une équipe peut déployer souvent une fonctionnalité que personne n'utilise. Elle peut améliorer son délai de changement tout en travaillant sur la mauvaise priorité. Pour piloter le produit, il faut compléter ces métriques avec l'adoption, la satisfaction client, les revenus concernés ou le risque business réduit.
Cette distinction rejoint le sujet plus large de la productivité des développeurs. Le delivery décrit la manière dont le logiciel arrive en production. Il ne résume pas tout le travail de l'équipe.
Installer une mesure assez simple pour être utile
Commencez par choisir une seule application et une période suffisamment longue pour voir une tendance. Mélanger tous les dépôts, toutes les équipes et tous les types de services crée une moyenne impossible à interpréter.
Définissez ensuite ce qu'est un déploiement réussi, un échec et une reprise non planifiée dans votre contexte. Si l'équipe ne partage pas les mêmes définitions, le tableau de bord semblera précis alors qu'il additionnera des événements différents.
Les premières données peuvent venir du contrôle de version, de la CI/CD et de la gestion des incidents. Une feuille de calcul suffit parfois pour établir une baseline. L'automatisation devient utile lorsque la collecte manuelle prend plus de temps que les discussions qu'elle doit éclairer.
Ne cherchez pas à reconstruire immédiatement un système analytique parfait. DORA lui-même recommande de commencer par une conversation, un diagnostic rapide et la recherche du principal goulot d'étranglement. Une mesure approximative mais comprise par l'équipe vaut mieux qu'un dashboard sophistiqué dont personne ne connaît les règles.
Prenons un exemple. Le délai de changement augmente, mais la fréquence de déploiement reste stable et le taux d'échec baisse. Le problème n'est peut-être pas une équipe qui ralentit. Les revues attendent plus longtemps, les changements grossissent ou une validation externe est apparue. La mesure ouvre l'enquête ; elle ne fournit pas seule la cause.
À l'inverse, une fréquence élevée accompagnée d'un taux de reprise croissant indique que l'équipe livre vite mais consomme une partie de sa capacité à réparer ses propres déploiements. Le chantier prioritaire peut alors concerner les tests, la taille des changements, l'observabilité ou la stratégie de rollback.
Si votre équipe manque de cadre pour relier ces signaux aux priorités business, un accompagnement CTO part-time peut aider à construire une lecture commune sans instaurer une surveillance individuelle.
Transformer un signal en amélioration du système
Une métrique DORA devient utile lorsqu'elle déclenche une décision concrète. Choisissez la friction dominante, formulez une hypothèse, changez une pratique, puis observez l'effet sur plusieurs semaines.
Si le délai de changement est long, mesurez où le travail attend réellement. La revue de code peut prendre deux jours alors que le développement en prend un. Un environnement de test instable peut bloquer chaque livraison. Une validation manuelle peut concentrer tous les déploiements en fin de semaine. L'action doit viser ce point précis, pas une injonction générale à « aller plus vite ».
Si les échecs augmentent, réduisez la taille des changements et améliorez la capacité de récupération. Des lots plus petits sont plus simples à comprendre, tester et annuler. L'objectif n'est pas d'empêcher toute erreur. Il est de limiter son impact et de revenir rapidement à un service stable.
Regardez toujours les cinq métriques ensemble. Accélérer le débit en dégradant la stabilité ne constitue pas une amélioration. Réduire les incidents en espaçant toutes les livraisons peut simplement cacher le risque dans des lots plus gros. La tension entre débit et instabilité protège contre ces conclusions trop rapides.
Enfin, partagez les résultats au niveau de l'équipe responsable du service. Le produit, le développement et les opérations influencent le même flux. Les séparer par indicateur encourage les renvois de responsabilité. Les réunir autour d'une contrainte observée permet de traiter le système.
Ce qu'il faut retenir
Le référentiel DORA actuel compte cinq métriques : délai de changement, fréquence de déploiement, temps de récupération après un déploiement échoué, taux d'échec des changements et taux de reprise des déploiements. Elles servent à améliorer le delivery d'une application dans son contexte, pas à noter des développeurs ni à classer des équipes différentes. Mesurez une baseline, trouvez la principale friction et vérifiez qu'une amélioration du débit ne dégrade pas la stabilité.
Questions fréquentes
Les métriques DORA mesurent-elles la productivité des développeurs ?
Non. Elles mesurent les résultats du système de delivery logiciel au niveau d'une application ou d'un service. Pour évaluer la valeur créée, ajoutez des indicateurs produit, client et business sans les transformer en score individuel.
Faut-il mesurer les cinq métriques dès le départ ?
Il faut comprendre les cinq pour éviter une lecture déséquilibrée, mais la collecte peut être progressive. Commencez par les données déjà fiables, documentez les définitions et automatisez seulement lorsque la mesure aide réellement l'équipe à décider.
Quel objectif DORA faut-il fixer à une petite équipe ?
Évitez de copier un seuil externe. Établissez la situation actuelle d'un service, choisissez la friction qui coûte le plus cher et cherchez une amélioration mesurable sans dégrader les autres indicateurs. La progression dans le même contexte compte davantage qu'un classement.
Conclusion
Vous voulez distinguer un problème de delivery d'un problème de produit ou d'organisation ? Réservez un échange de 30 minutes pour cadrer les mesures qui aideront réellement votre équipe à décider.