Imaginez une situation fréquente dans les grandes organisations : une équipe déploie 50 fois par jour avec un taux d'échec de 2 %, tandis qu'une autre, jugée plus « sérieuse » parce qu'elle prend son temps, ne déploie que 2 fois par mois avec un taux d'échec de 35 %. Le management considère pourtant la première comme risquée et la seconde comme exemplaire.
Cette situation absurde révèle un problème fondamental : comment mesurer objectivement la performance d'une équipe de livraison logicielle ? Les métriques traditionnelles (lignes de code, nombre de fonctionnalités, bugs résolus) sont faciles à manipuler et ne reflètent pas la valeur réelle délivrée.
Cette page explique les métriques DORA : leur origine, ce que chacune révèle, les niveaux de performance associés et leur évolution récente, la méthode de collecte, puis un plan d'amélioration pas à pas. Elle s'adresse aux équipes qui veulent remplacer les intuitions par des données.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Comprendre l'origine et la portée des métriques DORA.
- Distinguer les 4 métriques historiques et ce que chacune révèle vraiment.
- Situer votre équipe sur l'échelle de performance et connaître son évolution récente.
- Mettre en place une collecte outillée à partir du CI/CD, des incidents et du monitoring.
- Prioriser un plan d'amélioration sur le goulot d'étranglement principal.
- Éviter les pièges de mesure les plus fréquents (gamification, moyenne contre médiane).
Qu'est-ce que DORA ?
Section intitulée « Qu'est-ce que DORA ? »DORA (DevOps Research and Assessment) est un programme de recherche lancé en 2014 par Nicole Forsgren, Jez Humble et Gene Kim. Leur objectif : identifier par l'enquête et la statistique ce qui distingue les équipes de haute performance des autres, plutôt que de s'appuyer sur des opinions ou des modes.
Selon le rapport DORA 2024, la recherche a interrogé plus de 39 000 professionnels en une décennie, dans des organisations de toutes tailles et de tous secteurs. Les métriques clés qui en sont sorties sont devenues la référence pour mesurer la performance de livraison, reprises par des outils comme GitLab ou Apache DevLake.
Le programme reste actif et continue d'évoluer : son édition 2025 a changé de nom et de méthode d'analyse, signe que la recherche s'affine au lieu de se figer sur un modèle unique. La section sur les niveaux de performance détaille ce tournant.
Quelles sont les 4 métriques DORA ?
Section intitulée « Quelles sont les 4 métriques DORA ? »Les 4 métriques historiques se divisent en deux familles complémentaires : la vitesse de livraison (à quelle rapidité une idée devient du code en production) et la stabilité (à quel point vos déploiements sont fiables). Le schéma résume ce découpage et le constat central de la recherche.
Ce découpage vitesse et stabilité reste le plus enseigné. Le modèle actuel de DORA, présenté en fin de page, range le temps de restauration du côté du débit (throughput) et ajoute un cinquième indicateur d'instabilité : les idées de base, elles, ne changent pas.
Deployment Frequency (DF)
Section intitulée « Deployment Frequency (DF) »Question clé : à quelle fréquence votre organisation déploie-t-elle du code en production ?
Cette métrique mesure le débit de votre chaîne de livraison. Une fréquence élevée traduit en général des changements petits et incrémentaux, un pipeline CI/CD automatisé et une confiance réelle dans le processus de déploiement.
Ce que DF révèle vraiment
Section intitulée « Ce que DF révèle vraiment »Le tableau suivant relie une fréquence de déploiement observée à ce qu'elle révèle généralement sur la maturité du pipeline et sur l'organisation qui le fait tourner. Ce sont des tendances, pas un diagnostic automatique.
| Fréquence | Ce que ça indique |
|---|---|
| Plusieurs fois par jour | Trunk-based development, feature flags, déploiement continu |
| 1 fois par jour à 1 fois par semaine | Bon niveau d'automatisation, quelques processus manuels |
| 1 fois par semaine à 1 fois par mois | Branches longues, tests manuels, approbations multiples |
| Moins d'une fois par mois | Silos, bureaucratie, peur du changement |
Lead Time for Changes (LT)
Section intitulée « Lead Time for Changes (LT) »Question clé : combien de temps s'écoule entre le commit et le déploiement en production ?
Cette métrique mesure la fluidité de votre chaîne de valeur. Un lead time court signifie un feedback rapide sur les changements, des corrections possibles avant que les problèmes ne s'accumulent et une vraie réactivité face aux demandes métier urgentes.
Les composants du Lead Time
Section intitulée « Les composants du Lead Time »Le lead time n'est pas un bloc unique : il se décompose en phases successives, chacune avec ses propres causes de ralentissement et ses propres leviers. La cartographie du flux de valeur aide à mesurer chacune de ces attentes.
| Phase | Facteurs d'allongement | Actions d'amélioration |
|---|---|---|
| Revue de code | Équipe surchargée, merge requests trop grandes | Limiter la taille des changements, revue en binôme |
| CI/CD | Tests lents, builds séquentiels | Parallélisation, cache, tests sélectifs |
| Préproduction | Environnement instable, tests manuels | Tests automatisés, infrastructure as code |
| Déploiement | Fenêtres de release, approbations | Déploiement continu, feature flags |
Change Failure Rate (CFR)
Section intitulée « Change Failure Rate (CFR) »Question clé : quel pourcentage de déploiements provoque un incident en production ?
Cette métrique mesure la qualité de vos déploiements. Un CFR bas reflète en général des tests automatisés efficaces, des revues de code sérieuses et des changements bien dimensionnés.
Qu'est-ce qu'un « échec » ?
Section intitulée « Qu'est-ce qu'un « échec » ? »Pour que la métrique reste cohérente dans le temps, définissez clairement ce qui constitue un échec, puis tenez-vous-y. Le tableau propose une convention de départ répandue chez les praticiens, pas une définition officielle de DORA.
| Inclus dans le CFR | Exclu du CFR |
|---|---|
| Rollback nécessaire | Bug cosmétique sans impact |
| Correctif d'urgence déployé dans les 24 h | Feature flag désactivé volontairement |
| Incident créé (P1, P2) | Panne d'infrastructure sans lien avec le changement |
| Dégradation de performance au-delà du seuil | Amélioration planifiée qui révèle un bug existant |
La formule est simple : CFR = (déploiements ayant causé un incident / total des déploiements) × 100. Exemple : sur 100 déploiements ce mois-ci, 8 ont nécessité un rollback ou un correctif, soit un CFR de 8 %.
Time to Restore Service (MTTR)
Section intitulée « Time to Restore Service (MTTR) »Question clé : combien de temps faut-il pour restaurer le service après un incident en production ?
Cette métrique mesure la résilience de votre organisation. Un temps de restauration court suppose une détection rapide (monitoring, alertes), un processus d'incident rodé, la capacité à revenir en arrière vite et une culture blameless qui encourage la remontée d'information.
En 2023, DORA a renommé et redéfini cette métrique en Failed Deployment Recovery Time, pour la limiter aux pannes causées par un déploiement et l'isoler des pannes d'infrastructure externes. Le sigle MTTR reste le terme le plus répandu dans les outils : cette page l'emploie par cohérence avec ce vocabulaire courant.
Les phases de la restauration
Section intitulée « Les phases de la restauration »Comme le lead time, le temps de restauration se décompose en phases distinctes. Savoir laquelle traîne le plus évite d'investir dans le mauvais outil, par exemple améliorer les runbooks alors que le vrai goulot est la détection.
| Phase | Description | Optimisation |
|---|---|---|
| TTD (Time to Detect) | Délai avant qu'on sache qu'il y a un problème | Monitoring synthétique, alertes sur les SLO |
| TTAck (Time to Acknowledge) | Délai avant qu'un humain prenne en charge | Rotation d'astreinte claire, escalade automatique |
| TTF (Time to Fix) | Temps de diagnostic et de correction | Runbooks, observabilité, logs structurés |
| TTDep (Time to Deploy) | Délai pour déployer le correctif | Pipelines rapides, rollback automatisé |
| TTVer (Time to Verify) | Confirmation que l'incident est résolu | Tests de fumée, surveillance après déploiement |
Quels sont les niveaux de performance DORA ?
Section intitulée « Quels sont les niveaux de performance DORA ? »Jusqu'en 2024, le rapport annuel classait les équipes en 4 niveaux (Elite, High, Medium, Low) construits par regroupement statistique des réponses. Ce modèle reste la meilleure porte d'entrée pour situer une équipe, même si DORA l'a abandonné en 2025. Le schéma reprend les valeurs du rapport 2024, détaillées niveau par niveau ci-dessous.
Niveau Elite
Section intitulée « Niveau Elite »Ce niveau représente un objectif de long terme, pas un point de départ réaliste pour la majorité des équipes. Il sert surtout de référence pour visualiser ce qu'autorise un système de livraison mature, une fois les principaux freins manuels éliminés.
| Métrique | Valeur (rapport 2024) |
|---|---|
| Deployment Frequency | À la demande, plusieurs fois par jour |
| Lead Time for Changes | Moins d'un jour |
| Change Failure Rate | Autour de 5 % |
| Time to Restore | Moins d'une heure |
Les équipes Elite partagent quelques traits récurrents : trunk-based development avec feature flags, tests automatisés fiables sur les chemins critiques, déploiement continu sans intervention manuelle, monitoring proactif et culture d'apprentissage sans recherche de coupable.
Niveau High
Section intitulée « Niveau High »Ce niveau regroupe des équipes qui ont déjà investi dans l'automatisation, sans avoir éliminé tous les freins manuels restants (approbations, tests partiellement automatisés). C'est souvent le palier le plus atteignable pour une équipe qui sort du niveau Medium.
| Métrique | Valeur (rapport 2024) |
|---|---|
| Deployment Frequency | 1 fois par jour à 1 fois par semaine |
| Lead Time for Changes | Entre 1 jour et 1 semaine |
| Change Failure Rate | Autour de 20 % |
| Time to Restore | Moins d'un jour |
Pour passer de High à Elite, les leviers habituels sont d'éliminer les approbations manuelles restantes, d'investir dans l'observabilité (traces distribuées), de réduire la taille des changements et d'automatiser les rollbacks.
Niveau Medium
Section intitulée « Niveau Medium »Ce niveau intermédiaire rassemble le plus grand nombre de répondants en 2024 (35 %). L'automatisation existe, mais reste partielle : les branches longues et les créneaux de release fixes freinent encore le rythme, sans plonger l'organisation dans les rituels manuels du niveau Low.
| Métrique | Valeur (rapport 2024) |
|---|---|
| Deployment Frequency | 1 fois par semaine à 1 fois par mois |
| Lead Time for Changes | Entre 1 semaine et 1 mois |
| Change Failure Rate | Autour de 10 % |
| Time to Restore | Moins d'un jour |
Fait notable du rapport 2024 : le niveau Medium affichait un taux d'échec inférieur (environ 10 %) à celui du niveau High (environ 20 %), alors même qu'il déploie moins souvent. Cette bascule montre que ces niveaux sont des photographies annuelles, pas des lois immuables.
Pour passer de Medium à High, on automatise les tests d'intégration, on réduit les branches de longue durée, on met en place le déploiement continu et des environnements éphémères.
Niveau Low
Section intitulée « Niveau Low »Ce niveau caractérise des organisations où chaque déploiement reste un événement redouté, souvent entouré de validations manuelles. Le reconnaître honnêtement, plutôt que le nier, est la première étape avant toute amélioration.
| Métrique | Valeur (rapport 2024) |
|---|---|
| Deployment Frequency | 1 fois par mois à 1 fois tous les 6 mois |
| Lead Time for Changes | Entre 1 et 6 mois |
| Change Failure Rate | Autour de 40 % |
| Time to Restore | Entre 1 semaine et 1 mois |
Les signaux d'alarme sont reconnaissables : des « big bang releases » trimestrielles ou annuelles, des tests surtout manuels, une peur généralisée des déploiements et des incidents qui durent des semaines.
Le tournant 2025 : sept profils d'équipe remplacent les 4 niveaux
Section intitulée « Le tournant 2025 : sept profils d'équipe remplacent les 4 niveaux »Avec le rapport DORA 2025, le programme a renommé son rapport annuel « State of AI-assisted Software Development » et retiré le modèle Elite/High/Medium/Low au profit de sept profils d'équipe, construits à partir de huit mesures combinant débit, stabilité, performance produit, efficacité individuelle, temps consacré au travail utile, friction et risque d'épuisement.
Ce changement n'est pas cosmétique. La recherche 2025 constate que l'IA générative amplifie les dynamiques existantes plutôt qu'elle ne les corrige : une équipe solide progresse encore plus vite avec l'IA, une équipe fragile voit ses problèmes s'aggraver. Les profils portent des noms parlants comme « Legacy Bottleneck » (bloquée par la dette technique) ou « Harmonious High-Achievers » (performance et bien-être alignés).
Pour un lecteur qui découvre le sujet, le modèle à 4 niveaux reste la meilleure première grille de lecture : il est simple, largement documenté et encore utilisé par la plupart des outils de mesure. Sachez seulement que le rapport DORA le plus récent ne publie plus ces catégories.
Comment collecter les métriques DORA ?
Section intitulée « Comment collecter les métriques DORA ? »La collecte des métriques DORA agrège plusieurs sources : le pipeline de livraison ne suffit pas à lui seul, il faut croiser les incidents et le monitoring pour obtenir des chiffres fiables. Le schéma montre d'où vient chaque donnée et où elle se consolide.
Sources de données par métrique
Section intitulée « Sources de données par métrique »Chaque métrique se nourrit d'une combinaison différente d'outils. Repérer ces sources avant de choisir un outil de mesure évite de découvrir, une fois le projet lancé, qu'une donnée essentielle n'est tout simplement pas exportable.
| Métrique | Sources principales | Données à extraire |
|---|---|---|
| Deployment Frequency | CI/CD (GitLab CI, GitHub Actions, Jenkins) | Horodatage des déploiements réussis |
| Lead Time | Git + CI/CD | Horodatage du commit puis du déploiement |
| Change Failure Rate | CI/CD + gestion d'incidents | Déploiements et incidents corrélés |
| Time to Restore | Gestion d'incidents + monitoring | Ouverture puis résolution de l'incident |
Quels outils pour mesurer DORA ?
Section intitulée « Quels outils pour mesurer DORA ? »Pas besoin de développer votre propre système de mesure : le marché propose des solutions intégrées à votre plateforme Git ou CI/CD, et des solutions open source auto-hébergées. Le choix dépend surtout de votre budget et de votre tolérance à l'auto-hébergement.
Côté solutions intégrées, GitLab fournit des tableaux de bord DORA prêts à l'emploi dans son offre Ultimate. GitHub n'affiche pas les quatre métriques en natif : on les obtient par un outil tiers ou par le connecteur GitHub de DevLake. Des plateformes d'engineering intelligence comme Sleuth ou Harness Software Engineering Insights (ex-Propelo) les calculent à partir de plusieurs sources.
Côté open source, Apache DevLake collecte les données de nombreux outils et fournit un tableau de bord DORA intégré : c'est la référence actuelle en auto-hébergé. Four Keys, le projet initialement porté par Google, a été archivé en janvier 2024 et n'est plus maintenu : ne le choisissez pas pour un projet neuf.
Comment améliorer ses métriques DORA ?
Section intitulée « Comment améliorer ses métriques DORA ? »L'amélioration suit un cycle court centré sur un seul goulot à la fois : mesurer, identifier, fixer un objectif, agir, vérifier, puis passer au goulot suivant. Le schéma montre la boucle, les étapes détaillent ce que chacune demande.
-
Établir une baseline (semaines 1-2)
Avant toute amélioration, mesurez votre état actuel : nombre de déploiements ce mois-ci, délai médian du commit à la production, nombre de rollbacks et de correctifs, temps moyen de résolution des incidents P1/P2. Une estimation honnête suffit pour commencer.
-
Identifier le goulot d'étranglement (semaine 3)
Analysez quelle métrique pèse le plus sur votre capacité de livraison :
Symptôme Métrique à prioriser « On a peur de déployer » CFR (Change Failure Rate) « Les fonctionnalités mettent des mois à sortir » LT (Lead Time) « On déploie rarement et c'est toujours un événement » DF (Deployment Frequency) « Les incidents durent des jours » MTTR (Time to Restore) -
Définir un objectif SMART (semaine 3)
Exemple d'objectif bien formulé : « Réduire le lead time de 2 semaines à 3 jours d'ici la fin du trimestre, mesuré comme la médiane du temps commit-production sur nos 3 services principaux. »
-
Implémenter des améliorations ciblées (semaines 4-12)
Concentrez-vous sur le goulot identifié :
Métrique Actions à fort impact DF Automatiser les tests, réduire les approbations manuelles LT Limiter la taille des changements, paralléliser les tests CI CFR Ajouter des tests de non-régression, déployer en canary MTTR Écrire des runbooks, améliorer le monitoring -
Mesurer et ajuster (en continu)
Revue hebdomadaire pendant la période d'amélioration : progresse-t-on vers l'objectif ? Les autres métriques régressent-elles ? Quels blocages imprévus sont apparus ?
-
Passer au goulot suivant
Une fois l'objectif atteint, recommencez le cycle avec la prochaine métrique prioritaire.
Scénarios concrets d'amélioration
Section intitulée « Scénarios concrets d'amélioration »Ces trois scénarios reprennent des situations fréquentes : ils montrent comment le diagnostic DORA oriente une action différente selon le point de blocage réel, plutôt qu'une recette générique appliquée à l'aveugle.
Scénario 1 : déploiements fréquents mais instables
Section intitulée « Scénario 1 : déploiements fréquents mais instables »Contexte
Une startup SaaS déploie 10 fois par jour mais avec un CFR de 40 %. Les équipes passent plus de temps à éteindre des feux qu'à développer de nouvelles fonctionnalités.
Le diagnostic est net : la vitesse est là, mais la qualité ne suit pas. Le plan d'action ci-dessous part des incidents réels plutôt que d'une liste de bonnes pratiques.
-
Analyse des causes racines
L'examen des 10 derniers incidents révèle : 6 liés à des cas non testés, 3 à des incompatibilités de données, 1 à une erreur de configuration.
-
Actions immédiates
Ajouter des tests pour les cas manquants identifiés. Rendre les migrations de données réversibles. Valider les configurations en CI.
-
Actions structurelles
Protéger les changements risqués par des feature flags. Déployer en canary (1 %, puis 10 %, puis 100 %). Automatiser une liste de contrôles avant déploiement.
-
Objectif fixé
Ramener le CFR de 40 % à 15 % en 3 mois, sans réduire la fréquence de déploiement.
Scénario 2 : grande entreprise sans baseline
Section intitulée « Scénario 2 : grande entreprise sans baseline »Contexte
Une entreprise de services financiers avec 200 développeurs n'a aucune mesure de ses métriques DORA. Le DSI veut « faire du DevOps » mais ne sait pas par où commencer.
Le diagnostic tient en une phrase : on ne peut pas améliorer ce qu'on ne mesure pas. La première étape n'est donc pas un outil, c'est une baseline, même grossière.
-
Inventaire des systèmes
Cartographier les outils existants : Git (GitHub Enterprise), CI/CD (Jenkins historique et GitHub Actions pour les nouveaux projets), incidents (ServiceNow), monitoring (Datadog).
-
Mesure manuelle initiale
Pour les 5 applications critiques, relever à la main le nombre de déploiements, le délai commit-production et les incidents du dernier trimestre. Résultat typique : DF de 2 par mois, LT de 3 semaines, CFR de 25 %, MTTR de 4 jours.
-
Premier gain rapide : automatiser la mesure
Ajouter un webhook qui enregistre chaque déploiement dans une base centralisée.
-
Choisir un pilote
Sélectionner une seule équipe motivée pour améliorer ses métriques. Un succès visible facilite l'adoption par les autres.
Scénario 3 : conflit vitesse contre qualité
Section intitulée « Scénario 3 : conflit vitesse contre qualité »Contexte
Les développeurs veulent déployer plus souvent. L'équipe QA bloque, faute de tests suffisants. Le management ne sait pas qui a raison.
Le diagnostic : c'est un faux dilemme. DORA l'affirme sans détour, « speed and stability are not tradeoffs » : dans les données, débit et stabilité évoluent ensemble au lieu de s'opposer. Une précision honnête à garder face à un contradicteur : l'enquête est déclarative et établit une corrélation, pas une causalité démontrée. L'argument reste solide, car DORA constate aussi que le secteur d'activité ne prédit pas la performance : on trouve des équipes performantes partout, y compris dans les secteurs régulés.
-
Présenter les données
Montrer les chiffres du rapport DORA 2024 : les équipes Elite déploient 182 fois plus souvent que les équipes Low, avec un CFR 8 fois plus bas et une restauration plus de 2 000 fois plus rapide.
-
Expérience contrôlée
Proposer un pilote de 6 semaines sur un service non critique : déploiement quotidien automatisé, CFR et MTTR mesurés en continu, retour arrière immédiat si le CFR dépasse 20 %.
-
Itération basée sur les données
Si le CFR augmente, ajouter des tests ciblés sur les cas d'échec. S'il reste stable, étendre l'approche progressivement.
-
Résolution du conflit
Les métriques remplacent les opinions. Le débat « vitesse ou qualité » devient « comment améliorer les deux ».
Pièges courants et comment les éviter
Section intitulée « Pièges courants et comment les éviter »Mesurer sans discernement crée autant de dégâts que ne pas mesurer du tout. Les pièges suivants reviennent chez les équipes qui adoptent DORA sans préparation ; les repérer évite des mois de mesure contre-productive.
| Piège | Symptôme | Solution |
|---|---|---|
| Gamification | Équipes qui « trichent » pour améliorer les chiffres | Mesurer pour apprendre, pas pour punir. Pas de prime liée aux métriques. |
| Moyenne contre médiane | Un déploiement de 30 jours masqué par 29 déploiements d'un jour | Utiliser la médiane et les percentiles (P90, P95) |
| Silos de mesure | Chaque équipe mesure différemment | Définir un glossaire commun |
| Oubli du contexte | Comparer une startup à une banque | Se comparer d'abord à soi-même |
| Tout mesurer | Paralysie analytique | Commencer par une approximation, affiner ensuite |
| Valeurs extrêmes ignorées | Incidents majeurs exclus des statistiques | Les analyser à part, sans les effacer |
Au-delà des 4 métriques : comment le modèle a-t-il évolué ?
Section intitulée « Au-delà des 4 métriques : comment le modèle a-t-il évolué ? »Les 4 métriques de départ ont leur propre histoire, et la connaître explique pourquoi la terminologie varie d'une source à l'autre. Le modèle DORA n'a jamais été figé : il s'est enrichi par étapes, au fil des rapports successifs.
En 2018, DORA a ajouté une notion d'availability (disponibilité) pour couvrir la santé opérationnelle au-delà de la seule livraison. En 2021, cette notion a été élargie et renommée Reliability (fiabilité), pour englober aussi la latence, la performance et la scalabilité.
Contrairement aux métriques de livraison, la Reliability ne repose pas sur une formule unique : DORA la définit comme le fait, pour une équipe, de tenir ses propres objectifs de fiabilité, c'est-à-dire ses SLO (Service Level Objectives, les seuils cibles de disponibilité et de performance qu'elle se fixe). Une équipe qui vise 99,9 % de disponibilité et tient ce seuil consomme peu de son error budget (la marge d'échec tolérée avant de geler les nouvelles fonctionnalités).
En 2023, le MTTR a été redéfini en Failed Deployment Recovery Time. Puis en 2024, DORA a ajouté un cinquième indicateur, le Deployment Rework Rate : la part des déploiements qui corrigent en urgence un défaut déjà en production. Le modèle actuel range ainsi ses 5 métriques en deux familles : le Throughput (change lead time, deployment frequency, failed deployment recovery time) et l'Instability (change fail rate, deployment rework rate).
Checklist d'implémentation DORA
Section intitulée « Checklist d'implémentation DORA »Le cycle d'amélioration cible un seul goulot à la fois. Cette checklist couvre le déploiement de la démarche à l'échelle d'une équipe, du premier jour à l'institutionnalisation trimestrielle : l'un donne le rythme d'amélioration, l'autre le calendrier de mise en place.
-
Semaine 1 : baseline
Estimer les 4 métriques actuelles, même approximativement. Identifier les sources de données disponibles. Choisir une équipe pilote.
-
Semaines 2-4 : instrumentation
Automatiser la collecte de DF (déploiements) et de LT (commits et déploiements). Relier les incidents aux déploiements (CFR). Mesurer les temps de résolution (MTTR).
-
Mois 2 : premier cycle d'amélioration
Identifier le goulot principal. Définir un objectif SMART. Mener 2 ou 3 améliorations ciblées. Mesurer l'impact chaque semaine.
-
Trimestre 1 : institutionnalisation
Créer un tableau de bord visible par tous. Instaurer une revue mensuelle des métriques. Documenter les apprentissages. Étendre aux autres équipes.
-
En continu : culture d'amélioration
Pas de recherche de coupable, attention portée au système. Célébrer les progrès plutôt que les chiffres absolus. Partager les réussites comme les échecs.
À retenir
Section intitulée « À retenir »- Les métriques DORA mesurent la performance de livraison sur 4 axes historiques : fréquence de déploiement, lead time, taux d'échec et temps de restauration.
- Elles cassent une fausse intuition : vitesse et stabilité vont de pair. Les équipes Elite déploient plus souvent et échouent moins.
- Depuis 2025, le rapport DORA a remplacé le modèle Elite/High/Medium/Low par 7 profils d'équipe ; le modèle à 4 niveaux reste la meilleure porte d'entrée pédagogique.
- Le modèle actuel compte 5 métriques, dont le Deployment Rework Rate ajouté en 2024, rangées en throughput et instability.
- Ne vous en servez jamais pour comparer ou noter des équipes : elles servent à apprendre, pas à punir.
- Commencez par une baseline approximative, attaquez un seul goulot à la fois, puis itérez.
- La collecte agrège CI/CD, gestion d'incidents et monitoring ; Apache DevLake est la référence open source, Four Keys étant archivé depuis 2024.
- Ne confondez pas ces métriques avec le règlement DORA européen : même sigle, sujets différents.
Contrôle de connaissances
Section intitulée « Contrôle de connaissances »Vérifiez que vous avez retenu l'essentiel de ce guide. Les questions portent uniquement sur ce qui vient d'être expliqué ici.
Contrôle de connaissances
Validez vos connaissances avec ce quiz interactif
Informations
- Le chronomètre démarre au clic sur Démarrer
- Questions à choix multiples, vrai/faux et réponses courtes
- Vous pouvez naviguer entre les questions
- Les résultats détaillés sont affichés à la fin
Lance le quiz et démarre le chronomètre
Vérification
(0/0)Score par domaine
Un domaine regroupe plusieurs guides et reçoit plusieurs questions : son score est plus fiable qu'un score par thème, qui porte souvent sur une seule question.
Bilan
Points forts
Aucun sujet réussi à 80 % sur au moins deux questions pour l’instant.
Points faibles
Aucun sujet sous le seuil de réussite.
À faire ensuite
Des indices pour retenter votre chance ?
Continuer le cours : Mesurer sa posture : les KPI de sécurité
Continuer le cours : OWASP Top 10 CI/CD : les 10 risques de sécurité des pipelines
Nouveau quiz complet avec des questions aléatoires
Retravailler uniquement les questions ratées
Retour à la liste des certifications
FAQ : questions fréquentes
Section intitulée « FAQ : questions fréquentes »Les questions ci-dessous reprennent les doutes les plus fréquents sur les métriques DORA : leur définition, le niveau Elite, la collecte et la confusion avec le règlement européen du même nom.
- Deployment Frequency (DF) : à quelle fréquence vous déployez en production.
- Lead Time for Changes (LT) : délai entre le commit et le déploiement.
- Change Failure Rate (CFR) : pourcentage de déploiements provoquant un incident.
- Time to Restore Service (MTTR) : temps pour restaurer le service, renommé Failed Deployment Recovery Time en 2023.
| Métrique | Valeur Elite |
|---|---|
| Deployment Frequency | À la demande, plusieurs fois par jour |
| Lead Time | Moins d'un jour |
| Change Failure Rate | Autour de 5 % |
| Time to Restore | Moins d'une heure |
- Solutions intégrées : les tableaux de bord DORA de GitLab (offre Ultimate), ou des plateformes comme Sleuth et Harness Software Engineering Insights (ex-Propelo). GitHub n'affiche pas les quatre métriques en natif.
- Open source : Apache DevLake, référence actuelle auto-hébergée.
- Métriques DORA (DevOps Research and Assessment) : les indicateurs de performance de livraison décrits sur cette page.
- Règlement DORA (Digital Operational Resilience Act) : une réglementation européenne sur la résilience opérationnelle du secteur financier (cybersécurité, gestion des risques informatiques).