Mesurer la fluidité du delivery : ce que le QA peut lire et influencer

Brouillon du blog Shift Op, article 3 sur 5 de la série « Piloter la qualité » · @October 12, 2026 · @Jeff

« On livre trop lentement, et les tests y sont pour quelque chose. » Tu as sûrement entendu cette phrase. La plupart du temps, personne ne l'appuie sur un chiffre, et la QA se retrouve accusée d'un problème que l'équipe n'a jamais mesuré.

Cet article pose un vocabulaire commun pour parler de la fluidité de la livraison. Je m'appuie sur les métriques DORA dans leur forme actuelle, puis je distingue ce que le QA ne possède pas, ce qu'il peut lire et ce qu'il peut vraiment influencer.

Cet article fait partie d'une série de cinq articles sur le pilotage de la qualité : métriques, reporting et décisions. C'est le troisième. Les cinq articles se lisent idéalement dans l'ordre, mais chacun reste utile pris isolément.

Le vocabulaire a changé : les cinq métriques DORA

Si tu t'es formé à quatre indicateurs de livraison, dont le MTTR, la liste a évolué. La page DORA sur les métriques en retient aujourd'hui cinq, réparties en deux groupes : le débit de livraison et l'instabilité.

Un changement mérite ton attention. Le MTTR a été renommé et redéfini en 2023 sous le nom de temps de rétablissement après un déploiement échoué. La raison donnée par DORA : l'ancienne définition ne distinguait pas une panne causée par un changement logiciel d'une panne due à un facteur externe (historique des métriques DORA). Si ton équipe parle encore de MTTR, demande ce qu'elle compte exactement.

Deux précisions utiles. Le terme « cycle time » n'est pas dans cette liste : il circule avec des définitions variables d'une équipe à l'autre, donc demande toujours quel est son point de départ et son point d'arrivée avant de comparer deux chiffres. Et DORA indique que ces métriques s'appliquent au niveau d'une application ou d'un service, pas d'une organisation entière.

Ce que le QA ne possède pas, et ce qu'il peut influencer

Soyons honnêtes sur les rôles. La fréquence de déploiement dépend de la stratégie de livraison, de l'infrastructure et des décisions produit. Le QA n'en est pas propriétaire, et se présenter comme responsable de ces chiffres ne servirait à rien.

En revanche, plusieurs leviers passent par toi :

• La durée de la suite de tests dans le pipeline. Une suite qui met quarante minutes là où vingt suffiraient allonge directement le délai entre le commit et la production.
• La fiabilité de cette suite. Chaque test instable provoque des relances, des attentes et des doutes. L'article suivant revient sur ce point.
• La détection avant la production. Un défaut vu avant la mise en production ne fait ni échouer un changement ni ajouter un déploiement de correction. C'est le lien le plus direct entre ton travail et les deux métriques d'instabilité.
• La qualité de l'information. Un rapport qui dit clairement ce qui bloque une livraison, et pourquoi, raccourcit les discussions.

Ce ne sont pas des métriques DORA. Ce sont des indicateurs proches, que tu peux suivre toi-même : la durée de la suite dans le pipeline, le nombre de relances nécessaires pour obtenir un résultat vert, le taux de réouverture de bugs. Ils ne remplacent pas les cinq métriques, ils t'aident à expliquer leurs variations.

Une semaine de livraison, sur la boutique fictive

Prends l'équipe de la boutique fictive de cette série. Toutes les valeurs ci-dessous sont inventées pour l'exemple.

Sur la semaine, l'équipe fait cinq déploiements. L'un d'eux casse le paiement et oblige à revenir en arrière : le rollback prend quarante minutes. Dans le même temps, la suite de tests du pipeline est passée de vingt-cinq à quarante minutes depuis un mois, et un test instable oblige parfois à relancer l'ensemble.

Voici comment lire cette semaine :

• Taux d'échec des changements : un déploiement sur cinq, soit 20 %. Ne t'alarme pas pour autant. Avec cinq déploiements, un seul incident fait bondir le chiffre. Regarde plutôt la tendance sur plusieurs semaines.
• Temps de rétablissement : quarante minutes pour cet incident. Une valeur isolée ne dit rien : compare-la aux suivantes.
• Ce que tu peux expliquer : la suite a gagné quinze minutes en un mois, et un test instable rallonge certaines exécutions. Ce sont deux causes que tu peux traiter sans toucher à l'organisation.

Tu apportes ici quelque chose d'exploitable : pas un verdict sur la livraison, mais une explication chiffrée de ce qui la ralentit et une proposition pour y remédier, par exemple scinder la suite ou stabiliser le test instable.

Lire ces métriques sans te piéger

Ces cinq métriques peuvent elles-mêmes devenir des vanity metrics si on les utilise mal. DORA met en garde contre plusieurs usages sur sa page des métriques. Trois mises en garde en découlent.

N'en fais pas des objectifs. DORA déconseille de fixer une métrique comme but, parce que cela pousse les équipes à la manipuler. La page cite la loi de Goodhart et donne l'exemple d'une cible de plusieurs déploiements par jour. C'est exactement le mécanisme vu dans le premier article avec le taux d'exécution.

Ne compare pas des équipes très différentes. La page avertit que comparer des applications très différentes peut induire en erreur, et que le but est d'améliorer chaque équipe dans le temps, pas de les mettre en concurrence. Une équipe qui livre un site marchand et une équipe qui maintient un système réglementé n'ont pas les mêmes contraintes.

Lis le débit et l'instabilité ensemble. DORA range les cinq métriques en deux groupes. Je les lis comme un couple : livrer plus vite en voyant monter les échecs et le retravail n'est pas un progrès. C'est là que la QA a son mot à dire.

Ajoute à cela un réflexe simple déjà vu dans l'exemple : vérifie la taille de l'échantillon. Une équipe qui déploie une fois par mois n'a que douze points par an, et un seul incident change tout. Dans ce cas, complète les chiffres par un retour qualitatif après chaque livraison.

À retenir

• Utilise le vocabulaire actuel de DORA : trois métriques de débit et deux d'instabilité, le MTTR ayant été redéfini en 2023.
• Le QA ne possède pas ces chiffres. Il influence surtout la durée et la fiabilité de la suite de tests, et la détection avant la production.
• Suis des indicateurs proches que tu maîtrises (durée de la suite, relances, réouvertures) pour expliquer les variations.
• Ne transforme jamais ces métriques en objectifs ni en classement d'équipes.
• Une semaine ou un incident ne prouvent rien : lis les tendances sur plusieurs semaines, et exige une définition claire d'un « échec ».

FAQ

Cycle time ou lead time : lequel utiliser ?

DORA parle de délai de changement, mesuré du commit à la production. Le terme cycle time recouvre des définitions variables selon les équipes. Quel que soit le mot choisi, écris le point de départ et le point d'arrivée.

Le QA doit-il suivre les métriques DORA ?

Il doit les connaître et les lire. Les produire est souvent le rôle de l'équipe plateforme ou de développement. Ce que tu apportes, c'est l'explication liée aux tests et à la détection.

Quel niveau faut-il viser ?

Je ne te donne pas de seuil de référence ici. DORA met en garde contre les cibles et les comparaisons entre équipes. Observe ta propre tendance sur plusieurs mois et discute-la avec l'équipe.

Comment définir un « échec » pour le taux d'échec des changements ?

Mets-toi d'accord par écrit avec l'équipe : un rollback, un correctif en urgence, un incident utilisateur, ou tout cela. Peu importe le choix tant qu'il reste le même d'un mois à l'autre.

Mon équipe déploie une fois par mois. Ces métriques ont-elles un sens ?

Elles restent lisibles, mais sur peu de points. Regarde surtout le délai de changement et le retravail, et note après chaque livraison ce qui s'est passé.

La suite de la série

L'article suivant s'intéresse à la troisième couche : la dette de test et la dette qualité, avec ce que tu peux mesurer sans être développeur. Il arrive sur la newsletter La Guilde : laguilde.substack.com.

Plus d’articles comme celui-ci