Mesurer : les indicateurs DORA

Pourquoi

Les cinq leçons précédentes ont construit un pipeline : intégration, étapes, tests, livraison, sécurité. Reste une question : tout cela rend-il vraiment service ? Un pipeline peut être impressionnant et inutile, ou modeste et décisif. Pour le savoir, il faut mesurer, et mesurer les bonnes choses.

Le réflexe naïf est de compter l'activité : nombre de commits, de lignes, de tickets fermés. Ces chiffres mesurent l'agitation, pas la valeur, et se manipulent trivialement. Le programme de recherche DORA (DevOps Research and Assessment), mené depuis 2014 et popularisé par le livre Accelerate (Forsgren, Humble, Kim, 2018), a cherché, sur des dizaines de milliers d'équipes, quels indicateurs distinguent les organisations qui livrent bien. Il en a dégagé un petit ensemble qui a deux qualités rares : il mesure un résultat (la capacité à livrer des changements, vite et sûrement), et il résiste mieux que d'autres à la manipulation, parce qu'il équilibre vitesse et stabilité.

Cette leçon présente ces indicateurs, puis les calcule pour de vrai à partir d'un journal de déploiements, avec un petit script Python. Elle clôt le cours : on mesure ce que l'on a construit.

Les concepts

Deux familles, qui s'équilibrent

DORA regroupe ses indicateurs en deux familles opposées, et c'est l'opposition qui fait leur valeur.

    flowchart LR
  subgraph D["Débit (vitesse)"]
    F["Fréquence de déploiement"]
    L["Délai de livraison"]
  end
  subgraph I["Instabilité (sûreté)"]
    E["Taux d'échec des changements"]
    R["Délai de rétablissement"]
    W["Taux de reprise"]
  end
  D -.équilibre.- I
  

• Le débit mesure la vitesse : à quelle fréquence on livre, et en combien de temps un changement atteint la production.
• L'instabilité mesure le coût de cette vitesse : combien de livraisons tournent mal, et combien de temps on met à réparer.

Regarder une famille sans l'autre mène à l'absurde. On « améliore » le débit en déployant n'importe quoi, et l'instabilité explose. On « améliore » la stabilité en ne déployant plus jamais, et le débit s'effondre. La découverte de DORA est que les meilleures équipes sont bonnes sur les deux à la fois : vitesse et stabilité ne s'opposent pas, elles progressent ensemble quand les pratiques sont bonnes. C'est pourquoi on ne cite jamais un indicateur DORA seul.

Les cinq indicateurs

Les définitions actuelles de DORA :

Deux précisions de vocabulaire, parce que les noms ont changé :

• L'indicateur longtemps appelé mean time to recover (MTTR) a été renommé et redéfini en délai de rétablissement après échec (failed deployment recovery time) dans le rapport 2023 : il ne mesure que le rétablissement après un déploiement défaillant, pas après n'importe quel incident.
• Le modèle historique comptait quatre indicateurs. Le taux de reprise (deployment rework rate) a été ajouté en 2024, pour mesurer directement l'effort de reprise que le taux d'échec n'approchait qu'indirectement. On parle donc aujourd'hui de cinq indicateurs, répartis en « débit de livraison » et « instabilité de livraison ».

Ce qu'ils ne sont pas

Trois mises en garde, essentielles pour ne pas faire de dégâts avec ces chiffres.

• Ce ne sont pas des objectifs. Dès qu'une mesure devient une cible, elle cesse de mesurer : c'est la loi de Goodhart. Fixez « dix déploiements par jour » comme objectif, et vous obtiendrez dix déploiements vides. DORA le dit explicitement : améliorez la performance de votre équipe dans le temps, ne compétitionnez pas contre un chiffre.
• Ce ne sont pas un classement entre équipes. Les indicateurs valent au niveau d'une application ou d'un service ; comparer deux applications très différentes induit en erreur. Le site de Signalements et un service bancaire critique n'ont pas les mêmes contraintes.
• Ce n'est pas une mesure de productivité individuelle. Ils décrivent un système de livraison, pas une personne. S'en servir pour évaluer quelqu'un garantit qu'il sera manipulé, et détruit la confiance.

Bien utilisés, ils servent une seule chose : voir si un changement de pratique améliore la livraison, pour cette équipe, dans le temps.

En pratique

Un journal de déploiements

Tout se calcule à partir d'une trace des déploiements, comme le deploiements.log que notre serveur écrit depuis la leçon 4. Enrichissons-le de ce qu'il faut pour les cinq indicateurs : l'horodatage de la validation (le commit), celui du déploiement, et l'état du déploiement. Voici un exemple pour un mois de production de Signalements, au format CSV (deploiements.csv), dont voici les premières lignes :

# commit; validation; deploiement; etat
# etat : ok (déploiement sain) | echec (a nécessité une intervention) | correctif (déploiement qui répare un echec)
a1b2c3d; 2026-09-01T09:12:00; 2026-09-01T10:40:00; ok
b2c3d4e; 2026-09-02T14:03:00; 2026-09-02T15:20:00; ok
c3d4e5f; 2026-09-03T08:55:00; 2026-09-03T11:10:00; ok
d4e5f6a; 2026-09-03T16:40:00; 2026-09-03T17:30:00; echec
e5f6a7b; 2026-09-03T17:45:00; 2026-09-03T18:05:00; correctif
f6a7b8c; 2026-09-04T10:20:00; 2026-09-04T11:15:00; ok
...

Le jeu complet compte 26 déploiements de production sur le mois de septembre, dont deux echec suivis chacun d'un correctif. Les horodatages de validation et de déploiement sont ceux que le pipeline connaît déjà : le commit est horodaté par Git, le déploiement par le serveur qui l'exécute. L'état demande, lui, une décision humaine ou une détection : un déploiement qui a dû être réparé en urgence est un echec, le déploiement qui le répare est un correctif.

Le script de calcul

dora.py lit ce journal et calcule les cinq indicateurs. Il n'utilise que la bibliothèque standard.

#!/usr/bin/env python3
"""Calcule les cinq indicateurs DORA à partir d'un journal de déploiements.

Entrée : un CSV « commit; validation; deploiement; etat », une ligne par
déploiement en production, les lignes vides et les commentaires (#) ignorés.
etat : ok | echec (a nécessité une intervention) | correctif (répare un echec).
"""

import statistics
import sys
from datetime import datetime


def lire(chemin):
    deploiements = []
    with open(chemin, encoding="utf-8") as fichier:
        for ligne in fichier:
            ligne = ligne.strip()
            if not ligne or ligne.startswith("#"):
                continue
            commit, validation, deploiement, etat = (
                c.strip() for c in ligne.split(";")
            )
            deploiements.append(
                {
                    "commit": commit,
                    "validation": datetime.fromisoformat(validation),
                    "deploiement": datetime.fromisoformat(deploiement),
                    "etat": etat,
                }
            )
    return sorted(deploiements, key=lambda d: d["deploiement"])


def mediane_lisible(secondes):
    heures = secondes / 3600
    if heures < 1:
        return f"{secondes / 60:.0f} min"
    if heures < 24:
        return f"{heures:.1f} h"
    return f"{heures / 24:.1f} j"


def calculer(deploiements):
    debut = min(d["deploiement"] for d in deploiements)
    fin = max(d["deploiement"] for d in deploiements)
    jours = (fin - debut).days + 1
    total = len(deploiements)

    # Fréquence de déploiement
    par_jour = total / jours

    # Délai de livraison : de la validation au déploiement
    delais = [
        (d["deploiement"] - d["validation"]).total_seconds() for d in deploiements
    ]

    # Taux d'échec des changements : part des déploiements en échec
    echecs = [d for d in deploiements if d["etat"] == "echec"]
    taux_echec = len(echecs) / total

    # Délai de rétablissement : d'un échec au premier correctif qui suit
    retablissements = []
    for echec in echecs:
        suivants = [
            d
            for d in deploiements
            if d["etat"] == "correctif" and d["deploiement"] > echec["deploiement"]
        ]
        if suivants:
            premier = min(suivants, key=lambda d: d["deploiement"])
            retablissements.append(
                (premier["deploiement"] - echec["deploiement"]).total_seconds()
            )

    # Taux de reprise : part des déploiements non prévus, faits pour réparer un incident
    correctifs = [d for d in deploiements if d["etat"] == "correctif"]
    taux_reprise = len(correctifs) / total

    return {
        "periode": f"{debut.date()} au {fin.date()} ({jours} jours)",
        "total": total,
        "frequence": f"{par_jour:.2f} par jour ({total} sur {jours} jours)",
        "delai_median": mediane_lisible(statistics.median(delais)),
        "taux_echec": f"{taux_echec:.0%} ({len(echecs)} sur {total})",
        "retablissement_median": mediane_lisible(statistics.median(retablissements))
        if retablissements
        else "n/a",
        "taux_reprise": f"{taux_reprise:.0%} ({len(correctifs)} sur {total})",
    }


if __name__ == "__main__":
    resultats = calculer(lire(sys.argv[1] if len(sys.argv) > 1 else "deploiements.csv"))
    lignes = [
        ("Période", resultats["periode"]),
        ("Fréquence de déploiement", resultats["frequence"]),
        ("Délai de livraison (médian)", resultats["delai_median"]),
        ("Taux d'échec des changements", resultats["taux_echec"]),
        ("Délai de rétablissement médian", resultats["retablissement_median"]),
        ("Taux de reprise", resultats["taux_reprise"]),
    ]
    for libelle, valeur in lignes:
        print(f"{libelle:<30} : {valeur}")

Deux choix de calcul méritent une explication :

• On prend la médiane, pas la moyenne, pour le délai de livraison et le délai de rétablissement. Une seule panne réparée en huit heures tirerait une moyenne vers le haut et masquerait que neuf fois sur dix on répare en vingt minutes. La médiane décrit le cas courant ; c'est le choix de DORA.
• Le délai de rétablissement relie un echec au premier correctif qui le suit. C'est une simplification : dans la réalité, on relie l'incident au déploiement qui le résout grâce à un identifiant partagé. Le principe reste le même.

Le résultat

$ docker run --rm -v "$PWD":/src:ro -w /src python:3.14-slim python dora.py
Période                        : 2026-09-01 au 2026-09-30 (30 jours)
Fréquence de déploiement       : 0.87 par jour (26 sur 30 jours)
Délai de livraison (médian)    : 1.1 h
Taux d'échec des changements   : 8% (2 sur 26)
Délai de rétablissement médian : 42 min
Taux de reprise                : 8% (2 sur 26)

Lecture d'ensemble : Signalements est déployé presque une fois par jour, un changement atteint la production en un peu plus d'une heure après sa validation, environ un déploiement sur treize tourne mal, et quand cela arrive, on rétablit le service en moins d'une heure. Débit soutenu, instabilité faible et vite corrigée : les deux familles sont bonnes ensemble, ce qui est le signe recherché.

Lire la tendance, pas le chiffre

Un relevé isolé ne dit presque rien : 8 % d'échec, est-ce bien ? La question n'a pas de réponse dans l'absolu. Ce qui compte est la tendance : ces 8 % montent-ils ou descendent-ils de mois en mois ? Et le lien avec les pratiques : si l'équipe ajoute les tests d'intégration de la leçon 3, le taux d'échec du mois suivant baisse-t-il ? Si elle réduit la taille des lots (leçon 1), le délai de livraison se raccourcit-il ?

C'est l'usage juste de ces indicateurs : une boucle de retour sur les pratiques. On change une chose, on regarde si la courbe bouge dans le bon sens, sans dégrader l'autre famille. C'est aussi, précisément, ce que les recherches de DORA ont établi à grande échelle : les capacités techniques de ce cours (intégration continue, tests automatisés, livraison continue, déploiement par petits lots) causent de meilleurs indicateurs, et non l'inverse.

Sous le capot

D'où viennent les horodatages. Les trois données du journal sont déjà produites par le pipeline des leçons précédentes. L'horodatage de validation est celui du commit (git show -s --format=%cI <commit>). L'horodatage de déploiement est celui qu'écrit notre script deployer (date --iso-8601=seconds). L'état se déduit du journal de déploiements et du suivi des incidents : un retour arrière enregistré dans deploiements.log (comme celui de la leçon 4) marque le déploiement précédent comme echec et lui-même comme correctif. Autrement dit, l'instrumentation nécessaire aux indicateurs DORA est un sous-produit d'un pipeline bien tenu, pas un travail séparé.

Le délai de livraison, du commit ou de la demande de fusion ? DORA mesure du commit à la production. Certaines équipes préfèrent mesurer de l'ouverture de la demande de fusion, ou de la première ligne de code écrite, pour inclure le temps de revue. Chaque borne répond à une question différente ; l'important est de choisir une définition et de s'y tenir, pour que la tendance reste comparable à elle-même.

Pourquoi la médiane et pas un centile élevé. La médiane (centile 50) décrit le cas courant. Pour une application où les cas extrêmes comptent (un rétablissement très long est un incident grave), on suit aussi un centile élevé, le 90e ou le 95e, en plus de la médiane. Notre script affiche la médiane ; l'exercice 2 ajoute le 90e centile.

Pièges courants

Faire d'un indicateur une cible. Le piège numéro un, parce qu'il part d'une bonne intention. « Objectif : réduire le délai de livraison à moins d'une heure » pousse à découper artificiellement, à sauter la revue, à contourner les tests. Mesurez pour comprendre, fixez des objectifs sur les pratiques (« généraliser les tests d'intégration »), pas sur les indicateurs.

Ne regarder que le débit. Une direction séduite par « on déploie trente fois par jour » sans regarder le taux d'échec encourage la précipitation. Les cinq indicateurs se lisent ensemble, toujours.

Comparer des équipes. Afficher un tableau de bord qui classe les équipes transforme les indicateurs en arme politique et garantit leur manipulation. Chaque équipe suit sa propre tendance.

Confondre déploiement et mise à disposition. Une équipe qui pratique les drapeaux de fonctionnalité (leçon 4) déploie souvent sans rien activer. Sa fréquence de déploiement est élevée et saine ; la confondre avec la fréquence de mise à disposition de nouveautés aux utilisateurs induirait en erreur.

Mesurer l'activité au lieu du résultat. Nombre de commits, de lignes, de pipelines lancés : ces chiffres montent quand l'équipe s'agite, pas quand elle livre mieux. Les indicateurs DORA mesurent le passage effectif à la production.

Sécurité

Mesurer la livraison sert aussi la sécurité, souvent contre l'intuition :

• Un délai de livraison court est une capacité de sécurité. Quand une faille critique est publiée dans une dépendance, le temps pour déployer le correctif en production est... le délai de livraison. Une équipe qui livre en une heure corrige en une heure ; une équipe qui livre une fois par mois reste exposée des semaines. DORA classe d'ailleurs la capacité à déployer vite parmi les facteurs de résilience.
• Un déploiement vérifiable est un déploiement traçable. Le journal qui alimente les indicateurs (qui a déployé quoi, quand, avec quel résultat) est aussi la trace d'audit exigée en cas d'incident de sécurité (leçon 5, CICD-SEC-10). Les deux besoins se servent de la même donnée.
• Attention aux indicateurs qui poussent à masquer les incidents. Si un taux d'échec élevé est puni, les équipes cessent de déclarer les incidents, et l'on perd à la fois la mesure et la capacité à réagir. La mesure doit rester un outil d'amélioration, jamais de sanction : c'est une condition de la culture « sans blâme » (chapitre Organiser).

En production

• Automatisez la collecte. Un relevé à la main n'est pas tenable. En production, le pipeline écrit chaque déploiement dans une base ou un service dédié (les Four Keys de Google, ou des produits intégrés comme ceux de GitLab et de certaines forges), et le suivi d'incidents (une étiquette sur les tickets, un marqueur sur les retours arrière) fournit l'état. Notre deploiements.log est la version minimale de cette instrumentation.
• Reliez incident et déploiement. Pour calculer proprement le taux d'échec et le délai de rétablissement, il faut relier chaque incident au déploiement qui l'a causé et à celui qui l'a résolu. Un identifiant commun (numéro de version, empreinte de l'artefact) suffit, et c'est pourquoi la leçon 4 déployait par empreinte.
• Croisez avec les signaux de production. Les indicateurs DORA décrivent la livraison, pas la santé du service. On les regarde à côté des indicateurs d'exploitation (taux d'erreurs, latence, disponibilité), traités au chapitre Exploiter : un déploiement « réussi » qui double le taux d'erreurs dix minutes plus tard doit être compté comme un échec.
• Au niveau de Lyneko. Chaque application (cvizer, le portail IA, ce site...) a ses propres indicateurs ; on ne les additionne pas en un chiffre unique pour l'entreprise, on suit la tendance de chacune, et l'on se sert des écarts pour repérer où une pratique manque (une application sans tests d'intégration, une autre sans retour arrière outillé).

Exercices

1. Interpréter un relevé (niveau 100). Deux équipes livrent la même application sur deux trimestres. Équipe A : 5 déploiements par jour, délai de livraison 2 h, taux d'échec 4 %, rétablissement 20 min. Équipe B : 0,2 déploiement par jour, délai de livraison 3 semaines, taux d'échec 30 %, rétablissement 2 jours. Que concluez-vous, et quelle pratique recommanderiez-vous d'abord à l'équipe B ?

2. Ajouter un centile (niveau 100). Modifiez dora.py pour afficher, à côté de la médiane, le 90e centile du délai de livraison et du délai de rétablissement. Pourquoi ce chiffre complète-t-il utilement la médiane ?

def centile_90(valeurs):
    if len(valeurs) < 2:
        return valeurs[0] if valeurs else 0
    return statistics.quantiles(valeurs, n=10)[-1]  # borne haute du 9e dixième

3. Relier à une pratique (niveau 100). Pour chaque indicateur DORA, citez une pratique d'une leçon précédente de ce cours qui l'améliore, et expliquez le lien.

Récapitulatif

• Les indicateurs DORA mesurent un résultat (la capacité à livrer vite et sûrement), pas l'activité.
• Cinq indicateurs, deux familles : débit (fréquence de déploiement, délai de livraison) et instabilité (taux d'échec, délai de rétablissement, taux de reprise). On les lit ensemble : vitesse et stabilité progressent de pair.
• Ils se calculent à partir d'un simple journal de déploiements, sous-produit d'un pipeline bien tenu ; on prend la médiane, et on suit la tendance, pas le chiffre isolé.
• Ils ne sont ni des objectifs (loi de Goodhart), ni un classement d'équipes, ni une mesure individuelle.
• Bien utilisés, ils forment une boucle de retour sur les pratiques des leçons précédentes : on change une pratique, on regarde si la courbe s'améliore sans dégrader l'autre famille.

Pour aller plus loin

• Le livre Accelerate (Forsgren, Humble, Kim), qui expose la méthode de recherche et le lien de causalité entre pratiques et performance.
• Les guides de DORA sur la définition des indicateurs et leur histoire, pour suivre l'évolution du modèle (quatre puis cinq indicateurs).
• Le projet Four Keys de Google, pour une implémentation ouverte de la collecte automatique.
• Le chapitre Organiser de ce site, pour la culture (sans blâme, topologies d'équipes) sans laquelle ces indicateurs se retournent contre ceux qu'ils devaient aider ; et le chapitre Exploiter, pour les indicateurs de santé du service qui les complètent.

Ce cours CI/CD : les principes s'arrête ici. Vous savez ce qu'est un pipeline, ce qu'il contient, comment il teste, livre, se sécurise et se mesure, indépendamment de tout produit. Les cours suivants du chapitre Livrer appliquent ces principes avec de vrais outils : GitHub Actions pour écrire les pipelines, GitOps avec Argo CD pour déployer, Stratégies de déploiement pour le faire progressivement.