1. Les métriques DORA #
Le standard issu de dix ans de recherche.
Définitions #
| Métrique | Définition | Équipes les plus performantes |
|---|---|---|
| Fréquence de déploiement | à quelle fréquence l'organisation déploie en production | à la demande, plusieurs fois par jour |
| Délai de mise en production (lead time for changes) | temps entre le commit et son arrivée en production | moins d'un jour |
| Taux d'échec des changements | part des déploiements qui provoquent un incident ou un retour arrière | environ 5 % ou moins |
| Temps de restauration (failed deployment recovery time) | temps pour rétablir le service après un déploiement en échec | moins d'une heure |
| Taux de reprise (rework rate) | part des déploiements non planifiés pour corriger un problème en production | faible |
À 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 #
| Métrique | Source |
|---|---|
| Fréquence | événements de déploiement du pipeline ou de l'outil GitOps |
| Délai | date du commit (Git) et date du déploiement qui le contient |
| Taux d'échec | déploiements suivis d'un rollback, d'un hotfix ou d'un incident lié |
| Restauration | outil d'incident : ouverture et résolution |
# 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 #
| Dimension | Exemples d'indicateurs |
|---|---|
| Satisfaction et bien-être | enquêtes, intention de rester |
| Performance | qualité, fiabilité, impact client |
| Activité | nombre de déploiements, de revues (à ne jamais utiliser seul) |
| Communication et collaboration | délai de revue, qualité de la documentation |
| Efficacité et flux | temps sans interruption, files d'attente |
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 #
- Mesurer la situation actuelle (DORA, chaîne de valeur).
- Identifier la contrainte principale : tests manuels ? environnements ? revues lentes ?
- Choisir une expérimentation ciblée pour quelques semaines.
- Mesurer l'effet, garder ou abandonner.
- 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.
