Cycle writer/reviewer
Section intitulée « Cycle writer/reviewer »Le multi-agents, c’est souvent pour paralléliser. Le cycle writer/reviewer, c’est pour challenger — un pattern différent, avec une logique séquentielle délibérée.
Le principe est simple : un agent écrit, un autre relit. La séparation des rôles change la nature de la sortie — le reviewer n’est pas dans le même état d’esprit que celui qui a produit le code, ce qui lui permet de voir ce que le writer a laissé passer.
Pourquoi ça marche
Section intitulée « Pourquoi ça marche »Quand Claude génère du code, il est dans un mode de construction : il résout le problème posé, avance, remplit les blancs. C’est exactement ce qu’on lui demande.
Le problème, c’est que ce mode crée un biais de confirmation. Le writer a fait des choix — sur la structure, les noms, la logique — et ces choix lui paraissent cohérents parce qu’il les a faits.
Le reviewer arrive sans ce bagage. Il ne défend rien. Il peut challenger les choix, repérer les incohérences, identifier ce qui manque.
Même dans une session unique, le simple fait de changer de rôle suffit. Claude ne “se souvient” pas d’avoir écrit le code de la même façon qu’un humain — le changement de prompt est suffisant pour obtenir un regard différent.
Quand l’utiliser
Section intitulée « Quand l’utiliser »Sur les sujets que tu maîtrises moins — le reviewer est un filet de sécurité. Tu ne saurais pas forcément repérer une mauvaise pratique ou un edge case oublié. Le reviewer le fait pour toi.
Sur les sujets que tu maîtrises — le reviewer devient un challenger. Il questionne tes choix, propose des alternatives, signale ce qui pourrait poser problème plus tard. Même quand tu saurais relire toi-même, un deuxième regard structuré apporte quelque chose.
Comment faire
Section intitulée « Comment faire »Après que Claude a produit un résultat, lance un nouveau prompt avec un rôle de reviewer explicite. Donne-lui le contexte nécessaire, pas plus.
Tu es un reviewer senior. Voici le code que je viens de faire écrire par Claude :
[coller le code]
Contraintes du projet : [langage, framework, conventions importantes]Ce que je cherche à valider : [logique métier / sécurité / performance / lisibilité]
Analyse ce code de façon critique. Signale les problèmes réels, propose des améliorations concrètes, et indique ce qui est bon si c'est le cas.Le point clé : donner un angle précis. Un reviewer sans instruction va souvent valider en surface. Un reviewer avec une checklist ou un focus précis va creuser.
Session unique ou session fraîche ?
Section intitulée « Session unique ou session fraîche ? »Les deux fonctionnent. En pratique, la différence n’est pas notable — le changement de rôle via le prompt est suffisant pour obtenir un regard distinct, même si Claude a le contexte de la génération précédente.
Une session fraîche peut avoir un léger avantage sur des projets très complexes où tu veux éliminer tout biais de contexte, mais ce n’est pas nécessaire dans la majorité des cas.
Points d’attention
Section intitulée « Points d’attention »Le reviewer doit avoir un angle — sans instructions précises, il risque de valider trop facilement ou de pointer des détails mineurs en ignorant les vrais problèmes. Donne-lui un focus.
Le reviewer n’est pas infaillible — sur les sujets que tu ne maîtrises pas, ses retours peuvent sembler convaincants même s’ils sont partiellement faux. Croiser avec une deuxième source ou avec tes propres tests reste important.
Ce n’est pas un audit exhaustif — le cycle writer/reviewer améliore la qualité, il ne remplace pas les tests, la relecture humaine, ou la mise en production progressive.
← Multi-agents | MCP / Plugins →
→ Pour étendre les outils disponibles : MCP / Plugins