Les indicateurs DORA sont la référence internationale pour mesurer la performance de livraison d’une équipe de développement. Ils répondent à deux questions simples : à quelle vitesse l’équipe met-elle ses changements entre les mains des utilisateurs, et avec quelle fiabilité ? Les quatre indicateurs historiques sont la fréquence de déploiement, le délai de mise en production, le taux d’échec des changements et le temps de rétablissement. Ils s’appliquent aussi bien à une équipe interne qu’à une agence, et se calculent à partir de données déjà disponibles.
Pour un dirigeant, leur intérêt est double : disposer d’un langage commun avec l’équipe technique, et détecter tôt une dérive (livraisons qui ralentissent, incidents qui se multiplient) avant qu’elle ne se traduise par des retards de projet.
D’où viennent les indicateurs DORA ?
DORA (DevOps Research and Assessment) est un programme de recherche aujourd’hui rattaché à Google Cloud. Depuis plusieurs années, il interroge des professionnels du développement du monde entier et publie chaque année le rapport Accelerate State of DevOps. Les indicateurs ont été popularisés par le livre Accelerate de Nicole Forsgren, Jez Humble et Gene Kim.
Le constat central de ces travaux est contre-intuitif. Le guide officiel de DORA le résume ainsi : la vitesse et la stabilité ne sont pas des compromis. Les équipes qui livrent le plus souvent sont aussi, en général, celles qui cassent le moins. La raison : des livraisons fréquentes sont petites, donc plus faciles à tester, à comprendre et à annuler.
Attention à l’homonymie : le règlement européen DORA (Digital Operational Resilience Act) concerne la résilience numérique du secteur financier. Il n’a aucun lien avec les indicateurs présentés ici.
Les indicateurs DORA, un par un
Les indicateurs de débit (vitesse)
Le délai de mise en production d’un changement (change lead time) est le temps écoulé entre l’enregistrement d’une modification dans le gestionnaire de code et son déploiement en production. Il mesure la fluidité du circuit : relecture, tests, validation, déploiement.
La fréquence de déploiement (deployment frequency) est le nombre de mises en production sur une période, ou le temps moyen entre deux mises en production.
Le temps de rétablissement après un déploiement raté (failed deployment recovery time) est le temps nécessaire pour revenir à un service normal après un déploiement qui a exigé une intervention immédiate. DORA a fait évoluer cet indicateur, autrefois appelé MTTR (temps moyen de rétablissement), pour le centrer sur les incidents causés par des déploiements.
Les indicateurs d’instabilité
Le taux d’échec des changements (change fail rate) est la part des déploiements qui nécessitent une intervention immédiate, le plus souvent un retour arrière ou un correctif en urgence.
Le taux de reprise des déploiements (deployment rework rate) est le cinquième indicateur ajouté par DORA : la part des déploiements non planifiés, réalisés pour corriger un incident en production. Il révèle une équipe qui passe son temps à réparer plutôt qu’à construire.
| Indicateur | Question à laquelle il répond | Ce qu’un mauvais résultat révèle souvent |
|---|---|---|
| Délai de mise en production | Combien de temps entre « c’est codé » et « c’est utilisable » ? | Validations manuelles, attentes, lots trop gros |
| Fréquence de déploiement | À quel rythme livre-t-on ? | Déploiement manuel et risqué, peur de livrer |
| Temps de rétablissement | Combien de temps dure une panne causée par une livraison ? | Retour arrière non prévu, supervision insuffisante |
| Taux d’échec des changements | Quelle part des livraisons pose problème ? | Tests insuffisants, recette trop tardive |
| Taux de reprise | Quelle part du travail sert à éteindre des incendies ? | Dette technique, qualité dégradée |
Quels sont les repères de performance ?
Chaque année, DORA regroupe les répondants en profils de performance. D’après la synthèse publiée par Octopus Deploy à partir du rapport 2024, les repères sont les suivants :
| Profil | Délai de mise en production | Fréquence de déploiement | Taux d’échec | Temps de rétablissement |
|---|---|---|---|---|
| Élite | Moins d’un jour | À la demande | 5 % | Moins d’une heure |
| Élevé | Un jour à une semaine | Quotidienne à hebdomadaire | 20 % | Moins d’un jour |
| Moyen | Une semaine à un mois | Hebdomadaire à mensuelle | 10 % | Moins d’un jour |
| Faible | Un à six mois | Mensuelle à semestrielle | 40 % | Une semaine à un mois |
Deux remarques pour bien lire ce tableau. D’abord, en 2024, le profil « élevé » affiche un taux d’échec supérieur au profil « moyen » : la hiérarchie n’est pas parfaitement linéaire, et c’est un rappel que ces groupes décrivent des populations, pas des paliers à atteindre. Ensuite, la même synthèse indique que le groupe élite représente moins de 20 % des organisations interrogées.
Pour une application métier de PME ou d’ETI, viser le profil élite n’a pas toujours de sens. Une application de gestion des stocks utilisée par quarante personnes n’a pas besoin de dix déploiements par jour. En revanche, un délai de plusieurs mois entre une correction et sa mise en production, ou une livraison sur trois qui pose problème, sont des signaux d’alerte quel que soit le contexte.
Les pièges à éviter
Le guide DORA consacre une section entière aux erreurs courantes. Elles sont particulièrement importantes pour un dirigeant, parce que ce sont des erreurs de management plus que des erreurs techniques.
- Transformer les indicateurs en objectifs imposés. Dès qu’un chiffre devient une cible, il est contourné : c’est la loi de Goodhart. Une équipe sommée de déployer plus souvent peut découper artificiellement ses livraisons sans rien améliorer.
- Ne regarder qu’un seul indicateur. La fréquence de déploiement seule pousse à livrer vite au détriment de la qualité ; le taux d’échec seul pousse à ne plus rien livrer. Les indicateurs se lisent ensemble, en tension.
- Comparer des équipes ou des applications différentes. Un portail client et un module de paie n’ont ni les mêmes contraintes ni les mêmes rythmes.
- Répartir les indicateurs entre équipes cloisonnées. Confier la vitesse aux développeurs et la stabilité à l’exploitation crée des reproches mutuels ; DORA recommande une responsabilité partagée.
- Se servir du secteur comme excuse. Une activité réglementée n’interdit pas de livrer souvent ; elle impose de livrer de façon tracée.
- Mesurer au lieu d’améliorer. Construire un tableau de bord sophistiqué avant d’avoir changé quoi que ce soit est une perte de temps.
Comment démarrer dans une PME ou une ETI ?
La démarche la plus efficace est aussi la plus légère.
- Choisir une application : celle qui compte le plus pour l’activité, ou celle dont les livraisons posent problème. DORA précise que les indicateurs s’appliquent au niveau d’une application ou d’un service.
- Faire une première estimation à partir de l’historique des trois derniers mois : nombre de mises en production, incidents liés à une livraison, durée de ces incidents. Le Quick Check de DORA donne un premier positionnement en quelques minutes.
- Identifier le principal frein : souvent un déploiement manuel, une recette concentrée en fin de projet ou l’absence de tests automatisés.
- Lancer une action d’amélioration ciblée, puis remesurer au trimestre suivant.
- Partager les résultats avec l’équipe et le métier, sans classement ni sanction.
Les leviers d’amélioration sont bien documentés : livraisons plus petites, déploiement automatisé, mise en production progressive avec retour arrière rapide, et une maintenance qui traite la dette au fil de l’eau. Le livre SRE de Google rappelle d’ailleurs qu’environ 70 % des pannes proviennent de changements apportés à un système en fonctionnement : sécuriser les livraisons agit directement sur la stabilité.
Ce que ces indicateurs disent d’un prestataire
Si vous faites développer une application par une agence, les indicateurs DORA sont un excellent sujet de discussion, dès la sélection puis tout au long du projet. Quelques questions utiles :
- À quelle fréquence mettez-vous en production sur un projet comme le nôtre ?
- Combien de temps faut-il pour qu’une correction urgente arrive en production ?
- Comment revenez-vous en arrière si une livraison pose problème, et l’avez-vous déjà fait ?
- Suivez-vous la part de vos livraisons qui nécessitent une correction immédiate ?
Un prestataire qui répond précisément, chiffres ou exemples à l’appui, a l’habitude de piloter sa qualité. Ces questions complètent celles de notre guide pour choisir une agence de développement web, et elles éclairent aussi le volet maintenance et TMA du contrat.
Et l’IA dans tout cela ?
Le rapport DORA 2024 apporte un éclairage intéressant : l’adoption de l’IA améliore la productivité individuelle et la satisfaction des développeurs, mais elle a un effet négatif sur la stabilité et le débit de livraison. Les auteurs y voient la confirmation que les fondamentaux restent décisifs : petits lots, tests solides, revue de code. Écrire du code plus vite ne sert à rien si on le livre en gros paquets mal testés.
C’est précisément là que les indicateurs DORA prennent tout leur sens : ils permettent de vérifier qu’un gain de productivité apparent se traduit vraiment par des livraisons plus rapides et plus fiables pour les utilisateurs.
En résumé
Les indicateurs DORA ne sont ni un classement ni un outil de contrôle. Ce sont quelques mesures simples, à suivre dans le temps, qui disent si votre équipe livre de plus en plus vite et de plus en plus sûrement. Bien utilisés, ils transforment des débats d’impression (« ça avance lentement », « ça casse tout le temps ») en discussions factuelles.
Vous souhaitez faire le point sur la façon dont votre application est livrée et maintenue, ou lancer un projet avec une cadence de livraison claire dès le départ ? Présentez votre situation dans notre diagnostic de projet en ligne, et nous revenons vers vous avec une première analyse. Pour aller plus loin, notre méthode détaille comment nous livrons et démontrons chaque incrément.
