Chapitre 11.1 — Réviser : /code-review

⏱️ TL;DR — /code-review relit le diff courant à un niveau d’effort réglable, et remonte des findings (bugs de correction, simplifications, efficacité). Options : --comment pour poster en commentaires de PR, --fix pour appliquer les corrections. Pour les gros enjeux, la version ultra lance une revue multi-agent dans le cloud (plus profonde, adversariale). Le point clé : la revue par l’IA ne remplace pas ton jugement — elle prépare une liste que tu tries. Un regard automatisé de plus, pas un tampon automatique.

🎯 Objectifs

• Lancer /code-review sur un diff et exploiter ses findings.
• Choisir le bon niveau d’effort et les options (--comment, --fix).
• Savoir quand recourir à la revue cloud (ultra).
• Garder ton jugement au-dessus de la revue automatique.

La revue comme couche « rattraper »

Rappel du modèle en couches (3.3) : la revue est la couche rattraper, celle qui attrape ce que les autres (énoncer/montrer/imposer) ont laissé passer. /code-review l’automatise : elle relit le diff courant et remonte des findings classés — correction (vrais bugs), simplification/réutilisation, efficacité.

Niveau d’effort et options

/code-review se règle en effort :

• low / medium : moins de findings, mais haute confiance (peu de faux positifs). Bon pour un check rapide.
• high / max : couverture plus large, peut inclure des findings incertains (à trier). Pour les changements à fort enjeu.

Et en options :

• --comment : poste les findings en commentaires inline sur la PR (revue d’équipe).
• --fix : applique les findings au working tree (à relire ensuite).

/code-review high            # revue approfondie du diff courant
/code-review --comment       # poster sur la PR
/code-review --fix           # appliquer les corrections

💡 Réflexe d’architecte — Adapte l’effort à l’enjeu, comme le modèle et le plan mode. Un petit diff trivial → low/medium (rapide, sûr). Un changement d’architecture ou une PR sensible → high/max, quitte à trier plus de findings. La revue n’est pas binaire : c’est un curseur effort/couverture.

La version cloud : ultra

Pour les gros coups (une PR importante, une revue avant release), /code-review ultra lance une revue multi-agent dans le cloud : plus profonde, avec vérification adversariale des findings (rappel des patterns de workflow, 8.3) — chaque problème potentiel est challengé avant d’être retenu, ce qui élimine les faux positifs. C’est déclenché par toi et facturé ; tu ne peux pas la lancer « par erreur ». On l’utilise quand la confiance vaut le coût (relire toute une branche, un module critique).

📚 Aller plus loin — ultra fonctionne sur la branche locale (sans même un remote GitHub) ou sur une PR (/code-review ultra <PR#>). C’est l’artillerie de la revue : réserve-la aux moments où l’exhaustivité et la confiance priment (release, code sensible), pas pour un diff de trois lignes.

La revue ne remplace pas ton jugement

⚠️ Piège — Traiter la sortie de /code-review comme un verdict : appliquer tous les findings sans les lire, ou considérer « 0 finding » comme « c’est parfait ». Une revue automatique prépare une liste ; c’est toi qui tranches (ce finding est-il réel ? vaut-il une correction ? y a-t-il un faux positif ?). Elle attrape beaucoup, mais elle n’a pas ta vue d’ensemble du produit. Regard de plus, pas tampon automatique.

De même, --fix applique — donc relis la diff des corrections (5.4) avant de committer. L’automatisation accélère ; la responsabilité reste tienne.

Revue humaine + revue IA

La revue IA ne supprime pas la revue humaine ; elle la rend meilleure. En pré-mâchant les points mécaniques (bugs évidents, incohérences, simplifications), elle libère le relecteur humain pour ce qui compte vraiment : les décisions de design, l’adéquation au besoin, les compromis. Bon flux : /code-review d’abord (attrape le mécanique), revue humaine ensuite (juge le structurel).

🧭 Sur TaskFlow — Sur TaskFlow, on ajoute /code-review à la boucle de chaque feature (après les hooks P7, en complément de l’agent reviewer P8) : effort medium au quotidien, high/ultra avant une release ou sur du code sensible (auth, paiements plus tard). Et /security-review (11.5) pour l’axe sécurité. La qualité de TaskFlow devient une routine outillée, pas un effort ponctuel.

✏️ Exercices

Exercice 1 — Trie, ne gobe pas. Lance /code-review sur un vrai diff. Pour chaque finding : réel ou faux positif ? à corriger ou acceptable ? Applique seulement ce qui le mérite.

Exercice 2 — Effort selon l’enjeu. Fais deux revues : medium sur un petit diff, high sur un changement structurant. La différence de couverture (et de faux positifs) correspond-elle à l’enjeu ?

🧠 Quiz de révision

Chapitre suivant : Debugger : /diagnose — une méthode, pas du tâtonnement.