Métriques DORA et bonnes pratiques
Résumé : comment savoir si votre CI/CD est bon ? Le programme de recherche DORA (DevOps Research and Assessment), racheté par Google en 2018, a identifié quatre métriques qui prédisent statistiquement la performance d'une organisation. Cette leçon détaille chacune avec ses seuils, puis présente dix bonnes pratiques concrètes pour progresser.
1. D'où viennent les métriques DORA
Ce qui rend DORA crédible : ce ne sont pas des convictions d'experts, mais des résultats statistiques issus de dizaines de milliers de réponses sur plus d'une décennie. C'est ce qui distingue DORA des innombrables « bonnes pratiques » sans fondement empirique.
2. Les quatre métriques
L'équilibre est délibéré : deux métriques de vitesse et deux de stabilité. Cela empêche d'optimiser l'une au détriment de l'autre. Déployer 50 fois par jour avec 60 % d'échecs n'est pas une performance, et déployer une fois par an sans incident n'en est pas une non plus.
3. Les seuils par niveau de performance
Voici les paliers issus des rapports DORA récents.
| Métrique | Élite | Élevé | Moyen | Faible |
|---|---|---|---|---|
| Fréquence de déploiement | À la demande, plusieurs fois par jour | 1×/jour à 1×/semaine | 1×/semaine à 1×/mois | Moins d'1×/mois |
| Lead time for changes | Moins d'1 heure | 1 jour à 1 semaine | 1 semaine à 1 mois | Plus d'1 mois |
| Change failure rate | 0 à 15 % | 16 à 30 % | 16 à 30 % | 46 à 60 % |
| Time to restore service | Moins d'1 heure | Moins d'1 jour | 1 jour à 1 semaine | Plus d'1 semaine |
Comment vous situer honnêtement : mesurez vos quatre métriques sur les trois derniers mois, sans arrondir en votre faveur. La plupart des équipes se croient « élevé » et se découvrent « moyen ». C'est normal et c'est utile — une mesure honnête est le point de départ de toute amélioration.
Découverte contre-intuitive de DORA, à retenir absolument : les organisations élite sur la vitesse sont aussi celles qui sont élite sur la stabilité. Vitesse et fiabilité ne s'opposent pas — c'est même l'un des résultats les plus solides du programme, et il contredit l'intuition managériale classique.
4. Métrique 1 — Fréquence de déploiement
5. Métrique 2 — Lead time for changes
Conseil pratique de fort impact : avant d'investir des semaines à optimiser votre pipeline, mesurez la répartition de votre lead time. Si vos développeurs attendent en moyenne 14 heures qu'une pull request soit relue, réduire le pipeline de 12 à 8 minutes ne changera rien de perceptible.
6. Métrique 3 — Change failure rate
Point important souvent mal compris : un pipeline qui échoue avant la production n'est pas un change failure. C'est exactement ce qu'on attend de lui. Le change failure rate ne mesure que ce qui est passé en production et a causé un problème.
7. Métrique 4 — Time to restore service
Le levier le plus rentable sur cette métrique : le rollback en une commande. Beaucoup d'équipes passent des heures à diagnostiquer avant de réparer, alors que la bonne réflexe est d'abord rétablir (rollback), ensuite comprendre (post-mortem à froid). Cela peut faire passer un temps de rétablissement de 4 heures à 5 minutes.
8. Les dix bonnes pratiques CI/CD
9. La pyramide des tests en détail
C'est le principe qui détermine si votre pipeline sera rapide ou insupportable.
L'anti-modèle à éviter absolument : la pyramide inversée (parfois appelée cornet de glace) — beaucoup de tests end-to-end, peu de tests unitaires. Résultat systématique : un pipeline de 45 minutes, instable, que l'équipe finit par ignorer. C'est l'une des causes les plus fréquentes d'abandon d'une démarche CI/CD.
10. La gestion des secrets — le point le plus critique
L'approche OIDC mérite d'être connue : c'est aujourd'hui la référence. Votre pipeline GitHub Actions ne stocke aucune clé AWS. Il présente un jeton d'identité signé par GitHub, et AWS lui accorde un rôle temporaire de quinze minutes. Aucun secret de longue durée n'existe, donc aucun secret ne peut fuiter.
11. Comment mesurer vos métriques en pratique
Conseil pour démarrer : ne cherchez pas l'outil parfait. Commencez avec un tableur cette semaine. Une mesure approximative que vous regardez réellement vaut infiniment mieux qu'un tableau de bord parfait que personne ne consulte.
Avertissement d'usage : les métriques DORA sont conçues pour qu'une équipe s'améliore elle-même, pas pour comparer des équipes entre elles ni pour évaluer des individus. Utilisées comme outil de contrôle managérial, elles seront contournées — la loi de Goodhart s'applique pleinement.
Retenir en 30 secondes
- DORA = programme de recherche depuis 2014, livre « Accelerate » (2018), racheté par Google.
- Deux métriques de vitesse : fréquence de déploiement, lead time for changes.
- Deux métriques de stabilité : change failure rate, time to restore service.
- Niveau élite : plusieurs déploiements par jour, lead time inférieur à 1 h, moins de 15 % d'échec, rétablissement en moins d'1 h.
- Résultat contre-intuitif : vitesse et stabilité progressent ensemble, elles ne s'opposent pas.
- Le lead time est souvent dominé par l'attente de revue de code, pas par la durée du pipeline.
- Pyramide des tests : beaucoup d'unitaires, peu d'end-to-end. La pyramide inversée tue les pipelines.
- Secrets : viser l'identité fédérée OIDC, sans aucun secret de longue durée.
- Les métriques servent à s'améliorer, jamais à évaluer des personnes.
Suivant : Cas d'usage réels + FAQ 14 questions →