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

En chantier Cette section est en cours d'écriture : ce guide est lisible mais pas encore finalisé, son contenu peut évoluer.

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

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. Cette Section entière traite de l’exigence artisanale face au code généré ; ce guide pose sa pratique fondatrice : relire du code qu’on n’a pas écrit, vite, juste, et sans complaisance.

La revue n’est plus une étape, c’est le métier

L’économie du code a basculé sur une asymétrie : le coût de production s’est effondré, le coût de compréhension n’a pas bougé. 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, n’a pas bougé non plus. 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 ». Vous l’avez signé.

La conséquence pratique : la relecture cesse d’être un goulot d’étranglement à minimiser pour devenir la compétence à entraîner. Le reste de ce guide traite de comment la rendre rapide et fiable. Pas de comment s’en passer.

Ce qui change quand l’auteur est une machine

Relire un diff généré n’est pas relire la PR d’un collègue, et importer les réflexes de l’un vers l’autre produit des angles morts précis.

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é 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 ; 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 tips 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 exactement là que la dette s’installe.

Lire dans le bon ordre

La relecture ligne à ligne, de haut en bas, est le pire algorithme pour du code généré : elle épuise votre attention sur la syntaxe (la partie que l’agent rate le moins) avant d’arriver aux vraies questions. Lisez en trois passes, de la plus invalidante à la plus fine :

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 économique : 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.

Refuser souvent : le refus est redevenu bon marché

Refuser la PR d’un collègue coûte cher : du temps humain, de la diplomatie, un cycle de plusieurs heures. Toute la culture de la revue s’est construite autour de ce coût. On annote, on suggère, on rafistole en commentaires. Refuser un diff généré coûte une phrase et deux minutes. La plupart des développeurs n’ont pas tiré la conséquence de ce basculement : le refus est redevenu l’option par défaut raisonnable.

Devant un diff médiocre, le réflexe artisanal n’est 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). Réservez la correction manuelle aux retouches ponctuelles sur un diff par ailleurs accepté.

Le critère est inconfortable mais simple : 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.

Tenir la cadence sans baisser la garde

Reste l’objection sérieuse : l’agent produit plus vite que vous ne relisez, et la vigilance humaine fatigue. La réponse n’est pas de relire plus fort. C’est d’architecturer la relecture :

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 coût du craft, et il est très inférieur au coût de l’alternative.

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 le prochain guide : les tests comme contrat, ou comment transformer la vérification déclarée en vérification exécutable.