La plupart du travail de code commence encore par une phrase dans un groupe de discussion. « L'export CSV perd la dernière ligne. » « On peut ajouter le SSO avant la démo ? » « La prod renvoie des 500 au checkout, encore. » Quelqu'un réagit avec un pouce levé, on pointe peut-être un agent de codage dessus, et trois jours plus tard personne ne peut dire si c'est parti en production, qui l'a relu, ou quel commit l'a corrigé. Le message défile et disparaît. Le travail devient une légende.
Cet écart est un problème de structure, pas de discipline. Un message de chat n'a ni propriétaire, ni statut, ni test d'acceptation, ni lien vers le diff qui le résout. Pointez un agent de codage sur ce message et vous avez créé un travail impossible à tracer. Ça empire dès que vous faites tourner plus d'un agent, parce que vous ne pouvez plus dire non plus lequel y a touché.
Cet article montre comment transformer un message de chat en tâche de code traçable : ce qu'apporte une installation bricolée, où elle cesse de passer à l'échelle, et ce qu'ajoute une couche de tâches partagée. Sharkly est l'espace de travail pour la version traçable, parce qu'il se place au-dessus de vos agents de codage et conserve l'objectif, l'exécution, les blocages, le diff et la revue humaine dans un seul enregistrement. Vous avez déjà des agents de codage. Le boulot, c'est de transformer leur travail en quelque chose qu'une équipe peut suivre.
Pourquoi le chat est le cimetière des tâches de code
Un groupe de discussion est optimisé pour la rapidité de la conversation, soit l'exact opposé de ce dont une tâche de code a besoin. Une vraie tâche porte un objectif énoncé, un propriétaire, des critères d'acceptation, un statut interrogeable et un lien vers le changement qui l'a clôturée. Un message de chat ne porte rien de tout ça. Il porte un horodatage et une réaction.
Le mode de défaillance est précis. Une demande arrive, on s'accorde tacitement dessus dans le fil, et le fil continue d'avancer. Deux jours plus tard, quelqu'un demande « on a fini par corriger le bug d'export ? » et la réponse exige une recherche Slack, des suppositions et un défilement dans un canal où la même phrase apparaît neuf fois. Même si vous retrouvez le message, il ne vous dit pas si le correctif a été fusionné. La conversation et le code vivent dans des systèmes séparés qui n'ont jamais appris à se connaître.
Pointez un agent de codage autonome sur ce message et la trace se raccourcit encore. L'agent lit une ligne Slack, s'exécute dans un terminal sur l'ordinateur de quelqu'un, modifie des fichiers et rend compte dans le même fil qui avance vite et qui a déjà avalé la demande. Vous avez maintenant un journal d'exécution que personne n'a sauvegardé, un changement que personne n'a relié, et une décision que personne n'a consignée.
Le pipeline fait maison, et où il cesse de passer à l'échelle
Pas besoin d'un produit pour commencer. Un pipeline fait maison viable : copier le message du chat, le coller dans votre agent de codage comme prompt, le laisser travailler dans un worktree Git isolé pour qu'il n'entrre pas en collision avec votre copie principale, et ouvrir une pull request qui renvoie vers un ticket de suivi avec une ligne Closes #123. C'est de la vraie traçabilité, et pour un développeur solo qui traite une demande à la fois, c'est souvent suffisant.
Voici le vrai choix, posé honnêtement. Si vous êtes une seule personne, avec un seul agent, à clore une tâche avant la suivante, la boucle copier-coller-vers-worktree fonctionne et vous ne devriez rien y ajouter. La surcharge d'un système partagé coûterait plus qu'elle ne rapporte.
L'installation cesse de passer à l'échelle dès que deux choses sont vraies en même temps : deux agents en cours, ou deux personnes qui orientent le travail, ou deux dépôts en jeu. Le pipeline manuel se met alors à fuir :
| Ce qui casse | Pourquoi la boucle maison ne peut pas le couvrir |
|---|---|
| « Quel agent a le bug d'export ? » | L'affectation vivait dans votre tête, pas dans un enregistrement |
| « C'est fini ou ça tourne encore ? » | Le statut est un terminal que vous avez fermé, pas un champ interrogeable |
| « Qui a validé la modif d'auth ? » | La validation était un pouce levé, désormais hors écran |
| « Où est le diff pour cette demande Slack ? » | La PR renvoie vers un ticket, mais le ticket ne renvoie jamais vers la demande |
| « Qu'est-ce que l'agent a vraiment modifié ? » | Le journal d'exécution vivait dans une session qui s'est terminée |
Chaque trou est un endroit où la tâche redevient intraçable. Vous pouvez les rafistoler à la main avec plus de tickets, de conventions de nommage et de discipline. Ça marche jusqu'à ce que ça ne marche plus, et ça échoue en silence, ce qui est la pire façon pour un processus d'échouer.
Ce que « traçable » veut dire une fois la tâche partagée
Traçable, ce n'est pas une impression. Chaque question sur un travail a une réponse qui vit au même endroit et survit aux personnes qui étaient en ligne au moment où il a commencé. Une tâche traçable garde le contexte, l'affectation, l'avancement, les blocages, les résultats et la revue humaine visibles, de la demande à la mise en production.
Sharkly modélise cela sous forme de Task, l'unité de travail principale du système. Une Task n'est ni un message de chat, ni une session de terminal. C'est l'enregistrement partagé qu'un message de chat devient dès que vous décidez d'agir. L'objectif va dans la description. Un Agent ou une personne devient l'Assignee. L'exécution de l'Agent, ses blocages, ses résultats et la discussion qui suit reviennent tous dans la timeline de la Task au lieu de disparaître dans un terminal privé. Quand le changement arrive, la pull request est reliée par ID, si bien que la demande et le diff finissent par connaître leurs noms respectifs.
Une limite compte, car un lecteur pourrait supposer le contraire. Sharkly ne remplace pas Claude Code, Codex ou vos autres agents de codage. Ces outils exécutent. Sharkly ajoute la couche de tâche partagée, de contexte et de revue autour d'eux. L'Agent écrit toujours le code. Sharkly rend le travail assignable et traçable.
Transformer un message de chat en tâche traçable avec Sharkly
Le flux de travail est assez court pour être gardé en tête. Partez d'un vrai message, disons le bug d'export CSV, et faites-le sortir du canal :
- Capturez le message sous forme de Task. Créez une Task avec la demande comme objectif. Si votre chat vit dans Slack, un bot Slack pour agents de codage transforme la mention en Task sans quitter le fil.
- Formulez-la pour qu'un Agent puisse l'exécuter. Un rapport de bug d'une ligne n'est pas une spec exécutable. Ajoutez la reproduction, le comportement attendu et un test d'acceptation. Même discipline que pour la gestion de tâches pour agents IA : une Task qu'un Agent peut clore a besoin d'une description sur laquelle un Agent peut agir.
- Assignez-la et laissez l'Agent travailler. L'Agent prend la Task, travaille dans un worktree isolé pour que le travail parallèle n'entrre pas en collision, et diffuse sa progression dans la Task. Vous regardez un enregistrement, pas un terminal.
- Relisez et acceptez. L'Agent joint son résumé des modifications, ses résultats de tests et ses limites connues. Une personne accepte, demande des changements, ou prend la décision de fusionner.
Cette dernière étape est le contrat qu'il vaut la peine d'énoncer clairement : les Agents explorent, 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. Une tâche traçable rend ce passage de relais possible, parce que l'humain qui relit le changement voit tout le chemin de la demande au diff. Une fois le travail terminé, vous pouvez suivre ce que l'agent a réalisé sans le reconstituer de mémoire. C'est la même colonne vertébrale qu'un flux complet des exigences au code, en partant d'un bout de chat plutôt que d'un ticket formel.
Vous pouvez construire une version de tout ça à la main avec des tickets et des worktrees, ou utiliser Sharkly pour gérer le flux de travail afin que la trace tienne quand le volume grimpe.
La checklist applicable dès aujourd'hui
Passez-la sur votre installation actuelle. Chaque case non cochée est un endroit où une tâche née d'un chat peut échapper à toute traçabilité :
- [ ] Chaque demande de chat suivie d'effet devient une Task avec un responsable, pas un emoji de réaction.
- [ ] Chaque Task a une description qu'un Agent peut exécuter : repro, comportement attendu, test d'acceptation.
- [ ] Chaque Agent en cours travaille dans un worktree isolé, pour que deux tâches ne touchent jamais aux mêmes fichiers.
- [ ] Le journal d'exécution, les blocages et les résultats de l'Agent reviennent dans la Task, pas dans un terminal qui se ferme.
- [ ] La pull request est reliée à la Task par ID, si bien que la demande et le diff sont à un clic l'un de l'autre.
- [ ] Un humain accepte ou refuse le résultat, et cette décision est consignée dans la Task.
- [ ] Vous pouvez répondre à « est-ce fini, qui l'a fait, et où est le diff ? » sans chercher dans le chat.
En traitant une demande à la fois, la boucle manuelle coche la plupart de ces points toute seule. En faisant tourner plusieurs agents au sein d'une équipe, Sharkly vous donne un seul endroit pour gérer leurs tâches et leurs résultats. Téléchargez Sharkly et basculez une vraie demande de chat dans une Task avant d'y consacrer tout le canal.
FAQ
Est-ce que j'ai besoin de Sharkly pour rendre traçables des tâches nées d'un chat ? Non. Un développeur seul avec un seul agent obtient une vraie traçabilité avec un worktree plus une pull request reliée à un ticket. Le modèle de la boîte de réception pour agents IA gagne sa place dès que vous avez plusieurs agents ou plusieurs personnes et que les liens manuels commencent à glisser.
Qu'est-ce qui rend un message de chat difficile à exécuter pour un agent de codage ? Il lui manque généralement une reproduction, un résultat attendu et un test d'acceptation. Transformez « l'export est cassé » en « l'export CSV perd la dernière ligne ; attendu N lignes, obtenu N-1 ; corrigé quand le compte correspond ». L'Agent a alors quelque chose contre quoi clore la tâche.
En quoi est-ce différent d'un système de tickets classique ? Un ticket suit un travail qu'un humain va faire. Une tâche de code traçable porte aussi le journal d'exécution de l'Agent, son exécution isolée et le diff relié, si bien que l'enregistrement couvre la décision et le changement. Voir les agents de codage avec humain dans la boucle pour savoir où la personne reste impliquée.
Sharkly peut-il lire mon canal Slack directement ? Vous connectez un Agent Sharkly à Slack pour qu'une mention devienne une Task. La conversation reste dans Slack ; l'enregistrement de travail traçable vit dans Sharkly.
