Mesurer la performance DevOps : DORA et SPACE

1. Les métriques DORA #

Le standard issu de dix ans de recherche.

Définitions #

À savoir : Les seuils évoluent d'un rapport annuel State of DevOps à l'autre : comparez-vous surtout à vous-même dans le temps.

2. Collecter les données #

Automatiquement, depuis les outils.

Sources #

# délai médian approximatif entre commit et tag de déploiement (prod-*)
for tag in $(git tag -l 'prod-*' --sort=creatordate | tail -20); do
  prev=$(git describe --tags --abbrev=0 --match 'prod-*' "$tag^" 2>/dev/null) || continue
  deployed=$(git log -1 --format=%ct "$tag")
  git log --format=%ct "$prev..$tag" | while read -r c; do echo $(( (deployed - c) / 3600 )); done
done | sort -n | awk '{a[NR]=$1} END {print "délai médian :", a[int((NR+1)/2)], "h"}'

Des outils comme Four Keys, Apache DevLake, GitLab Value Stream Analytics ou les tableaux de bord DORA des plateformes CI/CD automatisent ce calcul.

3. Au-delà de DORA #

Mesurer sans détruire ce que l'on mesure.

Le cadre SPACE #

Pièges #

Erreur courante : Transformer une métrique en objectif individuel la dégrade (loi de Goodhart) : compter les commits ou les lignes de code pousse à les multiplier, pas à mieux livrer.

• Mesurer des équipes et des flux, jamais des individus.
• Combiner débit et stabilité : accélérer en cassant tout n'est pas un progrès.
• Utiliser les métriques pour choisir la prochaine amélioration, puis vérifier son effet.

4. S'améliorer #

Un processus continu.

La boucle d'amélioration #

1. Mesurer la situation actuelle (DORA, chaîne de valeur).
2. Identifier la contrainte principale : tests manuels ? environnements ? revues lentes ?
3. Choisir une expérimentation ciblée pour quelques semaines.
4. Mesurer l'effet, garder ou abandonner.
5. Recommencer avec la contrainte suivante.

Bonne Pratique : Les capacités qui pèsent le plus selon DORA : livraison continue, architecture faiblement couplée, trunk-based development, tests automatisés, observabilité, petits lots et culture générative.