Claude Code Harness : la boucle plan, travail, revue, livraison qui encadre les agents de code
Harnais de développement dédié Claude Code - Atteindre un développement de haute qualité grâce à un cycle d'examen des travaux de plan autonome.
En bref
- De quoi s’agit-il ?
- Analyse de Chachamaru127/claude-code-harness : cycle spec.md, implémentation, revue indépendante et preuves de release, avec un moteur Go qui juge chaque appel d'outil avant exécution et un socle runtime non désactivable.
- À qui s’adresse-t-il ?
- Claude Code Harness s'adresse aux équipes qui font travailler des agents sur du code réel et veulent une procédure qui survit au changement de modèle, pas une collection de prompts ; il ne rend pas un modèle plus capable et n'élimine pas la revue humaine, il la déplace en amont.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 2 jours.
- En quel langage est-il écrit ?
- Principalement Shell, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 14 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
La dérive des agents de code, et les cinq verbes qui y répondent
Le README ouvre sur un diagnostic partagé : le code par agent dérive, les plans vivent dans le chat et disparaissent, les tests deviennent optionnels sous pression, la revue arrive après la fusion, et les preuves de release se reconstruisent de mémoire. La réponse proposée est un chemin unique : écrire la spécification, implémenter seulement la part approuvée, vérifier, faire revue indépendamment, empaqueter les preuves.
La surface tient en cinq commandes : /harness-plan produit spec.md et Plans.md avec périmètre, critères d'acceptation, dépendances, inconnues et conditions d'arrêt ; /harness-work implémente une tâche approuvée, /harness-review révise séparément de l'implémentation, /harness-sync compare le plan au réel et signale la dérive, /harness-release n'empaquette que les preuves vérifiées dans CHANGELOG, tag et release. Le projet affirme ne pas rendre le modèle plus intelligent : il fixe la procédure et la frontière, pour que le dispositif survive au remplacement du modèle. Sous licence MIT, écrit en Shell, il affiche 3072 étoiles et 302 forks.
Des affirmations vérifiées par la CI : écrit n'est pas fonctionnel
Le README porte une phrase rare dans ce domaine : ses affirmations sont vérifiées mécaniquement. Des portes en CI contrôlent que les composants décrits sont réellement câblés, que le registre de tâches reste cohérent, et que les binaires livrés se reconstruisent depuis les sources. Une fonction n'apparaît dans le README qu'après qu'une porte a prouvé son accessibilité.
Cette discipline répond au vice principal de la documentation d'outils d'agents, des fonctionnalités décrites mais jamais exécutées. Pour un évaluateur, l'effet est concret : ce que le README décrit a été rejoué par la chaîne d'intégration à chaque version, et les releases suivent un rythme serré, v5.12.0 le 24 août 2026, v5.13.0 et v5.13.1 le 25 août. La documentation anglaise et japonaise coexistent, avec une page dédiée à la compatibilité Claude Code dans docs/CLAUDE_CODE_COMPATIBILITY.md.
Socle runtime intouchable contre guardrails R01 à R15 : deux forces distinctes
La couche de sécurité sépare le projet d'un simple gabarit de prompts : chaque appel d'outil est jugé par un moteur Go avant son exécution, pas après coup, un diff de fichier ne voyant ni envoi réseau ni suppression. Deux niveaux de force coexistent volontairement.
Le socle runtime couvre cinq catégories : facturation, sortie réseau, lecture de secrets, déploiements en production et destruction hors du worktree de la tâche. Il refuse net, sur un chemin de code isolé sans interrupteur de désactivation, si bien qu'une exécution autonome ne peut pas argumenter pour le franchir. Les guardrails R01 à R15 forment la couche réglable : poussées directes sur main, écritures dans des chemins protégés, poussées forcées, réécritures d'historique, chacun avec un verdict défini, refus, confirmation ou avertissement, et une partie configurable par projet.
Les confirmations déplacées au moment du plan, et un journal qui ne stocke rien de sensible
Au lieu d'interrompre une exécution, Harness collecte à l'avance les opérations risquées qu'un plan nécessitera et demande une seule fois, en amont. Chaque approbation porte une date d'expiration, un périmètre de tâche et un quota d'usage, pour qu'un oui ponctuel ne devienne jamais un trou permanent.
Chaque blocage laisse une trace dans un journal JSONL : identifiant de règle, catégorie, verdict. Le texte des commandes n'y figure jamais, seulement un hash et une longueur, et pour les lectures de secrets comme pour la facturation, pas même cela. Ce parti pris de journalisation minimal donne un comptage vérifiable des blocs subis, sans créer un nouveau dépôt de données sensibles, ce qui est cohérent avec la catégorie secrets du socle runtime.
Trois agents sur un dépôt : roster, inbox et messages à vérifier plutôt qu'à suivre
Plusieurs agents ouverts sur le même dépôt travaillent habituellement sans se voir. Le README appuie le coût du problème sur CooperBench : deux agents éditant le même fichier réussissent environ deux fois moins souvent qu'un agent seul, et 63 pour cent des échecs remontent à une croyance fausse sur ce que l'autre a modifié.
Harness tient un roster et un chemin de messages entre sessions locales. bin/harness session list liste les sessions vivantes de la machine, y compris celles des autres worktrees puisque le magasin se résout depuis git --git-common-dir. L'envoi passe par bin/harness inbox send avec équipe, émetteur, destinataire et sujet. Les messages arrivent à la frontière de tour du destinataire, enveloppés comme données avec un marquage non instructionnel : le message d'un pair est un rapport à vérifier, jamais un ordre. L'option [livemsg] verification = on ajoute une porte qui contrôle les affirmations factuelles, fichiers cités, commits résolubles, état du worktree, et renvoie la raison à l'émetteur plutôt que de livrer un message faux.
Plan Brief, Progress, Acceptance : trois vues pour un sponsor non développeur
Trois vues HTML d'un écran permettent à un commanditaire non technique de juger sans lire le code. Le Plan Brief, au moment où le plan est finalisé, montre la compréhension du sujet, les options, les risques et les critères d'acceptation. La vue Progress suit l'avancement avec les compteurs de tâches et les alertes de dérive, régénérée automatiquement.
La vue Acceptance, avant release, affiche le verdict par critère, réussite ou échec, assorti d'une recommandation : livrer, attendre ou rejeter. Ce trio adresse le maillon que les outils d'agents oublient, la décision métier. Un responsable qui ne coderait jamais peut néanmoins arrêter une livraison sur des critères qu'il a validés au moment du plan, ce qui referme la boucle ouverte par /harness-plan.
Quatre routes d'installation, et ce qu'elles garantissent différemment
Le README affirme sans détour que ses quatre routes d'installation ne portent pas la même garantie : une route d'entrée pour un outil prouve un chemin d'accès, pas une promesse produit commune. Claude Code passe par le marché de plugins puis /harness-setup ; Codex CLI par scripts/setup-codex.sh --user, à relancer après chaque mise à jour de Harness ; Cursor par scripts/setup-cursor.sh, avec une containment assurée par le harness lui-même ; Grok complète la liste.
Avant l'installation, deux vérifications servent : lire docs/CLAUDE_CODE_COMPATIBILITY.md pour votre outil et son niveau, puis tester la boucle entière sur une tâche volontairement petite, /harness-plan pour juger la spécification produite, /harness-review pour voir si les constats majeurs bloquent bien. Un outil qui modifie le comportement de votre shell et de vos dépôts ne se juge pas sur son README, mais sur la première revue qu'il vous fait gagner ou rater.
Conclusion éditoriale
Claude Code Harness s'adresse aux équipes qui font travailler des agents sur du code réel et veulent une procédure qui survit au changement de modèle, pas une collection de prompts ; il ne rend pas un modèle plus capable et n'élimine pas la revue humaine, il la déplace en amont. Avant l'adoption, testez la boucle complète sur une petite tâche avec /harness-plan puis /harness-review, lisez la compatibilité dans docs/CLAUDE_CODE_COMPATIBILITY.md pour votre outil, et figez la version installée, v5.13.1 à la date de ce dossier.
Notes de la communauté