Pourquoi la revue habituelle glisse dessus
Un développeur qui se trompe laisse des traces : une variable mal nommée, un commentaire hésitant, une indentation bancale, un bout de code commenté « au cas où ». La revue humaine s'est construite sur ces signaux, et elle les lit très vite.
Le code généré n'en émet aucun. Il est idiomatique, commenté, typé, testé. Il a l'air d'avoir été écrit par le meilleur de l'équipe un bon jour. La revue glisse — et c'est exactement ce qui rend certains défauts coûteux.
Le test qui ne teste rien
Un diff ajoute un test au calcul de TVA. Il est vert, bien écrit, il monte la couverture. Il recalcule la valeur attendue avec la fonction qu'il teste.
Ce test restera vert quoi qu'il arrive. Changez le taux d'une catégorie : vert. Inversez une condition : vert. Il ne détecte aucune régression, et il fait monter l'indicateur qui sert à décider qu'on peut fusionner. C'est le pire des deux mondes : aucune protection, plus de confiance.
La question à poser devant tout test généré tient en une phrase : d'où vient la valeur attendue ? Si elle vient du code testé, ce n'est pas un test.
Un test vert n'est une preuve que si sa valeur attendue vient d'ailleurs que du code qu'il teste.
Le faux plausible
Une table de longueurs d'IBAN par pays : Allemagne 22, Espagne 24, Italie 27, Belgique 16 — et France 26. Toutes justes sauf une : un IBAN français fait 27 caractères. Le test passe, parce que l'agent a fabriqué un exemple cohérent avec sa propre erreur.
Rien dans ce diff ne sonne faux. Il faut savoir, ou aller vérifier. C'est la famille de défauts la plus difficile, et la raison pour laquelle la revue du code généré ne se délègue pas à quelqu'un qui ne connaît pas le domaine.
Même mécanisme pour la dépendance inventée : un nom de paquet plausible, un import crédible, et une erreur qui n'apparaît qu'à l'installation.
Ce que la CI attrape, et ce qu'elle ne verra jamais
Trois défauts ont une forme reconnaissable : un secret en dur, une dépendance nouvelle, un diff qui déborde du périmètre annoncé. Trois contrôles automatiques suffisent, à condition de les avoir vus échouer au moins une fois — un garde-fou qu'on n'a jamais vu se déclencher est une décoration.
Deux défauts n'ont pas de forme : le test qui rejoue l'implémentation, et la constante fausse mais plausible. Aucune analyse statique ne les verra. Ils relèvent de la revue humaine, avec du métier.
Le contrôle de périmètre mérite une mention à part. Un diff qui fait ce qu'on a demandé et, « au passage », aligne une constante dans un fichier voisin, passe tous les tests — parce que personne n'a écrit de test sur ce que personne n'avait demandé de changer.
Mesurer l'équipe, pas l'outil
Les tableaux de bord fournis affichent les lignes générées et le taux d'acceptation des suggestions. Ce sont des indicateurs d'usage : ils montent quand on utilise l'outil, et ne disent rien de la livraison.
Sur notre jeu de soixante demandes de fusion, la corrélation avec les défauts trouvés en production est de 0,12 pour les lignes générées, et de 0,73 pour les retours en revue. Le volume produit ne prédit rien. La difficulté du diff, si.
- À suivre : délai d'ouverture à fusion, retours en revue, défauts en production, part des diffs rejetés
- À ignorer : lignes générées, suggestions acceptées, requêtes par jour
L'essentiel se joue dans le dépôt
La même demande, sur le même dépôt, avec et sans fichier d'instructions : sans, quatre conventions violées en douze lignes — flottants sur des montants, arrondi bancaire, exception nue, aucun test. Avec, un diff propre. Même modèle, même demande.
Ce qui fait la différence n'est pas un meilleur prompt, c'est un fichier que l'agent lit à chaque tâche. Et ce fichier vaut par ses règles vérifiables : « chaque fonction publique a un test qui compare à une valeur écrite en dur » se coche ; « le code doit être propre » produit une ambiance.