Vous découpez une grosse tâche en cinq cartes kanban, cinq agents se mettent au travail en parallèle, et tout le monde livre dans les temps. Puis vous fusionnez l’ensemble et le problème vous saute aux yeux : deux workers ont inventé indépendamment des réponses différentes à la même question de conception, un fichier a été remanié par trois cartes à la fois, et personne n’a rien relu — parce que la « revue » ne faisait jamais partie de la boucle. C’est l’aspect le plus douloureux de la collaboration multi-agents, et c’est exactement ce que corrige un ensemble de PR fusionnées le 10 août 2026 (#83412, #83423, #83424, #83428) : Hermes kanban dispose désormais d’un cycle de revue de première classe, plus trois garde-fous contre le chaos. Voici tout le flux — de la soumission du travail en revue à son renvoi à l’expéditeur — et les conventions qui gardent les agents parallèles honnêtes.

La boucle de revue : implémenteur → review lane → verdict

Les cartes kanban ont désormais une vraie phase de revue. Quand un implémenteur termine, il soumet via kanban_request_review :

kanban_request_review(
  task_id="T-42",
  summary="Implemented the export feature; verified with 3 sample files",
  reviewer="code-reviewer"    # optional
)

summary est obligatoire — elle indique au relecteur ce qui a été construit et comment cela a été vérifié ; reviewer est facultatif ; le contenu soumis est automatiquement expurgé. La carte passe dans la review lane, où un profil relecteur la prend en charge et où la skill sdlc-review se charge automatiquement. Le relecteur rend l’un des trois verdicts suivants :

Verdict	Action	Signification
Approve	kanban_complete	Critères d’acceptation remplis, la tâche se conclut
Request changes	kanban_comment + kanban_request_changes(reason=...)	Des défauts corrigibles subsistent ; la carte revient à l’implémenteur d’origine
Escalate	kanban_block	Une décision humaine ou un prérequis externe est nécessaire

La provenance est préservée : si l’implémenteur corrige la carte et redemande une revue sans nommer de relecteur, elle est routée vers le même profil relecteur — pas de réattribution aléatoire, un contexte de revue continu.

Des angles de revue rotatifs : round 1 lecture à froid, round 2 exécution, round 3 audit du contrat

La skill sdlc-review a une conception maligne : à chaque round, le travail est examiné sous un angle différent au lieu de répéter la même inspection. Le numéro de round correspond au nombre de tentatives précédentes de changes_requested plus un (round 1 = zéro renvoi, round 2 = un, et ainsi de suite) :

• Round 1 — Artifact : lisez le diff ou le livrable à froid, avant le résumé de l’implémenteur ; formez un jugement indépendant, puis comparez-le au récit de passation et investiguez chaque écart ;
• Round 2 — Execution : récupérez le travail et exécutez-le réellement via terminal — compilez, testez, et exercez vous-même le comportement décrit au lieu de relire l’artefact ;
• Round 3+ — Contract : relisez le corps de tâche original de la carte et les critères d’acceptation, auditez ensuite strictement le livrable par rapport à ceux-ci, et vérifiez que chaque point de chaque round précédent de request_changes a bien été pris en compte.

Le même principe s’applique lorsque vous déployez des relecteurs parallèles ad hoc via delegate_task : donnez à chaque relecteur un brief différent (l’un uniquement le diff, l’autre le contexte complet, le troisième checkout-et-exécution) plutôt que des briefs identiques. Des briefs identiques produisent des verdicts corrélés et des constats en double ; des angles variés couvrent davantage de classes de défauts pour le même coût de revue.

Garde-fou 1 : propriété des décisions — un propriétaire par question

Le mode de défaillance classique du multi-agents, c’est le « split-brain » : deux workers tranchent indépendamment la même question de conception avec des réponses différentes. Un nouveau contrat de propriété des décisions dans KANBAN_GUIDANCE bloque cette voie directement :

• Les décisions de conception appartiennent à l’orchestrator et sont prises avant le fan-out ;
• Aucune paire de cartes d’un même sous-arbre ne peut trancher la même question ;
• Le corps de chaque carte enfant doit porter les décisions dont elle dépend — car les workers ne peuvent pas voir le contexte de leurs cartes sœurs.

L’exemple de la documentation le dit parfaitement : une carte d’export et une carte d’import ne doivent pas chacune « inventer » le format de fichier. L’orchestrator choisit le format en premier et l’estampille sur les deux cartes, si bien que les deux workers écrivent chacun selon le même contrat et que rien ne se heurte au moment de la fusion.

Garde-fou 2 : zones de collision — signalez, n’empilez pas

Des modifications parallèles sur le même fichier vont forcément entrer en collision ; la nouvelle convention gère cela en amont. Quand un worker remarque que le fichier qu’il s’apprête à toucher n’arrête pas d’attirer des conflits depuis les cartes sœurs, il laisse un kanban_comment commençant par hotspot: (par ex. hotspot: src/config.py — three cards are editing this file) et le remonte dans les métadonnées de complétion. Un orchestrator qui voit 2+ signalements sur un même chemin crée une carte de décomposition — sortant ce fichier chaud de la file avant d’envoyer d’autres travaux qui le touchent. Pour les conflits déjà survenus, le merge-reconciler arbitre.

À retenir

Ensemble, ces changements transforment kanban d’un simple « distribuer le travail, collecter les résultats » en une boucle de développement complète : revue, perspectives rotatives, propriété des décisions et alerte précoce sur les conflits. Le point idéal est évident — les dépôts où plusieurs agents travaillent en parallèle et où la qualité a besoin d’un portail ; un agent unique qui fait de petites tâches n’a pas besoin d’un workflow aussi lourd. Pour la surface complète des commandes kanban, voir la référence des commandes hermes-kanban ; pour d’autres conventions dans les configurations multi-agents, nous avons aussi écrit sur la chaîne de répertoires AGENTS.md.