Skip to content
Learni
View all tutorials
DevOps & SRE

Comment mesurer les métriques DORA en production 2026

18 minEXPERT
DevOpsObservabilitéDORA

Introduction

Les métriques DORA restent en 2026 le standard de référence pour évaluer la performance DevOps. Elles permettent de corréler vitesse de livraison et stabilité. Ce tutoriel vous guide à travers une implémentation experte incluant collecte temps réel, calcul distribué et visualisation avancée. Vous apprendrez à instrumenter vos pipelines CI/CD et vos systèmes d'observabilité pour obtenir des données fiables et actionnables.

Prérequis

  • Kubernetes 1.29+ ou équivalent avec Prometheus
  • GitLab CI ou GitHub Actions
  • Base de données TimescaleDB ou ClickHouse
  • Connaissances solides en observabilité et scripting
  • Accès aux logs de déploiement et incidents

Collecte des déploiements

collect-deployments.sh
#!/bin/bash
set -e
DEPLOY_TIME=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
COMMIT_SHA=$(git rev-parse HEAD)
SERVICE_NAME="api-gateway"
echo "{\"timestamp\": \"$DEPLOY_TIME\", \"commit\": \"$COMMIT_SHA\", \"service\": \"$SERVICE_NAME\", \"status\": \"success\"}" | curl -X POST http://metrics-collector:8080/deployments -d @-

Ce script envoie les métadonnées de chaque déploiement réussi vers un collecteur centralisé. Il capture le timestamp UTC et le SHA du commit pour permettre le calcul précis du lead time et de la fréquence.

Calcul de la fréquence de déploiement

dora_calculator.py
from datetime import datetime, timedelta
import psycopg2

def calculate_deployment_frequency(service: str, days: int = 30):
    conn = psycopg2.connect("dbname=metrics user=metrics")
    cur = conn.cursor()
    cur.execute("""SELECT COUNT(*) FROM deployments 
                   WHERE service = %s AND timestamp > %s""", 
                   (service, datetime.utcnow() - timedelta(days=days)))
    count = cur.fetchone()[0]
    return count / days  # déploiements par jour

Cette fonction calcule la fréquence moyenne quotidienne sur 30 jours. Elle interroge directement la base de données des déploiements pour une mesure précise et historisée.

Mesure du lead time

lead_time.sql
SELECT 
  service,
  PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (deploy_time - commit_time))/3600) AS p95_lead_time_hours
FROM deployments
WHERE deploy_time > NOW() - INTERVAL '30 days'
GROUP BY service;

Cette requête SQL calcule le lead time au 95e percentile. Elle mesure le temps écoulé entre le commit et le déploiement en production pour identifier les goulots d'étranglement.

Instrumentation du MTTR

incident-tracking.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: dora-mttr-config
data:
  rules.yaml: |
    - alert: ServiceDown
      expr: up{service="api-gateway"} == 0
      annotations:
        incident_start: "{{ $value }}"
    - alert: ServiceRestored
      expr: up{service="api-gateway"} == 1
      annotations:
        incident_end: "{{ $value }}"

Cette configuration Prometheus permet de détecter automatiquement les incidents et leur résolution. Les timestamps sont ensuite utilisés pour calculer le Time to Restore Service.

Dashboard Grafana DORA

dora-dashboard.json
{
  "dashboard": {
    "title": "DORA Metrics 2026",
    "panels": [
      {
        "title": "Deployment Frequency",
        "targets": [{"expr": "sum(rate(deployments_total[24h]))"}]
      },
      {
        "title": "Change Failure Rate",
        "targets": [{"expr": "sum(failed_deployments)/sum(total_deployments)"}]
      }
    ]
  }
}

Ce fichier JSON définit un dashboard Grafana prêt à l'emploi. Il affiche les quatre métriques DORA avec des requêtes PromQL optimisées pour une lecture temps réel.

Bonnes pratiques

  • Toujours stocker les données brutes avec un horizon de 90 jours minimum
  • Utiliser des percentiles plutôt que des moyennes pour le lead time et le MTTR
  • Séparer les environnements (prod vs staging) dans les calculs
  • Automatiser l'alerte lorsque les métriques descendent sous les seuils d'élite
  • Corréler les métriques DORA avec les objectifs business

Erreurs courantes

  • Calculer la fréquence uniquement sur les déploiements manuels et ignorer les pipelines automatisés
  • Oublier de filtrer les déploiements de hotfix dans le change failure rate
  • Utiliser des timestamps locaux au lieu d'UTC pour les comparaisons internationales
  • Ne pas versionner les scripts de calcul des métriques

Pour aller plus loin

Découvrez nos formations avancées sur l'observabilité et l'excellence DevOps : https://learni-group.com/formations. Vous y apprendrez à construire des plateformes de métriques internes à l'échelle.