Le code généré, le code relu
Il y a un déséquilibre nouveau dans les projets logiciels : on génère en une heure ce qu'on relit en trois jours. Le goulot d'étranglement s'est déplacé, et beaucoup d'équipes ne l'ont pas encore vu.
La production n'est plus la contrainte
Écrire mille lignes ne coûte presque plus rien. Décider si ces mille lignes font la bonne chose, ne cassent rien ailleurs et resteront compréhensibles dans un an coûte exactement ce que ça a toujours coûté : de l'attention humaine.
Le code que personne n'a lu
Le vrai risque n'est pas le bug — un bug, ça se corrige. Le risque, c'est de se retrouver avec une base de code que plus personne ne comprend vraiment, parce que personne ne l'a écrite et que la relecture est passée à la trappe.
Le jour où il faut modifier une règle métier, on ne sait plus où elle vit. Alors on ajoute une exception à côté, plutôt que de toucher à l'existant. Puis une autre. C'est comme ça qu'un projet devient lourd en dix-huit mois au lieu de dix ans.
Ce qui aide concrètement
- Des petits lots — cinquante lignes relues valent mieux que cinq cents survolées
- Des tests sur ce qui compte — pas la couverture pour la couverture : les calculs, les montants, les droits d'accès, les changements d'état
- Une règle simple — si personne ne sait expliquer ce que fait un bout de code, il n'entre pas en production
- Moins de code — la ligne la plus fiable reste celle qu'on n'a pas écrite
Vitesse réelle et vitesse ressentie
Générer vite donne une impression d'avance. Elle est bien réelle les premières semaines, puis elle se paie : chaque évolution devient plus lente, chaque correction plus risquée. Sur un outil utilisé tous les jours, la vitesse qui compte est celle du sixième mois, pas celle du premier.
En résumé
Les outils de génération de code sont très utiles — j'en utilise tous les jours. Ils déplacent simplement l'effort : moins de frappe, plus de lecture. Une équipe qui accélère la production sans renforcer la relecture n'accélère pas vraiment, elle emprunte.