09 novembre 2026

DORA core model : structurer une démarche d’amélioration continue

Le DORA Core Model aide les équipes de développement à analyser la performance du delivery logiciel. Ses métriques objectivent les résultats obtenus et ses capabilities orientent les actions d’amélioration continue.

DORA Core Model : mesurer pour améliorer la performance du delivery

Issu des travaux DevOps Research and Assessment, le DORA Core Model établit des liens entre les pratiques des équipes, la performance du delivery logiciel, la performance organisationnelle et le bien-être. Ce modèle dépasse largement la simple logique d’un tableau de bord. Les métriques rendent compte de la performance, tandis que les capabilities désignent les pratiques techniques, organisationnelles et culturelles sur lesquelles les équipes peuvent agir.

Le modèle relie trois dimensions. Les capabilities correspondent aux pratiques techniques, organisationnelles et culturelles des équipes. Leur évolution influence la performance du delivery, observée à travers les métriques DORA et la fiabilité du service.

Cette performance du delivery est ensuite un prédicteur de la performance organisationnelle et du bien‑être des équipes. Les éléments comme la productivité, la satisfaction au travail, la réduction du rework ou la diminution du risque de burnout ne constituent pas des outputs séparés, mais des manifestations du bien‑être associé à une bonne performance de delivery. Une équipe observe son delivery, repère ses points de friction, sélectionne les capabilities à travailler puis suit l’évolution de sa performance. L’objectif n’est pas d’obtenir un score en soi, mais de s’appuyer sur des données partagées pour orienter les décisions et guider l’amélioration continue.

Quels sont les quatre indicateurs DORA ?

Les DORA metrics historiques observent deux dimensions complémentaires du software delivery : la vitesse de livraison et sa stabilité. Depuis 2024, DORA a fait évoluer ce référentiel en ajoutant une cinquième métrique, le Deployment Rework Rate. Les quatre indicateurs historiques restent largement utilisés comme socle de mesure :

Deployment Frequency mesure la fréquence des déploiements en production.
Lead Time for Changes mesure le délai entre une modification du code et son déploiement en production.
Change Failure Rate mesure la part des mises en production qui entraînent une dégradation du service.
Failed Deployment Recovery Time mesure le temps nécessaire pour rétablir le service après un échec de déploiement. Cette métrique prolonge la logique historiquement associée au MTTR (Mean Time to Recovery).

Ces indicateurs DORA se lisent ensemble, la performance DevOps ne se résumant pas à la rapidité des mises en production, mais intégrant pleinement leur stabilité. . La fréquence de déploiement et le Lead Time for Changes renseignent sur le débit du delivery, tandis que le Change Failure Rate et le Failed Deployment Recovery Time éclairent sa stabilité. La fiabilité du service complète cette lecture, notamment à travers les objectifs de niveau de service ou SLO utilisés dans les pratiques de Site Reliability Engineering (SRE).

À quelles équipes s’adresse la démarche DORA ?

DORA concerne les organisations qui développent et livrent des produits ou services logiciels. DSI, responsables Delivery ou DevOps, Engineering Managers et équipes de développement disposent d’un référentiel commun pour analyser leurs pratiques de software engineering et prioriser leurs travaux d’amélioration.

Les équipes de développement et d’opérations peuvent analyser la performance à partir de métriques communes. La fréquence des mises en production ou le nombre d’incidents ne sont plus observés isolément : ils sont replacés dans le fonctionnement du delivery.

Comment DORA s’articule avec Agile, Scrum et SAFe ?

DORA, Scrum et SAFe ne répondent pas au même besoin. DORA mesure la performance du delivery et identifie les capabilities qui l’influencent. Les pratiques Agile et Scrum structurent la façon dont les équipes organisent et font évoluer leur travail.

Le cadre SAFe intervient à une autre échelle. Il coordonne plusieurs équipes Agile autour d’un flux de valeur et d’un rythme partagé. Une organisation peut utiliser les enseignements de DORA pour identifier ses axes d’amélioration, puis inscrire les actions associées dans ses backlogs et ses cycles SAFe.

Les métriques fournissent le constat. L’organisation Agile donne aux équipes les moyens de traiter les points de friction identifiés.

DORA au cœur de l’organisation Datanumia

Chez Datanumia, la démarche DORA soutient l’amélioration continue du delivery depuis début 2025. L’objectif est d’identifier les capabilities qui influencent la performance de la livraison logicielle et des opérations, puis d’agir sur celles qui freinent le flux de valeur.

Datanumia cherche à réduire les délais de mise en production sans compromettre la qualité. Les équipes travaillent sur les pratiques qui influencent le delivery et l’impact business des développements, plutôt que de considérer les métriques DORA comme une finalité.

Les actions issues des Assessments DORA sont intégrées aux backlogs produits et suivent la comitologie SAFe, au même titre que les fonctionnalités métier. L’amélioration du delivery entre directement dans le travail courant des équipes. Ce fonctionnement prolonge des pratiques d’ingénierie déjà en place chez Datanumia.

Une itération DORA intégrée au calendrier de l’entreprise

Datanumia organise chaque cycle autour de trois temps :

Janvier, Assessment : les équipes évaluent leur niveau de maturité sur les différentes capabilities DORA.
Février, ciblage : chaque équipe Agile identifie les capabilities sur lesquelles elle souhaite progresser en priorité.
Mars à décembre, action : les améliorations retenues rejoignent les backlogs et sont rythmées par la comitologie SAFe.

Ce cycle relie directement l’évaluation au travail des équipes. Une capability retenue après l’Assessment devient un sujet planifié dans le backlog et suivi dans la durée.

Former et impliquer les équipes dans la démarche DORA

Les indicateurs n’ont d’intérêt que si les équipes comprennent ce qu’elles mesurent et les pratiques sur lesquelles elles peuvent agir. Chez Datanumia, la maîtrise technique du modèle s’accompagne d’un travail de formation et d’implication des équipes.

Les développeurs relient chaque capability aux difficultés rencontrées dans leur travail quotidien. Cette compréhension favorise la transparence lors des Assessments. DORA devient alors un outil d’aide à la décision : les équipes identifient les frictions qui pèsent sur leur delivery et concentrent leurs efforts sur des actions précises, avec l’objectif de réduire la charge mentale associée aux mises en production.

Actionner les bons leviers : un exemple concret chez Datanumia

Améliorer la performance du Delivery suppose d’intervenir sur les pratiques des équipes. En 2026, l’équipe Dionysos du train EMS (B2B) a choisi de travailler sur la capability Working in Small Batches, qui consiste à réduire la taille des lots de travail.

Historiquement, des périmètres de livraison trop larges rendaient certaines mises en production plus difficiles à gérer. Ils augmentaient le risque associé à chaque déploiement et retardaient les retours nécessaires pour détecter puis corriger un problème.

L’équipe Dionysos a systématisé le découpage du travail en unités plus petites. Ce choix a raccourci les boucles de feedback : les problèmes sont désormais identifiés et corrigés plus tôt dans le cycle de développement. Des incréments plus petits limitent aussi le périmètre exposé lors de chaque mise en production et réduisent l’impact potentiel d’un incident.

Le cas Dionysos montre comment une capability DORA se traduit dans le travail d’une équipe : une friction est identifiée, une pratique évolue et ses effets peuvent ensuite être suivis dans les métriques.

D’autres équipes Datanumia ont retenu des capabilities différentes selon les frictions identifiées lors de leurs Assessments :

Test Automation : automatiser davantage les tests pour fiabiliser les déploiements continus et réduire les validations manuelles.
Code Maintainability : préserver la maintenabilité du code afin de limiter les freins techniques qui ralentissent les évolutions.
Loosely Coupled Teams : réduire les dépendances entre équipes pour renforcer leur autonomie lors des déploiements.

Les priorités varient selon les équipes. Le fonctionnement reste le même : identifier une capability qui pèse sur le delivery, inscrire les actions correspondantes dans le backlog, puis suivre leur effet sur la performance.

Crédits : photo de Vitaly Gariev sur Unsplash