Qu’est-ce que les indicateurs DORA ?

Mis au point par l’équipe DevOps Research and Assessment (DORA) de Google, les indicateurs DORA fournissent des critères de référence conformes aux normes du secteur en matière de livraison logicielle et de maturité DevOps.

Fondamentalement, les indicateurs DORA s’articulent autour de deux dimensions :

1. La vitesse : la rapidité avec laquelle les équipes DevOps peuvent livrer des logiciels.
   
   
2. La stabilité : la fiabilité et la sécurité avec lesquelles les équipes DevOps peuvent livrer des logiciels.

Les indicateurs axés sur la vitesse révèlent la rapidité avec laquelle les changements de code progressent tout au long du cycle de développement logiciel (de la conception à la production), tandis que les indicateurs axés sur la stabilité indiquent la fréquence des défaillances lors des déploiements et la rapidité avec laquelle les équipes les corrigent. Ensemble, ils fournissent aux dirigeants d’entreprise et aux équipes DevOps des informations factuelles et reproductibles sur les performances DevOps. Les entreprises n’ont plus à se fier à des mesures de performance subjectives ou à des indicateurs de vanité tels que le « nombre de lignes de code écrites » ou le « nombre d’heures travaillées ».

Le suivi des indicateurs DORA permet aux équipes DevOps de se situer par rapport aux niveaux de performance reconnus par le secteur (faible, moyen, élevé et élite) et de vérifier leur adéquation avec les objectifs à l’échelle de l’entreprise. Ainsi, il est possible d’identifier objectivement les goulots d’étranglement dans les pipelines CI/CD, les tests logiciels et la gestion des incidents.   

Les indicateurs DORA permettent également aux dirigeants de communiquer plus facilement l’état de santé des services d’ingénierie aux parties prenantes de l’entreprise et de justifier les investissements dans les outils avancés d’automatisation, d’observabilité et d’ingénierie de fiabilité des sites (SRE) qui contribuent à optimiser les pratiques DevOps.

Dans le domaine du DevOps, DORA désigne l’équipe DevOps Research and Assessment qui a popularisé les indicateurs de performance organisationnelle destinés aux équipes de développement logiciel.

Aujourd’hui partie intégrante de Google Cloud, DORA a débuté sous la forme d’un projet de recherche indépendant visant à étudier l’impact des processus de livraison logicielle sur les résultats de l’entreprise. L’équipe DORA s’est attachée à répondre à une question clé : qu’est-ce qui différencie les équipes logicielles hautement performantes des autres ?

Elle a recueilli des données d’enquête et de télémétrie auprès de milliers d’équipes et a constaté qu’un petit ensemble d’indicateurs liés à la livraison et aux opérations permettait de prédire avec une grande précision la performance globale. Il s’agit notamment de la fréquence de déploiement, du délai nécessaire aux changements, du taux d’échec des changements et du temps de récupération après un échec de déploiement. Les résultats ont également démontré que la rapidité de mise en production et la stabilité des logiciels peuvent aller de pair, de sorte que les équipes n’ont pas à privilégier l’une au détriment de l’autre.

Finalement, ces quatre indicateurs sont devenus les indicateurs DORA standard, fournissant ainsi des critères de référence reconnus par le secteur pour évaluer les performances de livraison logicielle. En 2024, l’équipe de recherche DORA a ajouté un cinquième indicateur à ce cadre : le taux de reprise de déploiement.  

Les cinq indicateurs DORA peuvent être regroupés en deux grandes catégories : « vitesse » et « stabilité ».

Les indicateurs de vitesse comprennent la fréquence de déploiement, le délai nécessaire aux changements et le temps de récupération après un échec de déploiement ; ensemble, ils décrivent le nombre de changements qu’une application peut gérer et la rapidité avec laquelle ces changements sont mis en production.

Les indicateurs de stabilité comprennent le taux d’échec des changements et le taux de reprise de déploiement ; ils mesurent la proportion de déploiements à l’origine de défaillances ainsi que la part des déploiements non planifiés ou résultant d’incidents en production.

La fréquence de déploiement mesure la fréquence à laquelle une équipe réussit à déployer du code en production sur une période donnée (par jour, par semaine, par mois).

Il s’agit de l’un des indicateurs qui reflètent le mieux le degré d’agilité et de confiance d’une équipe logicielle à l’égard de son processus de livraison. Lorsqu’une équipe déploie du code en production plusieurs fois par jour, cela signifie généralement que les processus automatisés de développement, de test et de déploiement fonctionnent sans heurts et que des mécanismes d’observabilité fiables sont en place. Ces conditions permettent aux équipes de développement de publier des logiciels sans craindre de perturber le système.

À l’inverse, les équipes qui ne déploient qu’une fois par mois (voire moins souvent) s’appuient souvent sur des branches de code anciennes, des tests manuels, des protocoles d’approbation complexes et des journées complètes consacrées aux publications. Tous ces facteurs ralentissent le cycle de retour d’information des utilisateurs et augmentent le coût de la correction des défauts.

Il convient de noter qu’une fréquence de déploiement élevée n’est pas un signe de bonne santé si elle s’accompagne d’interruptions de service ou de retours en arrière fréquents. Les équipes hautement performantes combinent une fréquence de déploiement élevée avec des pratiques d’assurance qualité robustes (tests automatisés à plusieurs niveaux, déploiements échelonnés, indicateurs de fonctionnalité et pratiques de surveillance en temps réel) qui les aident à livrer fréquemment tout en minimisant les risques pour les utilisateurs.

Du point de vue de la direction, le suivi de la fréquence de déploiement au fil du temps peut révéler des goulots d’étranglement dans le pipeline de livraison logicielle. Par exemple, une baisse de la fréquence de déploiement après la mise en place d’un nouveau comité de validation pourrait indiquer que le processus est trop lourd. À l’inverse, une augmentation régulière de la fréquence de déploiement, associée à l’amélioration des indicateurs de fiabilité, constitue un indicateur fort que les investissements dans les pipelines CI/CD et les pratiques DevOps portent leurs fruits.

Le délai nécessaire aux changements mesure le temps nécessaire pour qu’une modification du code soit déployée et s’exécute correctement en production après avoir été validée dans la branche principale du code au sein d’un système de contrôle de version.

Ce délai de bout en bout englobe l’ensemble du processus, y compris le temps de compilation, l’exécution des tests, la révision du code, les validations, les étapes du pipeline et le déploiement proprement dit. Il indique la rapidité avec laquelle un système peut transformer une décision en un changement concret pour les utilisateurs finaux.

Lorsque le délai est court (moins d’une heure), les entreprises peuvent réagir aux incidents en temps quasi réel. Par exemple, si une équipe de sécurité signale une vulnérabilité, l’équipe d’ingénierie peut mettre en œuvre un correctif, le valider à l’aide de contrôles automatisés et le mettre en œuvre en très peu de temps. Cette boucle de rétroaction rapide relie directement le travail de développement aux résultats, car les équipes peuvent mesurer rapidement l’impact des changements et s’adapter en conséquence.

La réduction du délai de mise en œuvre nécessite presque toujours que les équipes DevOps automatisent et simplifient le pipeline de livraison. Ce processus implique généralement d’investir dans des outils d’intégration continue (CI) afin que chaque commit soit compilé et testé rapidement, ainsi que de rationaliser les processus de validation pour que les validations soient intégrées aux workflows de développement.  

Le temps de récupération après un échec de déploiement, également appelé temps moyen de récupération (MTTR) ou temps moyen de restauration du service, évalue le temps nécessaire pour rétablir le service à la normale après une défaillance liée au déploiement.

La résolution d’un incident peut nécessiter que les développeurs annulent un changement défectueux, déploient un correctif d’urgence (une petite modification urgente du code publiée en dehors du cycle de publication habituel) ou atténuent d’une autre manière l’impact du problème afin que les utilisateurs puissent à nouveau utiliser le système normalement.

Lorsque le temps de récupération est court (de l’ordre de quelques minutes), cela signifie généralement que plusieurs composants DevOps fonctionnent bien ensemble.

L’observabilité est solide. Les données de télémétrie en temps réel (indicateurs, journaux et traces) sont entièrement agrégées et centralisées dans des tableaux de bord. Les incidents sont détectés rapidement (souvent automatiquement) et sans attendre que les utilisateurs se plaignent.

Les alertes sont correctement paramétrées afin que les ingénieurs soient avertis rapidement sans pour autant être submergés par des notifications intempestives.

Les équipes DevOps s’appuient sur des runbooks (ou dossiers d’exploitation, c’est-à-dire des guides tactiques détaillant les étapes à suivre pour effectuer des tâches techniques), des playbooks (ou protocoles, c’est-à-dire des guides stratégiques de plus haut niveau décrivant comment les équipes doivent réagir face à une situation) et des procédures de retour en arrière documentées. Ces cadres de référence éliminent toute incertitude quant aux mesures à prendre en cas de panne.

Des temps de récupération longs (de l’ordre de quelques heures, voire de plusieurs jours) indiquent souvent des pratiques opérationnelles défaillantes. La détection peut être insuffisante, de sorte que les défaillances en production persistent jusqu’à ce que les clients les signalent. Le diagnostic est un processus lent, notamment en raison de la dispersion des données collectées, du manque de clarté des messages d’erreur ou de l’absence de consensus au sein des équipes quant au comportement du système en cas de défaillance. Dans ces environnements, chaque incident devient un événement très stressant et à haut risque, au lieu d’un simple exercice de résolution reposant sur un protocole clairement défini.

Associés aux autres indicateurs DORA, des temps de récupération courts après un échec de déploiement contribuent à garantir que, même si les déploiements échouent occasionnellement, la défaillance est maîtrisée et les temps de réponse restent courts.

Le taux d’échec des changements (CFR) est un indicateur de « qualité de livraison » qui indique aux équipes DevOps la fréquence à laquelle les déploiements échouent dans les environnements de production en direct. Tout déploiement en production problématique qui oblige l’équipe à intervenir immédiatement, au lieu d’attendre la prochaine version planifiée pour résoudre le problème, est considéré comme un déploiement « ayant échoué ».

Le suivi du CFR au fil du temps permet aux équipes de mesurer la fiabilité de leur mise en production des changements et sert de contrepoids aux indicateurs de débit (fréquence de déploiement, délai nécessaire aux changements) qui privilégient la rapidité.

Le CFR est généralement exprimé en pourcentage et s’obtient en divisant le nombre de déploiements ayant échoué par le nombre total de déploiements effectués au cours de la même période, puis en multipliant le résultat par 100.

Un faible taux d’échec indique que les changements apportés se comportent généralement comme prévu en production. Lorsque le CFR est faible et stable, les équipes peuvent augmenter en toute sécurité la fréquence de déploiement et raccourcir les délais de mise en œuvre des changements sans nuire à l’expérience utilisateur.

En revanche, un taux d’échec élevé suggère qu’un trop grand nombre de changements déstabilise le système. Cela peut s’expliquer par des tests incomplets ou peu fiables, des environnements de préproduction et de test différents de ceux de production, des déploiements trop volumineux ou encore une surveillance et des alertes trop lentes. Un CFR élevé indique que l’entreprise devrait privilégier des changements plus modestes et progressifs, ainsi que des pratiques de déploiement plus sûres (telles que les déploiements de type canari, où une nouvelle application ou fonctionnalité est déployée auprès d’un petit groupe d’utilisateurs avant sa mise en production à grande échelle), afin de réduire le nombre de changements se transformant en incidents de production.

Le taux de reprise de déploiement est un indicateur de stabilité qui mesure la proportion des déploiements d’une équipe qui font l’objet de reprises. Le terme « reprise » désigne tout déploiement déclenché par un bug ou un incident affectant les utilisateurs en production et ne faisant pas partie du cycle de publication initial prévu.

Le taux de reprise de déploiement complète les quatre indicateurs DORA d’origine en mettant en évidence le travail réactif. Il révèle la part de l’effort de développement d’une équipe consacrée à corriger les erreurs passées plutôt qu’à faire progresser le produit.

Un faible taux de reprises indique généralement que les équipes DevOps détectent la plupart des problèmes avant qu’ils n’atteignent les utilisateurs finaux et consacrent l’essentiel de leur temps à des tâches créatrices de valeur (optimisations et refactorisations planifiées). Un taux de reprises élevé signifie que les équipes passent trop de temps à résoudre des problèmes critiques.

Le taux de reprises est particulièrement utile lorsqu’il est associé à d’autres indicateurs clés. Par exemple, si une équipe présente une fréquence de déploiement élevée et un faible taux de reprises, cela indique qu’elle livre rapidement de nouvelles itérations logicielles sans sacrifier la qualité. En revanche, si elle affiche une fréquence de déploiement et un taux de reprises tous deux élevés, cela suggère qu’elle produit beaucoup de code, mais qu’elle consacre également beaucoup de temps à le corriger.

Il est important de noter qu’un taux de reprises non nul est normal (et souvent souhaitable). Même les meilleures équipes de développement peuvent commettre des erreurs, et les applications logicielles bien conçues nécessiteront toujours des améliorations et des mises à jour de fonctionnalités au fil du temps. L’objectif n’est pas d’atteindre 0 % de reprises, mais de maintenir celles-ci à un niveau faible et prévisible par rapport à l’ensemble des déploiements.

Pour chaque indicateur DORA, les équipes sont classées dans l’un des quatre niveaux de performance : élite, élevé, moyen ou faible. Chaque niveau repose sur des seuils établis pour l’indicateur concerné. Ces seuils sont les suivants :

Le taux de reprise de déploiement étant un indicateur relativement récent, il ne dispose pas encore de seuils ni de niveaux de performance établis. Cependant, de nombreuses entreprises et équipes DevOps suivent leurs propres valeurs de référence et s’efforcent de faire baisser ce taux. Associées au taux d’échec des changements et à d’autres indicateurs de fiabilité, les données relatives au taux de reprise permettent aux équipes d’améliorer ce taux sans pour autant corriger de manière excessive en se basant sur un seul chiffre. 

Les indicateurs DORA s’inscrivent dans l’approche DevOps plus large du développement logiciel, qui privilégie la collaboration continue entre des équipes pluridisciplinaires couvrant à la fois le développement d’applications et les opérations. Le bon fonctionnement des environnements DevOps dépend entièrement de la qualité des équipes qui les composent.

Les indicateurs DORA permettent aux entreprises de quantifier les performances des équipes selon des critères étroitement alignés sur les flux de valeur globaux et les résultats. Par exemple, les équipes très performantes et d’élite sont plus susceptibles d’atteindre les objectifs de rentabilité, de délai de mise sur le marché et de satisfaction client.

Les cultures DevOps se caractérisent également par un engagement en faveur d’une communication fluide et d’une responsabilité partagée entre les parties prenantes de la livraison logicielle, qui travaillent toutes ensemble pour créer des logiciels de haute qualité et accélérer l’innovation produit. C’est pourquoi de nombreuses entreprises utilisent les indicateurs DORA pour mettre en place une boucle de rétroaction permettant une amélioration continue. Ces indicateurs mesurent les performances de chaque équipe. Celles-ci peuvent alors discuter des possibilités d’amélioration à la lumière de ces mesures, tester de nouvelles approches et réévaluer leurs performances afin de déterminer quels changements améliorent réellement les pratiques de livraison.

Il est important de noter que les indicateurs DORA ont un caractère diagnostique et non punitif. Ils contribuent à mettre en évidence des tendances systémiques dans les processus de développement, plutôt que de se concentrer sur le travail des développeurs à titre individuel.