Les DORA metrics sont cinq indicateurs issus du programme de recherche DORA, mené par Google Cloud, qui mesurent la performance de livraison logicielle en débit et en instabilité. D'après le rapport DORA 2025, l'IA augmente le débit des équipes, mais aussi leur instabilité.
Les DORA metrics sont un standard du secteur pour mesurer la performance de livraison d'une équipe logicielle : la vitesse à laquelle ses changements arrivent en production, et la part de ces changements qui provoquent un incident. Elles tiennent en cinq indicateurs, issus de plus de dix ans de recherche du programme DORA, aujourd'hui mené par Google Cloud.
Les agents de code changent la façon de les lire. Selon le rapport DORA 2025, 90 % des professionnels interrogés utilisent l'IA au travail, et son adoption s'accompagne d'un débit de livraison plus élevé, mais aussi de plus d'instabilité. Une équipe qui livre plus vite grâce à l'IA a donc intérêt à surveiller d'abord ses métriques d'instabilité, puis à vérifier que ce surcroît de livraison profite à ses utilisateurs.
Que sont les DORA metrics ?
Les DORA metrics sont les indicateurs de performance de livraison logicielle définis par DORA (DevOps Research and Assessment), un programme de recherche dont la première étude date de 2014. Elles mesurent la capacité d'une équipe à faire passer des changements jusqu'en production rapidement et sans incident, application par application.
Au départ, DORA voulait relier, chiffres à l'appui, la performance informatique à la performance de l'organisation. Le livre Accelerate, de Nicole Forsgren, Jez Humble et Gene Kim, a popularisé ces travaux en 2018, l'année où DORA s'est associé à Google Cloud pour son rapport annuel. Les métriques sont nées dans la culture DevOps, qui rapproche développement et exploitation.
DORA leur donne deux fonctions. Ce sont des indicateurs avancés de la performance de l'organisation et du bien-être des équipes, et des indicateurs retardés de la qualité des pratiques de développement et de livraison. Elles portent sur le résultat du processus de livraison : le nombre de commits ou de pull requests d'un développeur n'en fait pas partie.
Quelles sont les 5 métriques DORA ?
DORA mesure aujourd'hui la performance de livraison avec cinq métriques, réparties en deux facteurs. Le débit (throughput) indique combien de changements traversent le système sur une période donnée. L'instabilité mesure si les déploiements se passent bien, c'est-à-dire si les utilisateurs rencontrent des problèmes juste après une mise en production.
| Métrique | Ce qu'elle mesure | Facteur |
|---|---|---|
| Change lead time | Le temps entre le commit d'un changement dans le gestionnaire de versions et son déploiement en production | Débit |
| Deployment frequency | Le nombre de déploiements sur une période, ou le temps écoulé entre deux déploiements | Débit |
| Failed deployment recovery time | Le temps nécessaire pour rétablir le service après un déploiement en échec qui exige une intervention immédiate | Débit |
| Change fail rate | La part des déploiements qui exigent une intervention immédiate, en général un rollback ou un hotfix | Instabilité |
| Deployment rework rate | La part des déploiements non planifiés, réalisés pour corriger un incident en production | Instabilité |
Le temps de rétablissement figurait du côté de la stabilité jusqu'en 2023. Depuis 2024, DORA le range avec le débit, à côté du lead time et de la fréquence de déploiement.
La recherche DORA tire de ces mesures un résultat constant : vitesse et stabilité ne s'opposent pas. Pour la plupart des équipes, les métriques évoluent ensemble, et les équipes les plus performantes obtiennent de bons résultats sur les cinq.
Les métriques s'appliquent à une application ou à un service à la fois. DORA déconseille d'agréger les chiffres de plusieurs équipes ou de toute une organisation, parce que les contextes diffèrent : une application mobile et un système mainframe ne se comparent pas.
Change lead time
Le change lead time correspond au temps qui sépare le commit d'un changement de son déploiement en production. Il couvre tout le chemin : build, tests, revue de code, validations et déploiement. On le calcule en rapprochant l'horodatage de chaque commit de celui du déploiement qui l'a mis en production. Sur une période, la médiane est plus parlante que la moyenne, qu'un seul changement bloqué plusieurs semaines suffit à faire dériver.
Un lead time qui s'allonge vient souvent de l'attente plus que du travail lui-même, avec des revues de code en file ou des validations manuelles. Il réagit aussi à la taille des changements : un gros changement met plus de temps à être relu et testé.
Deployment frequency
On mesure la deployment frequency en comptant les déploiements en production sur une période donnée, ou en relevant le temps écoulé entre deux déploiements.
Elle dépend directement de la taille des lots. Une équipe qui découpe son travail en petits changements déploie plus souvent, et chaque déploiement porte moins de risque. Une fréquence élevée ne dit rien de la qualité de ce qui part en production : elle se lit avec le change fail rate.
Failed deployment recovery time
Quand un déploiement échoue et exige une intervention immédiate, le failed deployment recovery time indique le temps nécessaire pour rétablir le service. Depuis 2023, il ne retient que les incidents provoqués par un changement en production.
Le temps de rétablissement dépend de la capacité de l'équipe à détecter le problème et à revenir en arrière vite. DORA note que des changements plus petits sont aussi plus faciles à réparer en cas d'échec.
Change fail rate
Pour obtenir le change fail rate, on rapporte le nombre de déploiements qui exigent une intervention immédiate, en général un rollback ou un hotfix, au nombre total de déploiements sur la période. Prenons une équipe qui fait 50 déploiements dans le mois, dont 4 nécessitent un rollback : son change fail rate est de 8 %.
La difficulté tient à la définition de l'échec. Avant de mesurer, l'équipe doit fixer ce qui compte comme une intervention immédiate. Si la règle change en cours de route, les chiffres d'avant et d'après ne se comparent plus.
Deployment rework rate
Dernier arrivé parmi les cinq indicateurs, le deployment rework rate mesure la part des déploiements non planifiés, réalisés pour corriger un incident en production. DORA l'a ajouté en 2024 pour tester une hypothèse ancienne de ses chercheurs : le change fail rate servirait d'indicateur indirect du travail de reprise. L'analyse du rapport 2024 a confirmé le lien entre les deux métriques, qui forment ensemble le facteur de stabilité.
Elles ne comptent pas la même chose pour autant. Le change fail rate compte les déploiements qui exigent une intervention immédiate. Le rework rate compte les déploiements imprévus faits pour corriger un bug visible des utilisateurs, que ce bug ait déclenché ou non une intervention immédiate. Les niveaux de performance du rapport 2024 ont été calculés sur les quatre métriques historiques : le rework rate n'y figure pas.
Quels sont les niveaux de performance DORA ?
Jusqu'en 2024, DORA répartissait les équipes en quatre groupes, qui émergent chaque année des réponses à son enquête : elite, high, medium et low. Voici les seuils du rapport 2024 :
| Niveau | Change lead time | Deployment frequency | Change fail rate | Failed deployment recovery time | Part des répondants |
|---|---|---|---|---|---|
| Elite | Moins d'un jour | À la demande (plusieurs déploiements par jour) | 5 % | Moins d'une heure | 19 % |
| High | Entre un jour et une semaine | Entre une fois par jour et une fois par semaine | 20 % | Moins d'un jour | 22 % |
| Medium | Entre une semaine et un mois | Entre une fois par semaine et une fois par mois | 10 % | Moins d'un jour | 35 % |
| Low | Entre un et six mois | Entre une fois par mois et une fois tous les six mois | 40 % | Entre une semaine et un mois | 25 % |
Le rapport chiffre l'écart entre les deux extrêmes. Par rapport aux équipes low, les équipes elite font 182 fois plus de déploiements par an, avec un lead time 127 fois plus court, un change fail rate 8 fois plus faible et un temps de rétablissement 2 293 fois plus court.
Le tableau montre aussi une anomalie : le groupe medium affiche un change fail rate plus faible que le groupe high. Pour DORA, progresser dans le temps compte davantage que d'atteindre un niveau donné. Le rapport 2025 a d'ailleurs remplacé les quatre groupes par sept profils d'équipe, qui croisent performance de livraison, stabilité et bien-être.
Que change l'IA aux DORA metrics ?
Selon les rapports DORA, l'IA améliore le travail des développeurs et la qualité du processus de développement, mais ces gains ne se traduisent pas automatiquement en performance de livraison. En 2024, l'adoption de l'IA était associée à un débit et à une stabilité en baisse. En 2025, le débit progresse avec l'IA, et l'instabilité continue d'augmenter.
Des gains sur le travail des développeurs
Le rapport 2024 estime l'effet d'une hausse de 25 % de l'adoption de l'IA. Pour un individu, la productivité progresse d'environ 2,1 %, avec des effets favorables sur le flow et la satisfaction au travail. Pour l'organisation, la qualité de la documentation progresse de 7,5 %, la qualité du code de 3,4 %, la vitesse des revues de code de 3,1 % et celle des validations de 1,3 %, tandis que la complexité du code recule de 1,8 %.
Ces estimations paraissent modestes, mais elles valent par personne. Les auteurs du rapport invitent à les projeter sur des dizaines, voire des dizaines de milliers de développeurs. En 2025, plus de 80 % des répondants estiment que l'IA a augmenté leur productivité, et DORA observe cette fois une relation positive entre l'adoption de l'IA et la performance produit.
Le rapport 2024 relève aussi une contrepartie. Plus les répondants adoptent l'IA, moins ils déclarent de temps passé sur un travail qu'ils jugent utile, alors que le temps consacré aux tâches ingrates ne bouge pas. DORA l'explique par ce qu'il appelle l'hypothèse du vide : l'IA accélère surtout le travail que les développeurs jugent utile, qui se termine donc plus vite, mais elle n'aide pas sur les réunions, la bureaucratie et les autres tâches qu'ils apprécient le moins.
Une livraison qui ne suit pas au même rythme
Les travaux antérieurs de DORA associent une meilleure documentation, un code de meilleure qualité et des revues plus rapides à une meilleure performance de livraison. Le rapport 2024 observe pourtant une baisse estimée de 1,5 % du débit et de 7,2 % de la stabilité pour une hausse de 25 % de l'adoption de l'IA, un résultat qui a surpris ses auteurs.
Le rapport 2025 s'appuie sur près de 5 000 répondants, dont 90 % utilisent l'IA au travail. Le débit repart dans le bon sens : DORA observe une relation positive entre l'adoption de l'IA et le débit de livraison. La relation avec la stabilité reste négative.
L'explication de DORA : des changements plus gros
Le rapport 2024 avance une hypothèse. L'IA permet de produire beaucoup plus de code dans le même temps, ce qui fait probablement grossir la taille des changements. Or la recherche DORA montre de façon constante que les gros changements sont plus lents et plus souvent source d'instabilité. Pour les auteurs, améliorer le processus de développement ne suffit pas si les fondamentaux de la livraison ne suivent pas, en particulier les petits lots et des tests robustes.
Le rapport 2025 prolonge cette lecture : l'IA accélère le développement, et cette accélération fait apparaître les faiblesses situées en aval. Sans systèmes de contrôle solides (tests automatisés, gestion de versions mature, boucles de feedback rapides), le volume supplémentaire de changements produit de l'instabilité. Quand ce sont des agents qui écrivent le code, ces contrôles font partie du harnais des agents IA, l'environnement qui encadre leur travail. Les gains se concentrent dans les équipes aux architectures faiblement couplées. Les systèmes très couplés et les processus lents n'en tirent presque rien.
DORA relève aussi un lien direct entre la qualité de la plateforme interne et la capacité d'une organisation à tirer parti de l'IA, alors que 90 % des organisations interrogées ont déjà adopté au moins une plateforme. Le rapport 2025 a tiré de ces résultats un modèle de sept capacités, le DORA AI Capabilities Model.
Une baisse temporaire à prévoir : la courbe en J
Dans son rapport de 2026 sur le retour sur investissement du développement assisté par l'IA, DORA décrit la trajectoire attendue sous la forme d'une courbe en J : une baisse temporaire de productivité et une période d'instabilité au début de l'adoption, avant la hausse. Le rapport y voit le coût d'apprentissage de la transformation. Il note que beaucoup d'initiatives échouent parce que la direction prend ce creux pour un échec et coupe le financement.
DORA attribue ce creux à trois facteurs. Les équipes passent du temps à apprendre de nouveaux outils et à revoir leurs façons de travailler. Les développeurs relisent le code généré, dont le volume alourdit la charge de revue : le rapport parle de « taxe de vérification ». Les tests et les validations en aval doivent enfin absorber le volume supplémentaire. La profondeur et la durée du creux restent imprévisibles : elles dépendent de la maturité technique de l'organisation et de la qualité de sa plateforme interne.
Comment lire ses DORA metrics avec des agents de code
Pour une organisation qui fait entrer des agents de code dans son cycle de développement, par exemple avec la méthode AI-DLC d'AWS, on en tire un ordre de lecture. La hausse de la fréquence de déploiement et la baisse du lead time arrivent en premier, et elles ne prouvent rien à elles seules. Le change fail rate et le deployment rework rate disent si le système de livraison absorbe le volume supplémentaire : ce sont les deux métriques à suivre en priorité, puisque les deux rapports situent le problème de leur côté. Dans son rapport sur le retour sur investissement, DORA propose une lecture proche : le lead time pour mesurer l'effet des agents sur la vitesse, et le change fail rate comme signal d'alerte précoce pendant la traversée de la courbe en J.
On recommande aussi de suivre la taille des pull requests en parallèle. Elle donne un signal plus précoce que les métriques de livraison, puisque c'est le mécanisme que le rapport 2024 met en avant.
Quatre ou cinq métriques DORA : qu'est-ce qui a changé ?
La grille à quatre métriques, encore très répandue, correspond à l'état de la recherche DORA entre 2015 et 2022. Pour la livraison, elle a changé deux fois depuis : le MTTR a été redéfini en 2023, et une cinquième métrique s'est ajoutée en 2024. DORA en a publié l'historique complet.
| Année | Ce qui change |
|---|---|
| 2014 | Première étude. DORA part de quatre variables : deployment frequency, lead time for changes, MTTR et change fail rate. Cette année-là, le change fail rate n'est pas corrélé statistiquement aux trois autres, et la performance IT repose sur trois métriques. |
| 2015 | Le modèle se fixe en deux familles : le débit (fréquence de déploiement, lead time) et la stabilité (MTTR, change fail rate). |
| 2018 | DORA ajoute la disponibilité pour mesurer l'exploitation et parle désormais de performance de livraison et d'exploitation. |
| 2021 | La disponibilité devient la fiabilité. Le rapport la présente comme une « cinquième métrique », ce que DORA a corrigé depuis : la fiabilité mesure l'exploitation, pas la livraison. |
| 2023 | Le MTTR devient le failed deployment recovery time. |
| 2024 | DORA ajoute le deployment rework rate. Le modèle compte cinq métriques, en débit et en instabilité. |
La redéfinition de 2023 a une conséquence pratique. Le MTTR comptait le temps de rétablissement après n'importe quelle panne, y compris une coupure de datacenter sans rapport avec le code. Le failed deployment recovery time ne retient que les incidents provoqués par un changement en production. Une équipe qui suit encore le MTTR mesure donc autre chose que ce que DORA publie, et ses chiffres ne se comparent pas directement à ceux des rapports.
Comment mesurer les DORA metrics dans une équipe ?
DORA conseille de commencer sans outillage lourd : une première mesure avec le DORA Quick Check, un auto-diagnostic en ligne, puis une discussion avec l'équipe responsable de l'application, de la priorisation jusqu'à l'exploitation. Selon DORA, brancher plusieurs systèmes pour obtenir des chiffres précis ne vaut pas forcément l'investissement au départ.
Les données existent déjà dans la plupart des équipes. Le lead time et la fréquence de déploiement se lisent dans le gestionnaire de versions et la chaîne de déploiement continu. Le change fail rate, le rework rate et le temps de rétablissement demandent de relier les déploiements aux incidents de production, ce qui suppose que les incidents soient déclarés de façon systématique.
La démarche proposée par DORA est itérative :
- Établir une baseline de la performance actuelle de l'application.
- Discuter des points de friction du processus de livraison, en s'aidant si besoin d'une cartographie du flux de valeur.
- S'engager, en équipe, à améliorer la contrainte principale.
- Traduire cet engagement en plan, avec des indicateurs plus fins comme la durée des revues de code ou la qualité des tests.
- Faire le travail, vérifier les progrès, puis recommencer.
Pour améliorer les cinq métriques à la fois, DORA met en avant la réduction de la taille des lots. Des changements plus petits traversent plus vite le processus de livraison et se réparent plus facilement en cas d'échec.
DORA liste aussi les pièges à éviter :
- Transformer une métrique en objectif. Une consigne du type « chaque application déploie plusieurs fois par jour d'ici la fin de l'année » pousse les équipes à manipuler la mesure, comme le prévoit la loi de Goodhart.
- Chercher la métrique unique, alors qu'un système complexe se mesure avec plusieurs indicateurs, dont certains en tension.
- Comparer des applications sans rapport entre elles, ou mettre les équipes en compétition.
- Confier chaque métrique à un silo, au lieu de partager les cinq entre développement, exploitation et release.
- Invoquer la réglementation de son secteur pour ne rien changer.
- Passer plus de temps à mesurer qu'à améliorer.
Les DORA metrics suffisent-elles à piloter une équipe Produit ?
Non. Les DORA metrics disent si les changements arrivent en production vite et sans incident. Elles ne disent pas si ces changements étaient utiles aux utilisateurs. Dans l'annonce de son rapport 2025, DORA écrit que les métriques de livraison seules ne suffisent pas : elles montrent ce qui se passe, sans expliquer pourquoi.
Le même rapport apporte un argument côté Produit. Selon DORA, l'IA est plus utile quand elle vise un problème clair, et une attention portée aux utilisateurs renforce son effet positif sur la performance des équipes. Une équipe Produit a donc besoin de lire ses DORA metrics à côté de ses indicateurs de résultat produit, comme l'adoption d'une fonctionnalité ou la rétention.
Côté équipe, DORA renvoie vers d'autres cadres de mesure. Le plus connu est SPACE, publié en 2021 et cosigné par Nicole Forsgren, qui mesure la productivité des développeurs sur cinq dimensions, dont la satisfaction et l'efficacité du flux.
On recommande de lire ces indicateurs dans la même instance de pilotage, avec le CPO et le CTO autour de la table. C'est à cet endroit qu'on voit si une livraison plus rapide se traduit en résultats pour les utilisateurs, ou surtout en rework.
Livrer plus vite avec l'IA demande aussi de revoir l'organisation. Pour adapter votre organisation Produit à l'IA, Thiga accompagne les équipes Produit et Tech, de la mesure de la livraison jusqu'à l'organisation du travail avec les agents.
FAQ
Que signifie DORA ?
DORA signifie DevOps Research and Assessment. C'est un programme de recherche sur la performance des équipes de développement et d'exploitation logicielle, dont la première étude date de 2014. Il est aujourd'hui mené par Google Cloud, qui publie un rapport chaque année.
Les DORA metrics ont-elles un rapport avec le règlement européen DORA ?
Non. Le règlement DORA (Digital Operational Resilience Act) est un texte européen sur la résilience opérationnelle numérique du secteur financier, applicable depuis le 17 janvier 2025. Il partage l'acronyme des DORA metrics, sans autre lien avec elles.
Faut-il un outil pour suivre les DORA metrics ?
Pas pour commencer. DORA recommande de démarrer par des discussions d'équipe et le Quick Check, puis de passer à un outil dont le code source est disponible ou à un produit commercial avec des intégrations prêtes à l'emploi. Construire soi-même des intégrations vers plusieurs systèmes coûte cher au départ.
Quelle différence entre DORA et SPACE ?
DORA mesure le résultat du processus de livraison : la vitesse et la stabilité avec lesquelles les changements arrivent en production. SPACE mesure la productivité des développeurs sur cinq dimensions : satisfaction et bien-être, performance, activité, communication et collaboration, efficacité et flux. DORA cite lui-même SPACE parmi les cadres qui aident à choisir ses indicateurs.
.jpg)
