Implémentation des métriques DORA

Parcours Implémentation — Partie 4 : Mesurer

Chapitre 4.1 — Implémenter les 4 métriques DORA.

Étape précédente : 3.2 Formation des équipes Prochaine étape : 4.2 KPIs Sécurité

En 2022, une équipe e-commerce déployait une fois par mois avec un taux d’échec de 35%. Après 6 mois de mesure et d’amélioration basées sur les métriques DORA, elle atteignait 12 déploiements quotidiens avec seulement 3% d’échecs. Ces quatre indicateurs, validés par des années de recherche sur plus de 36 000 professionnels, représentent aujourd’hui le standard incontournable pour mesurer la performance de livraison logicielle.

Les métriques DORA (DevOps Research and Assessment) ne sont pas de simples chiffres à afficher sur un dashboard. Elles constituent un système de diagnostic qui révèle la santé de votre pipeline de livraison. Pensez-y comme aux constantes vitales d’un patient : la fréquence cardiaque (Deployment Frequency), le temps de réaction (Lead Time), le taux d’erreur (Change Failure Rate) et le temps de récupération (MTTR). Ensemble, ces indicateurs racontent une histoire cohérente sur votre capacité à livrer de la valeur rapidement et de manière fiable.

Ce guide vous accompagne pas à pas dans l’implémentation concrète de ces métriques, depuis la collecte des données brutes jusqu’à la création d’un dashboard actionnable.

Prérequis

Avant de commencer l’implémentation, assurez-vous de disposer des éléments suivants :

Pipeline CI/CD sécurisé Pipeline CI/CD mature et automatisé pour déployer en production.

Observabilité Infrastructure de monitoring et collecte de métriques.

Fondamentaux DORA Comprendre la théorie derrière les 4 métriques clés.

Gestion des incidents Processus de tracking des incidents pour CFR et MTTR.

Pourquoi mesurer avec DORA ?

Avant de plonger dans l’implémentation technique, comprenons pourquoi ces quatre métriques spécifiques ont été choisies parmi des centaines de mesures possibles.

Le programme DORA, initié par Gene Kim, Jez Humble et Nicole Forsgren, a analysé les pratiques de milliers d’organisations pendant plus de 6 ans. La conclusion est sans appel : les équipes “Elite” livrent 208 fois plus fréquemment que les équipes les moins performantes, avec un temps de récupération 2 604 fois plus rapide.

Ces métriques fonctionnent en binôme selon deux dimensions. Les deux premières (Deployment Frequency et Lead Time) mesurent votre throughput — c’est-à-dire votre vélocité de livraison de valeur. Les deux dernières (Change Failure Rate et MTTR) mesurent votre stability — c’est-à-dire la fiabilité de ce que vous livrez. L’objectif n’est pas d’optimiser l’une au détriment de l’autre, mais d’améliorer les deux simultanément.

Les 4 métriques DORA

Le tableau suivant résume chaque métrique et ce qu’elle mesure concrètement :

Métrique	Ce qu’elle mesure	Dimension
Deployment Frequency (DF)	Nombre de déploiements réussis en production	Throughput
Lead Time for Changes (LT)	Temps entre le premier commit et la mise en production	Throughput
Change Failure Rate (CFR)	Pourcentage de déploiements causant des incidents	Stability
Mean Time to Recover (MTTR)	Durée moyenne pour restaurer le service après incident	Stability

Le paradoxe de la performance

Contrairement aux idées reçues, les équipes qui déploient le plus fréquemment ont aussi les taux d’échec les plus bas. La vitesse et la qualité vont de pair lorsque les pratiques DevOps sont bien implémentées.

Niveaux de performance

Comment savoir si vos métriques sont bonnes ? Le tableau ci-dessous définit les quatre niveaux de performance identifiés par la recherche DORA. Votre objectif est de progresser graduellement vers le niveau Elite :

Métrique	Low	Medium	High	Elite
Deployment Frequency	< 1/mois	1/semaine - 1/mois	1/jour - 1/semaine	Multiple/jour
Lead Time	> 6 mois	1-6 mois	1 jour - 1 semaine	< 1 jour
Change Failure Rate	> 30%	16-30%	0-15%	0-15%
MTTR	> 6 mois	1 jour - 1 semaine	< 1 jour	< 1 heure

Progression réaliste

Ne visez pas le niveau Elite immédiatement. Chaque amélioration de niveau représente un gain significatif. Passer de “Low” à “Medium” peut prendre 3 à 6 mois d’efforts soutenus.

1. Deployment Frequency (DF)

Comprendre cette métrique

La Deployment Frequency mesure combien de fois vous déployez en production sur une période donnée. C’est la métrique la plus simple à collecter, mais aussi la plus révélatrice de votre maturité DevOps.

Imaginez la fréquence de déploiement comme le pouls de votre équipe. Un pouls faible (1 déploiement par mois) indique souvent des processus lourds, des peurs du changement, ou une dette technique importante. Un pouls rapide (plusieurs fois par jour) révèle une équipe confiante dans ses tests, son automatisation et sa capacité à corriger rapidement les problèmes.

Ce qui compte comme un déploiement

Comptez uniquement les déploiements réussis vers l’environnement de production. Les déploiements vers staging ou les déploiements échoués ne comptent pas. Incluez tous les services, pas seulement l’application principale.

Collecte automatisée

La clé d’une bonne mesure est l’automatisation. Chaque déploiement doit envoyer un événement vers votre système de métriques. Voici comment l’implémenter selon votre plateforme CI/CD :

GitHub Actions

.github/workflows/deploy.yml

name: Deploy to Production

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy application
        run: ./deploy.sh

      - name: Track deployment metric
        if: success()
        run: |
          curl -X POST "${{ secrets.METRICS_ENDPOINT }}/deployments" \
            -H "Content-Type: application/json" \
            -d '{
              "timestamp": "'$(date -u +%Y-%m-%dT%H:%M:%SZ)'",
              "environment": "production",
              "service": "${{ github.repository }}",
              "commit_sha": "${{ github.sha }}",
              "status": "success"
            }'

GitLab CI

.gitlab-ci.yml

deploy_production:
  stage: deploy
  script:
    - ./deploy.sh
  after_script:
    - |
      if [ "$CI_JOB_STATUS" == "success" ]; then
        curl -X POST "$METRICS_ENDPOINT/deployments" \
          -H "Content-Type: application/json" \
          -d "{
            \"timestamp\": \"$(date -u +%Y-%m-%dT%H:%M:%SZ)\",
            \"environment\": \"production\",
            \"service\": \"$CI_PROJECT_PATH\",
            \"commit_sha\": \"$CI_COMMIT_SHA\",
            \"status\": \"success\"
          }"
      fi
  environment:
    name: production

ArgoCD

# ArgoCD notification avec webhook
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  annotations:
    notifications.argoproj.io/subscribe.on-sync-succeeded.webhook: deployment-tracker
---
# ConfigMap pour les notifications
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-notifications-cm
data:
  trigger.on-sync-succeeded: |
    - when: app.status.sync.status == 'Synced'
      send: [deployment-event]
  template.deployment-event: |
    webhook:
      deployment-tracker:
        method: POST
        body: |
          {
            "timestamp": "{{.app.status.operationState.finishedAt}}",
            "environment": "production",
            "service": "{{.app.metadata.name}}",
            "commit_sha": "{{.app.status.sync.revision}}",
            "status": "success"
          }

Améliorer la fréquence de déploiement

Si votre fréquence est trop basse, identifiez le goulot d’étranglement principal :

Symptôme	Cause probable	Solution
Déploiements groupés le vendredi	Peur du changement	Feature flags, rollback automatique
Batches de 50+ commits	Revues de code trop longues	Limiter la taille des PRs à 400 lignes
Tests qui durent 2+ heures	Suite de tests non optimisée	Parallélisation, tests par impact
Approbations manuelles multiples	Processus bureaucratique	Trunk-based development, confiance automatisée

2. Lead Time for Changes (LT)

Comprendre cette métrique

Le Lead Time mesure le temps écoulé entre le premier commit d’un changement et son déploiement en production. Cette métrique révèle la fluidité de votre pipeline de bout en bout.

Pensez au Lead Time comme au temps de trajet d’un colis. De la commande (commit) à la livraison (production), chaque étape ajoute du délai : la revue de code, les tests, les approbations, le déploiement lui-même. Un Lead Time de 6 mois signifie que vos clients attendent 6 mois pour bénéficier d’une correction de bug. Un Lead Time de quelques heures signifie que vous pouvez réagir rapidement aux retours utilisateurs.

Différence avec le Cycle Time

Le Lead Time DORA mesure commit → production. Ne le confondez pas avec le Cycle Time (début du travail → fin) ou le PR Time (ouverture PR → merge). Chaque métrique a sa valeur, mais DORA utilise spécifiquement le Lead Time.

Méthode de calcul

Le calcul du Lead Time nécessite de corréler les commits aux déploiements. Voici la logique :

# Exemple de calcul Lead Time
calcul_lead_time:
  # 1. Identifier le déploiement
  deployment:
    id: "deploy-123"
    commit_sha: "abc123"
    deploy_time: "2024-06-15T14:00:00Z"

  # 2. Trouver le premier commit de la PR/branche associée
  first_commit:
    sha: "def456"
    time: "2024-06-14T10:00:00Z"

  # 3. Calculer la différence
  lead_time: "28 heures"

Collecte via API

GitHub API

import requests
from datetime import datetime

def calculate_lead_time(owner: str, repo: str, deployment_sha: str) -> float:
    """
    Calcule le Lead Time en heures pour un déploiement donné.

    Le Lead Time est mesuré du premier commit de la PR
    jusqu'au timestamp du déploiement en production.
    """
    headers = {"Authorization": f"token {GITHUB_TOKEN}"}

    # Étape 1 : Trouver la PR associée au commit déployé
    pr_response = requests.get(
        f"https://api.github.com/repos/{owner}/{repo}/commits/{deployment_sha}/pulls",
        headers=headers
    )

    if not pr_response.json():
        return None  # Commit direct sans PR

    pr = pr_response.json()[0]

    # Étape 2 : Récupérer tous les commits de cette PR
    commits_response = requests.get(
        pr['commits_url'],
        headers=headers
    )
    commits = commits_response.json()

    # Le premier commit est le plus ancien
    first_commit_date = commits[0]['commit']['committer']['date']

    # Étape 3 : Récupérer le timestamp du déploiement
    deploy_time = get_deployment_timestamp(deployment_sha)

    # Étape 4 : Calculer la différence
    first_commit = datetime.fromisoformat(first_commit_date.replace('Z', '+00:00'))
    deployed = datetime.fromisoformat(deploy_time.replace('Z', '+00:00'))

    lead_time_hours = (deployed - first_commit).total_seconds() / 3600
    return lead_time_hours

Sleuth (SaaS)

sleuth.yaml

# Configuration Sleuth pour collecte automatique
version: 1
projects:
  - name: my-application
    code_deployments:
      - name: production
        provider: github_actions
        environment: production

    # Sleuth calcule automatiquement :
    # - Lead Time (premier commit → deploy)
    # - Deployment Frequency
    # - Change Failure Rate
    # - MTTR
    #
    # Intégrations supportées :
    # - GitHub, GitLab, Bitbucket
    # - Jenkins, CircleCI, GitHub Actions
    # - PagerDuty, Opsgenie, Incident.io

Améliorer le Lead Time

Le Lead Time se décompose en plusieurs phases. Identifiez laquelle consomme le plus de temps :

Phase	Durée typique problématique	Optimisation
Code	PRs de 1000+ lignes	Trunk-based development, PRs < 400 lignes
Review	> 48h en attente	Limiter le WIP, reviews < 24h, pair programming
Build	> 30 minutes	Cache des dépendances, builds incrémentaux
Tests	> 1 heure	Parallélisation, tests par impact, shift-left
Deploy	Manuel, > 1 jour	Automatisation complète, GitOps

3. Change Failure Rate (CFR)

Comprendre cette métrique

Le Change Failure Rate mesure le pourcentage de déploiements qui causent un incident en production ou nécessitent un rollback. C’est l’indicateur de la qualité de ce que vous livrez.

Imaginez le CFR comme votre taux de retour produit. Si vous envoyez 100 colis et que 30 reviennent pour défaut, vous avez un problème de qualité. De même, si 30% de vos déploiements causent des incidents, vos processus de validation sont insuffisants.

Définir ce qui compte comme un échec

Un déploiement est considéré comme “failed” si l’une de ces conditions est remplie dans les 24-48h suivant le déploiement :

• Un rollback est effectué
• Un incident est créé et lié au déploiement
• Un hotfix urgent est déployé
• Une dégradation de service est détectée

Méthode de calcul

# Calcul du Change Failure Rate
periode: "2024-06"

statistiques:
  deployments_total: 100
  deployments_failed:
    rollbacks: 3
    incidents_lies: 2
    hotfixes: 1
  total_failures: 6

# CFR = (failures / total) × 100
change_failure_rate: "6%"

Collecte et corrélation

La difficulté du CFR réside dans la corrélation entre déploiements et incidents. Voici deux approches :

Annotations Kubernetes

# Annotations sur les Deployments Kubernetes
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    # Identifiant unique du déploiement
    metrics.dora/deployment-id: "deploy-2024-06-15-001"
    # Statut mis à jour en cas de problème
    metrics.dora/status: "success"  # ou "rolled-back", "failed"
    # Timestamp pour corrélation
    metrics.dora/deployed-at: "2024-06-15T14:00:00Z"

Script de corrélation

from datetime import datetime, timedelta

def calculate_cfr(start_date: str, end_date: str) -> float:
    """
    Calcule le Change Failure Rate sur une période donnée.

    Un déploiement est marqué comme 'failed' si dans les 24h :
    - Un rollback a été effectué
    - Un incident a été lié au déploiement
    - Un hotfix a été déployé
    """
    deployments = get_deployments(start_date, end_date)
    incidents = get_incidents(start_date, end_date)

    failed_count = 0
    window = timedelta(hours=24)

    for deploy in deployments:
        deploy_time = datetime.fromisoformat(deploy['timestamp'])

        # Vérifier si rollback dans les 24h
        if has_rollback_within(deploy, window):
            failed_count += 1
            continue

        # Vérifier si incident lié
        for incident in incidents:
            incident_time = datetime.fromisoformat(incident['created_at'])

            # L'incident doit être dans la fenêtre de 24h
            if deploy_time <= incident_time <= deploy_time + window:
                # Vérifier le lien explicite ou par service
                if is_deployment_related(incident, deploy):
                    failed_count += 1
                    break

    cfr = (failed_count / len(deployments)) * 100
    return round(cfr, 2)

Améliorer le Change Failure Rate

Un CFR élevé révèle des problèmes dans votre chaîne de qualité :

Cause fréquente	Diagnostic	Solution
Tests insuffisants	Coverage < 60%	Augmenter les tests E2E, tests de contrat
Erreurs de configuration	Configs différentes dev/prod	Infrastructure as Code, validation pre-deploy
Changements trop gros	PRs > 1000 lignes	Smaller batches, feature flags
Environnements différents	”Ça marche sur ma machine”	Parité dev/staging/prod, containers
Données de test irréalistes	Tests passent, prod échoue	Anonymisation de données prod, chaos engineering

4. Mean Time to Recover (MTTR)

Comprendre cette métrique

Le MTTR mesure le temps moyen pour restaurer le service après un incident. C’est l’indicateur de votre résilience — votre capacité à rebondir quand les choses tournent mal.

Pensez au MTTR comme au temps de réponse des urgences. Face à un incendie, ce qui compte n’est pas qu’il ne se produise jamais (impossible), mais la rapidité avec laquelle les pompiers arrivent et maîtrisent la situation. Une équipe avec un MTTR de 6 mois laisse ses utilisateurs sans service pendant des mois. Une équipe Elite restaure le service en moins d’une heure.

MTTR vs autres métriques de temps

Le MTTR DORA mesure spécifiquement le temps de restauration du service. Il existe d’autres métriques comme le MTTA (Time to Acknowledge), le MTTD (Time to Detect), ou le MTTI (Time to Investigate). Pour DORA, concentrez-vous sur le temps total : détection → résolution.

Méthode de calcul

# Calcul du MTTR mensuel
periode: "2024-06"

incidents:
  - id: "INC-001"
    detected_at: "2024-06-05T10:00:00Z"
    resolved_at: "2024-06-05T10:45:00Z"
    recovery_time: "45 minutes"

  - id: "INC-002"
    detected_at: "2024-06-12T14:30:00Z"
    resolved_at: "2024-06-12T16:00:00Z"
    recovery_time: "90 minutes"

  - id: "INC-003"
    detected_at: "2024-06-20T03:00:00Z"
    resolved_at: "2024-06-20T03:20:00Z"
    recovery_time: "20 minutes"

# MTTR = moyenne des temps de recovery
mttr: "(45 + 90 + 20) / 3 = 51.67 minutes"

Collecte depuis les outils d’incident

PagerDuty

import pdpyras
from datetime import datetime
from statistics import mean

def get_mttr_from_pagerduty(start_date: str, end_date: str) -> float:
    """
    Récupère les incidents PagerDuty résolus et calcule le MTTR.

    Ne prend en compte que les incidents de production résolus.
    Retourne le MTTR en minutes.
    """
    session = pdpyras.APISession(PAGERDUTY_TOKEN)

    # Récupérer uniquement les incidents résolus
    incidents = session.iter_all(
        'incidents',
        params={
            'since': start_date,
            'until': end_date,
            'statuses[]': ['resolved'],
            # Filtrer par service de production
            'service_ids[]': PRODUCTION_SERVICE_IDS
        }
    )

    recovery_times = []

    for incident in incidents:
        created = datetime.fromisoformat(incident['created_at'])
        resolved = datetime.fromisoformat(incident['resolved_at'])

        # Temps de recovery en minutes
        recovery_minutes = (resolved - created).total_seconds() / 60
        recovery_times.append(recovery_minutes)

    if not recovery_times:
        return 0.0

    mttr = mean(recovery_times)
    return round(mttr, 2)

Incident.io

# Incident.io calcule automatiquement plusieurs métriques
# accessibles via leur API ou leur dashboard

metriques_disponibles:
  - time_to_acknowledge  # Temps avant première réponse
  - time_to_mitigate     # Temps avant mitigation
  - time_to_resolve      # MTTR - temps total de résolution

# Export des métriques via API
api_query: |
  GET /v2/metrics/incidents
  ?created_at[gte]=2024-06-01
  &created_at[lt]=2024-07-01
  &metrics[]=time_to_resolve

# Ou via leur langage de requête
analytics_query: |
  incidents
  | where created_at >= ago(30d)
  | where severity in ("critical", "major")
  | summarize
      mttr_minutes = avg(resolve_duration_minutes),
      incident_count = count()

Améliorer le MTTR

Le MTTR se décompose en plusieurs phases. Chacune peut être optimisée :

Phase	Ce qu’elle couvre	Leviers d’amélioration
Détection	Temps avant de savoir qu’il y a un problème	Alerting proactif, SLOs bien définis, monitoring synthétique
Diagnostic	Temps pour comprendre la cause	Observabilité complète (logs, traces, metrics), dashboards clairs
Mitigation	Temps pour arrêter l’hémorragie	Rollback automatique en 1 clic, feature flags, circuit breakers
Résolution	Temps pour corriger définitivement	Runbooks à jour, escalation claire, post-mortems

Architecture de collecte

Vue d’ensemble du flux de données

Pour que vos métriques DORA soient fiables, vous devez mettre en place une architecture de collecte automatisée. Les données proviennent de sources diverses — votre gestionnaire de code, votre pipeline CI/CD, votre système d’incidents — et convergent vers un dashboard centralisé.

Composants de l’architecture

L’architecture de collecte DORA comprend quatre couches distinctes :

Couche	Rôle	Exemples d’outils
Sources	Émettent les événements bruts	GitHub, GitLab, ArgoCD, PagerDuty, Opsgenie
Collecteur	Agrège et normalise les données	Scripts Python, OpenTelemetry, webhooks
Stockage	Conserve les séries temporelles	Prometheus, InfluxDB, TimescaleDB
Visualisation	Affiche les dashboards	Grafana, Datadog, custom

Commencez simple

Vous n’avez pas besoin d’une architecture complexe pour démarrer. Un simple script qui collecte les données une fois par jour et les stocke dans une base PostgreSQL suffit pour les premières semaines. Complexifiez uniquement quand vous avez validé la valeur des métriques.

Dashboard Grafana

Voici une configuration Grafana pour afficher les 4 métriques DORA. Chaque panel utilise des seuils colorés basés sur les niveaux de performance DORA :

{
  "dashboard": {
    "title": "DORA Metrics Dashboard",
    "description": "Vue d'ensemble des 4 métriques DORA",
    "panels": [
      {
        "title": "Deployment Frequency (7 jours)",
        "type": "stat",
        "description": "Nombre de déploiements réussis cette semaine",
        "targets": [{
          "expr": "sum(increase(deployments_total{env=\"production\", status=\"success\"}[7d]))"
        }],
        "thresholds": {
          "steps": [
            {"color": "red", "value": 0},
            {"color": "orange", "value": 1},
            {"color": "yellow", "value": 4},
            {"color": "green", "value": 7}
          ]
        }
      },
      {
        "title": "Lead Time (heures)",
        "type": "stat",
        "description": "Temps moyen commit → production",
        "targets": [{
          "expr": "avg(deployment_lead_time_hours{env=\"production\"})"
        }],
        "thresholds": {
          "steps": [
            {"color": "green", "value": 0},
            {"color": "yellow", "value": 24},
            {"color": "orange", "value": 168},
            {"color": "red", "value": 720}
          ]
        }
      },
      {
        "title": "Change Failure Rate (%)",
        "type": "gauge",
        "description": "Pourcentage de déploiements causant des incidents",
        "targets": [{
          "expr": "sum(deployments_failed_total) / sum(deployments_total) * 100"
        }],
        "thresholds": {
          "steps": [
            {"color": "green", "value": 0},
            {"color": "yellow", "value": 15},
            {"color": "orange", "value": 30},
            {"color": "red", "value": 45}
          ]
        }
      },
      {
        "title": "MTTR (minutes)",
        "type": "stat",
        "description": "Temps moyen de restauration du service",
        "targets": [{
          "expr": "avg(incident_recovery_time_minutes)"
        }],
        "thresholds": {
          "steps": [
            {"color": "green", "value": 0},
            {"color": "yellow", "value": 60},
            {"color": "orange", "value": 1440},
            {"color": "red", "value": 10080}
          ]
        }
      }
    ]
  }
}

Outils spécialisés DORA

Plutôt que de construire votre propre solution de collecte, vous pouvez utiliser des outils spécialisés. Voici une comparaison des principales options :

Outil	Type	Points forts	Idéal pour
Sleuth	SaaS	Auto-découverte, setup en 10 min	Équipes qui veulent démarrer vite
LinearB	SaaS	Métriques engineering complètes	Équipes cherchant des insights dev
Faros AI	Open source	Flexible, 100+ intégrations	Organisations avec contraintes data
Port	SaaS	Developer portal + DORA intégré	Platform engineering mature
Four Keys	Open source	Créé par Google, GCP-native	Équipes sur Google Cloud
Haystack	Open source	Self-hosted, privacy-first	Organisations sensibles aux données

Déployer Four Keys (Google)

Four Keys est l’outil open source de référence, créé par l’équipe DORA chez Google. Il se déploie sur Google Cloud Platform :

# Cloner le repository Four Keys
git clone https://github.com/GoogleCloudPlatform/fourkeys.git
cd fourkeys

# Configurer le projet GCP
export PROJECT_ID="mon-projet-dora"
export REGION="europe-west1"

# Lancer le script de déploiement
# Crée : BigQuery, Cloud Run, Pub/Sub, Cloud Build triggers
./setup/setup.sh

# Vérifier le déploiement
gcloud run services list --project=$PROJECT_ID

Alternatives à GCP

Si vous n’êtes pas sur Google Cloud, Faros AI ou Haystack offrent des alternatives self-hosted qui fonctionnent sur n’importe quelle infrastructure.

Cycle d’amélioration continue

L’implémentation des métriques DORA n’est pas une fin en soi. L’objectif est d’utiliser ces données pour améliorer continuellement vos pratiques. Voici le cycle recommandé :

Les 4 phases du cycle

1. Mesurer le baseline

   Collectez 2 à 4 semaines de données avant de tenter toute amélioration. Ce baseline vous permettra de mesurer l’impact réel de vos actions. Sans baseline, vous ne saurez jamais si vos changements ont eu un effet positif.

2. Analyser les goulots

   Identifiez quelle métrique est la plus faible et pourquoi. Utilisez les données pour trouver les causes racines. Par exemple, si votre Lead Time est élevé, décomposez-le : est-ce le temps de review ? Le build ? Les tests ?

3. Améliorer un processus

   Concentrez-vous sur une seule métrique à la fois. Implémentez un changement ciblé (ex: limiter la taille des PRs, paralléliser les tests) et donnez-lui le temps de produire des effets (2-4 semaines minimum).

4. Valider les résultats

   Comparez les nouvelles mesures au baseline. Le changement a-t-il eu l’effet escompté ? Y a-t-il eu des effets secondaires sur les autres métriques ? Documentez les apprentissages.

Plan d’implémentation

Voici un plan réaliste pour implémenter les métriques DORA dans votre organisation :

1. Semaine 1-2 : Instrumentation

   • Ajouter les webhooks de tracking dans vos pipelines CI/CD
   • Configurer la corrélation entre déploiements et incidents
   • Valider que les données arrivent correctement

2. Semaine 3-4 : Baseline et Dashboard

   • Déployer un dashboard Grafana basique
   • Collecter le baseline sur 2 semaines complètes
   • Partager le dashboard avec les équipes (lecture seule)

3. Mois 2 : Première amélioration

   • Identifier la métrique la plus faible
   • Choisir une action d’amélioration ciblée
   • Implémenter et mesurer l’impact

4. Mois 3+ : Culture de l’amélioration

   • Instaurer une revue mensuelle des métriques
   • Définir des objectifs par équipe (réalistes)
   • Célébrer les améliorations, sans blâmer les régressions

Éviter le piège des métriques

Les métriques DORA ne doivent jamais être utilisées pour évaluer ou comparer les individus. Utilisez-les uniquement pour améliorer les processus d’équipe. Sinon, vous créerez des comportements de gaming qui rendront les métriques inutiles.

Guides des outils de collecte

Pour aller plus loin dans l’implémentation, consultez ces guides spécifiques :

GitHub Actions Configurer la collecte des métriques depuis les workflows GitHub.

GitLab CI/CD Instrumenter vos pipelines GitLab pour les métriques DORA.

Prometheus Stockage et alerting des métriques temporelles.

Grafana Créer des dashboards de visualisation DORA.

Ressources complémentaires

Ressource	Description
DORA.dev	Site officiel du programme DORA avec outils et recherche
State of DevOps Report	Rapport annuel avec les dernières données sur 36 000+ professionnels
Four Keys	Outil open source de collecte DORA par Google
Accelerate	Le livre fondateur par Nicole Forsgren, Jez Humble et Gene Kim

À retenir

Les métriques DORA constituent le standard de mesure de la performance DevOps. Voici les points clés de ce guide :

• 4 métriques mesurent votre performance : Deployment Frequency, Lead Time, Change Failure Rate, MTTR
• 2 dimensions complémentaires : throughput (DF, LT) pour la vélocité, stability (CFR, MTTR) pour la fiabilité
• Les équipes Elite déploient 208× plus fréquemment avec un MTTR 2 604× plus rapide
• Collectez automatiquement via webhooks CI/CD et corrélation avec les incidents
• Partagez le dashboard avec toutes les équipes pour créer une culture de la mesure
• Améliorez une métrique à la fois pour voir l’impact réel
• Les métriques DORA prédisent le succès organisationnel — ce n’est pas juste de la vanité

Prochaine étape

Commencez par instrumenter vos déploiements cette semaine. Même une collecte manuelle dans un spreadsheet est mieux que pas de données du tout. L’automatisation viendra ensuite.

×

📖 Voir la documentation →