Maîtriser les indicateurs DORA : guide pratique pour évaluer et améliorer la livraison de logiciels

Mesure des indicateurs DORA

Collecte de données : manuelle ou automatisée

La collecte automatisée des données est le meilleur moyen d'éviter les indicateurs inexacts, qui peuvent conduire à des décisions commerciales erronées. Cependant, l'automatisation de tous les paramètres entrant dans le calcul d'un indicateur n'est pas toujours possible en raison de certaines contraintes. Dans ce cas, convenez d'une approche manuelle qui soit raisonnable et conforme aux normes du secteur.

Délai de livraison :

Mesuré en fonction du temps nécessaire à une fonctionnalité pour passer de la phase de demande métier à la mise en production. Cette mesure peut être effectuée à l'aide de plusieurs outils à chaque étape.

• Automatiser les tests et les déploiements(pipelines CI/CD).
• Réduire la taille des lots(modifications plus modestes et plus fréquentes).
• Améliorer les processus de révision et de validation du code.
• Surveiller les goulots d'étranglement(par exemple, QA trop longs, les validations manuelles)

Méthode manuelle :

Lorsque les outils ou plugins nécessaires au calcul automatisé du délai d'exécution ne sont pas disponibles, il est possible de recourir à une approche manuelle. Vous pouvez calculermanuellement le délai d'exécutiondans Azure DevOps (ADO) ou dans des systèmes similaires à partir d'extraits de données brutes. Voici la procédure étape par étape :

Extraction de données

• Source : Requête d'éléments de travail ADO ou API.

Champ d'application :

• Filtrer lesfonctionnalités/histoires utilisateur marquéescomme« Terminées » (c'est-à-dire déployées en production).

Extrait :

• Date de création(date à laquelle la tâche a été demandée).
• Date de clôture/d'achèvement(lorsqu'elle est marquée comme « Terminée »).

Formule pour calculer le délai de mise en œuvre d'une fonctionnalité ou d'une user story :

• Délai de traitement ( par article) = Date de clôture - Date de création

Formule pour calculer la moyenne au niveau du projet

• Délai moyen = Somme (délai par article) ÷ Nombre total d'articles

* Remarque : lorsque les fonctionnalités prévues sont développées à l'avance, l'indicateur de délai de mise en œuvre ne reflète pas fidèlement la réalité ; dans ce cas, on peut utiliser la durée du cycle comme indicateur de remplacement.

Fréquence de déploiement :

• Comptez le nombre de déploiements en production sur une période donnée (par exemple, par jour, par semaine ou par mois).

Extraction de données :

• Utilisez des outils CI/CD (par exemple, GitHub Actions) pour enregistrer le nombre de déploiements.

Formule pour la fréquence de déploiement :

• Nombre total de déploiements / Nombre de mois

Formule pour calculer la moyenne au niveau du projet :

• Nombre de déploiements du projet / Nombre de mois

*Remarque: conformément à la définition du secteur, les déploiements de correctifs ne sont pas pris en compte dans le décompte des déploiements.

Taux d'échec des modifications :

Qu'est-ce qui est considéré comme un « échec de déploiement » ?

• Rétrogradations (annulation d'une version en raison de problèmes).
• Correctifs (correctifs urgents post-déploiement).

Méthode de suivi :

• Intégrer le système aux échecs de déploiementdu pipeline CI/CD (par exemple, Jenkins, GitHub Actions) afin de signaler ces échecs.
• Utiliser des outils de gestiondes incidents (par exemple, ADO, Jira, ServiceNow).

 Formule permettant de calculer le taux d'échec :

• Nombre de modifications ayant échoué ÷ Nombre total de modifications × 100.

Méthode manuelle :

Pour calculer le nombre de modifications ayant échoué, on peut se baser sur le nombre d'incidents de support classés dans la catégorie «Bug logiciel ». En divisant ce chiffre par le nombre total de modifications publiées, on obtient le CFR.

Pour que cet indicateur soit fiable, les organisations doivent classer régulièrement les incidents.

Temps moyen de réparation (MTTR) :

Qu'entend-on par « temps de récupération » ?

• Début :lorsque la défaillance est détectée (alerte déclenchée).
• Fin :lorsque le système est entièrement rétabli (par exemple, restauration terminée, correctif déployé).

Méthode de suivi :

• Outils de gestion des incidents(par exemple, ADO, Jira).
• Systèmes de surveillance(par exemple, CloudWatch, Prometheus) permettant d'enregistrer les délais de résolution.

Formule de calcul du MTTR :

• Somme des durées de rétablissement ÷ Nombre de pannes

Méthode manuelle :

La somme des durées de résolution peut être calculée à partir des incidents de support classés comme «bogue logiciel ». La différence en jours entre la « date de création » et la « date de clôture » peut servir de numérateur.

Le nombre d'incidents classés comme «bogues logiciels »peut servir de dénominateur.

Interconnexion entre ADO, CI/CD et les systèmes de surveillance

La collecte régulière de ces indicateurs et leur optimisation aident les organisations à améliorer l'efficacité de leurs processus de déploiement logiciel.

Disposer d'outils et de plugins efficaces et les intégrer permet d'automatiser la plupart de ces tâches, de générer des indicateurs et de prendre les décisions qui s'imposent.

Azure DevOps (ADO) fournit les metadata nécessaires pour collecter les données brutes permettant de calculer ces indicateurs. L'équipe DevOps doit procéder à une évaluation minutieuse en tenant compte des besoins futurs de l'entreprise.

Outils de visualisation et tableaux de bord

Azure DevOps (ADO) offre des fonctionnalités de tableau de bord grâce à ces metadata et de ces widgets pour capturer certaines de ces métriques. Cependant, il est essentiel de s'assurer que metadata mises à jour pour chaque élément de travail afin de générer des métriques précises.

Des outils alternatifs tels que Power BI ou Grafana peuvent être utilisés pour améliorer la visualisation et la création de rapports destinés aux parties prenantes.

Défis et considérations pour les organisations

Collecte de données et utilisation des outils

Intégrité des données et limites des outils

Défis :

• Sources de données incohérentes :les pipelines DevSecOps extraient des données provenant d'outils disparates (systèmes CI/CD, scanners, outils de suivi des incidents), ce qui entraîne des chronologies discordantes, des faux positifs ou des lacunes.
• Biais lié au signalement manuel :les indicateurs établis par des personnes (par exemple, les rapports d'incident) manquent souvent de normalisation, ce qui fausse les tendances telles quele MTTR(temps moyen de rétablissement).

Solution :

• Assurer la traçabilité :utilisez metadata immuables metadata par exemple,les identifiants de pipeline d'Azure DevOps ou les commits Git) pour extraire les données relatives aux modifications du code.
• Valider grâce à la corrélation inter-outils :combiner les données de SonarQube (qualité du code), d'ADO pour signaler les anomalies et les normes industrielles pour valider les données métriques

Disponibilité des outils et des plugins

Défi :

• Certaines entreprises n'ont peut-être pas accès à des outils DevSecOps intégrés (par exemple, des scanners SAST/DAST ou des outils de suivi des déploiements) ou sont confrontées à des coûts de licence élevés.

Solution :

• Tirez parti del'Azure DevOps Marketplacepour les plugins (par exemple,OWASP ZAP,SonarQube).
• Optez pourdes solutions open source lorsque les budgets sont limités.

Configuration d'ADO pour la collecte Metadata

Défi :

• Les données brutes d'ADO (builds, versions, éléments de travail) doivent être correctement étiquetées et reliées entre elles pour permettre le calcul de métriques telles quele délai d'exécutionoula fréquence de déploiement.

Solution :

• Rendre obligatoires les champs obligatoiresdans les tâches et les mises à jour périodiques
• Utilisezles vues ADO Analyticsoules connecteurs Power BIpour interroger metadata du pipeline.

Mises à jour effectives concernant les changements d'état des tâches

Défi :

• Les mises à jour manuelles de l'état (par exemple, « Terminé » → « Approuvé ») retardent certains indicateurs, commele temps de cycle.

Solution :

• Automatisez les transitionsà l'aidedes webhooksADO oud'Azure Functions(par exemple, mise à jour automatique lors de la fusion de pull requests).
• Mettre en correspondance les états avecles étapes DevSecOps(par exemple, l'état « Révision de sécurité » avant le déploiement).

Données insuffisantes pour générer des indicateurs

Défi :

• Des données clairsemées (par exemple, des déploiements peu fréquents, un faible nombre d'incidents par projet) faussent les tendances.

Solution :

• Définir des seuils minimaux(par exemple : « Ne suivre que si > 5 incidents de la catégorie "bug logiciel" »).

Indicateurs qui ne permettent pas de prendre des décisions

Défi :

• Les indicateurs de vanité (par exemple, « un MTTR de 120 jours ») n'incitent pas à agir.

Solution :

• Mettre l'accent surdes indicateurs axés sur les résultatset étayés par des données suffisantes

Résistance organisationnelle et utilisation abusive

Résistance organisationnelle

Défis :

• Peur d'être mis en cause :les équipes peuvent se montrer réticentes à l'égard des indicateurs qui mettent en évidence des inefficacités (par exemple,un taux d'échecélevédes modificationsdû à des rejets pour des raisons de sécurité).
• Surcharge d'outils :l'introduction de nouveaux outils DevSecOps, metadata collecter et de plugins (par exemple, des scanners SAST) peut susciter des réticences si elle est perçue comme perturbatrice ou inutile.
• Incohérence des incitations :la direction privilégie un indicateur au détriment d'un autre. Le « délai d'exécution » pris isolément peut induire en erreur

Stratégies d'atténuation :

• Les indicateurs de performance comme outils d'amélioration :
  • Insistez sur la manière dont ces indicateurs aident l'organisation à long terme et permettent de comparer ou d'évaluer les performances
• Indicateurs du projet pilote :
  • Commencez par des projets non critiques afin de démontrer la valeur ajoutée avant le déploiement à l'échelle de l'organisation, et concentrez-vous sur les indicateurs qui apportent une valeur ajoutée à l'entreprise.

Objectifs à long terme de l'organisation vs résultats mesurés

Défi :

• Incohérence :l'optimisation des indicateurs à court terme (par exemple, l'améliorationde la fréquence de déploiement) peut entrer en conflit avec les objectifs à long terme (par exemple, la réduction de la dette technique ou la maturité en matière de conformité).
• Indicateurs de surface vs création de valeur :les équipes peuvent privilégier des indicateurs qui font bonne impression au détriment de résultats concrets.

Solution :

Mise en correspondance des indicateurs avec les thèmes stratégiques :

• Mettre en correspondance les indicateurs (par exemple,le délai d'exécution) avec les objectifs commerciaux (par exemple, « une mise sur le marché plus rapide pour les produits soumis à des exigences de conformité strictes »).

Défi :

Piège lié aux indicateurs lors de la définition d'une feuille de route: se concentrer excessivement sur un seul indicateur (par exemple,le MTTR) peut conduire à négliger des problèmes systémiques (par exemple, une automatisation des tests insuffisante).

Solution :

Portefeuilles métriques pondérés :

• Il convient de mettre en balance les indicateurs avec les objectifs à long terme de l'organisation (par exemple, la fréquence des déploiements), la stabilité (taux d'échec des changements) et le délai d'exécution

Concilier les indicateurs de performance et la culture d'équipe

Les risques culturels liés à l'utilisation excessive des indicateurs

Défis :

• La peur des indicateurs :les équipes peuvent percevoir les indicateurs comme une forme de surveillance, ce qui peut entraîner du stress et un épuisement professionnel.
• Contourner le système :la pression pour atteindre les objectifs (par exemple,la fréquence de déploiement) peut inciter à prendre des raccourcis (par exemple, sauter les analyses de sécurité).
• L'étouffement de l'innovation :une attention excessive portée aux indicateurs peut décourager l'expérimentation (par exemple, la crainte que des déploiements ratés n'affectentle taux d'échec des changements).

Solution :

• La sécurité psychologique avant tout :
  • Insistez sur le fait que les indicateurs sontdes outils de diagnostic, et non des évaluations de performance.
  • Mettez en avant « l'apprentissage tiré des échecs » (par exemple, les analyses post-incident qui permettent de réduirele MTTR).
• Conception des indicateurs pilotée par l'équipe :
  • Impliquez les ingénieurs dans le choix des indicateurs (par exemple, laissez-les choisir entrele délai d'exécutionetla durée du cyclecomme priorité par rapport au taux d'échec des modifications).

Indicateurs vs capacités de l'équipe et besoins en formation

Les lacunes en matière de capacités qui entravent la mise en place d'indicateurs

Défi :

Les équipes ne disposent pas des compétences nécessaires pour améliorer les indicateurs clés (par exemple,des délais d'exécutiontrop longs dus à une méconnaissance des outils de sécurité)

Solutions :

• Segmentation basée sur des indicateurs de compétences :
  • Exemple : suivre séparémentles délais de traitementpour les équipes qui adoptent de nouveaux outils SAST
• Formation à la demande :
  • Automatiser les déclencheurs de formation (par exemple, sile taux d'échec du pipeline pour des raisons de sécuritéest supérieur à 15 %, attribuer une formation modulaire).
• Indicateurs de mentorat :
  • Mesurer le pourcentage de sessions de programmation en binômeafin de favoriser le partage des connaissances.

Indicateurs qui ne tiennent pas compte de la croissance de l'équipe

Défi:

• Accorder une importance excessive aux indicateurs de rendement (par exemple,la fréquence de déploiement) revient à sous-estimer le renforcement des capacités.

Solutions :

• Équilibrer les indicateurs de rendement et de croissance :
  • Mettre en correspondancela fréquence de déploiementavec le pourcentage de l'équipe contribuant au code du pipeline.
• Indicateurs de parcours professionnel :
  • Exemple : suivre le pourcentage d'ingénieurs qui dirigent les revues de sécuritéafin de favoriser la prise en charge.

Références

• Accelerate, par Forsgren, Humble et Kim
• Documentation Azure DevOps
• Rapports DORA (DevOps Research and Assessment)