Chaque fois qu'un agent de codage termine une tâche, le même vide se creuse. Vous recevez un diff et un joyeux « terminé », mais pas ce qui a changé, ce qui a été laissé de côté, ce qui a été testé, ni ce sur quoi l'agent a encore des doutes. Vous relisez donc le diff, relancez les tests vous-même et reposez des questions auxquelles l'agent aurait pu répondre au moment de rendre le travail. Lancez deux agents et ce coût double. Le travail n'est pas le problème. La passation l'est : ce qui circule entre la personne qui a demandé et l'agent qui a exécuté, et ce qui revient.
Un modèle de passation pour agent de codage est une structure figée qui définit ce qu'une tâche transporte lorsqu'elle change de mains : d'une personne vers un agent au moment de l'attribution, puis d'un agent vers une personne au moment de la revue. Au lieu d'improviser la forme de chaque transfert, vous remplissez les mêmes champs à chaque fois. L'agent sait ce que « terminé » signifie avant de commencer, et vous recevez le même résumé, les mêmes preuves et les mêmes questions ouvertes lorsqu'il s'arrête.
Cet article détaille les deux modèles qui tiennent la route en pratique, avec Sharkly comme flux de travail : la couche au-dessus de vos agents de codage qui garde visibles le contexte, la progression, les blocages, les résultats et la revue humaine, de la demande à la mise en production. Vous avez déjà des agents de codage. Sharkly les transforme en équipe, et le modèle de passation est ce qui fait de chaque transfert un enregistrement plutôt qu'une supposition.
En quoi consiste un modèle de passation pour agent de codage
Un modèle de passation, c'est une liste de contrôle érigée en structure. Il répond à trois questions qu'un simple diff ne résout jamais : ce qui a été demandé, ce qui s'est passé et à qui c'est le tour maintenant. Quand ces trois éléments voyagent ensemble, l'intervenant suivant lit un seul enregistrement au lieu d'en reconstituer trois.
Deux passations méritent d'être formalisées dans un modèle, car elles vont dans des directions opposées et transportent des choses opposées :
- Passation d'attribution (une personne ou un agent leader, vers un agent) : l'objectif, les limites et la définition de « terminé », transmis avant le début du travail.
- Passation de revue (un agent, vers une personne) : la modification, les preuves qu'elle fonctionne et les éléments que l'humain doit encore juger, transmis à l'arrêt du travail.
Formaliser les deux est tout l'intérêt. La plupart des équipes rédigent un ticket approximatif et ne formalisent rien au retour, si bien que chaque revue commence comme un interrogatoire. C'est en corrigeant le trajet retour que le temps se gagne.
Le modèle de fonctionnement que le modèle de passation encode
Un modèle ne vaut que par le modèle de fonctionnement qui le sous-tend. Quatre verbes déterminent qui est responsable de chaque interface : qui attribue, qui exécute, qui révise, qui accepte. Les agents font la recherche, exécutent, testent et rendent compte. Les personnes 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.
C'est ce contrat qui explique pourquoi les deux modèles comportent des champs différents. Un agent ne doit jamais deviner à quoi ressemble l'acceptation, aussi le modèle d'attribution oblige-t-il le demandeur à l'écrire noir sur blanc. Une personne ne doit jamais deviner si un feu vert signifie que tout est sûr, aussi le modèle de revue oblige-t-il l'agent à montrer son travail. Voici la passation d'attribution sous forme de bloc à copier-coller :
## Assignment handoff
Task ID: SH-###
Goal: one sentence, in plain language
In scope: the specific files, endpoints, or behaviors to touch
Out of scope: what to leave alone (auth, billing, public contracts)
Definition of done:
- [ ] observable acceptance criterion 1
- [ ] observable acceptance criterion 2
Constraints: frameworks, patterns, or limits to respect
Assignee: the exact Agent that owns this
Ce sont les lignes « hors périmètre » et « définition de « terminé » » qui font le gros du travail. Sans elles, un agent optimise pour un diff qui passe, pas pour le résultat que vous visiez. Avec elles, le contrôle d'acceptation est rédigé avant qu'une seule ligne de code n'existe.
La passation de revue : ce qui revient
Le modèle de retour est celui que la plupart des flux de travail négligent, et celui qui vous sauve l'après-midi. Quand un agent a terminé, il ne devrait pas vous notifier avec un « c'est prêt » et un lien. Il devrait rendre une structure remplie :
## Review handoff
Task ID: SH-###
Summary: what changed, in 2-3 sentences
Acceptance: each definition-of-done item, checked with how it was verified
Tests: typecheck / unit / build results, pasted or linked
Diff: the PR or worktree branch
Known limits: what this does NOT cover, and any risky assumption
Open questions: decisions left for a human
Les champs « limites connues » et « questions ouvertes » sont ce qui distingue une véritable passation d'un mur de coches vertes. Une limite honnête (« le compteur Redis suppose une seule région ») transforme une fusion à l'aveugle en fusion éclairée. C'est le même principe qui sous-tend la revue du code généré par IA à l'aide de preuves au niveau de la tâche : le relecteur lit une affirmation et sa preuve, pas un diff et un espoir.
Une limite qu'il vaut la peine d'énoncer clairement : la passation de revue n'est pas une demande de fusion. C'est une demande de revue. L'agent présente ; la personne décide. C'est en gardant ces deux actes distincts qu'on empêche du travail non révisé d'être mis en production.
Statuts et points de revue : où le modèle réside
Un modèle qui vit dans l'historique d'un terminal est un modèle que personne ne lit. La passation doit être rattachée à quelque chose de partagé, et les statuts en sont l'emplacement naturel. Chaque tâche chemine dans une seule voie, et chaque changement de statut est une passation avec son modèle joint :
| Statut | Responsable | Modèle joint |
|---|---|---|
| À faire | Une personne ou un agent leader | Passation d'attribution |
| En cours | Agent | (travail dans un worktree isolé) |
| Prêt pour revue | Agent | Passation de revue |
| Terminé | Une personne | note d'acceptation + décision de fusion |
La règle qui rend tout cela lisible : les agents font passer une tâche à « Prêt pour revue » ; les personnes la font passer à « Terminé ». Un agent ne marque jamais son propre travail comme terminé, et une personne n'a jamais à reconstituer ce qui s'est passé, car la passation de revue se trouve déjà sur la tâche. Dans Sharkly, l'exécution, les blocages, les résultats et les discussions de suivi reviennent dans la chronologie de la tâche ; ainsi, quand dix agents tournent, vous lisez le tableau, et non dix terminaux. C'est la différence entre suivre ce que les agents ont accompli et espérer qu'un journal de commits l'explique plus tard. L'endroit où le travail autonome doit s'arrêter est en soi un choix de conception, abordé dans où placer les points d'approbation.
Un exemple concret : du ticket à la PR fusionnée
Prenons une tâche d'allure réelle, SH-441 : « Ajouter l'export CSV à la page des rapports. » Regardez les modèles se remplir, pas le code.
Une personne ouvre SH-441 et un agent leader complète la passation d'attribution : objectif (« permettre aux utilisateurs de télécharger le rapport courant au format CSV »), périmètre inclus (le contrôleur des rapports et un nouveau module d'export), périmètre exclu (l'authentification, les requêtes de rapport existantes) et une définition de « terminé » avec trois éléments vérifiables (un bouton de téléchargement, un échappement correct des virgules et des guillemets, un test avec une fixture de 10 000 lignes). Le destinataire est un agent backend. Rien n'est ambigu, parce que le modèle a refusé de le laisser l'être.
L'agent backend prend la tâche, travaille dans un worktree isolé pour ne jamais entrer en collision avec d'autres travaux, et exécute les éléments de la définition de « terminé » comme sa propre liste de contrôle. Quand la vérification de types, les tests unitaires et la compilation passent au vert, il fait passer SH-441 à « Prêt pour revue » avec le modèle de retour rempli : un résumé court, chaque élément d'acceptation coché avec la manière dont il a été vérifié, le diff et une limite connue (« les exports de plus de 100 000 lignes sont mis en mémoire tampon ; le streaming n'est pas implémenté »).
À présent, la passation change de sens. Une personne lit un seul enregistrement, pas un historique. Elle confirme le test d'échappement, pèse la limite de mémoire face aux tailles réelles des rapports, l'accepte pour l'instant et fait passer SH-441 à « Terminé », ce qui déclenche la fusion. Du ticket à la PR fusionnée, avec un modèle rempli aux deux interfaces et une trace de qui était responsable de chacune. C'est le chemin des exigences au code rendu traçable de bout en bout.
Quand un modèle est superflu
Les modèles ont un coût, alors voici le critère de décision, sans détour. Passez le modèle complet pour un travail petit et bien défini qu'un seul agent termine en une seule passe, où l'objectif et l'acceptation sont évidents d'après le titre de la tâche. Sortez-le dès que le travail franchit une interface qui compte : plusieurs agents sur un même objectif, une modification d'un contrat public, ou tout ce qui touche à l'authentification, à la facturation ou à des données qu'on ne peut pas facilement retirer. Un modèle est une assurance contre le contexte perdu, et on souscrit une assurance là où la perte ferait mal.
Vous pouvez mener tout cela à la main, avec un tableau partagé et de la discipline. Cela fonctionne jusqu'à ce que le nombre d'agents, de tâches et de dépôts augmente, et que la discipline soit la première chose à disparaître. Si vous exécutez déjà plusieurs agents, Sharkly vous offre un seul endroit pour gérer leurs tâches et leurs résultats : des tâches partagées qui portent les passations d'attribution et de revue, un destinataire par tâche, des worktrees isolés et une voie de statut où les agents atteignent « Prêt pour revue » et où les personnes décident « Terminé ». Gardez les agents de codage que vous utilisez déjà. Téléchargez Sharkly quand les interfaces entre eux commencent à coûter plus cher que le travail.
FAQ
Qu'est-ce qu'un modèle de passation pour agent de codage ? C'est une structure figée qui définit ce qu'une tâche transporte lorsqu'elle change de mains. Il en existe deux : une passation d'attribution (objectif, périmètre et définition de « terminé », d'une personne vers un agent) et une passation de revue (résumé, preuves et limites connues, d'un agent vers une personne). C'est en remplissant les mêmes champs à chaque fois que l'on empêche le contexte de s'évaporer entre les intervenants.
Pourquoi formaliser le trajet retour et pas seulement le ticket ? La plupart des équipes rédigent un ticket et ne formalisent rien au retour, si bien que chaque revue commence comme un interrogatoire. La passation de revue, avec son résumé, ses éléments d'acceptation cochés et ses limites connues, est l'endroit où un modèle fait gagner le plus de temps. Voir les agents de codage avec un humain dans la boucle.
Un agent doit-il marquer son propre travail comme terminé ? Non. Laissez un agent faire passer une tâche à « Prêt pour revue » avec le modèle de retour rempli ; réservez le passage à « Terminé », et la décision de fusion, à une personne. C'est en séparant « présenté » de « accepté » que l'on empêche du code non révisé d'être mis en production.
Où le modèle doit-il résider ? Sur une tâche partagée, rattaché à un changement de statut, et non dans un terminal qu'un seul agent a vu. Quand la passation est un statut auquel son modèle est rattaché, l'intervenant suivant voit exactement ce qui l'attend. Cela permet aussi d'éviter que la revue ne devienne le goulot d'étranglement lorsque de nombreux agents terminent en même temps.
Ai-je besoin d'un outil pour cela, ou puis-je le faire manuellement ? Vous pouvez le faire avec un tableau partagé et de la discipline. Une couche dédiée devient rentable dès que vous coordonnez plusieurs agents sur plusieurs dépôts et que le suivi manuel devient le travail à part entière. Comparez-la à un gestionnaire de tâches IA polyvalent pour le travail des agents.
