La chaîne complète, pas le premier maillon
Un assistant de code accélère l'écriture et laisse la revue, l'intégration et la reprise exactement où elles étaient. Mesurer le gain sur l'écriture seule produit un chiffre spectaculaire qui ne se retrouve jamais dans le délai de livraison.
Les trois maillons suivants représentent, sur les équipes que j'observe, la majorité du temps entre une intention et une mise en production. L'écriture est rarement le goulot.
Ce déséquilibre explique l'écart entre les gains annoncés et les gains constatés. Les deux chiffres sont exacts ; ils ne mesurent pas la même chose.
Ce qui peut même se dégrader
Un volume de code produit plus vite alimente une file de revue qui n'a pas grandi, et le délai global peut augmenter. C'est l'effet contre-intuitif qu'il faut surveiller.
Le mécanisme est celui de toute file d'attente : accélérer un poste en amont sans toucher au poste suivant déplace le stock, il ne le résorbe pas. La revue devient le goulot, et elle se dégrade en qualité parce que les relecteurs traitent plus de volume à effectif constant.
S'ajoute un effet propre au code généré : il est souvent plus long et plus verbeux que le code qu'un humain aurait écrit pour le même résultat. Plus de lignes à relire, pour la même fonction.
La parade n'est pas de renoncer à l'outil, c'est de mesurer le délai de bout en bout avant de généraliser. C'est le même principe de mesure préalable que dans mesurer l'adoption, pas la satisfaction.
Les quatre mesures qui donnent le gain net
- Le délai entre l'ouverture d'un ticket et sa mise en production, avant et après. C'est la seule mesure qui compte vraiment.
- Le temps de revue par demande de fusion, qui révèle le déplacement du goulot.
- Le taux d'acceptation des suggestions, qui dit si l'outil produit du code que l'équipe garde.
- Le taux de retour après mise en production, qui vérifie que la vitesse ne s'est pas payée en défauts.
Là où le gain est réel et net
Le code jetable, les tests et la reformulation profitent pleinement de l'assistant, parce qu'ils n'ont pas de file de revue derrière eux. C'est là qu'il faut chercher le bénéfice.
Le code jetable, d'abord : scripts d'analyse, migrations ponctuelles, prototypes qui ne seront pas maintenus. Aucune revue, aucune reprise, le gain est intégral.
Les tests unitaires ensuite. Écrire un test est répétitif, contraint, et la vérification est automatique puisque le test passe ou ne passe pas. Le gain y est important et sans contrepartie.
La reformulation enfin : renommer, extraire une fonction, adapter un style. Le résultat se vérifie mécaniquement.
Ces trois usages ont une propriété commune, la même que celle qui distingue les agents qui aboutissent : le résultat est vérifiable. Le raisonnement est développé dans agent ou simple appel.
Ce que ça change à la façon de déployer
Déployer sur les usages vérifiables d'abord, mesurer le délai global ensuite, généraliser en dernier. Cet ordre évite le déploiement massif dont personne ne sait dire s'il a servi.
La séquence habituelle est inverse : on équipe toute l'équipe, l'enthousiasme est réel pendant six semaines, puis l'usage se stabilise à un niveau que personne n'a mesuré, et la question du renouvellement se pose sans donnée.
La séquence que je recommande commence par les tests et le code jetable, où le gain est incontestable et immédiat. Elle produit un premier résultat mesurable qui finance la suite.
Elle laisse aussi le temps de traiter la question du trajet du code, qui est le vrai sujet de décision en entreprise et qui prend plus longtemps que le déploiement technique. Voir choisir un assistant de code en entreprise.
La mesure qui tranche en une semaine
Le délai médian entre l'ouverture d'un ticket et sa mise en production, relevé sur les trois mois précédant le déploiement. Sans ce point de départ, aucun gain ne sera démontrable, et il ne peut pas être reconstitué après coup.
Ce qu'il ne faut pas promettre
Un pourcentage de productivité en plus est une promesse invérifiable, et elle se retourne au premier bilan. Il vaut mieux annoncer ce qu'on va mesurer.
Les chiffres qui circulent sur les gains de productivité des assistants de code portent sur des exercices contrôlés, souvent sur du code neuf, sans revue, sans dette existante. Aucune équipe ne travaille dans ces conditions.
Ce qu'on peut annoncer honnêtement : un gain net sur les tests et le code jetable, un effet neutre à positif ailleurs, et une mesure de bout en bout à trois mois pour trancher.
Cette prudence n'affaiblit pas le dossier. Elle le rend défendable au moment du bilan, ce qui est exactement ce dont une équipe a besoin pour obtenir le renouvellement.
Questions fréquentes
Un assistant de code fait-il gagner du temps ?
Sur l'écriture, oui. Sur le délai entre une intention et une mise en production, le gain dépend de la revue et de l'intégration, qui ne sont pas accélérées et peuvent devenir le goulot.
Le délai global peut-il augmenter ?
Oui. Produire plus vite alimente une file de revue à effectif constant, et le code généré est souvent plus verbeux, donc plus long à relire pour la même fonction.
Où le gain est-il net ?
Sur le code jetable, les tests unitaires et la reformulation, parce que le résultat s'y vérifie mécaniquement et qu'aucune file de revue ne suit.
Que mesurer avant de déployer ?
Le délai médian entre l'ouverture d'un ticket et sa mise en production, sur les trois mois précédents. Ce point de départ ne peut pas être reconstitué après coup.