Connaître les indicateurs à surveiller et savoir quoi en faire est un bon point de départ pour mesurer la réussite d’un projet applicatif et renforcer sa sécurité.
L’entreprise moderne carbure aux indicateurs. Les performances mesurées fournissent aux responsables commerciaux et techniques des informations cruciales pour la prise de décision dans la conduite des services et des opérations.
Aujourd’hui, le développement logiciel occupe une place centrale dans de nombreuses organisations. Les décideurs s’appuient sur les métriques pour lancer des projets logiciels, évaluer les équipes de programmation, optimiser les processus de développement et renforcer la sécurité des applications et de l’infrastructure. Mais toutes les métriques ne se valent pas : chaque leader doit décider lesquelles sont utiles à la réussite de ses projets DevOps et DevSecOps.
DevSecOps : le rôle des métriques
De manière générale, les métriques servent à mesurer des performances, des comportements ou des propriétés. Pour la plupart, il s’agit de temps, de vitesse ou de volume.
Les métriques les plus courantes mesurent le temps nécessaire à la réalisation d’une tâche ou le nombre de fois qu’une tâche est réalisée à un rythme donné. Bien pensées et mises en œuvre, ces mesures dépeignent objectivement la réalité ou les perspectives éventuelles. Elles aident ainsi les responsables à prendre des décisions avisées en leur indiquant par exemple :
si un processus ou un service est stable et reproductible, ou imprévisible ou aléatoire ;
si un processus ou un service se déroule bien ou s’il rencontre des erreurs ou des perturbations ;
si les objectifs sont atteints et si le processus ou le service permet d’obtenir les résultats escomptés ;
les mérites comparés des processus, services et produits ;
comment et quand gérer le changement.
Devenues un aspect essentiel du développement, les métriques contribuent à améliorer la qualité des logiciels et les processus de création de ces produits. Les outils de développement modernes alliés aux chaînes de déploiement agiles – notamment DevOps et DevSecOps – produisent des volumes de données significatifs sur la création et le fonctionnement d’un produit logiciel.
Ces éclairages factuels aident les responsables des charges de travail et autres parties prenantes à obtenir les meilleurs résultats en répondant à des questions clés :
Le logiciel est-il sécurisé ? Son fonctionnement est-il correct et fiable ?
Le logiciel ou l’infrastructure sont-ils attaqués ?
Le logiciel apporte-t-il la valeur attendue ou produit-il les résultats commerciaux escomptés ?
En matière de performances et de fiabilité, le logiciel est-il bien pris en charge par l’infrastructure ?
La prise en charge et l’évolutivité du logiciel et de l’infrastructure sont-elles adéquates ?
Comment les coûts et risques sont-ils pris en compte dans les nouveaux développements ?
Les départements IT exploitent les métriques pour remonter le nombre de défauts logiciels et la durée moyenne de remédiation. Cette même pratique est mise en œuvre pour détecter d’éventuelles failles de sécurité et les corriger. Le nombre et le type de remontées peuvent dénoter des problèmes de qualité logicielle. Ils peuvent refléter les mauvaises performances d’une équipe ou le non-respect des consignes de développement et de sécurité. Le délai de remédiation, lui, illustre l’efficacité du processus sous-jacent.
Quelles métriques conviennent le mieux aux environnements DevSecOps ?
DevSecOps : 10 métriques clés
Les entreprises peuvent exploiter d’innombrables métriques, mais il n’existe pas de modèle unique et uniforme convenant à chacune. C’est l’activité qui détermine les métriques et non l’inverse. Il revient donc aux dirigeants et responsables informatiques de décider des métriques pertinentes dans leur organisation, ainsi que de leur implémentation et de leur utilisation.
Si l’entreprise peut utiliser n’importe quelles métriques adaptées à son activité et à ses objectifs, les 10 métriques les plus courantes dans un cadre d’une approche DevSecOps sont les suivantes.
1. Délai de changement de l’application
Cet indicateur rend compte de la durée entre la validation du code (commit) et son déploiement en production. Il reflète la rapidité du pipeline de développement, notamment le temps nécessaire pour générer, tester et publier une mise à jour. Si des délais plus courts suggèrent des pipelines de développement efficaces, il est toujours intéressant de corréler plusieurs indicateurs pour mieux comprendre le processus DevSecOps.
Dans certains cas, les taux d’échec ou de remaniement impactent le délai de modification de l’application. Dans d’autres, une chaîne de tests particulièrement étoffée peut ralentir la livraison, en raison du nombre de commits à vérifier.
2. Fréquence du déploiement d’application
Il s’agit du nombre de déploiements en production au cours d’une période donnée. N’utilisez pas cette métrique seule : d’autres permettront d’affiner son interprétation. Par exemple, une fréquence de déploiement faible est acceptable pour un produit ayant déjà fait ses preuves, alors qu’une fréquence élevée est courante au début du cycle de vie de produits nouveaux ou moins matures. Cette fréquence varie également selon les environnements. Les développeurs d’applications hébergées dans le cloud livrent des fonctionnalités toutes les semaines, voire tous les jours, parce que l’infrastructure sous-jacente et l’automatisation du provisionnement le permettent.
Toutefois, un déploiement peu fréquent combiné à de longs délais de correctifs ou un gros volume d’incidents peut indiquer des problèmes, au niveau de l’équipe ou du workflow, qui exigent un examen approfondi.
3. Disponibilité
Cette métrique mesure le temps de disponibilité ou d’interruption d’une application sur une période donnée. Elle s’exprime en durée ou en pourcentage. La disponibilité est une mesure importante, car elle renvoie aux accords de niveaux de service contractuels (SLA) qu’une entreprise garantit.
4. Taux d’échec des changements
Cette métrique indique, en nombre ou en pourcentage, les échecs de déploiement en production qui ont abouti à l’abandon de l’opération ou à la restauration de la version fonctionnelle précédente. Un taux élevé, rarement plus de quelques points, peut être le signe d’un problème au niveau des compétences de l’équipe ou de la clarté des objectifs opérationnels, du processus de déploiement, ou encore de la compréhension et de l’infrastructure sous-jacente.
5. Volume de changements
Il s’agit du nombre de nouvelles fonctions déployées dans une période donnée, qui constitue un indicateur global de la rapidité du développement. Un grand nombre de modifications peut dénoter un bel effort de développement, mais il convient de contextualiser. Un gros volume de modifications concomitant à un faible taux d’échec et à un faible volume d’incidents suggère un rythme rapide de développement abouti. En revanche, un gros volume de changements associé à un taux d’échec élevé ou à un volume important d’incidents peut indiquer que l’équipe de développement connaît des difficultés.
6. Délai de résolution des problèmes
Durée moyenne pour résoudre un problème signalé. Cette valeur mesure le délai entre l’identification et la correction d’un problème de configuration ou d’un défaut logiciel signalé. Les événements déclencheur et final de cet indicateur sont propres à chaque entreprise. Par exemple, la durée peut se mesurer depuis la création du ticket d’incident initial jusqu’au déploiement du correctif. De même, le problème peut dépendre de l’environnement de déploiement, par exemple le temps nécessaire pour localiser et corriger une configuration de la sécurité sur un serveur.
7. Volume d’incidents
Il s’agit sans surprise du nombre de problèmes remontés par la clientèle au cours d’une période donnée. Par exemple, cela peut correspondre à la quantité de tickets d’incidents créés par les utilisateurs d’une application métier. Les pics d’incidents sont fréquents lors de mises à jour logicielles ou d’application de correctifs, mais un volume élevé et durable d’incidents peut être le signe d’une insatisfaction de la clientèle ou de problèmes de développement plus vastes que l’équipe n’arrive pas à régler.
8. Délai moyen de réparation (MTTR, Mean Time To Recovery, en anglais)
Il s’agit généralement de l’intervalle qui s’écoule entre l’échec d’un déploiement et la restauration totale subséquente des opérations de production. Une valeur MTTR faible peut révéler la compétence d’une équipe DevSecOps en pleine maîtrise de l’environnement de déploiement, tandis qu’un long délai suggère des problèmes dans la préparation du déploiement, les workflows et les compétences opérationnelles. Susceptibles d’affecter négativement l’entreprise, de longs MTTR appellent souvent une réponse forte de la direction.
9. Délai de déploiement de correctifs
Temps qui s’écoule entre la découverte d’une vulnérabilité dans l’application et le déploiement réussi d’un correctif. Si elle s’apparente au délai de résolution des problèmes, cette mesure est une indication plus fine de la capacité des équipes DevSecOps à localiser et corriger un défaut logiciel.
10. Délai de rentabilité
Délai entre une demande de fonctionnalité et la réalisation de sa valeur commerciale, par exemple en termes de chiffre d’affaires, de compétitivité ou de capacités logicielles. Cette métrique est la moins précise. Elle doit être affinée en fonction des objectifs spécifiques de l’entreprise. Mais toute entreprise a intérêt à ce que ce délai soit court.
Les outils de collecte et d’analyse des métriques
D’où viennent les métriques nécessaires à la bonne conduite de l’approche DevSecOps ? La réponse n’est pas nécessairement claire. En effet, les métriques émanent d’outils très variés utilisés à différents stades du pipeline de développement. Parmi les instruments appropriés, citons :
les outils de build et de livraison comme GitHub, GitLab, Azure DevOps, Octopus Deploy, CircleCI et Jenkins ;
les outils de gestion de la configuration notamment Ansible, SaltStack, Puppet et Chef ;
les outils d’automatisation des tests comme Selenium, Worksoft et Kobiton ;
les outils de gestion de vulnérabilités comme Tenable, Qualys, WithSecure ou Snyk ;
les outils de supervision comme Nagios, le couple Prometheus – Grafana, New Relic, Dynatrace, Datadog, Splunk et SolarWinds AppOptics.
Il est possible de tirer des métriques complètes à partir d’outils déjà en place. Toutefois, toutes celles d’intérêt ne sont pas forcément prises en charge nativement par les outils qui composent la chaîne CI/CD. Les organisations doivent passer en revue leurs outils, évaluer les métriques disponibles, et définir les configurations pour produire des métriques adaptées au besoin. Dans certains cas, il faudra une personnalisation ou des outils supplémentaires pour prendre en charge des métriques inhabituelles ou spécifiques comme le délai de rentabilité.
La métrologie appliquée à l’approche DevSecOps
Les métriques ne sont pas parfaites. Ce ne sont que des chiffres qui n’ont aucun sens sans un travail de compréhension et d’interprétation adéquat. Ce sont des valeurs mesurées sans conseil ni indication sur les décisions à prendre ; elles illustrent le quoi, mais pas le pourquoi. Toute la puissance – mais aussi le risque – des métriques réside dans la collecte, l’interprétation et l’utilisation de ces chiffres et variables par l’entreprise.
Toute la puissance – mais aussi le risque – des métriques réside dans la collecte, l’interprétation et l’utilisation de ces chiffres et variables par l’entreprise.
L’interprétation et la compréhension ne doivent pas être négligées quand les métriques servent à impulser des changements comme l’adoption d’un nouvel outil ou des mouvements de personnel. Prenons par exemple le taux d’échec des changements. Quel est le taux acceptable ? Plus important encore, quelle raison explique un taux d’échec inacceptable ? Il peut s’agir d’un problème de compétence du personnel, de charge de travail, de jeu d’outils, ou encore d’une lacune au niveau du processus ou du workflow.
La collecte de métriques doit s’accompagner d’une compréhension approfondie des personnes, des outils et des processus utilisés dans tout l’environnement de développement et de déploiement. Imaginez qu’une métrique, comme le volume des changements, chute soudainement. La métrique seule ne permet pas d’identifier la cause sous-jacente. Alors qu’une évaluation intelligente pourra révéler qu’un outil de la chaîne DevSecOps a été mis à jour ou remplacé, que les équipes apprennent encore à intégrer et à utiliser la nouvelle plateforme, et que donc le problème pourrait n’être que temporaire et se résoudre rapidement sans autre intervention. Les outils ne sont pas gage de succès dans l’utilisation de métriques DevSecOps : tout dépend de l’humain.
