Quelles sont les 4 métriques DORA ?

La fréquence de déploiement et le délai des changements (qui mesurent le débit), le taux d'échec des changements et le temps de rétablissement après un déploiement raté (qui mesurent la stabilité). Deux pour la vitesse, deux pour la solidité.

Les métriques DORA mesurent-elles la productivité des développeurs ?

Non. Elles mesurent la performance du système de livraison d'une équipe, pas la productivité individuelle. S'en servir comme d'un classement entre développeurs est un contresens : c'est le meilleur moyen de les rendre inutiles, car chacun se mettra à optimiser le chiffre plutôt que le produit.

Qu'est-ce qu'une équipe « élite » selon DORA ?

D'après les rapports DORA, une équipe élite déploie à la demande (plusieurs fois par jour), a un délai des changements de moins d'une journée, un taux d'échec des changements sous les 5 %, et rétablit le service en moins d'une heure. Environ un cinquième des équipes atteignent ce niveau.

📊 Les 4 métriques DORA : mesurer sa livraison sans se mentir

📚 Introduction

« On livre bien, non ? » En équipe, cette question reçoit toujours une réponse au feeling. Et le feeling ment : on retient le dernier déploiement raté, ou au contraire on oublie les trois heures perdues à débugger la prod le vendredi soir. Sans chiffres, on avance à l’aveugle.

Le problème, c’est que les chiffres faciles à sortir sont souvent des métriques de vanité : lignes de code, nombre de commits, story points « vélocité ». Elles ne disent rien de la capacité réelle à livrer de la valeur. Les métriques DORA proposent autre chose : quatre indicateurs, issus de plusieurs années de recherche sur des milliers d’équipes, qui corrèlent avec la performance des organisations. C’est le sujet du jour — un article de la veine « culture DevOps », où l’on parle pratiques plutôt qu’outils.

🔎 C’est quoi, les métriques DORA ?

DORA, c’est DevOps Research and Assessment, un programme de recherche popularisé par le livre Accelerate (Nicole Forsgren, Jez Humble, Gene Kim) et poursuivi aujourd’hui sous l’égide de Google via des rapports annuels. Son apport principal : identifier quatre mesures qui distinguent les équipes performantes des autres.

Ces quatre métriques se rangent en deux familles. Deux mesurent le débit (à quelle vitesse tu livres), deux mesurent la stabilité (à quel point ça tient une fois livré). L’idée n’est pas de fliquer, mais de rendre visible ce qui, d’habitude, reste dans le ressenti.

📊 Les quatre métriques

Les quatre métriques DORA réparties en deux familles : débit et stabilité

Fréquence de déploiement — à quelle fréquence tu mets en production. Une équipe qui déploie plusieurs fois par jour travaille en tout petits incréments ; une qui déploie une fois par trimestre accumule le risque. C’est ici que paie une bonne CI/CD, GitLab CI ou GitHub Actions.
Délai des changements (lead time for changes) — le temps entre un commit mergé et sa mise en production. Il mesure la longueur de ton pipeline, du merge à la prod.
Taux d’échec des changements — la part des déploiements qui provoquent une dégradation nécessitant un correctif (rollback, hotfix). C’est la qualité de ce qui sort.
Temps de rétablissement (failed deployment recovery time) — combien de temps il faut pour se remettre d’un déploiement raté. Personne ne vise zéro incident ; ce qui compte, c’est de réparer vite.

D’après les rapports DORA, une équipe élite déploie à la demande, avec un délai sous la journée, un taux d’échec sous 5 % et un rétablissement en moins d’une heure. À l’autre bout, les équipes « faibles » déploient moins d’une fois par mois.

🎯 Débit et stabilité ne s’opposent pas

Le contre-sens le plus répandu : croire qu’il faut choisir entre aller vite et rester stable. « On ne peut pas déployer dix fois par jour ET être fiable. » La recherche DORA dit exactement l’inverse : les équipes qui excellent le font sur les quatre métriques à la fois. Les équipes lentes ne sont pas plus stables — elles sont lentes et fragiles.

La raison est mécanique. Déployer souvent, c’est déployer de petits changements ; de petits changements sont plus faciles à relire, à tester et à annuler. La vitesse bien pratiquée produit de la stabilité, elle ne la sacrifie pas.

⚠️ Quelques précautions

Ce sont des métriques d’équipe, pas d’individu. Les transformer en classement personnel garantit qu’elles deviendront inutiles : chacun optimisera le chiffre (multiplier les micro-déploiements vides, par exemple) au lieu du produit. C’est la loi de Goodhart — « quand une mesure devient un objectif, elle cesse d’être une bonne mesure ».
Elles décrivent, elles n’expliquent pas. Un mauvais temps de rétablissement pointe un problème ; il ne dit pas si c’est le manque de tests, d’observabilité ou de doc. Les quatre chiffres sont un point de départ pour la discussion, pas une conclusion.
Le contexte compte. Déployer un service web et un firmware embarqué n’ont pas les mêmes contraintes. On compare une équipe à elle-même dans le temps, pas à un benchmark hors-sol.

🎉 Conclusion

Les métriques DORA ne sont pas un tableau de bord pour manager pressé, mais un miroir honnête : livres-tu vite, et ce que tu livres tient-il ? Commence simplement — mesure la fréquence de déploiement et le temps de rétablissement, les deux plus parlants — et regarde la tendance sur quelques mois. L’objectif n’est pas d’être « élite » pour la médaille, mais de voir enfin, chiffres à l’appui, ce que le feeling te cachait.