Mesurer la performance de livraison
Les quatre métriques DORA qui captent vraiment la performance — débit et stabilité — et pourquoi les mesures habituelles trompent.
Avant de chercher à améliorer la façon dont on construit du logiciel, il faut savoir mesurer ce qu'on veut améliorer. Les auteurs d'Accelerate partent d'un constat exigeant : on ne peut pas piloter scientifiquement une transformation tant qu'on n'a pas défini ce que « bon » veut dire dans ce domaine. Or mesurer la performance dans le logiciel est intrinsèquement difficile. Contrairement à l'industrie manufacturière, l'inventaire est invisible : on ne voit pas s'accumuler les pièces en attente. Le découpage du travail est relativement arbitraire, et — surtout dans le paradigme Agile — la conception et la livraison se déroulent simultanément, l'une nourrissant l'autre. La toute première étape consiste donc à se doter d'une mesure valide et fiable de la performance de livraison logicielle (software delivery performance).
Ce chapitre montre pourquoi les mesures historiques (lignes de code, vélocité, taux d'utilisation) induisent en erreur, présente les quatre métriques retenues par la recherche — devenues les célèbres métriques DORA — et établit le résultat le plus contre-intuitif de l'ouvrage : vitesse et stabilité ne s'opposent pas, elles vont de pair. Enfin, il montre que cette performance de livraison prédit la performance de l'organisation elle-même.
Les pièges des mesures classiques
De nombreuses tentatives ont visé à mesurer la performance des équipes logicielles, presque toujours sous l'angle de la productivité. Les auteurs leur reprochent deux travers récurrents. D'abord, elles mesurent des extrants (outputs) plutôt que des résultats (outcomes) : on récompense l'activité, pas l'effet utile. Ensuite, elles mesurent des grandeurs individuelles ou locales plutôt que collectives ou globales, ce qui pousse à des optima locaux au détriment de l'ensemble. Trois exemples le démontrent.
Lignes de code
Mesurer la productivité en lignes de code (lines of code) a une longue histoire ; certaines entreprises ont même demandé aux développeurs de consigner les lignes livrées par semaine. Mais en réalité, on préfère une solution de 10 lignes à une solution de 1 000 lignes pour le même problème. Récompenser l'écriture de lignes engendre du logiciel boursouflé, plus coûteux à maintenir et à faire évoluer. Idéalement, on récompenserait la résolution d'un problème métier avec le minimum de code — mieux encore, sans écrire de code du tout, voire en supprimant du code (par un changement de processus métier). Pour autant, minimiser les lignes n'est pas non plus un bon critère : résoudre une tâche en une ligne illisible pour autrui vaut moins que quelques lignes claires et maintenables.
Vélocité
L'Agile a apporté sa propre mesure : la vélocité (velocity). Les problèmes sont découpés en stories, estimées par les développeurs en « points » d'effort relatif ; à la fin d'une itération, on additionne les points validés par le client. La vélocité est conçue comme un outil de planification de capacité — extrapoler le temps nécessaire pour achever le travail planifié. Détournée en mesure de productivité ou en instrument de comparaison entre équipes, elle révèle plusieurs défauts :
- C'est une mesure relative et dépendante de l'équipe, non absolue. Les contextes diffèrent au point de rendre les vélocités incommensurables d'une équipe à l'autre.
- Utilisée comme cible, elle est truquée (gamed) : les équipes gonflent leurs estimations et cherchent à clore le plus de stories possible.
- Elle inhibe la collaboration : aider une autre équipe ferait baisser sa propre vélocité tout en augmentant celle de l'autre — donc « mal paraître ». La mesure détruit ainsi son utilité d'origine.
Taux d'utilisation
Beaucoup d'organisations mesurent le taux d'utilisation (utilization) comme indicateur indirect de productivité. Le problème : une utilisation élevée n'est bénéfique que jusqu'à un certain point. Au-delà, il n'existe plus de capacité disponible — de mou (slack) — pour absorber le travail imprévu, les changements de plan ou le travail d'amélioration. Conséquence : les délais s'allongent. La théorie des files d'attente est sans appel : à mesure que l'utilisation approche les 100 %, les délais tendent vers l'infini. Autrement dit, à très haut taux d'utilisation, il faut un temps exponentiellement croissant pour terminer quoi que ce soit.
Attention
Ces trois métriques partagent le même vice : elles encouragent un comportement local qui dégrade le résultat global. Récompenser les développeurs sur le débit et les opérations sur la stabilité fabrique le « mur de la confusion » (wall of confusion) : le développement jette par-dessus le mur du code de mauvaise qualité, et les opérations érigent des processus de gestion du changement douloureux pour freiner ce flux. Une bonne mesure doit viser un résultat global, qu'aucune fonction ne peut atteindre seule.
Les deux propriétés d'une bonne mesure
De cette critique, les auteurs tirent les deux caractéristiques qu'une mesure réussie doit posséder :
- Se concentrer sur un résultat global, pour que les équipes ne soient pas montées les unes contre les autres.
- Mesurer des résultats, pas des extrants : ne pas récompenser l'abattage de tâches occupées (busywork) qui n'aide en rien les objectifs de l'organisation.
C'est en cherchant des mesures satisfaisant ces deux critères que les auteurs ont retenu quatre indicateurs : le délai de livraison, la fréquence de déploiement, le temps de restauration du service et le taux d'échec des changements.
Les quatre métriques DORA
Les quatre mesures se rangent en deux dimensions complémentaires. Le débit (throughput) — aussi appelé tempo — décrit la vitesse à laquelle on livre des changements ; il combine le délai de livraison et la fréquence de déploiement. La stabilité (stability) décrit la robustesse du service face au changement ; elle combine le temps de restauration et le taux d'échec.
| Métrique | Dimension | Définition retenue dans la recherche |
|---|---|---|
| Délai de livraison des changements (lead time for changes) | Débit | Temps écoulé entre le commit accepté et son exécution réussie en production |
| Fréquence de déploiement (deployment frequency) | Débit | À quelle fréquence l'organisation déploie son service principal (proxy de la taille des lots) |
| Temps de restauration du service (time to restore / MTTR) | Stabilité | Temps généralement nécessaire pour rétablir le service après un incident |
| Taux d'échec des changements (change failure rate) | Stabilité | Part des changements en production qui dégradent le service ou exigent une remédiation |
Pourquoi le délai de livraison
L'élévation du délai au rang de métrique est un pilier de la pensée Lean. Le délai (lead time) est le temps entre la demande d'un client et sa satisfaction. En développement produit, il comporte deux parties : le temps pour concevoir et valider une fonctionnalité, et le temps pour la livrer. La partie conception souffre d'une forte variabilité et d'un démarrage flou — Reinertsen la nomme le « front flou » (fuzzy front end). La partie livraison, elle, est plus facile à mesurer et bien moins variable.
| Conception et développement du produit | Livraison du produit (build, test, déploiement) | |
|---|---|---|
| Nature | Créer de nouveaux produits résolvant des problèmes clients (hypothèses, UX, design thinking) | Permettre un flux rapide du dev vers la prod et des releases fiables (standardisation, réduction de variabilité et de taille des lots) |
| Nouveauté | Le travail peut n'avoir jamais été fait auparavant | Intégration, test et déploiement effectués en continu, le plus vite possible |
| Estimations | Hautement incertaines | Temps de cycle connus et prévisibles |
| Résultats | Hautement variables | À faible variabilité |
C'est donc la partie livraison que la recherche mesure : du code committé au code tournant en production. Des délais courts sont préférables, car ils accélèrent le retour (feedback) sur ce qu'on construit, permettent de corriger le cap plus vite et, en cas de défaut ou de panne, de livrer un correctif rapidement et avec confiance.
Pourquoi la fréquence de déploiement
La deuxième idée Lean est la réduction de la taille des lots (batch size) — l'une des clés du système de production Toyota. Réduire les lots diminue les temps de cycle et la variabilité, accélère le feedback, réduit le risque, les coûts et les dérives de planning. Mais dans le logiciel, la taille des lots est difficile à mesurer faute d'inventaire visible. Les auteurs ont donc retenu la fréquence de déploiement comme proxy : plus on déploie souvent, plus les lots sont petits. Strictement, la fréquence de déploiement est l'inverse de la taille des lots.
Note
Le sommet de cette logique est le flux à une pièce (single-piece flow), où chaque commit peut partir en production — pratique connue sous le nom de déploiement continu (continuous deployment). À l'inverse, une release classique regroupe de multiples commits dans un même lot.
Pourquoi le temps de restauration plutôt que le temps entre pannes
Traditionnellement, la fiabilité se mesure par le temps entre pannes. Mais dans des systèmes logiciels modernes, complexes et changeant vite, la panne est inévitable. La bonne question n'est donc plus « à quelle fréquence ça tombe ? » mais « à quelle vitesse remet-on le service en marche ? » — d'où le temps de restauration du service après un incident (panne non planifiée, dégradation).
Pourquoi le taux d'échec des changements
Enfin, on veut savoir quelle proportion de changements en production (releases logicielles, modifications de configuration d'infrastructure…) échoue — c'est-à-dire dégrade le service ou exige ensuite une remédiation (correctif à chaud, rollback, fix-forward, patch). Dans le vocabulaire Lean, c'est l'équivalent du « complet et exact » (percent complete and accurate) du processus de livraison, une métrique de qualité clé.
Vitesse et stabilité ne s'opposent pas
Pour classer les organisations sans préjuger de ce qui est « bon » ou « mauvais », les auteurs ont employé l'analyse de clusters (cluster analysis). Cette technique regroupe les réponses similaires sans aucune connaissance sémantique : elle ignore ce qui compte comme bonne ou mauvaise réponse. Appliquée chaque année du programme, elle a fait émerger des catégories nettement distinctes — hauts, moyens et bas performeurs (high, medium, low performers) — significativement différentes sur les quatre mesures à la fois.
| Métrique (2017) | Hauts performeurs | Moyens performeurs | Bas performeurs |
|---|---|---|---|
| Fréquence de déploiement | À la demande (plusieurs/jour) | Entre 1×/semaine et 1×/mois | Entre 1×/semaine et 1×/mois* |
| Délai de livraison | < 1 heure | Entre 1 semaine et 1 mois | Entre 1 semaine et 1 mois* |
| Temps de restauration (MTTR) | < 1 heure | < 1 jour | Entre 1 jour et 1 semaine |
| Taux d'échec des changements | 0–15 % | 0–15 % | 31–45 % |
* Les bas performeurs étaient en moyenne plus faibles (de façon statistiquement significative) mais avaient la même médiane que les moyens performeurs.
Le résultat est, selon le terme des auteurs, stupéfiant : il n'existe aucun compromis entre améliorer la performance (vitesse) et atteindre de meilleurs niveaux de stabilité et de qualité. Les hauts performeurs font mieux sur les quatre mesures simultanément. C'est exactement ce que prédisent les mouvements Agile et Lean, alors qu'un dogme tenace de l'industrie repose encore sur l'hypothèse fausse selon laquelle aller plus vite se paierait par une dégradation des autres objectifs. En intégrant la qualité dès le départ (building quality in), on obtient les deux à la fois.
À retenir
L'ampleur des écarts est considérable. Comparés aux bas performeurs, les hauts performeurs de 2017 affichaient :
- 46 fois plus de déploiements de code,
- un délai de livraison du commit au déploiement 440 fois plus rapide,
- un temps moyen de restauration après panne 170 fois plus rapide,
- un taux d'échec des changements 5 fois plus bas (un changement risque 5 fois moins d'échouer).
Le peloton de tête se détache
Comparé à 2016, l'écart entre hauts et bas performeurs s'est resserré sur le tempo (fréquence et délai) mais élargi sur la stabilité (restauration et taux d'échec). L'explication avancée : les équipes peu performantes ont cherché à augmenter le tempo sans assez investir dans la qualité du processus — d'où des échecs de déploiement plus gros et plus longs à restaurer. Pousser au « travaillez plus dur ! » sans traiter les obstacles de fond (ré-architecture, amélioration des processus, automatisation) ne fait pas progresser la performance globale. Les hauts performeurs, eux, maintiennent ou améliorent leur position d'année en année, maximisant à la fois tempo et stabilité. Le mantra DevOps de l'amélioration continue est réel : ce qui était l'état de l'art il y a trois ans ne suffit plus aujourd'hui.
Piège courant
Une bizarrerie mérite d'être signalée pour rester fidèle aux données. En 2016, les moyens performeurs faisaient moins bien que les bas performeurs sur le taux d'échec. La recherche ne l'explique pas de façon concluante. L'hypothèse des auteurs : les moyens performeurs traversent une transformation lourde (ré-architecture, migration de code legacy) et consacrent plus de temps au travail neuf — peut-être au prix d'un rework critique ignoré, accumulant de la dette technique qui fragilise les systèmes et élève le taux d'échec.
L'impact sur la performance organisationnelle
Restait la question décisive : cette performance de livraison compte-t-elle vraiment ? Pour le savoir, les répondants ont évalué la performance relative de leur organisation sur plusieurs dimensions — rentabilité (profitability), part de marché (market share), productivité — au moyen d'une échelle validée par des recherches antérieures, fortement corrélée au retour sur investissement (ROI) et robuste aux cycles économiques.
Le résultat, mesuré sur plusieurs années : les organisations hautes performeuses avaient deux fois plus de chances de dépasser ces objectifs que les basses performeuses. La capacité de livraison logicielle constitue donc bel et bien un avantage compétitif.
En 2017, l'étude a élargi la question aux objectifs non commerciaux (noncommercial goals) — car toute organisation, à but lucratif ou non, dépend de la technologie pour accomplir sa mission. À l'aide d'une autre échelle validée, les auteurs ont trouvé que les hauts performeurs étaient deux fois plus susceptibles de dépasser leurs objectifs en quantité de biens et services, efficacité opérationnelle, satisfaction client, qualité des produits et atteinte des buts de mission.
Astuce
Le livre insiste sur la lecture de ses schémas : une flèche entre deux constructs (concepts mesurés) signifie une relation prédictive, pas une simple corrélation. On peut lire ces flèches comme « pilote », « prédit », « affecte » ou « impacte ». La figure clé du chapitre se lit ainsi : la performance de livraison logicielle impacte la performance organisationnelle et la performance non commerciale. C'est ce passage de la corrélation à la prédiction qui distingue cette recherche.
Plusieurs corollaires en découlent. La capacité à travailler et livrer en petits lots est précieuse car elle permet de recueillir vite le retour utilisateur (par exemple via des tests A/B), et cette approche expérimentale du produit est elle-même fortement corrélée aux pratiques techniques de la livraison continue (continuous delivery). Le fait que la performance de livraison compte fournit aussi un argument fort contre l'externalisation du développement du logiciel stratégique : mieux vaut l'amener au cœur de l'organisation, à l'image de ce qu'a fait l'US Digital Service. À l'inverse, le logiciel non stratégique (bureautique, paie) gagne souvent à être acquis en mode SaaS — distinguer les deux est d'une importance capitale.
Mesurer sans nuire
Disposer d'une mesure valide ouvre la voie à des décisions fondées sur des preuves : comparer et étalonner des équipes, suivre leur progression — ou leur régression — dans le temps, et tester des hypothèses sur les pratiques qui impactent réellement la performance. Les auteurs glissent d'ailleurs un résultat marquant : les comités d'approbation des changements (change approval boards) n'améliorent pas la performance de livraison ; ils sont négativement corrélés au tempo et à la stabilité.
Attention
Ces outils ne sont puissants que dans une culture d'apprentissage. Dans les cultures pathologiques ou bureaucratiques, la mesure devient un instrument de contrôle : les gens dissimulent les informations qui menacent les règles et les structures de pouvoir en place. Comme le rappelait Deming, « dès qu'il y a de la peur, vous obtenez les mauvais chiffres ». Avant de déployer une approche scientifique de l'amélioration, il faut d'abord comprendre et développer sa culture — c'est l'objet du chapitre suivant.
À retenir
- Les mesures classiques — lignes de code, vélocité, taux d'utilisation — trompent : elles récompensent des extrants locaux plutôt que des résultats globaux, et poussent à truquer les chiffres ou à fuir la collaboration.
- Une bonne mesure vise un résultat global et des résultats, pas des extrants. La recherche retient quatre métriques (DORA) en deux dimensions : débit (délai de livraison + fréquence de déploiement) et stabilité (temps de restauration + taux d'échec).
- Résultat majeur : aucun compromis entre vitesse et stabilité. Les hauts performeurs excellent sur les quatre à la fois, en intégrant la qualité dès le départ.
- En 2017, les hauts performeurs déployaient 46 fois plus souvent, avec un délai 440 fois plus rapide, un temps de restauration 170 fois plus rapide et un taux d'échec 5 fois plus bas que les bas performeurs.
- La performance de livraison prédit la performance de l'organisation : les hauts performeurs ont deux fois plus de chances de dépasser leurs objectifs de rentabilité, de part de marché, de productivité et leurs objectifs non commerciaux.
- Ces mesures ne sont puissantes que dans une culture d'apprentissage ; utilisées comme outil de contrôle dans une culture de la peur, elles produisent de mauvais chiffres.