Suivez les métriques DORA : expédiez de meilleurs logiciels plus rapidement

Introduction

La plupart des équipes d’ingénierie disposent de nombreuses données sur leur travail. Vitesse de sprint. Points d’histoire terminés. Les bugs comptent. Lignes de code validées. Ces chiffres sont faciles à générer et à déclarer. Ils apparaissent sur les tableaux de bord, dans les stand-ups hebdomadaires et dans les revues trimestrielles. Ils donnent l’impression que la performance de l’équipe est mesurée et comprise.

Le problème est qu’aucun d’entre eux ne vous dit si l’équipe s’améliore réellement dans la fourniture de logiciels. La vélocité mesure la quantité de travail parcourue dans un processus. Cela ne dit rien sur la question de savoir si ce travail parvient aux utilisateurs de manière fiable, rapide ou sans interruption en cours de route. Une équipe peut avoir une excellente vélocité et une livraison constamment lente et peu fiable. Les indicateurs semblent sains, tandis que les performances réelles de livraison restent stables ou se détériorent.

C’est la lacune que les métriques DORA ont été conçues pour combler. Non pas pour remplacer les mesures d’ingénierie existantes, mais comme un type de signal différent, qui mesure les résultats de livraison plutôt que l’activité de livraison, et qui relie le travail d’ingénierie aux éléments qui comptent réellement pour les utilisateurs et l’entreprise.

Ce que mesurent réellement les métriques DORA

Le framework DORA est né d’années de recherche menées par le programme DevOps Research and Assessment, qui a étudié des milliers d’équipes d’ingénierie de tous les secteurs pour comprendre ce qui prédit réellement les performances de livraison de logiciels. L’étude a révélé que cinq indicateurs spécifiques séparaient systématiquement les équipes les plus performantes des moins performantes, non pas la taille de l’équipe, les choix technologiques ou le budget, mais les comportements spécifiques autour de la manière dont les équipes déployaient les logiciels et réagissaient en cas de problème.

Ces cinq métriques DORA constituent désormais le cadre standard pour mesurer les performances de livraison de logiciels.

1. Fréquence de déploiement

La fréquence de déploiement mesure la fréquence à laquelle une équipe publie du code en production. Cette mesure reflète la capacité de l’équipe à fournir de la valeur en continu plutôt que par lots importants et peu fréquents. Les équipes qui déploient fréquemment ont tendance à proposer des modifications plus modestes, plus faciles à tester, à comprendre et à annuler en cas de problème. La recherche DORA révèle systématiquement qu’un déploiement plus fréquent est en corrélation avec une fiabilité plus élevée plutôt qu’avec une fiabilité moindre, contre-intuitive mais mécaniquement saine.

2. Délai de modification

Le délai de modification mesure le temps qu’il faut entre le moment où un développeur valide le code et le moment où ce code s’exécute en production. Il s’agit du temps de cycle de l’organisation d’ingénierie, la vitesse à laquelle le travail passe de l’achèvement à la livraison. Des délais de livraison longs indiquent généralement des frictions dans le pipeline plutôt qu’un développement lent. Code en attente de révision, environnements indisponibles pour les tests, portes d’approbation qui introduisent des retards : tels sont les facteurs qui gonflent les délais, et ils sont tous traitables une fois qu’ils sont visibles.

3. Modifier le taux d’échec

Le taux d’échec des modifications mesure le pourcentage de déploiements qui provoquent un problème nécessitant une correction : une restauration, un correctif ou un incident de production. C’est le signal de qualité dans le cadre DORA. Un faible taux d’échec des modifications indique que les pratiques de validation et de test de l’équipe détectent les problèmes avant qu’ils n’atteignent les utilisateurs. Un taux d’échec de modification élevé signifie que les problèmes atteignent systématiquement la production, créant des retouches, érodant la confiance des utilisateurs et consommant du temps d’ingénierie qui pourrait être consacré à la création de nouvelles fonctionnalités.

4. Échec du temps de récupération du déploiement

Le temps de récupération en cas d’échec d’un déploiement mesure le temps nécessaire pour restaurer un service normal après un incident de production. Cette mesure reflète la résilience organisationnelle : la rapidité avec laquelle l’équipe peut détecter, diagnostiquer et résoudre les problèmes lorsqu’ils surviennent. Les équipes disposant de temps de récupération courts ont investi dans l’observabilité, mis en pratique leurs processus de réponse aux incidents et construit des architectures de déploiement prenant en charge une restauration rapide. Les équipes ayant de longs temps de récupération présentent des lacunes dans un ou plusieurs de ces domaines, ce qui s’avère coûteux en cas d’incident.

5. Taux de reprise du déploiement

Le taux de reprise du déploiement, la cinquième mesure ajoutée au cadre DORA en 2024, mesure la proportion d’efforts de déploiement consacrés à la réparation des travaux précédemment expédiés. Il capture la charge de retouche : quelle part de la capacité de l’équipe est consacrée à remédier aux échecs de ce qui a déjà été déployé plutôt qu’à fournir une nouvelle valeur. Un taux de reprise de déploiement élevé, associé à un faible taux d’échec des modifications, indique souvent que la définition du taux d’échec des modifications omet les échecs qui apparaissent après la fenêtre immédiatement post-déploiement.

Pourquoi les équipes qui suivent ces métriques s’améliorent plus rapidement

Le lien entre le suivi des métriques DORA et la livraison plus rapide de meilleurs logiciels n’est pas automatique. Le suivi des métriques ne les améliore pas ; comprendre ce qu’ils vous disent et agir en fonction de ces informations le fait. Mais les équipes qui suivent les métriques DORA s’améliorent systématiquement plus rapidement que les équipes qui ne le font pas, pour une raison spécifique : ces métriques indiquent les bons problèmes.

La plupart des discussions sur les performances techniques se concentrent sur les intrants. Combien d’ingénieurs avons-nous ? Sont-ils productifs ? Travaillent-ils sur les bonnes choses ? Ce sont des questions légitimes, mais il est difficile de les relier aux résultats. L’ajout d’ingénieurs ne rend pas automatiquement la livraison plus rapide ou plus fiable. Faire travailler les ingénieurs plus dur ne réduit pas le taux d’échec des changements. La vision de la performance technique centrée sur les intrants génère de l’activité sans nécessairement générer d’amélioration.

Les métriques DORA se concentrent sur les résultats. À quelle vitesse les logiciels fonctionnels parviennent-ils aux utilisateurs ? À quelle fréquence casse-t-il une fois arrivé là-bas ? À quelle vitesse l’équipe peut-elle récupérer lorsqu’elle le fait ? Ces questions sont directement liées à ce qui intéresse réellement les utilisateurs et l’entreprise, et elles pointent vers des problèmes spécifiques et traitables lorsque les réponses ne sont pas celles que l’équipe souhaite.

Un taux d’échec de changement élevé indique l’infrastructure de validation et de test. Quelque chose en train de vérifier si le code est prêt à être expédié ne détecte pas les échecs qui atteignent la production. Pour résoudre ce problème, il peut s’agir d’améliorer la couverture des tests d’intégration, de valider le comportement du service par rapport au comportement de dépendance actuel plutôt qu’à des fichiers fictifs obsolètes, ou de mettre en œuvre des stratégies de déploiement par étapes qui détectent les problèmes avant l’exposition complète du trafic.

Pour les systèmes pilotés par API en particulier, l’une des sources les plus courantes de taux d’échec de modification élevé sont les fichiers fictifs qui ont dérivé du comportement actuel des services qu’ils représentent. L’équipe résout ce problème en capturant le trafic HTTP réel entre les services et en générant des cas de test et des simulations de dépendances à partir de ces interactions réelles plutôt qu’à partir de spécifications gérées manuellement.

Lorsque les services en aval modifient leur comportement après un déploiement, les nouvelles captures de trafic reflètent automatiquement ces changements, garantissant ainsi la précision de la validation préalable au déploiement sans nécessiter de maintenance fictive manuelle. Le résultat est que le taux d’échec des modifications reflète la qualité réelle du déploiement plutôt que les performances du pipeline, qui reposent sur des hypothèses obsolètes.

Un long délai de livraison indique des frictions dans le pipeline plutôt que la vitesse de développement. La solution consiste à identifier les endroits où le code accumule du temps d’attente (files d’attente de révision, disponibilité de l’environnement, processus d’approbation) et à résoudre ces goulots d’étranglement spécifiques plutôt que de demander aux développeurs de travailler plus rapidement.

Une faible fréquence de déploiement combinée à des délais de livraison longs indique la taille des lots et les frais de coordination. La solution consiste à diviser le travail en unités plus petites qui peuvent parcourir le pipeline et atteindre la production de manière indépendante, plutôt que d’attendre un événement de sortie coordonné.

L’effet cumulatif d’une mesure cohérente

L’un des avantages les moins évidents du suivi des métriques DORA est la manière dont des mesures cohérentes affectent la prise de décision des équipes d’ingénierie au fil du temps.

Lorsque les équipes ne disposent pas d’indicateurs de résultats clairs, les efforts d’amélioration reposent nécessairement sur l’intuition et l’expérience. Un ingénieur senior soupçonne que le processus de déploiement comporte trop d’étapes manuelles et propose l’automatisation. La proposition est financée, ou non, en fonction de la manière dont elle peut être convaincante plutôt que sur la base des preuves du coût du processus actuel. Si l’automatisation est mise en œuvre, il est difficile de déterminer si elle a réellement amélioré quelque chose car il n’existait pas de référence claire avec laquelle comparer.

Lorsque les équipes suivent les métriques DORA de manière cohérente, cette dynamique change. La ligne de base existe. Les améliorations proposées peuvent être évaluées par rapport à des objectifs métriques spécifiques. Après la mise en œuvre, l’effet du changement est visible dans les mesures plutôt que dans les anecdotes sur la façon dont les choses semblent différentes. Les équipes peuvent faire la distinction entre les changements qui ont véritablement amélioré les performances de livraison et les changements qui semblent productifs sans modifier les chiffres.

Ce cycle d’amélioration fondé sur des données probantes est ce qui produit l’effet cumulatif que la recherche DORA a découvert parmi les équipes les plus performantes. Ils ne sont pas meilleurs parce qu’ils sont plus intelligents ou dotés de meilleures ressources. Ils sont meilleurs parce qu’ils mesurent les bons éléments depuis suffisamment longtemps pour comprendre ce qui détermine réellement leurs performances de livraison spécifiques et pour agir de manière cohérente en fonction de cette compréhension.

Commencer par les métriques DORA

Pour les équipes qui ne suivent pas actuellement les métriques DORA, le démarrage ne nécessite pas d’outils sophistiqués ni de changement majeur de processus. Les cinq métriques peuvent être calculées à partir des données dont la plupart des équipes disposent déjà : journaux de déploiement, horodatages de validation, enregistrements d’incidents et historique de déploiement.

Le point de départ le plus utile consiste à choisir la mesure que l’équipe soupçonne être la plus éloignée de ce qu’elle devrait être et à établir une référence. Non pas pour le réparer immédiatement, mais pour comprendre de quoi il s’agit réellement.

De nombreuses équipes qui commencent à suivre les taux d’échec des changements découvrent qu’ils sont nettement plus élevés que prévu. Beaucoup de ceux qui commencent à suivre les délais de livraison découvrent que la plupart du temps est passé à attendre plutôt qu’à se développer activement. La mesure elle-même révèle des informations qui changent la façon dont l’équipe réfléchit à ce qui doit être amélioré.

À partir de cette base de référence, le cycle d’amélioration permis par le cadre DORA commence par l’identification des points de friction spécifiques révélés par les mesures, par la réalisation de changements ciblés et par la mesure si ces changements ont réellement fait évoluer les chiffres. Les équipes qui exécutent ce cycle de manière cohérente pendant six mois à un an signalent un changement spécifique dans la façon dont elles abordent leur processus de livraison.

Pas seulement une expédition plus rapide, mais une expédition plus sûre, une compréhension plus claire de ce que leur pipeline leur dit réellement et une plus grande certitude que les améliorations qu’ils apportent produisent de vrais résultats plutôt que de simplement produire de l’activité.