Mesurer sans se mentir

L’Étape précédente s’est close sur la question qui décide de tout le reste : est-ce que ces pratiques tiennent ?

Le problème, c’est qu’on essaie de mesurer un système où la production est devenue abondante avec les métriques d’un monde où elle était rare. C’est la meilleure façon de se mentir avec des chiffres : les indicateurs évidents ne survivent pas aux agents.

---

Pourquoi les métriques de productivité ne marchent plus ?

Parce qu’elles reposent toutes sur un présupposé devenu faux : que produire est difficile. Lignes de code, nombre de commits, PR fermées, points de vélocité — tant que chaque ligne coûtait du temps humain, le volume disait quelque chose, même grossièrement.

Un agent inverse la rareté. La production est maintenant la partie bon marché du système, et compter ce qu’il produit revient à mesurer votre facture de tokens, pas votre progrès. Un débit qui double n’est une bonne nouvelle que si ce qui sort vaut quelque chose — et c’est précisément ce que ces métriques ne voient pas.

Pire : la loi de Goodhart (toute mesure qui devient un objectif cesse d’être une bonne mesure) change carrément d’échelle. Un humain triche avec une métrique au prix d’un effort et d’une gêne. Un agent la satisfait littéralement, sans le moindre état d’âme, parce que c’est ce qu’il fait de toute consigne. L’IA dans la CI l’a posé : un agent satisfait ce qui est vérifié, et exactement ça.

Donnez un objectif de volume à une équipe assistée, et vous l’aurez. Dans la semaine. Au centuple.

Même prudence avec les métriques que les outils vous servent tout cuites : taux d’acceptation des suggestions, pourcentage de code généré, sessions actives. Elles mesurent l’adoption, pas l’amélioration. Utiles pour savoir si l’outil est utilisé, parfaitement muettes sur la question de savoir s’il rend le produit meilleur. Un taux d’acceptation élevé, ça peut signaler un agent pertinent — ou une équipe qui tamponne.

Que mesurer à la place ?

Les effets, jamais le débit. Ce qui reste mesurable honnêtement se trouve aux frontières du système et en aval, là où l’agent ne peut pas produire le chiffre directement, parce que le chiffre constate ce qui est arrivé au code, pas ce que le code déclare.

• La cadence réelle se lit sur le trajet : le temps entre une issue prête et son changement en production. C’est la seule vitesse qui compte, parce qu’elle intègre tout ce que le volume ignore — la CI qui itère, la revue qui bloque, le rework qui recommence. Un débit de PR qui double pendant que le délai issue-production stagne ne dit qu’une chose : le goulot s’est déplacé.
• La qualité se lit dans le taux de retour : reverts, hotfixes, bugs échappés en production, PR reprises après merge. C’est le verdict différé du code. Pas « est-ce que ça semble correct ? » mais « est-ce que ça a tenu ? ». À quoi s’ajoute un indicateur propre au développement assisté : le taux de refus des productions d’agent. Et attention, c’est un taux de refus nul qui doit vous alarmer. Le refus rapide est une pratique saine ; s’il ne se produit jamais, ce n’est pas que tout est bon, c’est que plus personne ne refuse.
• La revue qui lit encore se mesure par ses traces : des approbations systématiquement sans commentaire, des délais d’approbation insensibles à la taille du diff. Un diff de mille lignes approuvé aussi vite qu’un diff de dix n’a été lu ni l’un ni l’autre.

Et maintenant la règle qui rend tout ça honnête : aucun de ces indicateurs ne se lit seul. Chaque métrique de vitesse va avec sa contrepartie de qualité — délai issue-production avec taux de retour, débit de merge avec taux de revert. Comme ça, améliorer l’une en sacrifiant l’autre devient visible au lieu de passer pour un progrès.

Une métrique isolée est une cible offerte. Une paire en tension est un instrument.

LE CRAFTOMANCER

Ne donnez jamais une métrique en objectif à un agent. Ni dans un prompt, ni dans le dossier de contexte, ni dans un verdict de CI mal conçu. « Augmente la couverture » produit des tests décoratifs ; « réduis les warnings » produit des suppressions d’avertissement ; « accélère le pipeline » produit des tests sautés. L’agent atteindra le chiffre, par le chemin le plus court. C’est la loi de Goodhart à la vitesse de la machine. Les métriques servent à observer le système, jamais à piloter un modèle.

Concrètement, cette phrase-là n’a rien à faire dans un prompt, et rien à faire dans un CLAUDE.md :

Augmente la couverture de tests à 80 %

Vous l’aurez, vos 80 %. Vous n’aurez pas les tests.

Combien ça coûte vraiment ?

Beaucoup plus que la facture de tokens, qui est le coût visible — donc celui qu’on surveille. Vous connaissez l’histoire du type qui cherche ses clés sous le lampadaire, pas parce qu’il les a perdues là, mais parce que c’est le seul endroit éclairé ? Voilà.

L’unité de compte honnête, ce n’est pas le coût du token : c’est le coût du changement mergé qui survit. Ce qui inclut les tokens, oui, mais aussi :

• les minutes de CI consommées par les itérations (la boucle de feedback est un coût de production) ;
• le temps de revue humaine ;
• et surtout le rework — le changement repris, le revert, la deuxième PR qui corrige la première.

Une PR bon marché reprise deux fois coûte plus cher qu’une PR chère qui tient. Ramener le coût à ce qui survit en production rend cette arithmétique visible, et elle surprend souvent.

Il y a une deuxième tricherie comptable, plus subtile : le contrefactuel flatteur. Comparer le coût de l’agent au temps qu’« aurait pris » la tâche à la main, en oubliant soigneusement ce que l’assistance vous coûte à vous. Les agents autonomes l’ont posé : l’investissement s’est déplacé vers l’amont et l’aval. Spécifier, relire, entretenir le dossier de contexte et les verdicts — ce temps n’a pas disparu, il a changé de place. Un bilan qui ne le compte pas ne compare pas deux façons de travailler : il compare un coût complet à un coût tronqué.

Comment garder ses chiffres honnêtes ?

En décidant une bonne fois à quoi ils servent. Une métrique d’équipe a deux destins possibles — instrument d’observation ou instrument d’évaluation — et le second tue le premier.

Le jour où un indicateur entre dans l’évaluation des personnes, il cesse de décrire le système et se met à décrire ce que les gens veulent montrer. Avec des agents à disposition, le chiffre demandé sera produit, et vite. Toutes les métriques de cette page mesurent le système (pipeline, pratiques, outillage), jamais les individus.

Deux disciplines complètent ce statut :

• Des tendances, pas des cibles. La valeur absolue d’un indicateur dépend beaucoup trop du projet pour être comparée à un seuil universel. Sa pente, elle, vous appartient. Un taux de retour qui monte depuis trois mois est une information ; « être sous les 5 % » est une cible qui attend son Goodhart.
• La mesure avant le changement. Chaque évolution de pratique — nouvel outil, nouveau gate de CI, nouvelle norme de revue — se juge sur les paires d’indicateurs relevées avant et après, pas sur l’impression d’amélioration.

C’est exactement le même réflexe que face à une sortie de modèle : la conviction ne prouve rien, la trace si.

En pratique

• Cessez de compter la production (lignes, commits, PR, points) : un agent rend ces chiffres abondants, donc muets.
• Mesurez aux frontières : délai issue-production pour la cadence, taux de retour (reverts, hotfixes, reprises) pour la qualité, traces de revue (approbations sans commentaire, délais insensibles à la taille) pour le tampon.
• Lisez toute métrique de vitesse appariée à sa contrepartie de qualité ; une métrique isolée est une cible offerte.
• Un taux de refus des PR d’agent durablement nul est une alarme, pas une réussite.
• Comptez le coût par changement mergé qui survit (tokens, CI, revue, rework) et incluez votre propre temps d’amont et d’aval dans le bilan.
• Jamais une métrique en objectif dans le contexte d’un agent ; jamais une métrique d’observation dans l’évaluation des personnes.
• Des tendances et des avant/après, pas des cibles chiffrées.

Cette Étape clôt « La pratique ». La promesse de la Section tenait en une ligne : industrialiser le développement assisté sans sacrifier la qualité. La mesure honnête, c’est ce qui transforme cette promesse en constat. Le reste, le craft ne se mesure qu’en l’exerçant.