Un agent de codage peut transformer un ticket en pull request le temps que vous alliez chercher un café. Cette vitesse soulève une question plus discrète, à laquelle aucun outil ne répond à votre place : une fois le diff produit, qui en est responsable ? Pas qui l'a tapé — c'est l'agent qui s'en est chargé. Mais qui répond de sa mise en production, de la pertinence du changement, et de ce qui se passe quand ça casse à 2 h du matin. L'exécution est passée à l'agent. La responsabilité, non — et elle ne le peut pas.
Le flou s'aggrave dès que vous faites tourner plus d'un agent. Confiez un bug à Claude Code et un autre à Codex : vous voilà avec deux branches, deux résumés, et aucune réponse commune à une question simple : à qui seront attribués ces changements une fois fusionnés ? Une responsabilité qui ne vit que dans le scrollback d'un terminal n'est pas une responsabilité. C'est une supposition qui tient jusqu'au prochain git log.
C'est le problème autour duquel Sharkly a été conçu. Sharkly se place au-dessus de vos agents de codage comme la couche qui enregistre qui a assigné le travail, quel agent l'a exécuté, qui en révise le résultat et qui l'accepte. Cet article présente ce modèle opérationnel sous la forme de quatre rôles et d'un ensemble de statuts, puis suit un ticket de l'assignation à la fusion d'une PR. Pour les mécanismes de revue qui le sous-tendent, notre guide des agents de codage avec humain dans la boucle détaille les cinq points de contrôle qui font appliquer ces décisions.
TL;DR
La responsabilité humaine sur le travail des agents signifie que la responsabilité d'un changement n'est jamais transférée à l'agent, même lorsque l'exécution l'est. Le modèle opérationnel comporte quatre rôles : une personne assigne, un Agent exécute, un humain nommé révise, et ce même humain accepte. Les agents peuvent faire avancer une Tâche jusqu'à « Prêt pour revue » ; seule une personne la fait passer à « Terminé ». Les agents explorent, exécutent, testent et rendent compte. Les humains donnent la direction, accordent l'autorité et acceptent le résultat.
Qui est responsable du travail produit par un agent
La responsabilité et l'exécution sont deux métiers distincts, et les confondre est l'erreur de fond. L'exécution, c'est produire le changement : lire le code, modifier les fichiers, lancer les tests, ouvrir une PR. Un agent le fait bien et vite. La responsabilité, c'est répondre du résultat : que le changement valait la peine d'être fait, qu'il respecte les critères d'acceptation, et que quelqu'un pourra être interrogé à son sujet dans trois mois. Cette redevabilité reste du côté humain, car on ne peut pas demander à un agent de justifier un compromis après coup ni d'en assumer les conséquences.
La façon la plus claire d'énoncer ce partage est le contrat humain-agent : les agents explorent, exécutent, testent et rendent compte ; les humains donnent la direction, accordent l'autorité et acceptent le résultat. L'automatisation s'arrête là où le jugement de l'équipe est requis. Tout ce qui précède « accepter le résultat » peut être confié à un agent. L'acceptation elle-même ne le peut pas, pas plus que la décision de livrer. Notre article sur les assistants IA face aux coéquipiers IA trace la même frontière, mais dans l'autre sens.
Le modèle opérationnel : assigner, exécuter, réviser, accepter
Une fois la responsabilité séparée de l'exécution, le flux de travail se répartit en quatre rôles, chacun avec une seule mission. C'est en les nommant qu'on évite que cinq agents en parallèle ne deviennent cinq branches orphelines.
| Étape | Qui agit | Ce qui lui incombe |
|---|---|---|
| Assigner | Une personne | Décider que le travail vaut la peine d'être fait, rédiger les critères d'acceptation et désigner qui en répond |
| Exécuter | Un Agent, via un Runtime sur un Ordinateur | Produire le changement, lancer les tests et rendre compte de ce qu'il a fait et de ce qui reste incertain |
| Réviser | L'Assigné humain | Juger le résultat au regard des critères d'acceptation et des preuves |
| Accepter | Le même Assigné humain | La décision de fusionner et de livrer |
Le détail important se trouve dans la première et la dernière ligne : c'est la même personne qui porte l'assignation et l'acceptation. C'est ainsi que la boucle se referme. Celui ou celle qui a jugé que le travail comptait est aussi la personne qui confirme qu'il a été fait. Sharkly le permet en conservant deux champs d'assignation sur une Tâche, un Assigné humain et un assigné Agent, afin que la responsabilité et l'exécution soient enregistrées comme deux faits distincts plutôt qu'un « assigné à » ambigu. Pour savoir comment le travail parvient à l'agent, consultez notre guide pour assigner, suivre et réviser le travail des agents au même endroit.
Statuts et points de contrôle : les agents vont jusqu'à « Prêt pour revue », les humains font passer le travail à « Terminé »
Le modèle opérationnel devient concret lorsqu'il se traduit en statuts de Tâche, car un changement de statut est une décision que l'on peut pointer du doigt plus tard. Ici, la règle est stricte et mérite d'être énoncée clairement : les agents peuvent faire avancer le travail jusqu'à « Prêt pour revue » ; seule une personne fait passer une Tâche à « Terminé ».
| Catégorie de statut | Qui le fait changer | Signification |
|---|---|---|
| Backlog | Personne | Pas encore commencé. Assigner un Agent ici ne déclenche rien |
| Prêt pour le travail | Personne | C'est le passage d'une Tâche dans cette catégorie qui déclenche l'exécution de l'Agent |
| En cours | Agent | L'exécution se déroule dans un worktree isolé |
| Prêt pour revue | Agent | L'exécution est terminée et attend l'humain désigné |
| Terminé / Accepté | Personne | Une personne a lu les preuves et accepté le résultat |
Deux garde-fous protègent ce principe. Premier garde-fou : un Agent ne peut pas sélectionner un statut que son Workflow de Tâche ne lui accorde pas ; il ne peut donc pas marquer son propre travail comme accepté. Il laisse la Tâche en attente de revue humaine, et ce signal arrive dans la Boîte de réception de la personne responsable plutôt que dans un canal que personne ne lit. Deuxième garde-fou : fusionner une pull request liée ne change pas le statut de la Tâche. Une fusion est un événement Git, pas une décision d'acceptation, et Sharkly les tient séparés pour que « la PR est fusionnée » ne soit jamais pris pour « une personne a jugé que c'était correct ». Si la capacité de revue vous préoccupe, notre analyse expliquant pourquoi la revue humaine est le véritable goulot d'étranglement explique comment concevoir pour y faire face.
Du ticket à la PR fusionnée : un exemple concret
Voici le modèle déroulé de bout en bout sur une seule Tâche, SH-312, « Ajouter une limitation de débit à l'endpoint de recherche public ».
- Assigner. Une ingénieure rédige la Tâche : l'endpoint concerné, la limite visée et les critères d'acceptation (429 en cas de dépassement, les tests existants toujours au vert, un nouveau test pour la limite). Elle se désigne comme Assigné humain et choisit l'assigné Agent. La Tâche reste en Backlog. Rien ne se déclenche encore.
- Exécuter. Elle fait passer
SH-312dans un statut « Prêt pour le travail ». Ce changement de statut déclenche l'exécution. L'Agent prend la Tâche en charge, prépare un worktree neuf pour que ce travail n'entre pas en collision avec autre chose, lit la description et les derniers commentaires, modifie l'endpoint, ajoute le test et lance la suite de tests. - Rendre compte. L'Agent ouvre une pull request et publie un commentaire sur la Tâche : le résumé du changement, les tests exécutés et leurs résultats, et une remarque honnête indiquant qu'il n'a pas testé la limite en charge avec du trafic réel. Il fait passer
SH-312à « Prêt pour revue ». Il s'arrête là. Il ne peut pas aller plus loin. - Réviser. Le signal d'attente de revue arrive dans la Boîte de réception de l'ingénieure. Elle lit dans l'ordre : les critères d'acceptation, le commentaire de l'Agent, le journal d'exécution, puis le diff. Le journal montre pourquoi l'exécution a été mise en file et quels appels d'outils ont été effectués ; elle révise donc le changement lui-même, pas un récit à son sujet. La lacune sur le test de charge est réelle : elle commente pour demander un test à la limite documentée. Ce commentaire met en file une exécution de suivi pour le même Agent ; elle n'ouvre pas une seconde Tâche.
- Accepter. L'Agent ajoute le test, rend compte à nouveau et renvoie la Tâche à « Prêt pour revue ». Cette fois, les preuves correspondent aux critères. Elle fusionne la PR et fait passer
SH-312à « Terminé » : deux actes délibérés de la part de la personne qui portait ce travail depuis le début.
Chaque étape revient à la Tâche : l'exécution, le lien de la PR, les commentaires de revue, l'acceptation. Rien ne vit uniquement dans un terminal. Notre guide pour réviser du code généré par IA à l'aide de preuves au niveau de la Tâche approfondit ce qu'il faut lire avant d'accepter.
Là où la responsabilité se perd sans bruit
Vous n'avez pas besoin de tout ce rituel pour chaque Tâche, et prétendre le contraire transforme la revue en mascarade. Utilisez la version allégée quand le travail est en lecture seule ou trivialement réversible : un audit de dépôt ou une mise à jour de dépendance avec des tests au vert peut passer directement de l'exécution à une acceptation rapide. Utilisez la boucle complète à quatre rôles, avec un humain nommé aux deux extrémités, dès qu'un changement touche aux données, modifie une interface publique ou ne peut pas être annulé d'une seule commande.
Le mode de défaillance à surveiller n'est pas celui d'agents qui en font trop. C'est la responsabilité qui reste non attribuée. Une Tâche avec un assigné Agent et sans Assigné humain, c'est de l'exécution sans redevabilité : le problème de la branche orpheline déguisé en progrès. La solution tient en une règle, partout : toute Tâche d'Agent désigne un humain qui en répond. Si vous coordonnez des transferts entre plusieurs agents, notre guide des schémas de transfert d'agent à agent et d'agent à humain montre où se situe le propriétaire humain dans la chaîne.
Conclusion
La responsabilité humaine sur le travail des agents n'est pas un frein à l'automatisation. C'est ce qui permet de passer à l'échelle sans risque. Laissez les agents faire l'exécution, toute l'exécution, aussi vite qu'ils le peuvent. Gardez quatre décisions du côté humain : quoi assigner, faut-il accorder l'autorité d'exécuter, le résultat atteint-il la barre fixée, et faut-il le livrer. Consignez ces décisions sous forme de changements de statut sur une Tâche partagée, pour que la redevabilité soit un fait que chacun peut lire, et non une supposition perdue dans le scrollback de quelqu'un.
Si vous faites déjà tourner plusieurs agents de codage, Sharkly vous offre un seul endroit pour assigner leur travail, suivre son exécution et consigner qui a révisé et accepté chaque résultat. Vous pouvez assembler ce modèle à la main avec des worktrees et un tableur, ou télécharger Sharkly et laisser la Tâche s'en charger. Pour découvrir toute l'ampleur de cette couche, commencez par la gestion des agents de codage au-dessus de Claude Code et Codex.
FAQ
La responsabilité humaine implique-t-elle qu'une personne surveille chaque exécution d'agent ? Non. La responsabilité, c'est répondre du résultat, pas surveiller. Une personne assigne le travail et accepte le résultat ; entre les deux, l'agent s'exécute sans supervision. De toute façon, surveiller un terminal ne passe pas l'échelle au-delà d'un seul agent.
Un agent peut-il marquer son propre travail comme terminé ? Non. Un Agent peut faire avancer une Tâche jusqu'à « Prêt pour revue », mais son Workflow de Tâche ne lui accorde pas le statut « accepté ». Une personne lit les preuves et fait passer la Tâche à « Terminé ».
Fusionner la pull request revient-il à accepter la tâche ? Non. Fusionner une PR liée est un événement Git et ne change pas le statut de la Tâche dans Sharkly. L'acceptation est un changement de statut distinct, effectué par le propriétaire humain après la revue.
Qui doit être responsable de la tâche d'un agent ? La personne qui a jugé que le travail valait la peine d'être fait. Sharkly conserve un champ d'Assigné humain à côté de l'assigné Agent, de sorte que le signal de revue soit dirigé vers cette personne, qui l'accepte.
Que se passe-t-il si aucun humain n'est assigné ? Vous obtenez de l'exécution sans redevabilité. La règle sûre est que toute Tâche d'Agent désigne un propriétaire humain, afin qu'une exécution terminée ait toujours quelqu'un pour en répondre.
