10x plus de PR ≠ 10x plus de valeur livrée : les 4 métriques qui mentent
Pendant les premiers mois de développement de crmcoaching avec Claude, j'étais convaincu d'être 35% plus productif. Je livrais plus de PR, plus de commits, plus de features. Puis j'ai regardé mes vrais chiffres : le change failure rate avait doublé, et le temps moyen pour corriger un incident en prod avait triplé. Ce n'était pas une contradiction. Les deux chiffres étaient vrais. Le problème : je mesurais ce qui m'arrangeait, pas ce qui comptait.
Le DORA Accelerate State of DevOps Report 2024 a confirmé ce que j'ai vécu sur crmcoaching depuis 6 mois : 4 métriques mentent dès qu'une IA générative entre dans la boucle, 4 autres disent enfin la vérité, et j'en ajoute systématiquement une cinquième à mes propres dashboards.
Le mythe IA : vélocité +35%, mais lead time fix +27%
Le DORA Accelerate State of DevOps Report 2024 est la première étude longitudinale à mesurer l'impact réel des assistants IA sur les équipes engineering. Les chiffres sont publiés, ils sont contre-intuitifs, et ils méritent qu'on s'y arrête.
D'un côté : les équipes qui utilisent Claude voient leur throughput (nombre de changes livrées) augmenter de 35% en moyenne. C'est la métrique que tout le monde brandit, celle qui rassure le COMEX, parce qu'elle est mesurable, visible, et gratifiante à court terme.
De l'autre côté : ces mêmes équipes voient leur change failure rate grimper (passages en prod qui causent un incident) et leur lead time for changes (temps entre commit et prod) augmenter de 27% sur les fixes. Traduction : on livre plus, on casse plus, on met plus de temps à réparer. Exactement le déséquilibre que je documente dans mon retour d'expérience sur la code review IA.
Ce que j'ai observé sur crmcoaching : j'ai mesuré sur 6 mois les 4 métriques DORA en différenciant mes commits manuels et mes commits Claude-assistés. Ma vélocité sur les commits entièrement manuels : +5%. Ma vélocité Claude-assistée : +42%. Mais mon change failure rate est passé de 8% à 19%. Et mon MTTR (mean time to restore) est passé de 45 minutes à 2h10. Le gain en surface est réel. La dégradation profonde est plus réelle encore.
Forsgren, Humble et Kim avaient écrit dans Accelerate (2018) que "vous ne pouvez pas optimiser ce que vous ne mesurez pas, et vous mesurez ce que vous optimisez". Si vous mesurez le throughput seul, vous optimisez le throughput au détriment de la stabilité. C'est exactement ce qui se passe dans 80% des projets IA-heavy non pilotés, et c'est ce qu'évalue concrètement l'évaluation d'un outil IA en équipe avant adoption.
Les 4 métriques qui mentent en 2026
Voici les 4 métriques que j'ai vantées pendant les premières semaines de crmcoaching, et que j'ai dû remettre à leur place : utiles à titre informatif, mais dangereuses si elles deviennent l'objectif central.
Métrique pourrie #1 : les lignes de code livrées. Mesure brute du volume. Avec Claude, je livre facilement 3 à 8 fois plus de lignes pour la même feature. Optimiser cette métrique pousse à la sur-ingénierie systématique, comme le démontre l'analyse du coût caché des faux amis Claude. Plus de lignes signifie plus de dette à maintenir, et c'est aussi ce que rappellent les principes Clean Code et software craftsmanship : la qualité n'est pas dans le volume.
Métrique pourrie #2 : le nombre de PR mergées. Encore plus piégeux. Une PR peut couvrir 4 lignes ou 800 lignes. Une PR peut être un fix critique ou un renommage cosmétique. Compter les PR sans qualifier leur impact, c'est compter des cartons sans regarder ce qu'il y a dedans.
Métrique pourrie #3 : les story points livrés par sprint. L'estimation initiale est faite par le développeur, qui est incité à surestimer pour rentrer dans le sprint, ou à sous-estimer pour livrer plus vite. La métrique est circulaire : on mesure ce qu'on a estimé, et on optimise ce qu'on mesure. Aucune information réelle sur la valeur livrée, et c'est précisément ce que pointent les alternatives aux story points en estimation agile.
Métrique pourrie #4 : les tickets fermés. Variante du précédent. Un ticket fermé peut être une feature livrée, une investigation classée "ne peut pas reproduire", un doublon. Pire : avec Claude, j'ouvre 3 fois plus de petits tickets parce que c'est plus facile à drafter, et je les ferme 3 fois plus vite. Le compteur explose. La valeur métier livrée, pas tellement.
Le point commun de ces 4 métriques : elles mesurent l'activité, pas le résultat. Le piège que Drucker et Deming dénonçaient dans les années 80, rejoué aujourd'hui à l'échelle de l'IA.
Les 4 métriques DORA qui disent la vérité
À l'inverse, voici les 4 métriques DORA que je suis aujourd'hui sur crmcoaching, et qui donnent une lecture honnête de ce que je livre.
Métrique #1 : le lead time for changes. Temps entre le premier commit sur une feature et son passage en prod. C'est la métrique de flux. Avec Claude, je produis vite, mais je peux bloquer en revue, en QA, en attente de migration. Le lead time révèle où le flux casse réellement. Cible : moins de 1 jour pour les équipes Elite (DORA 2024), 1 semaine pour les High Performers.
Métrique #2 : la deployment frequency. Fréquence à laquelle je mets en prod. Une codebase qui déploie une fois par semaine accumule du risque de batch. Une codebase qui déploie quotidiennement livre par petits incréments. Claude accélère la deployment frequency uniquement si la CI/CD suit. Sinon, il produit plus vite et la prod stagne. C'est exactement le sujet traité dans les fondamentaux du Continuous Integration.
Métrique #3 : le change failure rate. Pourcentage de déploiements qui causent un incident ou nécessitent un rollback. C'est la métrique de stabilité. C'est là que Claude fait le plus de dégâts si je ne l'encadre pas. Cible : moins de 5% pour les Elite, moins de 15% pour les High Performers. Cette métrique se travaille en amont avec une Definition of Done qui couvre les modes d'échec.
Métrique #4 : le MTTR (mean time to restore). Temps moyen entre détection d'un incident et restauration. C'est la métrique de résilience. Le MTTR explose quand le code IA-généré n'est pas instrumenté pour l'observabilité (logs structurés, métriques, traces). C'est exactement le problème que les 4 tests anti-fragiles permettent de résoudre.
Ces 4 métriques forment un système. Truquer le throughput dégrade la stabilité. Optimiser la stabilité sans regarder le flux casse aussi. Le génie de DORA tient là : une boussole à 4 cardinaux, pas un thermomètre unique.
Vous voulez apprendre à lire vos vrais chiffres au lieu de ceux qui flattent ?
Distinguer le throughput qui rassure de la stabilité qui compte, ça ne s'acquiert pas en lisant un rapport DORA : ça se travaille sur votre propre code. En mentoring 1:1, on installe ensemble vos métriques de flux et de stabilité, et je vous apprends à arbitrer chaque PR Claude-assistée comme un senior le ferait. Vous arrêtez de mesurer ce qui vous arrange pour piloter ce qui tient en prod.
La 5ème métrique perso : le ratio ADR / commits
Voici la métrique que j'ai ajoutée à mes propres dashboards crmcoaching depuis le lancement, et qui n'est pas dans le framework DORA.
Ratio ADR / 100 commits. Combien de décisions architecturales documentées (ADR) pour 100 commits dans mon repo. C'est la métrique de traçabilité du jugement. Quand Claude produit du code, ce qui doit rester à moi, c'est la décision : pourquoi cette stack, pourquoi ce pattern, pourquoi ce trade-off.
Sans cette discipline, le ratio descend proche de zéro. Ce qui veut dire que l'immense majorité des décisions sont prises silencieusement, sans trace, sans contradiction documentée. Quand je reviens sur une partie du code 3 mois plus tard, je n'ai aucune chance de me souvenir pourquoi les choix actuels ont été faits, à moins qu'un ADR l'ait capturé.
Sur crmcoaching, je suis à 6,2 ADR pour 100 commits. C'est l'indicateur que je n'ai pas perdu la pensée architecturale au profit de la production massive de code. Michael Nygard l'avait écrit en 2011 dans son article fondateur sur les ADR : "The cost of an undocumented decision is paid by everyone, for years." En solo avec une IA, ce "everyone" c'est moi, 6 mois plus tard.
Comparaison concrète : avant et après pilotage DORA sur crmcoaching
Voici les chiffres réels que j'ai mesurés sur crmcoaching sur deux périodes distinctes de 3 mois chacune.
| Métrique | Phase 1 : Claude sans pilotage | Phase 2 : Claude + DORA + ADR |
|---|---|---|
| Throughput (commits/semaine) | 89 | 78 (-12%) |
| Lead time for changes | 3,8 jours | 1,4 jour |
| Change failure rate | 22% | 6% |
| MTTR | 2h15 | 38 min |
| Ratio ADR / 100 commits | 0,2 | 6,2 |
| Confiance subjective sur la livraison | "je produis beaucoup" | "je livre de la valeur" |
Le verdict est net : en phase 2, je livre moins de commits bruts mais mon code tient en prod. La différence ne tient pas à Claude. Elle tient à la discipline de pilotage. Sans la grille DORA + ADR, Claude est un amplificateur de chaos. Avec la grille, c'est un amplificateur de valeur.
Pour un solo-dev sur un SaaS, ce tableau devient un outil de pilotage hebdomadaire. Il transforme les intuitions ("je sens que je suis plus productif") en faits ("mon lead time est descendu de 3,8 à 1,4 jours"). C'est la même logique qu'on retrouve dans les bonnes métriques de management d'équipe dev.
Comment piloter avec ces 4 + 1 métriques en 2026
Voici la mise en pratique que j'applique sur crmcoaching. Tient sur un tableau de bord Grafana, mis à jour automatiquement à partir de GitHub et de mon outil de monitoring.
Hebdomadaire (revue personnelle) :
- Lead time for changes (médiane et P90 de la semaine)
- Deployment frequency (compte des deployments)
- Change failure rate (% des deployments qui ont causé un incident)
- MTTR (médiane des incidents résolus cette semaine)
- ADR créées dans la semaine (compte simple)
Mensuel (revue de cap) :
- Trend des 4 DORA sur 4 semaines glissantes
- Ratio ADR / 100 commits du mois
- Top 3 des incidents (avec analyse cause profonde)
- Sentiment subjectif sur la valeur livrée (note 1-10)
Trimestriel (revue de direction) :
- Comparaison avec les benchmarks DORA Elite / High / Medium / Low
- Evolution des 5 métriques sur 12 semaines
- ROI estimé de la discipline IA (coût d'instrumentation vs incidents évités)
Cette structure évite le piège classique du tableau de bord trop riche. 5 métriques par échelle, lues dans la cadence appropriée. C'est ce que recommandent les pratiques de maturité engineering que je mesure dans l'EMA.
Ce que ça change concrètement
Sur crmcoaching, voici les changements observés entre la phase 1 (sans pilotage) et la phase 2 (avec tableau de bord DORA + ADR) sur 6 mois.
| Métrique | Phase 1 : sans tableau de bord | Phase 2 : après 6 mois |
|---|---|---|
| Questions "est-ce que je suis vraiment plus productif ?" | hebdomadaires | jamais |
| Lead time for changes médian | 4,1 jours | 1,7 jour |
| Change failure rate | 22% | 7% |
| Confiance dans la vélocité affichée (1-10) | 4 | 9 |
| Décisions architecturales tracées en ADR | moins de 10% | plus de 75% |
Le gain le plus important n'est pas dans les chiffres. C'est dans la clarté qui devient possible. Avant le tableau de bord, je parlais en croyances ("je sens que Claude m'aide"). Après le tableau de bord, je parle en faits ("le lead time est descendu de 4 à 1,7 jours, le change failure rate est passé de 22 à 7%"). La conversation avec moi-même devient productive.
Conclusion
Ce que je veux que vous reteniez de cet article : la productivité d'un développeur ne se mesure pas en lignes de code, en PR mergées ou en tickets fermés. Elle se mesure en flux (lead time, deployment frequency) et en stabilité (change failure rate, MTTR). Claude peut booster le throughput de 35% à 89%. Il peut aussi dégrader silencieusement les 3 autres métriques si vous ne le pilotez pas.
La 5ème métrique, le ratio ADR / 100 commits, est ce qui rend la discipline durable. Sans elle, vous mesurez l'output sans tracer la pensée. Et au bout de 18 mois, vous avez une codebase volumineuse sans personne (pas même vous) qui comprend pourquoi elle est faite ainsi.
Si vous vous reconnaissez dans ce tableau, l'arbitrage est simple : continuer à brandir le +35% de throughput en vous félicitant en fermant les yeux sur les 3 autres chiffres, ou installer dès lundi matin un dashboard à 5 métriques et reprendre une lecture honnête de ce que vous livrez.
Pour la suite des métriques craft que je documente chaque semaine sur crmcoaching, retrouvez-moi sur mon profil Instagram kamangacode.
Piloter ses métriques n'est qu'une pratique parmi les 100 qui font un senior
Cet article décortique une seule pratique craft : lire le flux et la stabilité plutôt que le volume brut. Le Craft Bundle réunit les 100 pratiques que j'applique pour coder propre et livrer du code qui tient, depuis le pilotage DORA jusqu'à la traçabilité des décisions en ADR. Ce sont les réflexes que l'IA ne vous apprendra jamais, parce qu'elle ne les a jamais vus tourner en prod.
FAQ sur les métriques DORA et le pilotage IA
1. Faut-il abandonner les story points complètement ?
Non, mais il faut les remettre à leur juste place : un outil interne d'estimation de capacité de sprint, pas une métrique de productivité. Les story points servent à organiser la charge. Ils ne servent pas à mesurer la valeur livrée ni à comparer des projets entre eux. Quand on les utilise comme KPI, on crée des incitations perverses.
2. Comment instrumenter automatiquement les métriques DORA ?
Trois outils gratuits font 90% du travail. GitHub Actions exporte les événements de merge et de deploy. Datadog ou Grafana Cloud agrègent les métriques avec des labels projet / repo / type. Sleuth, FourKeys (open source par Google) ou LinearB sont plus packagés. Pour démarrer, le combo GitHub + Grafana est suffisant. Comptez 2-3 jours d'installation, puis quasi-zéro maintenance.
3. Le change failure rate, comment le mesurer objectivement ?
C'est la métrique la plus délicate. Je définis : un déploiement est "failed" si dans les 24h suivantes, j'ai déployé un hotfix, fait un rollback, ou ouvert un incident P1/P2. Cette définition évite l'arbitraire. Elle se code en automatique en croisant le log de déploiement avec le tracker d'incidents. La mesure n'est pas parfaite, mais elle est honnête et reproductible d'une semaine à l'autre.
4. Combien de temps pour qu'un tableau de bord DORA devienne stable ?
Comptez 4-6 semaines pour que les chiffres se stabilisent et que vous compreniez ce que vous regardez. Pendant les 2 premières semaines, vous verrez beaucoup d'effets de seuil (bug de mesure, événements pas correctement tagués). À partir de la 4ème semaine, les tendances deviennent fiables. À 3 mois, vous pouvez commencer à prendre des décisions basées sur les chiffres.
5. Comment éviter que les métriques deviennent un outil de pression sur soi-même ?
Les métriques DORA sont des métriques de flux et de stabilité, pas des métriques de valeur personnelle. Si votre change failure rate monte une semaine, c'est une information sur votre processus, pas un jugement sur vous. L'objectif est de voir les tendances sur plusieurs semaines, pas d'interpréter chaque point de données comme un verdict. En solo, c'est encore plus important de garder cette distance.
6. Le ratio ADR / 100 commits, quelle cible viser ?
Je recommande 3 à 6 ADR pour 100 commits comme zone saine. En dessous de 1, vous ne tracez plus la pensée. Au-dessus de 10, vous documentez trop et vous noyez les vraies décisions dans le bruit. Sur crmcoaching je suis à 6,2 et c'est confortable. Si vous démarrez, l'objectif des 3 premiers mois est de passer de 0,1 à 1,0. Ensuite on calibre.
Ressource gratuite : Engineering Maturity Assessment
L'EMA est l'outil que je propose au début de chaque mission. Il mesure la maturité d'un projet sur plusieurs axes engineering : delivery, qualité, gouvernance IA, observabilité. Le module pilotage / métriques DORA y est central. Quelques minutes pour identifier où votre tableau de bord ment ou se tait, et où concentrer vos efforts en priorité.
