Il est 2 h du matin et vos deux agents viennent de terminer leur travail en parallèle : l’un a refactoré les signatures de fonctions du module de paiement, l’autre a ajouté une nouvelle fonctionnalité dans le même fichier, et git merge pousse un gémissement tandis que les marqueurs de conflit inondent l’écran. À qui demander de démêler tout ça ? Demandez à l’agent A et il décrétera que sa refactorisation est la plus importante ; demandez à l’agent B et il soutiendra que la nouvelle fonctionnalité est le vrai travail — une partie prenante n’est jamais un juge impartial. En août 2026, Hermes a fusionné un skill nommé merge-reconciler (PR #83063) reposant sur une idée simple : aucun des deux auteurs ne touche au merge — un agent tiers neutre arbitre à leur place.

Pourquoi les parties ne peuvent pas se réconcilier seules

C’est le postulat sur lequel repose toute la conception, et c’est l’observation que martèle la documentation du skill : lorsqu’un agent se retrouve face au code d’un pair, il porte un biais inhérent — soit il estime que son propre changement est plus correct et écrase silencieusement l’autre camp, soit il ne parvient pas à donner un sens au code du pair et abandonne son propre travail. Aucun de ces deux résultats n’est bon. Le point le plus subtil, c’est que les conflits de merge sont rarement un simple « le code ne s’applique pas » — les deux changements portent des intentions derrière eux, et ce n’est qu’en mettant les deux intentions sur la table qu’on peut décider de ce que doit devenir chaque hunk conflictuel.

merge-reconciler confie l’arbitrage à un tiers sans intérêt dans le conflit : il reçoit les deux diffs ainsi que les intentions déclarées des deux camps, puis tranche hunk par hunk. Le skill est un pur skill-plus-docs — zéro changement de code dans le cœur — si bien que chaque utilisateur d’Hermes en profite dès l’installation, sans aucune mise à jour de configuration.

Trois classes de conflits, trois règles de jugement

L’arbitre ne coupe pas la poire en deux : il classe chaque hunk conflictuel et applique la règle correspondante :

Classe de hunk	Signification	Résolution
disjoint-intent	Les deux changements servent des objectifs différents et peuvent coexister	Garder les deux — combiner
same-question-different-answer	Les deux camps ont répondu différemment à une même question de conception	Choisir UN selon les intentions déclarées ; exposer la décision
superseded	La prémisse d’un camp ne tient plus après le changement de l’autre	Garder le camp survivant ; expliquer pourquoi

La règle la plus contre-intuitive est ne jamais couper la poire en deux : si les deux camps ont répondu différemment à la même question de conception, l’arbitre doit en choisir UN — pas souder un hybride que personne n’a conçu. Le processus de jugement obéit aussi à un contrat d’impartialité : ne favoriser jamais l’un des camps, ne toucher QU’AUX régions conflictuelles (pas de correctifs opportunistes), et chaque choix de conception doit apparaître dans le résumé final, là où un humain peut y mettre son veto.

Comment l’utiliser : trois formes

Forme une : autonome. Chargez le skill dans le repo en conflit et suivez la procédure de bout en bout : trouvez l’ancêtre commun avec git merge-base <A> <B>, collectez les changements des deux camps avec git log --oneline <base>..<side> et git diff <base>..<side> -- <file>, déterminez les deux intentions via les résumés des tâches kanban ou les corps de PR, puis classez, tranchez, vérifiez et committez hunk par hunk.

Forme deux : déléguer un agent neutre. La forme privilégiée pour les campagnes multi-agents — lancez un sous-agent avec delegate_task dont le message de tâche porte le chemin du repo, les deux noms de branches, les résumés d’intention des deux camps verbatim, et l’instruction de suivre ce skill. Le sous-agent est un tiers naturel, sans aucun motif de biais.

Forme trois : kanban-natif. Si votre travail en parallèle passe par kanban, créez une carte de réconciliation dédiée, assignée à un troisième profil (celui d’aucun des deux travailleurs), avec les DEUX cartes en conflit liées comme cartes parentes :

kanban_create(
    title="reconcile branch-a x branch-b",
    assignee="reconciler",
    parents=["t_a", "t_b"]
)

Les liens parents transportent automatiquement les résumés de complétion des deux camps dans le contexte de l’arbitre ; le corps de la carte ne fait que nommer le chemin du repo et les deux branches. Quand l’arbitrage se termine, concluez avec kanban_complete(summary=...) en listant le jugement rendu pour chaque hunk.

Quand ne PAS l’utiliser

La documentation du skill trace des limites claires : les conflits au sein du travail d’un seul agent, ou les collisions triviales de lockfile/fichiers générés, doivent être régénérés plutôt qu’arbitrés. Le skill cible le cas difficile des campagnes en parallèle où deux agents ont modifié le même code avec intention. Et si l’intention de l’un des camps ne peut pas être reconstituée à partir des messages de commit, des corps de PR ou des résumés kanban — escaladez plutôt que de deviner. Juger sans intentions, c’est jouer aux dés.

Le travail multi-agents en parallèle est l’une des forces d’Hermes — nous avons couvert les chaînes de répertoires AGENTS.md pour la collaboration multi-agents et les combos de skills enchaînés. Pour faire travailler des agents en parallèle sans collision, la référence de la commande kanban et notre guide complet d’automatisation cron sont de bonnes prochaines lectures.