Mesurer sans se mentir

Le guide précédent s’est clos sur la question qui décide de tout le reste : ces pratiques tiennent-elles ? Tout, dans le développement assisté, prétend s’améliorer. Les outils le promettent, les démos le montrent, et votre propre enthousiasme le confirme volontiers. Encore faut-il le constater.

Mais mesurer un système où la production est devenue abondante avec les métriques d’un monde où elle était rare, c’est se mentir avec des chiffres : les indicateurs évidents ne survivent pas aux agents. Ce guide pose ce qui meurt, ce qui vaut encore la peine d’être compté, et comment compter sans corrompre ce qu’on mesure.

---

Le théâtre de la vélocité

Les métriques classiques de productivité (lignes de code, nombre de commits, PR fermées, points de vélocité) partagent un présupposé devenu faux : que produire est difficile. 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 désormais la partie bon marché du système. Compter ce qu’il produit, c’est 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.

La loi de Goodhart (toute mesure qui devient un objectif cesse d’être une bonne mesure) change d’échelle au passage. Un humain triche avec une métrique au prix d’un effort et d’une gêne. Un agent la satisfait littéralement et sans état d’âme, parce que c’est exactement ce qu’il fait de toute consigne. Le guide sur 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. C’est la seule promesse que le théâtre de la vélocité tient toujours.

Même prudence avec les métriques livrées par les outils eux-mêmes : 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é, muettes sur la question de savoir s’il rend le produit meilleur. Un taux d’acceptation élevé peut signaler un agent pertinent comme une équipe qui tamponne ses suggestions.

Mesurer les effets, pas 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. Les trois questions héritées du guide précédent y trouvent chacune leurs indicateurs :

• La cadence réelle se lit sur le trajet, pas sur le volume : le temps entre une issue prête et son changement en production. C’est la seule vitesse qui compte, et elle a une propriété précieuse : 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é, exactement comme le guide sur la CI l’annonçait.
• 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 « semble-t-il correct ? » mais « a-t-il tenu ? ». À quoi s’ajoute un indicateur propre au développement assisté : le taux de refus des productions d’agent. Contre-intuitivement, un taux de refus nul est le signal d’alarme. Le refus rapide est une pratique saine posée au guide précédent ; 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. Le tampon laisse des empreintes ; il suffit de les regarder.

Aucun de ces indicateurs ne se lit seul : c’est l’appariement qui les rend honnêtes. Chaque métrique de vitesse se lit avec sa contrepartie de qualité (délai issue-production avec taux de retour, débit de merge avec taux de revert), de sorte qu’améliorer l’une en sacrifiant l’autre devienne 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 tips 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.

Les coûts : compter ce qui coûte vraiment

La facture de tokens est le coût visible, donc celui qu’on surveille. Et c’est un piège de lampadaire. L’unité de compte honnête n’est pas le coût du token mais le coût du changement mergé qui survit : tokens, certes, mais aussi minutes de CI consommées par les itérations (la boucle de feedback est un coût de production, le guide sur la CI l’a posé), temps de revue humaine, et 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.

L’autre tricherie comptable, c’est le contrefactuel flatteur : comparer le coût de l’agent au temps qu’« aurait pris » la tâche à la main, en oubliant ce que l’assistance vous coûte à vous. Le premier guide de cette Section l’a 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é.

Mesurer sans corrompre

Reste la question qui décide si vos chiffres resteront vrais : à quoi servent-ils ? 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 commence à décrire ce que les gens veulent montrer. Avec des agents à disposition, le chiffre demandé sera produit, littéralement. Les métriques de cette page mesurent le système (pipeline, pratiques, outillage), jamais les individus.

Deux disciplines complètent ce statut. Les tendances plutôt que les cibles : la valeur absolue d’un indicateur dépend 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. Et 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 le même réflexe que pour 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.

Ce guide clôt « Passer à l’échelle », et avec elle le Parcours. La promesse de la Section tenait en une ligne : industrialiser le développement assisté sans sacrifier la qualité. La mesure honnête est ce qui transforme cette promesse en constat. Non pas croire que la qualité a tenu : le vérifier. Le reste relève de la pratique, pas de la lecture. Le craft ne se mesure qu’en l’exerçant.