# Métriques DORA : les 5 mesures de livraison logicielle

URL: https://upstreamapi.com/fr/journal/metriques-dora-comment-les-mesurer
Type: blog
Locale: fr
Published: 2026-10-03
Updated: 2026-10-03

---

> Cinq mesures de livraison logicielle : lead time, fréquence, récupération, taux d'échec et retravail. Ensemble, elles disent la vitesse et la stabilité. Mesurées bien, elles pointent le goulot.

C'est quoi les métriques DORA ? Elles sont cinq mesures de la livraison logicielle : lead time des changements, fréquence de déploiement, temps de récupération des déploiements échoués, taux d'échec des changements et taux de retravail. Les trois premières décrivent le débit, les deux dernières décrivent l'instabilité. Ensemble, elles vous disent à quelle vitesse les changements arrivent en prod et combien de fois ces changements cassent. Utilisées bien, elles pointent le vrai goulot. Utilisées mal, elles deviennent un bullettin scolaire que votre équipe apprend à manipuler.

## D'où viennent les nombres, et pourquoi le vocabulaire a tenu

Un tech lead de plateforme se retrouve en revue trimestrielle. Le CTO pose une question : est-ce qu'on livre plus vite qu'l'année dernière, et est-ce qu'on casse moins ? Sans vocabulaire partagé, la réponse est une pile d'anecdotes. Les métriques DORA existent pour remplacer les anecdotes par quatre ou cinq nombres qu'on peut extraire des systèmes qu'on fait déjà tourner.

Le nom vient de DevOps Research and Assessment, le programme de recherche qui a passé des années à sonder les équipes d'ingénierie et à corréler leurs pratiques de livraison avec les résultats organisationnels. C'est maintenant une branche de Google Cloud, et les résultats sont publiés chaque année dans le [programme de recherche DORA](https://dora.dev/research/). Le livre Accelerate a popularisé les quatre métriques initiales. Le cadre a été révisé depuis, et cette révision compte plus que la plupart des articles de blog ne l'admettent.

Voilà le point qu'on perd souvent : ces métriques n'ont jamais été conçues comme un classement. Elles sont sorties d'une trouvaille statistique. Les équipes qui notaient bien en vitesse notaient aussi bien en stabilité. La vitesse et la sécurité n'étaient pas un compromis, elles allaient ensemble. C'est une affirmation sur la corrélation entre beaucoup d'équipes, pas une cible pour la vôtre.

## Les cinq métriques, définies comme un SRE en astreinte les définirait

Les définitions actuelles sur le [guide officiel des métriques DORA](https://dora.dev/guides/dora-metrics/) se divisent en deux groupes. Lisez-les en gardant un service spécifique en tête, parce que chaque définition s'effondre si vous l'appliquez à « l'entreprise entière ».

**Lead time des changements.** Le temps entre un commit et ce commit qui tourne en production. Pas depuis que le ticket a été ouvert, pas depuis que la pull request a été approuvée. Depuis le commit. Si votre pipeline prend quarante minutes et que votre train de release part le jeudi, votre lead time est dominé par le jeudi.

**Fréquence de déploiement.** Combien de fois vous livrez en production. Vous pouvez compter les déploiements sur une période ou mesurer l'écart entre eux. Un service qui déploie onze fois par jour et un service qui déploie une fois par mois, c'est deux bêtes différentes, et faire la moyenne les cache tous les deux.

**Temps de récupération des déploiements échoués.** Combien de temps il faut pour récupérer quand un déploiement cause un problème qui a besoin d'une intervention. Ça s'appelait mean time to restore, et le changement de nom est intentionnel. Ça ne compte que les incidents causés par votre propre changement, pas une panne du cloud provider un mardi.

**Taux d'échec des changements.** La part des déploiements qui ont besoin d'une intervention immédiate après : un rollback, un hotfix, un fix poussé à la vitesse. Dix déploiements, deux revertis, un taux d'échec de vingt pour cent.

**Taux de retravail.** La part des déploiements qui sont imprévus, déclenchés par un incident en production plutôt que par le roadmap. C'est l'ajout le plus récent, et il attrape quelque chose que le taux d'échec rate : l'équipe qui ne revert jamais mais passe la moitié de sa semaine à shipper des patches d'urgence.

![Stopwatch resting on a server rack panel, a picture of lead time](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/02c796-i1.webp)

## Débit contre instabilité : pourquoi vous ne lisez jamais une métrique seule

Les trois premières métriques, c'est le débit. Les deux dernières, c'est l'instabilité. Le groupement, c'est tout le point.

Si vous regardez seulement le débit, vous allez célébrer une équipe qui déploie quarante fois par jour et reverrait tranquillement un quart d'entre eux. Si vous regardez seulement l'instabilité, vous allez récompenser une équipe qui shippe une fois par mois avec un dossier parfait, parce que personne ne change rien. Chaque métrique a un truc pas cher pour l'améliorer qui casse le système.

La fréquence de déploiement monte quand vous divisez un deploy en cinq deploys vides. Le taux d'échec descend quand vous arrêtez de compter les hotfixes comme des échecs. Le lead time rétrécit quand vous redéfinissez où l'horloge commence. C'est la loi de Goodhart qui fait ce qu'elle fait toujours : quand une mesure devient un objectif, elle arrête d'être une bonne mesure. Le guide officiel la met en première place parmi ses avertissements, et c'est celle qui mord le plus fort.

Donc la règle qui tient, c'est les paires. Lisez lead time à côté du taux d'échec. Lisez fréquence de déploiement à côté du taux de retravail. Un mouvement dans une direction sans histoire assorties dans l'autre, c'est un signal de regarder de plus près, pas une victoire à annoncer.

Les benchmarks circulent dans chaque présentation de vendor, et c'est un piège. Le pattern rapporté par les rapports DORA récents est constant dans sa forme : le cluster le plus fort déploie sur demande, avec un lead time sous un jour, et se récupère d'un déploiement échoué en moins d'une heure. Le cluster le plus lent s'étire sur des semaines à des mois sur les deux.

Ces chiffres servent une chose : calibrer votre intuition sur ce qui est possible. C'est pas bon comme objectifs. Un service de paiement avec une porte de vérification obligatoire ne va pas matcher un site marketing, et il ne devrait pas essayer. Le guidage officiel est explicite : vous ne devriez comparer que des services ou applications similaires, et vous devriez viser l'amélioration contre votre propre baseline plutôt que la compétition entre équipes.

Commencez par votre propre médiane. Mesurez-la pendant un mois avant de fixer un objectif. Le premier nombre est presque toujours gênant, et c'est ok. Un baseline qui vous gêne, c'est un baseline que vous fichez vraiment.

## Comment les instrumenter sans construire une data warehouse

La plupart des équipes sur-construisent ça. Vous n'avez pas besoin d'un projet warehouse. Vous avez besoin de quatre timestamps et un flag.

Les timestamps : commit merged sur la branche principale, build terminé, déploiement lancé en production, déploiement terminé. Le flag : est-ce que le déploiement a été revert plus tard, hotfix, ou suivi d'un deploy non planifié dans une fenêtre définie.

Voilà un sketch minimal en TypeScript. Il prend une liste d'enregistrements de déploiement et renvoie les nombres qui comptent.

`type Deploy = {
  service: string;
  committedAt: Date;
  deployedAt: Date;
  failed: boolean;       // reverted, hotfixed, or manual intervention
  unplanned: boolean;    // triggered by an incident, not by roadmap work
  recoveredAt?: Date;    // set when failed is true
};

const median = (xs: number[]) => {
  const s = [...xs].sort((a, b) => a - b);
  return s.length ? s[Math.floor(s.length / 2)] : 0;
};

export function doraSummary(deploys: Deploy[], days: number) {
  const leadHours = deploys.map(
    d => (d.deployedAt.getTime() - d.committedAt.getTime()) / 36e5,
  );
  const failures = deploys.filter(d => d.failed);
  const recoveryMins = failures
    .filter(d => d.recoveredAt)
    .map(d => (d.recoveredAt!.getTime() - d.deployedAt.getTime()) / 6e4);

  return {
    leadTimeHoursP50: median(leadHours),
    deploysPerDay: deploys.length / days,
    changeFailRate: failures.length / Math.max(deploys.length, 1),
    recoveryMinutesP50: median(recoveryMins),
    reworkRate: deploys.filter(d => d.unplanned).length / Math.max(deploys.length, 1),
  };
}`Deux décisions dans ce snippet portent le poids. D'abord, il utilise la médiane, pas la moyenne. Une mauvaise semaine avec une récupération de trois jours va détruire une moyenne et ne vous dire rien sur un mardi typique. Ensuite, il calcule tout par service. Regroupez par équipe ou département seulement après avoir regardé les services en dessous.

La partie dure, c'est pas le code. C'est le flag `failed`. Quelqu'un doit décider ce qui compte comme un échec, l'écrire, et l'appliquer pareil à chaque fois. Si votre incident tracker relie les incidents au déploiement qui les a causés, vous avez ça presque gratis. Si c'est pas le cas, commencez là.

![Industrial breaker panel with one red lever pulled, a picture of a failed change](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/f8caad-i2.webp)

La question du tooling arrive après la question des données. Vous possédez déjà la plupart des données brutes. Votre Git host a les temps de commit. Votre CI a les événements de build et de déploiement. Votre incident tool a les échecs. Le travail, c'est les joindre sur un identifiant de déploiement partagé.

Les plateformes d'observabilité sont une place naturelle pour superposer les markers de déploiement sur top des error rates et de la latence, donc vous pouvez voir quel deploy a précédé quel spike.

Si vous préférez garder la stack ouverte et self-hosted, une couche dashboard sur votre propre database d'événements de déploiement fait le même job à coût plus bas, avec plus de plomberie de votre côté.

Il y a aussi une catégorie d'outils qui lisent vos repos et votre historique de delivery et surfacent le risque, comme les hotspots où le code churn et les défauts passés se groupent. Ça ne va pas remplacer les quatre timestamps, mais ça explique pourquoi un service a un taux d'échec élevé quand ses voisins ne l'ont pas.

Une mise en garde sur acheter quoi que ce soit ici. Un dashboard qui montre les nombres, c'est pas pareil qu'une équipe qui agit dessus. Si personne n'est proprio du graphique de temps de récupération, acheter un plus joli graphique change rien.

## Les leviers qui bougent vraiment chaque nombre

Les métriques, c'est un diagnostic. Le traitement est ailleurs, et c'est différent pour chacune.

Pour le lead time, regardez l'attente, pas le travail. Tirez une douzaine de changements récents et marquez où chacun s'est assis oisif : en attente de review, en attente d'un slot de build, en attente d'une fenêtre de release. Chez la plupart des équipes, le temps oisif surpasse le temps de code plusieurs fois. Les petites pull requests et une expectation de level-of-service sur la review battent n'importe quel tuning du pipeline.

Pour la fréquence de déploiement, le levier, c'est la taille de batch. Les changements plus petits sont plus faciles à review, plus faciles à comprendre, et plus faciles à revert. Le trunk-based development et les feature flags existent pour vous laisser merger du travail non terminé en sécurité, c'est comment vous découpler deployer de releasing.

Pour le taux d'échec, le levier, c'est combien du blast radius vous pouvez voir avant que ce soit la flotte entière. Un rollout qui expose un pour cent du traffic, montre un error rate contre un SLO, et s'arrête sur une violation transforme un incident qui aurait pu arriver en non-événement. C'est l'écart entre un déploiement échoué et un changement échoué que personne en dehors de l'équipe a remarqué.

Pour le temps de récupération, le levier, c'est le revert. Si le fix le plus rapide, c'est rollback, alors le temps de récupération, c'est le temps pour détecter le problème plus le temps pour appuyer sur le bouton. Automatiser le revert sur un seuil réduit l'humain des dix premières minutes. À 3h du matin, ça compte plus que n'importe quel runbook.

Pour le taux de retravail, le levier, c'est en amont. Un nombre élevé signifie que les incidents génèrent des déploiements. Regardez quels services produisent les patches d'urgence, et lisez leurs post-mortems comme un ensemble plutôt que un à la fois.

## Ce qui change quand l'IA écrit plus de votre code

La recherche DORA récente pointe quelque chose qui gêne n'importe qui qui vend un assistant de codage. Les assistants accélèrent les tâches bas niveau, pourtant les gains n'ont pas clairement porté sur le lead time ou le taux d'échec. Plus de code écrit par heure, c'est pas pareil que plus de valeur livrée par semaine.

Si quelque chose, un plus grand volume de changements générés pousse la pression sur la review et sur votre pipeline de delivery. Les plus gros batchs font mal à la stabilité, et la capacité de review ne scale pas avec la vitesse de typing. Regardez votre taux d'échec et votre taux de retravail de près dans les mois qui suivent l'adoption d'un assistant par une équipe. Si le lead time chute mais le retravail monte, vous n'avez pas accéléré, vous avez déplacé le coût.

![Notebook with hand-drawn trend charts for a team retrospective](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/30e093-i3.webp)

## Comment les utiliser dans une rétro sans casser votre équipe

Voilà ce qui marche en pratique. Mettez les courbes sur l'écran pour le dernier trimestre et posez une question : qu'est-ce qui a changé ici, et pourquoi ? Ne demandez pas qui. L'objectif, c'est une hypothèse sur le système, pas un verdict sur une personne.

Trois habitudes tiennent les nombres honnêtes.

D'abord, ne les mettez jamais dans les revues de performance individuelle. À partir du moment où une métrique s'attache à un nom, les gens optimisent la métrique, et vos données arrêtent de décrire la réalité.

Deuxièmement, appairez chaque nombre avec une histoire. Un spike dans le temps de récupération, c'est un incident avec un nom et un post-mortem. Lisez le post-mortem avant de lire le graphique.

Troisièmement, changez une chose à la fois. Si vous adoptez les feature flags, rétrécissez les pull requests, et automatisez les reverts le même mois, vous ne saurez jamais lequel a bougé l'aiguille.

Sautez la slide du modèle de maturité qui trie votre org en tiers et remet une médaille. Ça vaut l'effort à la place : une seule page par service, mise à jour mensuellement, listant les cinq nombres, la valeur du mois précédent, et une phrase sur ce qui a changé.

Supposez que vous aviez quatre-vingt-dix jours de données propres sur un service, et vous avez vu le taux d'échec remonter tranquillement tandis que la fréquence de déploiement restait plate. Où regarderiez-vous d'abord : la taille des changements, la qualité de la review, ou la visibilité que vous avez sur un rollout pendant qu'il se fait ? Votre réponse dit plus sur votre système de delivery qu'un benchmark ne le fait.

## FAQ

### Les métriques DORA remplacent-elles un post-mortem ?

Non. Les métriques vous disent qu'il y a un problème. Le post-mortem vous dit pourquoi et quoi faire. Les métriques contextualisent le post-mortem, elles ne le remplacent pas.

### Par combien de mois dois-je mesurer avant de fixer un objectif ?

Au moins un mois de données propres. Le premier baseline est presque toujours embarrassant. Mais c'est un baseline que vous pouvez ficher.

### Puis-je comparer mon équipe de paiement à mon équipe de marketing ?

Non. Les métriques n'ont de sens que pour des services similaires. Une porte de vérification obligatoire n'est pas une faiblesse, c'est un design choisi.

### Comment détecter si mon équipe truque les métriques ?

Regardez les paires. Si le lead time chute mais le taux d'échec monte, quelqu'un divise un deploy en cinq deploys vides. Les paires ne mentent pas.

### Avons-nous vraiment besoin d'une data warehouse pour les DORA ?

Non. Quatre timestamps et un flag, c'est tout. Git, CI, incident tool, et une ligne partagée de déploiement. C'est tout ce que vous avez besoin.