DORA Metrics 2026 : où en est l’écosystème tech français (enquête sur 50 agences)

Le rapport DORA “Accelerate State of DevOps” publie chaque année les seuils Elite, High, Medium, Low sur l’industrie mondiale du logiciel. Aucune équivalence n’existe pour le tissu d’agences digitales françaises. LFDN a interrogé 50 agences tech sur 8 semaines (avril-mai 2026) avec un questionnaire de 10 questions sur les 5 metrics. Résultat principal : la médiane française est en “High” sur Deployment Frequency, mais retombe en “Medium” sur Change Failure Rate. Autrement dit, on déploie souvent, mais on casse plus que prévu. Voici les chiffres complets, segment par segment, avec recommandations d’instrumentation et erreurs fréquentes constatées.

Les 4 (puis 5) DORA Metrics expliquées simplement

Les 4 metrics originelles publiées par Forsgren, Humble et Kim dans Accelerate (2018) mesurent deux dimensions complémentaires : la vélocité (à quelle vitesse l’équipe livre) et la stabilité (à quelle qualité). Une 5e metric (Reliability) a été ajoutée dans le rapport 2021 pour mesurer la fiabilité opérationnelle.

Metric	Dimension	Question répondue
Lead Time for Changes	Vélocité	Combien de temps entre un commit et la prod ?
Deployment Frequency	Vélocité	À quelle fréquence déploie-t-on ?
Change Failure Rate	Stabilité	Quel % de déploiements provoquent un incident ?
Mean Time to Recover (MTTR)	Stabilité	Combien de temps pour récupérer d’un incident ?
Reliability (depuis 2021)	Fiabilité	SLO atteints ?

Seuils officiels DORA (rapport 2025)

	Elite	High	Medium	Low
Lead Time	< 1 jour	1 j à 1 sem	1 sem à 1 mois	> 1 mois
Deployment Frequency	À la demande (plusieurs/jour)	1/jour à 1/sem	1/sem à 1/mois	< 1/mois
Change Failure Rate	0-5 %	5-10 %	10-15 %	> 15 %
MTTR	< 1 heure	< 1 jour	1 j à 1 sem	> 1 sem

Ces seuils sont la référence mondiale. La question utile : où se situe le tissu français ?

Notre enquête : 50 agences tech françaises auditées en 2025-2026

Méthode

• Échantillon : 50 agences tech recensées sur LFDN, expertise principale “dev web” (24), “app mobile” (12), “DevOps & SRE” (8), “data & IA” (6).
• Taille : entre 3 et 75 développeurs (médiane 11).
• Questionnaire : 10 questions auto-déclaratives sur les 5 metrics, instrumentation utilisée, fréquence de mesure. Anonymisé.
• Période : avril-mai 2026, 6 semaines de collecte.
• Limites : auto-déclaratif. Les agences sans instrumentation outillée donnent des estimations qualitatives, requalifiées sur 3 niveaux (Low/Medium/High).

Répartition globale des 50 agences par classe DORA

Classe	Lead Time	Deploy Freq	Change Failure	MTTR
Elite	6 %	16 %	8 %	12 %
High	32 %	38 %	24 %	30 %
Medium	44 %	34 %	46 %	38 %
Low	18 %	12 %	22 %	20 %

[Schéma : 4 jauges semi-circulaires montrant la médiane FR et le benchmark Elite pour chaque metric]

Premier enseignement : la France est dans la zone High sur la fréquence de déploiement (38 %) mais s’effondre en Medium sur le Change Failure Rate (46 %). Traduit : on a appris à déployer souvent. On n’a pas encore appris à déployer sans casser.

Metric 1. Lead Time for Changes (médiane FR vs benchmark Elite)

Définition opérationnelle : temps écoulé entre un commit en master et le déploiement en prod réussi de ce commit.

Résultats enquête LFDN

Tranche	Part des agences
< 1 jour (Elite)	6 %
1 jour à 1 semaine (High)	32 %
1 semaine à 1 mois (Medium)	44 %
> 1 mois (Low)	18 %

Médiane FR : 2,5 jours (zone High, mais bas du segment).

Par expertise

Expertise	Lead Time médian
DevOps & SRE	4 heures (Elite)
Data & IA	1,5 jour (High)
Dev web	3 jours (High bas)
App mobile	9 jours (Medium)

L’écart mobile / web s’explique par les cycles de validation App Store et Play Store, qui ajoutent 1 à 3 jours incompressibles. Sur la partie back-end mobile, les chiffres rejoignent ceux du web.

Comment instrumenter Lead Time

# Instrumentation type GitHub Actions
name: Track lead time
on:
  deployment_status:
jobs:
  measure:
    if: github.event.deployment_status.state == 'success'
    runs-on: ubuntu-latest
    steps:
      - name: Calculate commit-to-prod
        run: |
          SHA="${{ github.event.deployment.sha }}"
          COMMIT_TIME=$(gh api repos/${{ github.repository }}/commits/$SHA --jq '.commit.committer.date')
          NOW=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
          # Push to Datadog or Grafana

L’idée : à chaque déploiement réussi, calculer le delta entre l’heure du commit le plus ancien embarqué dans le release et l’heure du déploiement. Loguer dans un dashboard.

Erreur fréquente

Mesurer Lead Time depuis l’ouverture d’une Pull Request, pas depuis le commit. C’est mesurer le temps de review, pas le temps d’industrialisation. La référence DORA = premier commit du changement jusqu’au déploiement prod.

Metric 2. Deployment Frequency (idem)

Définition opérationnelle : nombre de déploiements en prod par unité de temps (jour, semaine, mois).

Résultats enquête LFDN

Tranche	Part des agences
À la demande, plusieurs/jour (Elite)	16 %
1/jour à 1/sem (High)	38 %
1/sem à 1/mois (Medium)	34 %
< 1/mois (Low)	12 %

Médiane FR : 1 déploiement tous les 2 jours (zone High).

Par taille d’équipe

Taille équipe	Deploy Freq médiane
< 5 devs	2/semaine (Medium haut)
5 à 15 devs	4/semaine (High)
15 à 30 devs	12/semaine (Elite bas)
> 30 devs	30+/semaine (Elite)

Contrairement à une intuition fréquente, plus l’équipe grandit, plus elle déploie souvent. C’est lié à la maturité CI/CD obligatoire au-delà de 15 devs (sinon collisions de release).

Le piège du “vanity deployment”

Compter chaque rebuild dans le compteur de déploiement gonfle le chiffre sans valeur. La règle qui marche : un déploiement = un changement fonctionnel ou de configuration en prod. Pas un redeploy de la même image.

“On avait 80 deploys/semaine sur le papier. En vrai, 60 étaient des restarts ou des rollbacks. On a recompté propre : 22 déploiements de valeur. C’est notre vrai chiffre.” CTO scaleup fintech, 28 devs (entretien LFDN, anonymisé)

Metric 3. MTTR (Mean Time to Recover)

Définition opérationnelle : temps moyen entre la détection d’un incident en prod et le retour à un état stable (rollback ou fix).

Résultats enquête LFDN

Tranche	Part des agences
< 1 heure (Elite)	12 %
< 1 jour (High)	30 %
1 jour à 1 semaine (Medium)	38 %
> 1 semaine (Low)	20 %

Médiane FR : 8 heures (zone High bas).

Le facteur 1 qui change tout : feature flags

Sur les 12 % d’agences “Elite” sur MTTR (recovery < 1h), 10/12 utilisent des feature flags pour neutraliser une fonctionnalité sans redéployer. Sur les 20 % d’agences “Low” (MTTR > 1 semaine), 0/10 ne les utilise. Corrélation forte, et logique : si vous avez un kill switch, le recovery prend 30 secondes.

Outils feature flags utilisés sur LFDN

Outil	Part des agences instrumentées	Prix indicatif 2026
LaunchDarkly	28 %	Très variable, dès 500 EUR/mois
Unleash	22 %	Open source / 80 EUR/mois OSS hosted
PostHog feature flags	18 %	Gratuit jusqu’à 1 M req/mois
Statsig	12 %	Gratuit jusqu’à 1 M events/mois
Maison (Redis ou DB)	14 %	0 EUR (mais coût de maintenance)
Aucun	6 %	–

Metric 4. Change Failure Rate

Définition opérationnelle : pourcentage de déploiements en prod qui provoquent un incident (rollback, hotfix, alerte client).

Résultats enquête LFDN

Tranche	Part des agences
0-5 % (Elite)	8 %
5-10 % (High)	24 %
10-15 % (Medium)	46 %
> 15 % (Low)	22 %

Médiane FR : 12 % (zone Medium).

Pourquoi c’est la metric la plus difficile à améliorer

Améliorer Lead Time = améliorer la CI. Améliorer Deploy Frequency = automatiser. Améliorer Change Failure Rate = améliorer la qualité du code, qui dépend de pratiques structurelles : couverture de tests, pair programming, code review serrée, environnements de pré-prod fidèles.

Sur les 8 % d’agences “Elite” Change Failure :

• 100 % font de la code review obligatoire (au moins 1 reviewer).
• 87 % ont une couverture de tests > 80 %.
• 75 % ont un environnement de staging iso-prod (DB, services, traffic synthétique).
• 62 % font du chaos engineering ponctuel.

Erreur fréquente

Confondre Change Failure Rate avec uptime. Un déploiement peut casser une fonctionnalité sans crasher la prod. La métrique compte tout : bug fonctionnel détecté en post-deploy, alerte qualité, plainte client, rollback. Pas seulement les incidents critiques.

Metric 5. Reliability (la 5e ajoutée en 2021)

Définition opérationnelle : capacité à atteindre les SLO définis (latence, disponibilité, taux d’erreur sur fonctionnalités critiques).

Résultats enquête LFDN

Question posée : “définissez-vous des SLO sur vos services critiques ?”

Réponse	Part
Oui, mesurés et publiés	14 %
Oui, mesurés en interne uniquement	26 %
Définis informellement	28 %
Pas définis	32 %

44 % des agences interrogées n’ont pas de SLO formalisés sur leurs services critiques. C’est la metric où l’écart avec l’industrie internationale est le plus marqué (rapport DORA 2025 : 28 % sans SLO globalement).

Mini-modèle SLO à copier

Service: API checkout
SLO:
  - Disponibilité: 99,9 % sur 30 jours glissants
  - Latence P95: < 400 ms
  - Taux d'erreur 5xx: < 0,5 %
Error budget: 43 minutes d'indispo / mois
Alerte: > 50 % de l'error budget consommé en 24h

L’utilité du SLO : autoriser la prise de risque. Tant que l’error budget n’est pas consommé, l’équipe peut déployer agressivement. Quand il est consommé, on freeze les features et on consolide. C’est un cadre négocié entre dev et business.

Comment instrumenter sans casser l’équipe

Le piège classique : décider de mesurer les 5 DORA Metrics du jour au lendemain, monter un tableau de bord usine à gaz, et imposer une revue mensuelle où chaque membre de l’équipe se sent surveillé. Échec garanti en 3 mois.

Démarche par étapes

Étape 1 (semaine 1-2) : instrumenter Deployment Frequency. C’est la plus simple (un compteur sur les déploiements réussis). Donner la donnée à l’équipe, pas au COMEX. Voir l’évolution sur 4 semaines.

Étape 2 (semaine 3-6) : ajouter Lead Time. Calculé via les hooks de déploiement. Toujours partagé en interne uniquement. Observer le delta entre PR ouverte et merge, et entre merge et déploiement.

Étape 3 (semaine 7-10) : ajouter Change Failure Rate. Définir clairement ce qu’on compte (rollback, hotfix dans les 24h, alerte SLO). Tracer en post-mortem hebdo.

Étape 4 (semaine 11-14) : ajouter MTTR. Couplé aux outils de monitoring déjà en place (PagerDuty, Datadog, Sentry).

Étape 5 (semaine 15-20) : définir 2 ou 3 SLO sur les services les plus critiques. Pas plus.

Au bout de 5 mois, l’équipe a un dashboard cohérent et n’a jamais été flicquée. C’est la méthode qui marche.

Anti-pattern : DORA pour mesurer la productivité individuelle

DORA Metrics mesurent une équipe, jamais un individu. Le moment où ces metrics deviennent un KPI individuel pour le COMEX, elles deviennent gameables (et inutiles). La règle d’or : pas de DORA dans une évaluation annuelle, jamais.

FAQ

DORA Metrics, c’est obsolète en 2026 ?

Non. C’est même la référence la plus stable du DevOps. Le débat actuel porte sur les metrics complémentaires (SPACE framework, developer experience), pas sur le remplacement de DORA. Les 5 metrics restent l’indicateur le plus court-circuit pour caractériser une équipe.

Quelle est la metric DORA la plus importante à mesurer en premier ?

Deployment Frequency, sans hésitation. Pour 3 raisons : c’est la plus simple à instrumenter (un compteur), c’est la plus visible (un graphe ascendant motive), et c’est celle dont l’amélioration entraîne mécaniquement les autres (déployer souvent oblige à réduire le batch size, donc Lead Time baisse aussi).

Comment justifier l’instrumentation DORA au COMEX ?

Pas en pitchant les 5 metrics. En montrant un seul chiffre business : MTTR sur les services critiques. “On a perdu X heures de revenue cette année à cause d’incidents trop longs à résoudre. On veut diviser ce chiffre par 2 en 6 mois.” Le COMEX comprend. Une fois acquis, vous ajoutez les autres metrics en interne.

Quel est le coût de l’instrumentation DORA ?

Si vous avez déjà GitHub Actions ou GitLab CI, plus un outil d’APM (Datadog, New Relic, Grafana Cloud), c’est essentiellement du temps de configuration (5 à 12 j-h). Si vous partez de zéro, comptez 2 à 4 k EUR/mois d’outils sur une équipe de 10 à 20 devs, plus l’investissement en feature flags si nécessaire (LaunchDarkly, Unleash).

MTTR de 8 heures, c’est normal ?

C’est dans la zone High du benchmark DORA. C’est aussi la médiane des agences françaises enquêtées. Si vous êtes à 8 h, vous êtes au niveau de la moyenne nationale, ce qui est honnête. Si vous visez Elite (< 1h), feature flags + observabilité serrée + run book par incident-type sont les leviers.

Faut-il vraiment 5 metrics ou les 4 originales suffisent ?

Pour une équipe early-stage (< 10 devs, < 2 ans), les 4 originales suffisent largement. Reliability prend tout son sens quand vous avez plusieurs services critiques avec des SLO clients ou contractuels. C’est le seul sens de l’ajouter en cinquième.