Relire du code qu’on n’a pas écrit

Pendant vingt ans, la revue de code a été une pratique d’hygiène : utile, recommandée, et contournable un vendredi soir. Le développement assisté la rend centrale.

Parce que quand un agent produit l’essentiel de vos diffs, l’acte qui engage votre responsabilité n’est plus d’écrire. C’est de lire, juger, accepter ou refuser.

---

Pourquoi la revue est devenue le métier ?

À cause d’une asymétrie : le coût de production s’est effondré, le coût de compréhension n’a pas bougé d’un pouce. Un agent produit en trois minutes un diff que vous mettrez trente minutes à comprendre vraiment.

Si votre définition du métier reste « écrire du code », cette asymétrie joue contre vous. Si elle devient « décider quel code mérite d’exister », elle joue pour vous.

Parce que la responsabilité, elle non plus, n’a pas bougé. C’est votre nom sur le commit, votre astreinte quand ça casse en production, votre dette quand le raccourci généré se paye dans six mois. Le code que vous mergez est le vôtre, quel que soit son auteur. « C’est l’IA qui l’a écrit » n’est pas plus recevable que « c’est le stagiaire ».

La conséquence pratique : la relecture cesse d’être un goulot d’étranglement à minimiser pour devenir la compétence à entraîner.

Qu’est-ce qui change quand l’auteur est une machine ?

Trois choses, et importer les réflexes de la revue entre humains produit exactement trois angles morts.

D’abord, il n’y a pas d’intention à reconstruire. Face au code d’un collègue, la lecture consiste largement à retrouver le raisonnement de l’auteur — et ce raisonnement existe. Le code généré, lui, imite du code intentionnel : chaque ligne ressemble à une décision, aucune n’en est une. Le commentaire explicatif, le nom de variable soigné, la gestion d’erreur consciencieuse sont des continuations probables, pas des choix. Vous ne pouvez pas vous demander « pourquoi a-t-il fait ça ? » : il n’y a pas de pourquoi, seulement un vraisemblable.

Ensuite, l’auteur ne peut pas défendre son code. Interroger l’agent sur son propre diff produit une justification fluide, que le code soit correct ou non. C’est la sycophantie décrite dans Limites et hallucinations. Son explication est une carte utile pour naviguer le diff, jamais une preuve de sa correction.

Enfin, la propreté de surface est garantie, donc muette. Un humain qui écrit du code confus signale souvent une pensée confuse, et ce signal guide la revue. Le code généré est uniformément fluide, idiomatique, bien commenté — y compris quand il est faux. Le style ne porte plus aucune information : toute votre vigilance doit se reporter sur le fond.

LE CRAFTOMANCER

La règle du merge n’a pas changé, elle est juste devenue coûteuse à respecter : ne mergez pas une ligne que vous ne sauriez pas expliquer à un collègue. Si un diff généré contient trois lignes que vous survolez en vous disant « ça doit être nécessaire », vous n’avez pas relu. Vous avez ratifié. C’est là que la dette s’installe.

Dans quel ordre relire un diff généré ?

De la question la plus invalidante à la plus fine. La relecture ligne à ligne, de haut en bas, est le pire algorithme possible : elle épuise votre attention sur la syntaxe — la partie que l’agent rate le moins — avant d’arriver aux vraies questions.

J’aime bien l’image du tri postal : on regarde l’adresse avant de lire la lettre. Trois passes, donc.

• L’intention. Ce diff résout-il le bon problème, dans le bon périmètre ? Les agents débordent par défaut : fichiers touchés sans raison, refactoring opportuniste, dépendance ajoutée pour s’épargner dix lignes. Un diff hors périmètre se refuse en trente secondes, sans lire le reste.
• L’intégration. Le code s’appuie-t-il sur l’existant ou le réinvente-t-il ? La défaillance signature du code généré, c’est la duplication plausible : un helper réécrit à côté de celui qui existait, une convention voisine de la vôtre mais pas la vôtre. Chaque doublon merge une divergence qui grossira.
• Le détail, calibré sur le risque. Ligne à ligne, mais seulement là où l’erreur coûte : conditions aux limites, gestion d’erreur (souvent décorative, le catch qui logge et avale), concurrence, requêtes, migrations, tout ce qui touche l’argent ou les données. Le composant d’affichage, lui, sera jugé par les types et l’écran.

Cet ordre a une vertu très concrète : les deux premières passes sont rapides et éliminent la majorité des diffs refusables avant la passe coûteuse. Vous dépensez votre attention là où ni le compilateur ni les tests ne voient.

Faut-il corriger ou régénérer ?

Régénérer, presque toujours. Et c’est un changement d’habitude qui demande un effort, parce que toute la culture de la revue s’est construite sur le coût du refus.

Refuser la PR d’un collègue coûte cher : du temps humain, de la diplomatie, un cycle de plusieurs heures. D’où les annotations, les suggestions, le rafistolage en commentaires. Refuser un diff généré coûte une phrase et deux minutes. Le refus est redevenu l’option par défaut raisonnable.

Devant un diff médiocre, le réflexe artisanal n’est donc plus de le corriger à la main. C’est de comprendre ce que la demande ne disait pas, de l’ajouter, et de régénérer. Rafistoler un diff moyen vous fait hériter d’un code que vous n’avez ni écrit ni vraiment choisi ; régénérer sur une spécification améliorée capitalise l’effort — et finit, pour les leçons durables, dans le fichier d’instructions. Gardez la correction manuelle pour les retouches ponctuelles sur un diff par ailleurs accepté.

Un dernier critère, inconfortable mais imparable : si vous acceptez aujourd’hui un code que vous auriez refusé d’un humain il y a deux ans, ce n’est pas la machine qui a baissé le niveau.

Comment tenir la cadence sans baisser la garde ?

En architecturant la relecture, pas en relisant plus fort. Parce que l’objection est sérieuse : l’agent produit plus vite que vous ne relisez, et la vigilance humaine fatigue.

• Faites passer la machine avant vos yeux. Types, lint, tests, exécution ne fatiguent pas et ne ratent jamais ce qu’ils savent voir. Toute relecture humaine d’un diff qui ne compile pas encore est de l’attention gaspillée.
• Refusez les diffs illisibles par construction. La taille d’un diff se négocie au moment de la demande, pas de la revue. Une tâche découpée en trois livraisons relisables vaut mieux qu’un diff de mille lignes que personne ne lira honnêtement.
• Servez-vous de l’agent comme guide de lecture, pas comme caution. « Liste les décisions discutables de ce diff et les cas limites non couverts » oriente votre passe de détail. Demander « est-ce que c’est correct ? » ne produit qu’un oui.
• Acceptez l’inconfort résiduel. Une relecture honnête refuse, questionne et ralentit parfois la machine. C’est le prix du craft.

En pratique

• Vous signez tout ce que vous mergez : « c’est l’IA qui l’a écrit » n’existe pas en production.
• Lisez en trois passes (intention, intégration, détail) et refusez dès la première qui échoue, sans lire la suite.
• La fluidité du code généré n’est pas un signal de qualité. Ne mergez aucune ligne que vous ne sauriez pas expliquer.
• Un diff médiocre se régénère sur une meilleure spécification, il ne se rafistole pas en revue.
• Négociez la taille des diffs en amont et laissez types, tests et exécution filtrer avant vos yeux : votre attention est la ressource rare.

La suite de la Section outille chacun de ces points. À commencer par la prochaine Étape : les tests comme contrat, ou comment transformer la vérification déclarée en vérification exécutable.