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 features, bugs résolus) sont facilement manipulables et ne reflètent pas la valeur réelle délivrée.
Cette page explique les métriques DORA : leur origine scientifique, ce que chacune révèle, les niveaux de performance associés (et leur évolution récente), la méthode pour les collecter, et 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 scientifique 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 vs 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 scientifiquement ce qui distingue les équipes de haute performance des autres, plutôt que de s'appuyer sur des opinions ou des modes.
Après avoir analysé les pratiques de plus de 32 000 professionnels dans des milliers d'organisations sur plusieurs années, ils ont identifié des métriques clés qui prédisent la performance de livraison logicielle. Ces métriques sont devenues la référence mondiale pour mesurer la maturité DevOps, reprises par des outils comme GitLab, GitHub ou des plateformes dédiées.
Le programme reste actif et continue d'évoluer : sa dernière édition (2025) a changé de nom et de méthode d'analyse, un signe que la recherche continue à s'affiner plutôt qu'à se figer sur un modèle unique. Cette évolution est détaillée plus loin, dans la section sur les niveaux de performance.
Les 4 métriques DORA expliquées
Section intitulée « Les 4 métriques DORA expliquées »
Les 4 métriques historiques se divisent en deux catégories complémentaires :
- Vitesse de livraison : à quelle rapidité pouvez-vous transformer une idée en code en production ?
- Stabilité : quelle est la fiabilité de vos déploiements ?
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 pipeline de livraison. Une fréquence élevée indique :
- Des changements petits et incrémentaux (plus faciles à tester et reverter)
- Un pipeline CI/CD automatisé et fiable
- Une confiance élevée 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 l'organisation qui le fait tourner :
| Fréquence | Ce que ça indique |
|---|---|
| Multiple fois/jour | Trunk-based development, feature flags, déploiement continu |
| 1x/jour à 1x/semaine | Bon niveau d'automatisation, quelques processus manuels |
| 1x/semaine à 1x/mois | Branches longues, tests manuels, approbations multiples |
| Moins de 1x/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 premier commit et le déploiement en production ?
Cette métrique mesure la fluidité de votre chaîne de valeur. Un lead time court signifie :
- Feedback rapide sur les changements
- Corrections possibles avant que les problèmes ne s'accumulent
- Agilité 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 plusieurs phases successives, chacune avec ses propres causes de ralentissement et ses propres leviers d'amélioration.
| Phase | Facteurs d'allongement | Actions d'amélioration |
|---|---|---|
| Code Review | Équipe surchargée, PRs trop grandes | Limiter taille PRs, review en pair |
| CI/CD | Tests lents, builds séquentiels | Parallélisation, cache, tests sélectifs |
| Staging | Environnement instable, tests manuels | Tests automatisés, infrastructure as code |
| Deploy | 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 indique :
- Tests automatisés efficaces
- Code reviews rigoureuses
- Changements bien dimensionnés
Qu'est-ce qu'un "échec" ?
Section intitulée « Qu'est-ce qu'un "échec" ? »Pour être cohérent, définissez clairement ce qui constitue un échec :
| Inclus dans CFR | Exclus de CFR |
|---|---|
| Rollback nécessaire | Bug cosmétique sans impact |
| Hotfix déployé dans les 24h | Feature flag désactivée volontairement |
| Incident créé (P1, P2) | Problème infrastructure non lié au code |
| Dégradation de performance supérieure au seuil | Amélioration planifiée qui révèle un bug existant |
Formule : CFR = (Déploiements ayant causé un incident / Total déploiements) × 100
Exemple : Sur 100 déploiements ce mois-ci, 8 ont nécessité un rollback ou un hotfix, 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 MTTR court indique :
- Détection rapide des problèmes (monitoring, alerting)
- Processus d'incident bien rodés
- Capacité à rollback ou hotfix rapidement
- Culture blameless qui encourage la remontée d'info
En 2023, DORA a officiellement renommé et redéfini cette métrique en Failed Deployment Recovery Time, pour distinguer un incident causé par un changement d'une panne d'infrastructure externe sans rapport avec un déploiement. Le sigle MTTR reste toutefois le terme le plus répandu dans l'industrie et les outils : cette page l'emploie par cohérence avec le 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 dans votre organisation é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 proactives |
| TTAck (Time to Acknowledge) | Délai avant qu'un humain prenne en charge | Rotation on-call claire, escalade automatique |
| TTF (Time to Fix) | Temps de diagnostic et correction | Runbooks, observabilité, logs structurés |
| TTDep (Time to Deploy) | Délai pour déployer le fix | Pipelines rapides, rollback automatisé |
| TTVer (Time to Verify) | Confirmation que c'est résolu | Tests de smoke, monitoring post-deploy |
Niveaux de performance DORA
Section intitulée « Niveaux de performance DORA »Le rapport State of DevOps a longtemps classé les organisations en 4 niveaux basés sur leurs métriques. Ce modèle reste la meilleure porte d'entrée pour situer une équipe débutante, même si la recherche DORA elle-même a fait évoluer son cadre d'analyse en 2025 (voir plus bas).
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 |
|---|---|
| Deployment Frequency | Multiple fois par jour, à la demande |
| Lead Time for Changes | Moins d'une heure |
| Change Failure Rate | Autour de 5 % |
| Time to Restore | Moins d'une heure |
Caractéristiques des équipes Elite :
- Trunk-based development avec feature flags
- Tests automatisés avec plus de 80 % de couverture significative
- Déploiement continu sans intervention humaine
- Monitoring et alerting proactifs
- Culture blameless et apprentissage continu
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 |
|---|---|
| Deployment Frequency | 1 fois par jour à 1 fois par semaine |
| Lead Time for Changes | Entre 1 heure et 1 jour |
| Change Failure Rate | Ordre de grandeur : 15-20 % |
| Time to Restore | Moins d'un jour |
Pour passer de High à Elite :
- Éliminer les approbations manuelles restantes
- Investir dans l'observabilité (traces distribuées)
- Réduire la taille des changements
- Automatiser les rollbacks
Niveau Medium
Section intitulée « Niveau Medium »Ce niveau intermédiaire concentre historiquement le plus grand nombre d'équipes observées par la recherche DORA. L'automatisation existe, mais reste partielle : les branches longues et les créneaux de release fixes freinent encore le rythme de livraison, sans pour autant plonger l'organisation dans les rituels manuels du niveau Low.
| Métrique | Valeur |
|---|---|
| Deployment Frequency | 1 fois par semaine à 1 fois par mois |
| Lead Time for Changes | Entre 1 jour et 1 semaine |
| Change Failure Rate | Ordre de grandeur : 15-20 % |
| Time to Restore | Moins d'une semaine |
Fait notable observé dans le rapport 2024 : pour la première fois, le cluster Medium affichait un taux d'échec inférieur au cluster High. Ce genre de bascule illustre pourquoi DORA insiste sur le fait que ces niveaux sont des photographies annuelles, pas des lois immuables.
Pour passer de Medium à High :
- Automatiser les tests d'intégration
- Réduire les branches de longue durée
- Implémenter le déploiement continu
- Mettre en place 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 rituels de validation manuels. Reconnaître honnêtement ce niveau, plutôt que le nier, est la première étape avant toute amélioration.
| Métrique | Valeur |
|---|---|
| Deployment Frequency | Moins d'une fois par mois |
| Lead Time for Changes | Plus d'un mois |
| Change Failure Rate | Nettement supérieur aux autres niveaux |
| Time to Restore | Plus d'un mois |
Signaux d'alarme du niveau Low :
- "Big bang releases" trimestrielles ou annuelles
- Tests principalement manuels
- Peur généralisée des déploiements
- 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 en "State of AI-assisted Software Development" et retiré le modèle Elite/High/Medium/Low au profit de sept profils d'équipe ("archétypes"), construits à partir de huit mesures combinant débit, stabilité, performance produit, efficacité individuelle, temps consacré au travail à valeur ajoutée, friction et risque d'épuisement.
Ce changement n'est pas cosmétique. La recherche 2025 constate que l'intelligence artificielle générative amplifie les dynamiques existantes plutôt qu'elle ne les corrige : une équipe déjà solide progresse encore plus vite avec l'IA, tandis qu'une équipe fragile voit ses problèmes s'aggraver. Les archétypes portent des noms parlants comme "Legacy Bottleneck" (bloquée par la dette technique) ou "Harmonious High Achiever" (performance et bien-être alignés), à l'opposé d'un simple classement à 4 cases.
Pour un lecteur qui découvre le sujet, le modèle historique à 4 niveaux reste la meilleure première grille de lecture : il est simple, largement documenté et encore utilisé par la quasi-totalité des outils de mesure DORA. Gardez simplement à l'esprit que si vous consultez le rapport DORA le plus récent, vous n'y retrouverez plus les catégories Elite/High/Medium/Low telles que décrites ci-dessus.
Comment collecter les métriques DORA
Section intitulée « Comment collecter les métriques DORA »
La collecte des métriques DORA nécessite d'agréger des données de plusieurs sources : le pipeline de livraison ne suffit pas à lui seul, il faut aussi croiser les incidents et le monitoring pour obtenir des chiffres fiables.
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, GitHub Actions, Jenkins) | Timestamp des déploiements réussis |
| Lead Time | VCS + CI/CD | Timestamp commit → timestamp deploy |
| Change Failure Rate | CI/CD + Incident Management | Déploiements + incidents corrélés |
| Time to Restore | Incident Management + Monitoring | Création incident → résolution |
Outils de mesure DORA
Section intitulée « Outils de mesure DORA »Pas besoin de développer votre propre système de mesure : le marché propose des solutions intégrées (directement dans 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.
Solutions intégrées :
- GitLab DORA Metrics (Ultimate) : intégré nativement avec tableaux de bord prêts à l'emploi
- GitHub Insights (Enterprise) : métriques de base avec intégration GitHub Actions
- Sleuth : spécialisé DORA, multi-source (GitHub, GitLab, Jira, PagerDuty)
- Harness Software Engineering Insights (ex-Propelo, ex-LevelOps) : plateforme d'engineering intelligence qui inclut les métriques DORA parmi d'autres indicateurs
Solutions open source :
- DevLake (Apache) : collecte multi-sources, dashboard DORA intégré, référence actuelle pour une solution auto-hébergée
- Four Keys (initialement porté par Google) : le dépôt a été archivé début 2024 et n'est plus maintenu ; préférez DevLake ou un outil intégré pour un projet neuf
Implémenter DORA : approche pratique
Section intitulée « Implémenter DORA : approche pratique »
-
Établir une baseline (Semaines 1-2)
Avant toute amélioration, mesurez votre état actuel. Répondez à ces questions :
- Combien de déploiements ce mois-ci ?
- Délai moyen commit → production ?
- Combien de rollbacks/hotfixes ?
- Temps moyen de résolution des incidents P1/P2 ?
Ne cherchez pas la précision parfaite : une estimation honnête suffit pour commencer.
-
Identifier le goulot d'étranglement (Semaine 3)
Analysez quelle métrique a le plus d'impact sur votre capacité de livraison :
Symptôme Métrique à prioriser "On a peur de déployer" CFR (Change Failure Rate) "Les features mettent des mois à sortir" LT (Lead Time) "On déploie rarement mais 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-to-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 taille des PRs, paralléliser les tests CI CFR Ajouter des tests de non-régression, implémenter canary deploys MTTR Créer des runbooks, améliorer le monitoring -
Mesurer et ajuster (Continu)
Revue hebdomadaire des métriques pendant la période d'amélioration :
- Est-ce qu'on progresse vers l'objectif ?
- Les autres métriques ne régressent-elles pas ?
- Quels blocages imprévus avons-nous rencontrés ?
-
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 en organisation : 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 features.
Diagnostic : la vitesse est là, mais la qualité ne suit pas.
-
Analyse des causes racines
Examiner les 10 derniers incidents révèle : 6 liés à des cas non testés, 3 liés à des incompatibilités de données, 1 lié à une erreur de configuration.
-
Actions immédiates
Ajouter des tests pour les cas manquants identifiés. Implémenter des migrations de données réversibles. Valider les configurations en CI.
-
Actions structurelles
Mettre en place des feature flags pour les changements risqués. Implémenter des déploiements canary (1 % → 10 % → 100 %). Créer une checklist pre-deploy automatisée.
-
Résultat attendu
CFR de 40 % à 15 % en 3 mois, tout en maintenant 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 "implémenter DevOps" mais ne sait pas par où commencer.
Diagnostic : impossible d'améliorer ce qu'on ne mesure pas.
-
Inventaire des systèmes
Cartographier les outils existants : VCS (GitHub Enterprise), CI/CD (Jenkins legacy + GitHub Actions nouveaux projets), Incidents (ServiceNow), Monitoring (Datadog).
-
Mesure manuelle initiale
Pour les 5 applications critiques, collecter manuellement le nombre de déploiements, temps moyen commit→prod, incidents du dernier trimestre. Résultat typique : DF=2/mois, LT=3 semaines, CFR=25%, MTTR=4 jours.
-
Quick win : automatiser la mesure
Implémenter un webhook qui log chaque déploiement vers une base centralisée.
-
Choisir un pilote
Sélectionner UNE équipe motivée pour améliorer ses métriques. Succès visible = adoption facilitée.
Scénario 3 : Conflit vitesse vs qualité
Section intitulée « Scénario 3 : Conflit vitesse vs qualité »Contexte
Les développeurs veulent déployer plus souvent. L'équipe QA bloque car "pas assez de tests". Le management ne sait pas qui a raison.
Diagnostic : faux dilemme. Les données DORA prouvent que vitesse et qualité sont corrélées, pas opposées. C'est l'un des insights les plus contre-intuitifs de la recherche DORA.
-
Présenter les données
Montrer les statistiques du rapport DORA 2024 : les équipes Elite déploient environ 182 fois plus souvent que les équipes Low, avec un CFR 8 fois plus bas et un temps de récupération plus de 2 000 fois plus rapide.
-
Expérience contrôlée
Proposer un pilote de 6 semaines sur un service non critique avec déploiement quotidien automatisé, mesure CFR et MTTR en continu, et engagement de rollback immédiat si CFR dépasse 20 %.
-
Itération basée sur les données
Si CFR augmente : ajouter des tests spécifiques aux cas d'échec. Si CFR reste stable : étendre l'approche progressivement.
-
Résolution du conflit
Les métriques objectives remplacent les opinions. Le débat "vitesse vs 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 systématiquement chez les équipes qui adoptent DORA sans préparation, et savoir les repérer évite des mois de mesure inutile ou contre-productive.
| Piège | Symptôme | Solution |
|---|---|---|
| Gamification | Équipes qui "trichent" pour améliorer les chiffres | Mesurer pour apprendre, pas pour punir. Pas de bonus liés aux métriques. |
| Moyenne vs Médiane | Un déploiement de 30 jours masqué par 29 déploiements d'1 jour | Utiliser la médiane et les percentiles (P90, P95) |
| Silos de mesure | Chaque équipe mesure différemment | Définir un glossaire commun |
| Oublier le contexte | Comparer une startup à une banque | Benchmarker par rapport à vous-même d'abord |
| Tout mesurer | Paralysie analytique | Commencer avec une approximation, raffiner ensuite |
| Ignorer les outliers | Incidents majeurs exclus des stats | Analyser séparément mais ne pas ignorer |
Au-delà des 4 métriques : l'évolution du modèle
Section intitulée « Au-delà des 4 métriques : l'évolution du modèle »Les 4 métriques de 2014 ont vécu leur propre histoire, et connaître cette histoire aide à comprendre 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 recherches successives.
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 4 métriques historiques, la Reliability ne repose pas sur une formule unique : DORA la définit comme le fait, pour une équipe, de respecter ou non ses propres objectifs de fiabilité, c'est-à-dire ses SLO (Service Level Objectives, les seuils cibles de disponibilité et de performance qu'une équipe se fixe). Une équipe qui vise 99,9 % de disponibilité et qui tient ce seuil consomme peu de son error budget (la marge d'échec tolérée avant de devoir stopper les nouvelles fonctionnalités) ; une équipe qui descend en dessous, même de justesse, est en dette de fiabilité, quel que soit par ailleurs son volume de déploiements.
En 2023, le MTTR historique a été redéfini en Failed Deployment Recovery Time (voir la section sur cette métrique plus haut). Puis en 2024, DORA a ajouté un cinquième indicateur officiel, le Deployment Rework Rate : le pourcentage de déploiements qui correspondent en réalité à un travail non planifié pour corriger un bug introduit précédemment. Le modèle actuel regroupe ainsi ses 5 métriques en deux familles : le Throughput (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 vu plus haut cible un seul goulot d'étranglement à la fois. Cette checklist, elle, couvre le déploiement de la démarche DORA à l'échelle d'une équipe, du premier jour jusqu'à l'institutionnalisation trimestrielle : les deux se combinent, 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). Automatiser la collecte de LT (commits + déploiements). Relier 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. Implémenter 2-3 améliorations ciblées. Mesurer l'impact hebdomadairement.
-
Trimestre 1 : Institutionnalisation
Créer un dashboard visible par tous. Mettre en place une revue mensuelle des métriques. Documenter les apprentissages. Étendre aux autres équipes.
-
Continu : Culture d'amélioration
Pas de blame, focus sur le système. Célébrer les progrès, pas les chiffres absolus. Partager les réussites et 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 toutefois la meilleure porte d'entrée pédagogique.
- Ne vous en servez jamais pour comparer ou noter des équipes : elles servent à apprendre, pas à punir, sous peine de détruire la confiance.
- 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 ; DevLake est aujourd'hui la référence open source, Four Keys de Google étant archivé depuis 2024.
- Ne confondez pas ces métriques avec le règlement DORA européen sur la résilience opérationnelle du secteur financier : même sigle, sujets différents.
FAQ : questions fréquentes
Section intitulée « FAQ : questions fréquentes »- Deployment Frequency (DF) : à quelle fréquence vous déployez en production.
- Lead Time for Changes (LT) : délai entre le premier 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 après un incident.
| Métrique | Valeur Elite |
|---|---|
| Deployment Frequency | Plusieurs fois par jour, à la demande |
| Lead Time | Moins d'une heure |
| Change Failure Rate | Autour de 5 % |
| Time to Restore | Moins d'une heure |
- Solutions intégrées : GitLab DORA Metrics, GitHub Insights, Sleuth, Harness Software Engineering Insights (ex-Propelo).
- Open source : Apache DevLake, référence actuelle auto-hébergée.
- Métriques DORA (DevOps Research and Assessment) : les 4 indicateurs de performance DevOps 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 IT).