Mesurer les 4 métriques DORA sans ambiguïté (définitions & calcul)
Les définitions DORA standardisent les mesures autour des déploiements, changements et incidents, à condition de garder le même périmètre de calcul pour un service ou une application (source: Google Cloud — DORA Metrics documentation (consulté 2026-05)). Les travaux à l’origine de DORA lient ces métriques à l’amélioration de la performance logicielle et organisationnelle, sous réserve de définitions stables et comparables dans le temps (source: Forsgren, Humble, Kim — Accelerate (2018)).
Fréquence de déploiement
Compte les déploiements effectifs en production par unité de temps, au niveau service ou application. Le numérateur exclut les builds CI, les merges et les releases non exposées aux utilisateurs.
Lead Time for Changes
Mesure le temps entre le premier commit lié au changement et son déploiement effectif en production. L’ancrage doit rester cohérent : ne mélangez pas premier commit, commit de merge et création de pull request.
Change Failure Rate
Calcule la part des déploiements qui causent un incident ou un rollback par rapport aux déploiements totaux. Le calcul exige une taxonomie d’incident partagée, sinon chaque équipe classe différemment les échecs.
MTTR
Mesure la durée entre le début d’un incident causé par un changement et la restauration du service au niveau attendu. L’horodatage de fin doit refléter la récupération utilisateur, pas seulement la fermeture du ticket.
Le rapport DORA 2023 relie la haute performance à des déploiements plus fréquents et à une restauration plus rapide après incident, sans remplacer vos définitions internes par des seuils arbitraires (source: DORA 2023 Accelerate State of DevOps Report — Google Cloud (2023)).
Schéma d’événements: mapper Git, CI/CD et incidents vers DORA
Le modèle doit relier chaque livraison à une chaîne vérifiable: commit, PR ou merge, build, tests, déploiement, incident, résolution. Les clés minimales sont sha, run_id et release_tag.
Chaîner les événements techniques
Dans Git, capturez commit_sha, repo, branch, pr_id et merged_at. Dans la CI, rattachez run_id, commit_sha, test_status et artifact_id.
Corréler déploiement et production
Dans Argo CD ou Spinnaker, stockez release_tag, artifact_id, environment, service et deployed_at. Le champ environment doit distinguer production et non-production.
Relier incidents et restauration
Dans PagerDuty ou Statuspage, ajoutez incident_id, service, started_at, resolved_at et, si disponible, release_tag. Cette corrélation alimente le taux d’échec et le temps de restauration.
Utilisez repo, commit_sha, pr_id, workflow_run_id, artifact_id et team. En monorepo, ajoutez path_prefix pour attribuer le changement au bon service.
Ajoutez un change_type pour distinguer hotfix, rollback, déploiement sans changement de code, feature flag, dark launch et promotion entre environnements.
Stockez tous les timestamps en UTC. Définissez une source par étape: Git pour le merge, CI pour le build, CD pour le déploiement, outil d’incident pour la résolution.
Alimentez service et team depuis les tags du dépôt, les répertoires du monorepo ou un fichier d’ownership. Les vues DORA restent segmentables sans recalcul manuel.
Widgets utiles: ce qui doit apparaître sur votre dashboard DORA
Affichez une série temporelle par service pour chaque métrique DORA. La fenêtre glissante doit limiter le bruit quotidien et signaler une dérive quand la tendance s’éloigne du comportement récent du service.
Ajoutez une vue par équipe ou stream, avec drill-down jusqu’aux PR, commits et déploiements reliés à un point anormal. Un pic de Lead Time doit pointer vers les changements concernés, pas vers une moyenne opaque.
Les cartes de corrélation doivent relier taille de PR, temps de revue et files CI/CD au Lead Time. Exemple utile: filtrer un service, isoler les PR volumineuses, puis vérifier si l’attente vient de la revue ou du pipeline.
Les alertes opérationnelles doivent partir d’une dégradation de tendance et être reliées aux horaires d’astreinte, afin d’orienter la notification vers une équipe capable d’agir.
Garde-fou anti-gamification: interdisez les objectifs bruts sur les taux et les classements individuels. Chaque widget doit ramener aux causes: attente de revue, file CI/CD, rollback, incident ou changement trop large.
Critères d’achat pour un outil DORA: intégration, gouvernance, coût total
Un achat solide se valide sur les événements disponibles. Vérifiez les connecteurs nécessaires pour GitHub, GitLab, Bitbucket, Actions, GitLab CI, Jenkins, Argo CD, Spinnaker, PagerDuty et Opsgenie.
| Critère | Test d’achat concret |
|---|---|
| Intégration | Importer commits, merges, jobs CI, déploiements CD et incidents sans script maison. |
| Historique | Rejouer les événements et backfiller les périodes passées avec les mêmes règles de calcul. |
| Robustesse | Conserver les liens après renommage de branche ou de dépôt, sans casser les séries DORA. |
| Traçabilité | Afficher la formule, les événements sources et les exclusions derrière chaque métrique. |
| Gouvernance | Activer SSO SAML/OIDC, RBAC par équipe ou projet, masquage des PII et rétention configurable. |
| Déploiement | Choisir cloud ou self-host selon les contraintes de données, réseau et administration. |
| Coût total | Comparer facturation par utilisateur ou service, ingestion, egress et effort d’intégration interne. |
La conformité doit couvrir le traitement et la conservation des données d’ingénierie: identifiants de commit, auteurs, tickets, incidents et journaux de déploiement. Le cadre doit être compatible RGPD et documenté contractuellement (source: Règlement (UE) 2016/679 (RGPD) — Journal officiel de l’UE (2016)).
Avant signature, demandez un export d’exemple. L’export doit permettre de recalculer la métrique auditée depuis les événements bruts, avec le même résultat que le dashboard.
Plan d’implémentation en 7 jours: du branchement aux alertes
Cadrer le périmètre
Listez les services suivis, leurs environnements et les équipes propriétaires. Choisissez les horodatages d’ancrage: merge Git, début ou fin de déploiement, ouverture et résolution d’incident. Fixez la granularité de reporting par équipe, service ou environnement.
Brancher SCM et CI/CD
Connectez le SCM et la chaîne CI/CD. Importez un historique récent d’événements, puis vérifiez les liens commit SHA, build, artefact et déploiement. Marquez comme incomplet tout déploiement sans SHA ou sans environnement cible.
Relier incidents et déploiements
Ajoutez des tags ou SHAs dans les tickets d’incident pour rattacher chaque impact à un déploiement. Convenez avec l’équipe SRE d’une taxonomie stable: incident utilisateur, dégradation, rollback, alerte non actionnable.
Calculer et vérifier
Lancez le calcul DORA quotidiennement sur le périmètre validé. Faites relire un échantillon par des équipes pilotes: chaque valeur doit remonter jusqu’aux événements sources, sans correction manuelle silencieuse.
Dashboard, drill-down et alertes
Construisez une vue agrégée, puis un drill-down service → déploiement → commits → incident. Définissez les destinataires des alertes: owner service, SRE d’astreinte, tech lead.
Adoption et garde-fous
Organisez une rétro d’adoption. Documentez les angles morts: hotfix manuel, incident sans ticket, déploiement hors pipeline. Publiez le journal d’audit, les règles d’exclusion visibles et les changements de taxonomie.
Continue reading
Comparaison d'Intercom Fin et des solutions de support
Un cadre technique concret pour choisir entre Intercom Fin et les solutions de support, avec un plan d’essai de 14 jours et des métriques actionnables.
Meilleures alternatives à Intercom Fin pour les startups
Shortlist par cas d’usage, workflow de test 48 h et prompts prêts à l’emploi pour choisir une alternative viable à Intercom Fin sans perdre de temps.
Comment remplacer Intercom Fin par une solution abordable
Un plan modulaire prêt à câbler pour remplacer Intercom Fin à moindre coût, avec architecture, règles de routage, prompts et checklists pour lancer en production rapidement.