Code review avec l'agent
Un agent peut relire du code en quelques secondes, le sien ou le tien. Mais un reviewer qui a écrit le code qu'il relit est juge et partie. Pourquoi reviewer du code qui passe les tests, self-review contre sub-agent review, la review guidée par checklist, et la limite que l'agent ne franchit pas.
Pourquoi reviewer du code qui compile et passe les tests
Les tests verts prouvent une chose : le code fait ce que les tests vérifient. Ils ne disent rien de tout le reste. Un code peut être vert et rester mauvais.
Ce que les tests ne voient pas : la lisibilité, le nommage, le respect des conventions du projet, le code mort, la complexité inutile, les cas limites non testés, la pertinence architecturale. Aucune assertion ne capture ces dimensions — elles relèvent du jugement, donc de la review.
Point clé : Tests = le code fait-il ce qu’on a vérifié ? Review = est-ce du bon code, au bon endroit, maintenable ? Les deux sont complémentaires, jamais interchangeables.
Self-review contre sub-agent review
Il y a deux façons de faire relire du code par un agent, et elles n’ont pas la même valeur.
| Approche | Principe | Limite |
|---|---|---|
| Self-review | On demande à l’agent de relire son propre travail. | Il a déjà vu son raisonnement : il tend à confirmer ses choix (biais de confirmation). |
| Sub-agent review | Un second agent, qui n’a pas vu le processus de création, reçoit seulement le code final et les conventions. | Plus objectif, mais ignore l’intention métier non écrite. |
Point clé : Le contexte frais est ce qui rend une review utile. Un reviewer qui n’a pas participé à l’écriture repère ce que l’auteur ne voit plus. Dans Claude Code, le Task tool permet exactement ce reviewer à contexte frais.
La review guidée : donner une checklist
« Est-ce que ce code est bien ? » produit une réponse vague et complaisante. Une review utile est cadrée par une checklist explicite : nommage, tests manquants sur les cas limites, code mort, gestion d’erreurs, complexité, respect des conventions du projet.
Attention : Sans critères, l’agent répond souvent « le code est propre et bien structuré ». Ce n’est pas une review, c’est de la flagornerie. Une checklist force des observations concrètes et actionnables.
L’agent reviewer junior : une limite à connaître
L’agent est un reviewer junior rapide et infatigable : il signale les incohérences de style, les cas non testés, le code mort. Mais il ne porte pas la responsabilité du merge et ne connaît pas l’intention métier qui n’est pas écrite.
Point clé : La review agentique ne remplace pas la review humaine : elle la prépare et la filtre. L’agent dégrossit (style, oublis, conventions), l’humain tranche sur le sens métier, l’architecture et le risque.
En hexagonal/DDD, le piège est subtil : un sub-agent reçoit le code et les conventions, mais pas les invariants implicites du bounded context. Il peut approuver un code lisible, bien nommé, testé — et sémantiquement faux au regard de la règle métier réelle. La review agentique vérifie la forme et les cas techniques ; la review humaine garde la main sur le sens métier et les invariants du domaine.
Remonte relire la fiche memo ci-dessus en pretant attention aux points rates, puis clique sur « Recommencer » pour retenter.