# Que sont les métriques DORA et comment les tracker URL: https://whatshouldibuildnext.com/fr/journal/metriques-dora Type: blog Locale: fr Published: 2026-09-19 Updated: 2026-09-19 --- > Les métriques DORA mesurent la vitesse et la fiabilité de livraison de code. Fréquence de déploiement, délai de mise en production, taux d'échec, temps de récupération. Pertinent pour tous les profils Que sont les metriques DORA et pourquoi faudrait-il les tracker ? Ce sont quatre mesures qui quantifient la performance de livraison logicielle. Ces quatre clés permettent à une équipe de comprendre à quelle vitesse elle déploie, avec quelle fiabilité, et à quelle vitesse elle récupère après incident. Développées par Nicole Forsgren, Jez Humble et Gene Kim, validées sur des dizaines de milliers d'équipes, et acquises par Google en 2018. Ce guide couvre ce que chaque métrique piste, à quoi ressemblent les benchmarks en pratique, et où ce modèle arrête d'être utile. ## D'où viennent les métriques DORA et pourquoi la recherche compte Le programme DORA a démarré en 2014 avec une question simple : qu'est-ce que les équipes de développement performantes font différemment ? L'équipe de recherche a lancé chaque année des sondages auprès de dizaines de milliers de devs dans tous les secteurs, cherchant à identifier les pratiques qui prédisaient une bonne performance de livraison. Le résultat qui a fait passer le message était contre-intuitif. Les équipes d'élite ne sacrifiaient pas la stabilité pour la vitesse. Elles livraient plus vite *et* avaient moins d'incidents en production. Ce qui explosait la justification standard du déploiement rare : « si on déploie moins souvent, on cassera moins de choses ». Les données disaient le contraire. Les équipes qui livraient souvent construisaient des boucles de feedback meilleures, détectaient les problèmes plus tôt, et se rétablissaient plus vite quand quelque chose se cassait. Vitesse et stabilité n'étaient pas en opposition. Elles étaient corrélées. Google a acquis le programme DORA en 2018. L'équipe publie maintenant un rapport annuel « State of DevOps », a mis à jour le modèle en 2025 avec une cinquième métrique (Taux de refonte), et maintient la recherche comme initiative ouverte sur dora.dev. ## Les quatre mesures et ce qu'elles traquent réellement Le modèle a été mis à jour en 2025 avec le Taux de refonte comme cinquième métrique, mais les quatre clés originales restent le standard pour la plupart des outils et des discussions d'équipe. ### Fréquence de déploiement C'est tout simple : à quelle fréquence tu pousses en production. C'est la définition complète. Les équipes d'élite déploient à la demande : plusieurs fois par jour si quelque chose est prêt. Les équipes faibles déploient une fois par mois, ou parfois une fois tous les trois mois. Pour un dev solo, une cadence régulière d'une livraison par semaine te met déjà dans la catégorie des performants sur cette métrique seule. La fréquence de déploiement est un proxy pour la confiance dans le pipeline. Les équipes qui déploient rarement ont habituellement une infrastructure fragile, des tests manuels lourds, ou des chaînes d'approbation organisationnelles qui étouffent les releases. Les équipes qui livrent plusieurs fois par jour ont automatisé la plupart de ces goulots. La fréquence est un symptôme, pas la cause. ### Délai de mise en production Le temps qui s'écoule entre un commit qui arrive en contrôle de version et ce changement qui tourne en production. La majorité de ce délai n'est pas du temps à coder. C'est du temps à attendre : PR qui stagnent dans la queue, pipelines CI/CD qui tournent, slots de déploiement qui se libèrent, quelqu'un avec accès qui valide la release. Un délai de quelques heures, c'est un workflow serré et largement automatisé. Un délai qui se compte en semaines, c'est qu'il y a un problème structurel qui ajoute de la friction à un ou plusieurs handoff. Pour un dev solo, le délai de mise en production c'est ce qui se passe entre push et utilisateurs qui voient le résultat. Parfois c'est un pipeline qui prend 12 minutes. Parfois c'est ton hésitation interne à savoir si c'est assez stable pour shipper. ![Schéma d'un pipeline de déploiement logiciel avec quatre étapes](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-09/7127f0-inline1.webp) ### Taux d'échec des changements Le pourcentage de déploiements qui causent un problème assez grave pour nécessiter un hotfix, rollback, ou réponse d'incident. C'est le signal de qualité dans le modèle DORA. Le rapport 2024 « State of DevOps » place les équipes d'élite à environ 5% de taux d'échec. Les équipes faibles tournent à 46 à 63%. Si la moitié de tes déploiements nécessite une intervention immédiate, ta couverture de tests et ton processus de review ont des lacunes structurelles sérieuses. Le taux d'échec n'est pas une mesure abstraite de qualité de code. C'est une mesure de si les changements que tu deploys se comportent comme prévu en production spécifiquement. Un suite de tests qui passe localement mais qui ne couvre pas les chemins d'intégration qui cassent en production ne va pas bouger ce chiffre. ### Temps de récupération Quand un déploiement cause un incident, combien de temps avant que le service soit rétabli ? Il s'appelait à l'origine Mean Time to Recovery (MTTR). L'équipe DORA a réencadré ça en 2025 en « Temps de récupération suite à déploiement cassé », traçant spécifiquement la récupération après incidents causés par le déploiement plutôt que des pannes d'infra ou des outages tiers. La distinction importe parce que les incidents causés par le déploiement sont 100% du contrôle de l'équipe, ce qui en fait la vraie cible pour améliorer le processus. Les équipes d'élite récupèrent en moins d'une heure. Les équipes faibles peuvent mettre des jours ou une semaine. Si tu es dev solo, cette métrique dépend largement de si tu as de la monitoring en place. Les équipes sans infra d'alerting découvrent les pannes par plaintes d'utilisateurs plutôt que par signaux automatisés, ce qui ajoute des heures au temps de récupération. ## À quoi ressemblent les niveaux de performance Le rapport « State of DevOps » classe les équipes en quatre niveaux selon leurs chiffres DORA. Ce sont des gammes approximatives du rapport 2024, pas des coupures strictes : **Niveau Élite** : Fréquence plusieurs fois par jour, délai moins d'1 heure, taux d'échec moins de 5%, récupération moins d'1 heure. **Niveau Haute** : Fréquence quotidien à hebdomadaire, délai 1 jour à 1 semaine, taux d'échec 5-10%, récupération moins d'1 jour. **Niveau Moyenne** : Fréquence hebdomadaire à mensuel, délai 1 semaine à 1 mois, taux d'échec 10-15%, récupération 1 jour à 1 semaine. **Niveau Faible** : Fréquence mensuel ou moins, délai 1 à 6 mois, taux d'échec 46-63%, récupération 1 semaine à 6 mois. L'écart entre élite et faible n'est pas graduel. Selon le rapport 2024, les équipes faibles peuvent prendre plus de 180 fois plus longtemps à déployer et plus de 2 500 fois plus longtemps à récupérer d'incidents comparé aux équipes d'élite. C'est pas des différences marginales. Atteindre le niveau élite est faisable avec un investissement durable dans l'automatisation CI/CD, la couverture de tests, et la visibilité en production. Ça n'arrive pas en écrivant du code plus vite. Ça arrive en supprimant les étapes manuelles et les temps d'attente entre commit et exécution fiable en production. ## Comment les outils IA de développement impactent les métriques DORA en 2026 En 2026, les outils de codage IA sont assez courants pour affecter les métriques DORA d'une façon qu'il vaut le coup de tracker spécifiquement. Les équipes qui utilisent Cursor, GitHub Copilot, ou des outils similaires écrivent du code plus vite, ce qui tend à pousser la fréquence de déploiement à la hausse. Le délai de mise en production a aussi diminué dans beaucoup d'équipes parce qu'il y a plus de code produit par dev par semaine, donc plus de commits qui traversent le pipeline. ![Deux ingénieur passant en revue les métriques DORA sur des dashboards](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-09/1659ac-inline2.webp) Le taux d'échec a varié dans les deux directions. Les équipes avec des processus de review forts et une bonne couverture de tests ont tenu leurs taux stables en livrant plus. Les équipes qui shipent du code généré par IA sans review adéquat ont vu leurs taux d'échec augmenter. Le modèle DORA s'en fout de comment le code est écrit. Il mesure ce qui arrive *après* que le code arrive en production. Le rapport 2024 « State of DevOps » a trouvé que 41% des équipes sondées utilisaient des outils de développement assistés par IA. Ces équipes affichaient une fréquence de déploiement plus haute sans augmentation proportionnelle du taux d'échec quand l'adoption d'IA était jumelée avec des pipelines de test et review automatisés. Voilà ce qui coince en pratique : l'IA accélère l'avant du pipeline de manière significative. Les métriques DORA te disent si cette accélération est absorbée proprement ou si elle crée de l'instabilité en aval. ## Outils pour tracker les métriques DORA sans sur-construire ta stack La plupart des équipes commencent à mesurer les métriques DORA en tirant les données d'outils qu'elles utilisent déjà : GitHub ou GitLab pour les événements de déploiement et timestamps de commits, PagerDuty ou OpsGenie pour les données de temps de récupération, et le système de gestion d'incidents pour les comptes de taux d'échec. Plusieurs plateformes ont construit des dashboards DORA spécifiques autour de ces quatre métriques. Pour un dev solo sans budget tooling : un script qui log le timestamp de chaque déploiement en production et chaque événement de récupération te donne la fréquence et le temps de récupération sans frais d'infra. Le délai de mise en production peut être approximé à partir des timestamps de commits dans le Git log. ## Où les métriques DORA ont des vraies limites Mesurer DORA c'est utile. Le traiter comme la vue complète de la performance d'ingénierie crée plusieurs blind spots spécifiques qui valent le coup d'être nommés. **Accumulation de dette technique.** Une fréquence haute avec un taux d'échec bas ne te dit rien sur si la codebase devient plus difficile à faire évoluer au fil du temps. Une équipe peut atteindre les chiffres DORA d'élite tout en accumulant régulièrement la dette qui rend chaque nouvelle feature plus lente à livrer. DORA mesure la production ; il ne mesure pas l'état de ce dans quoi tu produis. **Alignement avec les outcomes.** La fréquence de déploiement mesure la production, pas les résultats. Shiper cinq fois par jour ne compte pour rien si aucun de ces changements ne bouge une métrique que le produit ou l'entreprise vise. Les feature flags, infra de A/B testing, et tracking de métriques métier sont complètement en dehors du modèle DORA. **Durabilité.** L'équipe de recherche DORA a ajouté une dimension d'expérience développeur au framework en 2023, en reconnaissant qu'une performance haute durable nécessite des ingénieurs qui ne tournent pas au burnout. Les quatre métriques core ne trackent pas si atteindre les chiffres d'élite a un coût ailleurs. Utilise DORA comme un outil de diagnostic baseline, pas comme un scoreboard. Les questions que les métriques soulèvent sont souvent plus actionnables que les chiffres eux-mêmes. Un taux d'échec de 30% est moins utile que de savoir quels types de changements échouent le plus et pourquoi. ## Par où commencer si t'as jamais tracké ça avant Un side project vieux de six mois sans données DORA, c'est normal. La plupart des petites équipes et devs solo n'ont jamais mesuré aucun de ces truc. Si tu pars de zéro, commence par la fréquence de déploiement et le délai de mise en production. Les deux sont faciles à extraire des timestamps de commits Git et des logs de déploiement, et ils te donnent un feedback immédiat sur si tu as de la friction inutile dans ton pipeline. Un délai de trois jours pour un changement qui a pris 40 minutes à écrire, c'est un signal qui vaut la peine d'investiguer. Le taux d'échec et le temps de récupération requièrent que des incidents s'accumulent avant que les chiffres veuillent dire quelque chose. Quand quelque chose casse en production, log le timestamp quand tu l'as détecté et le timestamp quand c'était résolu. Ces données s'accumulent au fil du temps. Une habitude pratique : après chaque incident en production, pose deux questions. Combien de temps avant de détecter ce problème ? Combien de temps de la détection à la résolution ? Ces deux chiffres sont les inputs du temps de récupération. En les trackant régulièrement pendant six mois, tu as assez d'historique pour savoir si ton processus de récupération s'améliore ou stagne. Trois raisons pour lesquelles tu devrais mesurer les métriques DORA même solo, une raison de pas te casser la tête : les métriques rendent la friction invisible visible, elles créent de la responsabilité pour les investissements en automatisation, et tu as quelque chose de concret à améliorer entre les features. La raison de pas te casser la tête : si tu es pré-lancement avec zéro utilisateurs en prod, les chiffres ne veulent pas dire grand chose encore. Commence à mesurer quand tu livres à des utilisateurs réels régulièrement. Ce n'est pas une idée parfaite. C'est une idée faisable. ## FAQ ### Que signifie l'acronyme DORA en développement logiciel ? DORA signifie DevOps Research and Assessment. C'est un programme de recherche fondé en 2014 par Nicole Forsgren, Jez Humble et Gene Kim, acquis par Google en 2018, qui étudie quelles pratiques prédisent une haute performance de livraison logicielle dans les organisations d'ingénierie. ### Quelles sont les quatre métriques DORA ? Les quatre métriques DORA sont : Fréquence de déploiement (à quelle fréquence tu déploies en prod), Délai de mise en production (temps entre commit et prod), Taux d'échec des changements (pourcentage de déploiements qui causent des incidents), et Temps de récupération (combien de temps pour récupérer d'une panne causée par déploiement). ### À quelle fréquence une équipe devrait-elle déployer pour être considérée d'élite selon DORA ? Les équipes d'élite déploient à la demande, ce qui signifie plusieurs fois par jour quand les changements sont prêts. Les équipes de haute performance déploient quotidiennement à hebdomadairement. Si ton équipe déploie moins d'une fois par semaine régulièrement, il y a probablement de la friction dans ton pipeline qui vaut la peine d'investiguer. ### Quel est un bon objectif de taux d'échec selon les benchmarks d'élite ? Les équipes d'élite dans le rapport 2024 tournent à environ 5% de taux d'échec. Les équipes de haute performance sont dans la gamme 5-10%. Un taux d'échec au-delà de 15% suggère des lacunes significatives dans les tests, la review, ou les processus de validation de déploiement. ### Comment mesurer les métriques DORA sans acheter des outils spécialisés ? Tu peux approximer les quatre métriques avec les données qu'tu as déjà : fréquence et délai depuis Git et logs de déploiement, taux d'échec depuis les records d'incidents, et temps de récupération depuis les timestamps d'ouverture et fermeture d'incidents. Un spreadsheet ou un script simple suffit pour commencer. ### Les métriques DORA sont-elles pertinentes pour les devs solo et petites équipes ? Oui. Les questions sous-jacentes s'appliquent à n'importe quelle échelle : à quelle fréquence tu livres ? À quelle fréquence les déploiements cassent les choses ? À quelle vitesse tu fixes les panne ? Les devs solo souvent skipent complètement la mesure, ce qui rend difficile de savoir si tes améliorations de pipeline aident vraiment. ### DORA a-t-il ajouté une cinquième métrique ? Oui. En 2025, l'équipe DORA a ajouté le Taux de refonte, qui piste le ratio de déploiements qui sont des fixes réactifs non-planifiés plutôt que du travail de feature planifié. Un taux de refonte élevé signifie que l'équipe passe du temps d'ingénierie à nettoyer des incidents au lieu de livrer ce qui était prévu.