DORA 2026 : mesurer la fiabilité sans KPI toxiques

Les métriques DORA sont devenues un raccourci courant pour parler de performance DevOps. Fréquence de déploiement, délai de mise en production, taux d’échec des changements et délai de restauration : le cadre est simple à retenir, facile à afficher dans un outil de reporting et suffisamment connu pour être repris dans une revue de direction.

Le problème commence lorsque cette simplicité est transformée en objectif individuel, en classement entre équipes ou en seuil arbitraire à atteindre. Un indicateur de déploiement ne raconte pas, à lui seul, la qualité d’un produit, la difficulté d’un domaine métier, la dette technique accumulée ou la charge opérationnelle réelle. Il peut même encourager des comportements qui améliorent le chiffre sans améliorer le système.

En 2026, l’intérêt des métriques DORA reste donc intact, à une condition : les utiliser comme des signaux pour enquêter sur le fonctionnement du delivery. Elles doivent aider une équipe à voir où le pipeline ralentit, où les changements échouent et où les retours en arrière coûtent trop cher. Elles ne doivent pas servir à noter les développeurs, à imposer une cadence uniforme ou à déclarer une équipe « mature » sur la base d’un écran de dashboard.

Pourquoi les métriques DORA restent utiles

Le cadre DORA, popularisé par les recherches sur la performance de livraison logicielle, a eu un mérite important : déplacer la discussion de l’intuition vers l’observation. Au lieu de dire qu’une équipe « livre lentement » ou que les mises en production sont « risquées », on peut examiner des événements concrets sur une période donnée.

Les quatre métriques les plus couramment associées à DORA sont les suivantes :

• La fréquence de déploiement : à quelle fréquence un service ou une application est déployé en production.
• Le délai de mise en production, souvent appelé lead time for changes : le temps entre un changement de code et sa disponibilité en production.
• Le taux d’échec des changements : la part des déploiements qui entraînent une dégradation, un incident, un rollback, un correctif urgent ou une autre forme d’intervention corrective, selon la définition retenue.
• Le délai de restauration de service : le temps nécessaire pour rétablir un service après un incident.

Ces mesures ont une valeur pratique parce qu’elles couvrent deux réalités qui doivent rester liées : le débit de livraison et la stabilité du service. Une équipe qui déploie souvent mais passe son temps à réparer n’a pas trouvé un bon équilibre. À l’inverse, une équipe qui ne produit presque aucun incident mais ne peut publier qu’après plusieurs semaines de validations manuelles peut avoir un problème de flux.

Le cadre est particulièrement utile pour faire émerger des questions précises. Pourquoi le délai de mise en production augmente-t-il alors que le volume de changements reste stable ? Pourquoi les incidents surviennent-ils surtout après certains types de déploiements ? Pourquoi le temps de restauration dépend-il d’une seule personne ou d’un accès d’urgence difficile à obtenir ?

Ces questions sont plus utiles qu’une comparaison brute entre deux équipes. Un service de paiement exposé au public, une plateforme interne et une application réglementée ne portent pas les mêmes contraintes. Chercher à les faire entrer dans une même cadence de déploiement est rarement pertinent.

Ce que les quatre métriques ne mesurent pas

Les métriques DORA ne constituent pas une définition complète de la performance d’une organisation technique. Elles ne mesurent pas directement la valeur métier, l’accessibilité, la sécurité, la maintenabilité, la consommation d’infrastructure, la satisfaction des utilisateurs ou la qualité de l’astreinte.

Elles ne disent pas non plus pourquoi un délai est élevé. Un lead time de plusieurs jours peut révéler une file d’attente de revue de code, des tests d’intégration instables, une validation sécurité tardive, un changement de base de données complexe ou une procédure de mise en production manuelle. La valeur agrégée est un point de départ ; elle ne remplace pas l’analyse du flux.

Il faut également définir avec précision les événements comptés. Prenons la fréquence de déploiement : faut-il inclure une modification de configuration, un flag activé sans nouvelle image, un déploiement canari, une migration de données ou la simple republication d’un artefact identique ? Il n’existe pas de réponse universelle. L’essentiel est d’adopter une convention claire, stable dans le temps et cohérente avec la manière dont le service est réellement opéré.

Le même soin est nécessaire pour le taux d’échec des changements. Compter tous les tickets de support comme des échecs de déploiement rend la mesure inutilisable. Ne compter que les rollbacks automatiques peut au contraire masquer des dégradations réelles détectées plus tard. Une équipe doit documenter ce qui entre dans le périmètre : incident confirmé, restauration nécessaire, hotfix en production, retour arrière ou violation d’un objectif de niveau de service, par exemple.

Une métrique DORA fiable n’est pas celle qui donne le meilleur chiffre. C’est celle dont les équipes comprennent le périmètre et qu’elles peuvent utiliser pour décider d’une amélioration.

Dans ce contexte, les données de GitHub, GitLab, Jira, Azure DevOps, Argo CD, GitHub Actions ou Jenkins peuvent aider, mais aucun de ces outils ne reconstitue automatiquement toute la vérité du delivery. Il faut souvent relier les commits, les pull requests, les builds, les déploiements, les alertes et les incidents. Cette difficulté est normale : elle reflète la réalité d’un système réparti entre plusieurs outils et plusieurs équipes.

Quand un KPI de déploiement devient toxique

Un indicateur devient dangereux lorsqu’il est détaché de son contexte et associé à une récompense, une sanction ou une évaluation individuelle. C’est particulièrement vrai pour les métriques de delivery, car les personnes peuvent rarement les contrôler seules.

Un développeur dépend des règles de revue, de la disponibilité des environnements, du temps de la CI, des politiques de changement, des équipes de sécurité, de la qualité de l’observabilité et parfois d’un prestataire externe. Lui attribuer un délai de mise en production revient souvent à lui attribuer les faiblesses du système entier.

Voici quelques effets pervers fréquents :

• Fractionner artificiellement les changements pour augmenter le nombre de déploiements, sans que cela corresponde à une meilleure capacité de livraison.
• Éviter les travaux risqués mais nécessaires, comme une migration de base de données, une refonte d’authentification ou la suppression de dette technique, afin de préserver un faible taux d’échec.
• Masquer ou requalifier les incidents pour éviter qu’ils ne dégradent un indicateur d’équipe.
• Déployer des modifications sans impact réel afin de satisfaire une cadence imposée.
• Reporter les validations ou réduire les contrôles pour raccourcir un délai, au prix d’un risque déplacé vers la production.
• Créer une compétition entre équipes dont les services, les contraintes et les responsabilités ne sont pas comparables.

Le résultat est paradoxal : l’organisation pense piloter la fiabilité, mais elle pousse les équipes à optimiser une représentation incomplète de la fiabilité. C’est un exemple classique de mesure devenue cible.

La bonne unité d’analyse est généralement le flux de valeur, le produit ou le service opéré collectivement. Les métriques doivent être visibles par l’équipe concernée et discutées dans un cadre où il est possible de parler des causes sans chercher un responsable individuel. Une revue de delivery utile ressemble davantage à une analyse de système qu’à un entretien d’évaluation.

Cette précaution rejoint un principe essentiel de l’automatisation : supprimer les manipulations manuelles répétitives ne suffit pas. Il faut aussi rendre les processus explicites et observables. À ce sujet, l’article éviter les pannes silencieuses dans les scripts d’automatisation rappelle qu’un job qui échoue sans signal utile fausse autant l’exploitation que les mesures qui en découlent.

Construire un tableau de bord minimal et réellement exploitable

Un bon tableau de bord ne cherche pas à tout montrer. Il doit permettre à une équipe de détecter un changement, de formuler une hypothèse et d’ouvrir une action. Commencer avec quatre métriques DORA et quelques éléments de contexte est souvent plus efficace qu’accumuler des dizaines de graphiques.

Une structure pragmatique peut reposer sur trois axes : débit, stabilité et temps perdu dans le pipeline.

Débit : observer le passage des changements

Le débit peut être suivi avec la fréquence de déploiement et le délai de mise en production. Mais le délai global est rarement assez précis pour agir. Il est utile de le décomposer en étapes lorsque les données sont disponibles :

• temps entre ouverture et fusion d’une pull request ;
• temps d’attente avant le démarrage d’un pipeline ;
• durée des builds et des tests ;
• temps d’attente avant déploiement ;
• temps de validation après déploiement.

Supposons que le délai de mise en production augmente. Si les tests ne durent pas plus longtemps mais que les pipelines attendent fréquemment un runner disponible, le problème n’est pas la qualité du code : c’est la capacité d’exécution de la CI. Des runners éphémères peuvent être une piste, mais seulement si le diagnostic confirme que la saturation, l’isolation ou l’entretien des runners constituent la friction principale.

Stabilité : relier changement, incident et restauration

Le taux d’échec des changements doit être affiché avec le délai de restauration, pas isolément. Un faible volume d’échecs n’a pas la même signification selon qu’un incident est corrigé en quelques minutes grâce à un rollback maîtrisé ou qu’il nécessite plusieurs heures de diagnostic et une intervention manuelle.

La chronologie compte également. Un incident survenu après un déploiement n’est pas automatiquement causé par ce déploiement. L’analyse doit confirmer le lien. À l’inverse, un rollback peut avoir évité une interruption visible pour les utilisateurs ; le compter comme un signal de risque peut être pertinent, sans présenter le mécanisme de rollback comme un échec humain.

Les capacités de restauration doivent être testées. Une procédure écrite mais jamais exécutée en conditions réalistes ne garantit rien. Les équipes gagnent à vérifier que l’artefact précédent est disponible, que la procédure est automatisée autant que possible et que les droits nécessaires sont accessibles lors d’un incident. Les principes abordés dans structurer un pipeline CI/CD fiable sans usine à gaz sont directement liés à cette capacité de retour à un état sain.

Temps perdu : rendre visibles les attentes et les reprises

Les métriques DORA montrent un résultat global. Pour améliorer le système, il faut aussi suivre les temps perdus qui alimentent ce résultat : pipelines relancés, validations manuelles, environnements indisponibles, échecs intermittents de tests, attente d’un approbateur ou incidents de déploiement.

Il n’est pas nécessaire de produire un chiffre parfait. Une catégorisation simple des motifs de reprise ou de blocage, revue périodiquement, peut déjà révéler un problème récurrent. Si une équipe relance souvent les mêmes jobs à cause d’échecs réseau ou de tests non déterministes, elle possède une cible d’amélioration plus concrète qu’un objectif abstrait de réduction du lead time.

Collecter les données sans créer une usine de reporting

La collecte doit partir des systèmes qui font foi. GitHub et GitLab fournissent les événements liés aux commits, merge requests ou pull requests et pipelines. Les plateformes de CI telles que GitHub Actions, GitLab CI/CD, Jenkins ou CircleCI exposent des exécutions de jobs. Les outils de déploiement comme Argo CD ou Flux peuvent apporter la trace de synchronisation vers un environnement. Enfin, PagerDuty, Opsgenie, ServiceNow ou un outil de gestion d’incidents interne peuvent contribuer aux données de restauration.

La difficulté principale est l’identifiant commun entre ces étapes. Sans lien entre un changement, un artefact et un déploiement, on obtient des moyennes approximatives. Il est donc utile de standardiser quelques métadonnées :

• un identifiant de commit ou de version dans l’artefact ;
• un environnement explicitement renseigné lors du déploiement ;
• un lien entre incident et service affecté ;
• une définition partagée de ce qui constitue une mise en production.

Cette standardisation ne demande pas forcément une plateforme interne complète. Elle peut commencer dans les conventions de pipeline, les tags d’images de conteneurs et les événements envoyés à l’outil d’observabilité. Avant d’ajouter une couche de reporting, vérifiez que les pipelines produisent déjà des signaux fiables : statut de déploiement, version déployée, durée, lien vers les logs et motif d’échec.

Une attention particulière doit être portée aux accès. Centraliser des données de delivery ne justifie pas la multiplication de jetons permanents dans les pipelines. Les approches basées sur l’identité fédérée réduisent ce besoin dans de nombreux cas ; l’article sur OIDC en CI/CD et la réduction des secrets statiques détaille l’intérêt opérationnel et sécuritaire de cette évolution.

Lire les tendances plutôt que poursuivre un seuil universel

Une valeur ponctuelle est rarement intéressante. Les déploiements peuvent varier selon les périodes, les lancements produit, les congés, les migrations ou les incidents majeurs. L’enjeu est d’observer une tendance sur une période cohérente avec le rythme du service.

Une équipe peut par exemple constater que son délai de mise en production s’allonge depuis plusieurs semaines. Avant de conclure que les développeurs sont moins efficaces, elle peut examiner :

• la taille et le nombre des pull requests ;
• le temps d’attente des revues ;
• la disponibilité des runners et des environnements ;
• l’évolution de la durée des suites de tests ;
• le nombre de validations manuelles ;
• les changements dans les règles de sécurité ou de conformité.

De même, une hausse temporaire du taux d’échec peut être acceptable si l’équipe mène volontairement une migration difficile, à condition que le risque soit visible, que les mécanismes de récupération existent et que les enseignements soient réinjectés dans le pipeline. Le chiffre ne doit pas effacer le contexte ; il doit le rendre discutable.

Comparer une équipe à elle-même est souvent plus utile que la comparer à une moyenne externe. Une amélioration durable peut être modeste mais très concrète : diminuer les échecs intermittents d’une suite de tests, rendre un rollback reproductible, supprimer une validation manuelle sans valeur ou réduire l’attente liée à un environnement partagé.

Transformer les mesures en décisions d’amélioration

Le tableau de bord n’est utile que s’il alimente une boucle de décision. Sans rituel de revue, les métriques deviennent de la décoration. Une cadence régulière, intégrée à une rétrospective, une revue de fiabilité ou un point d’exploitation, suffit souvent.

Une revue efficace peut suivre une séquence simple :

• Observer : quelle tendance a réellement changé depuis la dernière période ?
• Qualifier : le changement concerne-t-il tous les services, un pipeline, un environnement ou un type de modification ?
• Expliquer : quelles données complémentaires permettent de confirmer une hypothèse ?
• Choisir : quelle action limitée peut réduire la friction ou le risque ?
• Vérifier : après mise en œuvre, la mesure et les retours des équipes évoluent-ils dans le bon sens ?

Exemple concret : le dashboard montre une augmentation du délai entre fusion et production. L’analyse révèle que les builds attendent un runner et que les jobs de test se relancent souvent. Au lieu d’exiger davantage de déploiements, l’équipe peut prioriser la suppression d’un test instable, ajuster la capacité des runners et mesurer ensuite le temps d’attente. L’action porte sur une cause observable, non sur le comportement individuel.

Autre cas : plusieurs incidents nécessitent un correctif urgent après une même classe de changement. La réponse n’est pas nécessairement d’ajouter une approbation manuelle à chaque déploiement. L’équipe peut ajouter un test ciblé, une vérification de compatibilité, un déploiement progressif ou une alerte mieux corrélée à la version. La surveillance des flux de déploiement de bout en bout aide ici à relier les étapes techniques aux conséquences opérationnelles.

Protéger la confiance autour des chiffres

La qualité des métriques dépend fortement de la confiance entre les personnes qui les utilisent. Si les équipes pensent qu’un incident déclaré sera utilisé contre elles, elles auront intérêt à minimiser, retarder ou requalifier les problèmes. Le dashboard deviendra alors plus rassurant, mais moins vrai.

Quelques règles simples réduisent ce risque :

• ne pas intégrer les métriques DORA dans l’évaluation individuelle ;
• publier les définitions et les limites de chaque indicateur ;
• associer les chiffres à des commentaires de contexte ;
• analyser les incidents sans recherche automatique de faute ;
• autoriser les équipes à signaler une donnée incomplète ou trompeuse ;
• valoriser la suppression d’une friction autant que l’amélioration d’un chiffre.

La transparence doit aussi s’appliquer aux arbitrages. Une organisation peut accepter un délai plus long pour un changement particulièrement sensible, ou investir temporairement moins dans la cadence de livraison pendant une phase de stabilisation. Ce choix n’est pas un échec s’il est explicite, compris et réévalué.

Conclusion : faire des métriques DORA un outil de diagnostic

Les métriques DORA restent un cadre utile pour piloter la livraison logicielle, à condition de ne pas leur demander ce qu’elles ne peuvent pas fournir. Elles peuvent montrer un ralentissement, une fragilité ou une difficulté de restauration. Elles ne peuvent pas, seules, expliquer la cause ni juger le travail d’une personne.

Le bon usage consiste à mesurer peu, définir clairement, comparer les tendances dans le temps et relier chaque signal à une amélioration concrète du pipeline ou de l’exploitation. Si votre tableau de bord conduit surtout à demander « qui est en retard ? », il mérite d’être revu. S’il aide les équipes à supprimer une attente, fiabiliser un test ou restaurer plus vite un service, il commence à remplir son rôle.

Commencez par un service, une période d’observation et une friction connue. Puis utilisez les données pour traiter le système qui produit les résultats, pas les personnes qui le subissent.