DORA metrics 2026 : les 4 indicateurs qui mesurent vraiment votre delivery.

Pourquoi les DORA metrics, et pourquoi maintenant

Mesurer la performance d'une équipe d'ingénierie au nombre de lignes de code ou de story points, c'est mesurer la vitesse d'une voiture au bruit du moteur. Les DORA metrics — issues du programme DevOps Research and Assessment de Google et popularisées par le livre Accelerate — proposent autre chose : quatre indicateurs qui regardent ce qui compte vraiment, la capacité de l'équipe à livrer du changement vite et sans tout casser.

Leur force, c'est leur sobriété. Quatre chiffres, deux axes : la vélocité (à quelle vitesse on livre) et la stabilité (à quel point on casse en livrant). Le mythe selon lequel il faudrait choisir entre les deux est faux — les équipes Elite sont à la fois plus rapides ET plus stables. C'est précisément ce que les DORA metrics rendent visible.

Les 4 indicateurs, concrètement

Deux mesurent le débit, deux mesurent la résilience. Pris ensemble, ils racontent toute l'histoire de votre delivery.

• Lead time for changes — le temps entre un commit mergé et sa mise en production. C'est la mesure reine : elle agrège la qualité de votre CI, de vos tests, de vos environnements et de votre process de review. Un lead time qui se compte en heures est le signe d'un pipeline sain.
• Deployment frequency — combien de fois vous déployez en production. Une équipe Elite déploie à la demande, plusieurs fois par jour. Déployer souvent réduit la taille des lots, donc le risque par déploiement. La fréquence n'est pas une fin en soi, c'est la conséquence d'un système qui sait livrer petit.
• Change failure rate — le pourcentage de déploiements qui provoquent un incident (rollback, hotfix, dégradation de service). Il mesure la qualité de ce que vous poussez. Un taux bas obtenu en déployant une fois par mois n'a rien d'impressionnant : il se lit toujours en regard de la fréquence.
• Mean time to restore (MTTR) — le temps moyen pour revenir à la normale après un incident. C'est la métrique d'humilité : elle part du principe que les incidents arrivent, et mesure votre capacité à les encaisser. Un MTTR court est souvent plus précieux qu'un change failure rate nul mais artificiel.

DORA classe les équipes en quatre paliers — Low, Medium, High, Elite. L'intérêt n'est pas de décrocher le badge Elite, mais de savoir où l'on se situe et dans quel sens la tendance pointe. Une équipe qui passe de Low à High en six mois en dit plus long qu'un score figé.

Les instrumenter sans construire une usine à gaz

L'erreur classique : vouloir une plateforme d'observabilité complète avant d'avoir le premier chiffre. On fait l'inverse. La donnée existe déjà, dispersée dans trois sources que vous avez sous la main.

1. Git et la CI/CD pour la vélocité — les timestamps de merge et les événements de déploiement de votre pipeline (GitHub Actions, GitLab CI, ArgoCD) donnent directement lead time et deployment frequency. Aucun outil tiers nécessaire pour démarrer.
2. Le tracker d'incidents pour la stabilité — relier chaque incident au déploiement qui l'a causé permet de calculer change failure rate et MTTR. Une convention de tagging simple sur vos tickets suffit.
3. Un dashboard minimal — un graphe par métrique, lu en tendance hebdomadaire ou mensuelle. C'est tout. Les outils dédiés (LinearB, Swarmia, Sleuth) ont leur place une fois la culture installée, pas avant.

La règle Abbeal : on instrumente d'abord ce qui se déduit du pipeline existant, on ajoute de l'outillage seulement quand l'équipe lit ses chiffres chaque semaine et veut aller plus loin. Un dashboard qu'on regarde vaut mieux qu'une plateforme qu'on a oubliée.

Les pièges : vanity metrics et gaming

Le jour où une métrique devient un objectif, elle cesse d'être une bonne métrique — c'est la loi de Goodhart, et les DORA metrics n'y échappent pas. Quelques travers à connaître avant de les afficher partout.

• La fréquence isolée est une vanity metric. Déployer 40 fois par jour ne dit rien si la moitié des déploiements sont des hotfixes. La fréquence ne se lit jamais sans le change failure rate en face.
• Le gaming arrive vite. Découper artificiellement les PR pour gonfler la fréquence, ne pas déclarer les petits incidents pour préserver le change failure rate : ce sont des réflexes humains dès qu'on transforme un chiffre en évaluation individuelle.
• Jamais au niveau de l'individu. Les DORA metrics se lisent par équipe, par produit, sur une tendance. Les utiliser pour noter ou comparer des développeurs détruit la confiance et la qualité des données en quelques semaines.
• Une photo n'est pas un film. Un chiffre à un instant T ne vaut rien. Ce qui compte, c'est la direction : est-ce que ça s'améliore, et qu'est-ce qui bloque la prochaine marche ?

Le vrai sujet : le lien avec la performance produit

Les DORA metrics ne sont pas un concours d'ingénierie. Leur intérêt business, c'est qu'elles corrèlent avec la performance de l'organisation : les équipes qui livrent vite et stable raccourcissent leur boucle de feedback produit. Elles testent une idée, mesurent, ajustent — plusieurs fois par semaine plutôt qu'une fois par trimestre.

Un lead time court n'est pas un luxe technique : c'est la vitesse à laquelle votre produit apprend de ses utilisateurs. Un MTTR maîtrisé, c'est la confiance de pouvoir tenter quelque chose sans risquer la maison. C'est ce qui fait des DORA metrics un langage commun entre l'engineering et le produit, là où les story points ne parlent qu'aux ingénieurs.

Au-delà des 4 clés : reliability et SPACE

Les quatre métriques mesurent le débit et la stabilité de la livraison — pas la fiabilité opérationnelle perçue, ni la valeur réellement produite, ni la santé de l'équipe. DORA a depuis ajouté une cinquième dimension, la reliability (la capacité à tenir ses objectifs de service, dans la lignée des SLO/SLI), pour combler l'angle mort du fonctionnement en production.

Et pour ce que les quatre clés ne voient pas — la satisfaction, la collaboration, la charge cognitive — le framework SPACE est le complément naturel. Les DORA metrics restent le meilleur point de départ : on commence par elles, on élargit ensuite, jamais l'inverse.

Comment Abbeal s'en sert sur ses squads

Chez Abbeal, les DORA metrics sont l'instrument de bord par défaut quand on prend en charge un périmètre. Sur du staff augmentation comme sur du delivery clé en main, c'est le langage qui aligne l'équipe et le client sur une réalité chiffrée plutôt que sur une impression.

Notre modèle Follow-the-Sun — des hubs synchronisés à Paris, Montréal et Tokyo — ajoute une exigence : une roadmap qui avance 24h/24 ne tient que si les handoffs sont propres et la livraison continue. Lead time et deployment frequency sont précisément les chiffres qui révèlent si l'overlap entre fuseaux fonctionne ou s'il crée des files d'attente cachées.

On l'a vu sur des contextes exigeants — banque, retail à fort trafic — où chaque déploiement compte et où un incident se mesure en euros. Sur une scale-up mobilité avec hubs Montréal/Paris, le travail sur l'observabilité et l'infra (côté GreenOps) s'est traduit par -30% de coûts infra et une meilleure résilience : autant de gains que les DORA metrics rendent lisibles et défendables face au métier.

Notre conviction : les DORA metrics ne sont pas un tableau de bord pour rassurer le management, c'est un outil d'ingénieur pour décider quoi améliorer ensuite. Vous voulez auditer la santé delivery d'une squad ou mettre en place ce pilotage sur un périmètre critique ? C'est exactement le genre de chantier qu'on mène. Pour la définition courte et les paliers Low/Medium/High/Elite, voir aussi notre fiche glossaire DORA metrics : /fr/glossaire/dora.