Les agents de codage human-in-the-loop sont généralement présentés comme un simple réglage : le mode où l'outil demande confirmation avant de modifier quoi que ce soit. C'est une boucle, et c'est la plus petite qui soit. Elle tourne dans le terminal d'un seul développeur, le temps d'une session, et elle s'évapore dès que la session se termine. Une équipe qui croit exercer une supervision humaine parce que tout le monde a laissé Claude Code en mode Manual ne supervise que des frappes clavier, pas des résultats.
Ce guide présente le workflow de revue sous la forme de cinq portes, depuis l'invite de permission au sein du runtime jusqu'à la décision d'acceptation consignée dans le dossier partagé, en précisant qui décide à chaque étape et où cette décision est écrite. Les portes liées au runtime proviennent de la documentation des outils eux-mêmes. Les portes liées à l'équipe s'appuient sur Sharkly, parce qu'il les enregistre sur la Task plutôt que dans l'historique de quelqu'un. Si vous voulez d'abord la définition de la pratique, notre guide sur la gestion de projet avec des agents IA couvre la boucle dans laquelle s'inscrit ce workflow.
TL;DR
Un workflow de revue human-in-the-loop pour les agents de codage comporte cinq portes : le mode de permission du runtime, la confirmation du plan avant que le travail ne devienne des Tasks, la frontière d'exécution qui détermine quand un run peut démarrer, le signal d'attention qui achemine la revue vers une personne nommée, et l'acceptation enregistrée comme un changement de statut opéré par cette personne. Seule la première porte est un réglage d'outil. Les quatre autres sont des décisions d'équipe, et elles ont besoin d'un dossier partagé pour exister réellement. Les agents font la recherche, l'exécution, les tests et le compte rendu. Les humains fixent la direction, accordent l'autorité et acceptent le résultat.
Porte 1 : le mode de permission dans le runtime
Chaque agent de codage sérieux embarque un bouton de validation. Les modes de permission de Claude Code vont de default, étiqueté Manual, qui demande confirmation avant les modifications, les commandes shell et l'accès réseau, à acceptEdits, plan et auto, où un second modèle appelé le classifieur examine les actions à votre place, jusqu'à bypassPermissions, réservé aux conteneurs isolés. Basculez avec Maj+Tab ou --permission-mode. Codex expose la même idée via sa commande /permissions, qui définit quand il peut modifier des fichiers ou exécuter des commandes sans demander.
Cette porte est nécessaire, mais insuffisante. Elle est propre à chaque session et à chaque développeur, elle protège la machine plutôt que l'exigence, et elle ne laisse aucune trace qu'un coéquipier puisse lire. Sur les offres Pro, Max et Team, Claude Code démarre désormais en mode auto par défaut, ce qui est un choix raisonnable précisément parce que le classifieur est plus rapide et plus constant qu'un humain fatigué qui clique sur oui. La leçon n'est pas de lutter contre ce bouton. Elle est de cesser de le prendre pour la revue elle-même.
Porte 2 : la confirmation du plan
La première porte au niveau de l'équipe intervient avant même qu'une ligne de code n'existe. Dans le chat Agent de Sharkly, le mode Plan permet à l'Agent de proposer des actions à votre examen, et la Task planifiée ainsi que ses sous-tâches ne sont créées qu'après confirmation de la proposition par une personne. Vous pouvez confirmer sans démarrer, ou confirmer et démarrer.
C'est là que le périmètre se décide, et cela ne coûte pas cher : modifier une sous-tâche proposée prend une minute, relire un refactoring non demandé prend un après-midi. Gardez Explore sélectionné lorsque vous ne voulez que de l'analyse. Utilisez une Crew quand un leader doit interpréter l'objectif et impliquer d'autres membres Agent ; utilisez un seul Agent, et faites l'économie du rituel, quand un seul rôle couvre le travail. Notre guide pour discuter avec un agent IA ou assigner une Task présente les trois modes.
Porte 3 : la frontière d'exécution
Une Task assignée à un Agent ne démarre pas tant qu'elle se trouve dans Backlog. C'est son passage vers un statut dont la catégorie est « ready for work » qui déclenche le run, et les catégories completed, canceled et duplicate ne déclenchent jamais de run initial. La catégorie de statut est donc une porte qu'une personne actionne délibérément, et elle est visible sur le tableau.
Deux choses font de cette porte autre chose qu'une formalité. Chaque run dispose d'un répertoire isolé, et les runs adossés à un dépôt préparent un worktree neuf, si bien qu'un run approuvé ne peut pas endommager un run que personne n'a approuvé. Et le run embarque la description de la Task, les commentaires récents et le type de Task Workflow, qui contraint les statuts que l'Agent peut sélectionner. Un Agent ne peut pas marquer son propre travail comme accepté si le Workflow ne lui donne pas ce statut. Notre article sur les worktrees Git avec des agents de codage IA explique cet isolement.
Porte 4 : le signal d'attention
Un Agent termine un run à l'un de deux endroits utiles : avec un résultat, ou avec une question. Sharkly nomme les deux. Un Agent peut laisser une Task en attente d'une réponse humaine ou d'une revue humaine, et le travail échoué ou bloqué remonte comme un élément d'attention. Ces signaux arrivent dans l'Inbox, dans la section Primary, pour la personne responsable, et les échecs de run sont notifiés à la personne assignée plutôt qu'à tous les abonnés.
La porte ici, c'est le routage, et c'est celle que la plupart des équipes ratent par accident. Une revue qui part dans un canal ne va à personne. Une revue qui va à la personne assignée, sur la Task, avec le journal d'exécution à un clic, va à quelqu'un à qui on pourra demander des comptes plus tard. Notre guide sur l'inbox d'agents IA couvre le fonctionnement de la file.
Répondre, c'est aussi ce qui permet au travail de continuer. Un commentaire de membre sur une Task dont l'Agent assigné est prêt peut mettre en file un nouveau run, de sorte que le retour de revue poursuit le même travail au lieu de lancer un second processus. Mentionner une personne, ou utiliser une mention globale, ne déclenche pas l'Agent à lui seul, ce qui évite qu'un échange entre humains réveille l'Agent.
Porte 5 : l'acceptation consignée
Accepter, c'est pour une personne changer le statut de la Task après avoir lu les preuves. Lisez dans cet ordre : les critères d'acceptation dans la description, le commentaire de l'Agent nommant les vérifications effectuées et ce qui reste incertain, le journal d'exécution, puis le diff. Le journal consigne pourquoi le run a été mis en file, quand il a commencé et fini, les appels d'outils et les événements Runtime, la source du déclenchement et les détails de l'échec ; c'est ce qui sépare la revue d'un changement de la revue d'un récit sur un changement.
Deux règles protègent cette porte. Fusionner une pull request liée ne change pas le statut de la Task, si bien qu'une fusion n'est jamais prise pour une acceptation. Et un run d'Automation terminé décrit le run, pas la promesse que tous les résultats en aval étaient corrects. Ces deux règles viennent directement de la documentation produit, et elles existent parce que les équipes confondaient sans cesse terminé et correct.
Le workflow en un tableau
| Porte | La question à laquelle elle répond | Qui décide | Où c'est consigné |
|---|---|---|---|
| Mode de permission | Cette session a-t-elle le droit de toucher à ça ? | Le développeur | Nulle part en partagé |
| Confirmation du plan | Est-ce le bon découpage ? | Une personne, sur la proposition | Les sous-tâches confirmées |
| Frontière d'exécution | Cette Task peut-elle démarrer maintenant ? | Celui qui la sort du Backlog | Changement de statut dans Activity |
| Signal d'attention | Qui doit regarder, et quoi ? | Sharkly l'achemine vers la personne assignée | Inbox Primary et la Task |
| Acceptation | Le résultat est-il correct ? | La personne assignée | Changement de statut par une personne nommée |
Quand ouvrir les portes plus grand
Toutes les Tasks ne méritent pas cinq arrêts, et prétendre le contraire est la meilleure façon de transformer la revue en théâtre. Un travail en lecture seule, comme un audit de dépôt, n'a besoin que des portes 1 et 5. Un travail réversible dans un worktree isolé, comme une mise à jour de dépendance avec ses tests, peut se passer de la confirmation du plan. Les Automations qui tournent selon un planning devraient préciser dans leurs instructions quand une personne doit examiner ou décider, et être lancées manuellement et inspectées avant que quiconque ne dépende du planning ; notre guide sur les Automations dans Sharkly traite de ce point.
Gardez les cinq pour tout ce qui modifie une interface publique, touche à des données ou ne peut pas être annulé par une seule commande. Et gardez une règle partout : une personne assignée nommée sur chaque Task d'Agent. Sharkly sépare volontairement la responsabilité humaine de l'exécution par l'Agent, si bien qu'une Task peut avoir des personnes assignées et un Agent assigné en même temps. La responsabilité ne se délègue pas, et le dossier doit montrer qui la porte.
Ce que le human-in-the-loop n'est pas
Ce n'est pas une personne qui surveille un terminal. Ce n'est pas une invite de permission avec un relecteur épuisé derrière. Et ce n'est pas un statut qui affiche Completed. L'automatisation s'arrête là où le jugement de l'équipe est requis et rend une livraison avec un contexte complet et des preuves inspectables. Cette phrase résume tout le workflow ; les portes ne sont que les endroits où il est appliqué. Sharkly ne remplace pas Claude Code, Codex ou d'autres outils d'exécution ; c'est la couche qui consigne ces décisions.
FAQ
Le mode auto de Claude Code retire-t-il l'humain de la boucle ? Il retire l'humain de l'invite de permission. Le classifieur examine les actions au regard de votre demande ; il ne vérifie pas si le résultat satisfait à l'exigence. Les portes 2 à 5 restent du ressort des humains.
Comment arrêter un Agent en cours de run ? Une exécution en file ou en cours peut être annulée. Déplacer une Task vers un statut Canceled ou Duplicate arrête aussi les runs actifs ; la déplacer vers Completed ne les arrête pas, donc annulez d'abord si l'Agent travaille encore.
Qui doit être le relecteur ? La personne assignée sur la Task. Sharkly envoie les signaux d'attente de revue et d'échec à cette personne, c'est pourquoi chaque Task d'Agent devrait en nommer une. Notre guide sur les Agents dans Sharkly explique les deux emplacements d'assignation.
Un retour de revue peut-il repartir vers l'Agent sans nouvelle Task ? Oui. Un commentaire sur la Task peut mettre en file un run de suivi pour l'Agent assigné, et les commentaires rapprochés sont regroupés pour ne pas créer de runs en doublon.
