Claude Code est un outil de codage agentique qui lit votre base de code, modifie des fichiers, exécute des commandes et travaille directement avec git. Pour un développeur seul dans un seul terminal, il ne demande aucune gestion : vous décrivez le travail, vous le regardez s'exécuter et vous relisez le diff. Cette boucle est rapide, et rien dans ce guide ne vous demande d'y renoncer.
Le décalage apparaît dès qu'une équipe en dépend. Cinq développeurs qui lancent des sessions Claude Code produisent du vrai résultat, mais ce travail reste enfermé dans des terminaux privés. Personne ne peut répondre aux questions sur lesquelles une équipe fonctionne : qui a demandé ce changement, qui l'exécute à cet instant, qu'a réellement fait l'exécution, et qui a validé le résultat avant la fusion. L'exécution est excellente ; la trace du travail, elle, n'existe pas.
La gestion de projet avec Claude Code consiste à traiter ce travail comme un véritable travail de projet, suivi et relisible : un ticket devient une tâche cadrée, la tâche est assignée à un agent qui exécute via Claude Code, l'exécution se déroule dans un worktree isolé sur une machine que vous contrôlez, et le résultat revient à un humain pour relecture. Ce guide déroule ce parcours avec Sharkly, qui ne remplace pas Claude Code. Il ajoute la couche partagée de tâches, de contexte, de contrôle et de relecture autour de l'outil que votre équipe utilise déjà.
TL;DR
Pour gérer le travail Claude Code comme un travail de projet, rédigez le ticket sous la forme d'une tâche cadrée avec un objectif, des limites et des critères d'acceptation ; assignez-la à un agent dont le Runtime est Claude Code ; laissez l'exécution se faire sur un Computer connecté, dans un worktree git isolé, pendant que la progression remonte en continu ; puis examinez les preuves sur la tâche et acceptez, demandez des modifications ou réassignez. C'est Claude Code qui exécute. Sharkly gère autour de lui l'assignation, le contexte, la progression, les blocages, les résultats et la relecture humaine, afin que les exécutions parallèles restent visibles pour toute l'équipe au lieu de disparaître dans des terminaux privés. Les sessions en terminal en solo restent l'outil idéal pour un travail rapide, local et sans grand enjeu.
Ce qu'une tâche gérée apporte à une session Claude Code brute
Une session brute et une tâche gérée font tourner le même Claude Code en dessous. La différence tient à tout ce qui entoure l'exécution, et elle se répartit en quatre capacités qu'un terminal ne peut pas offrir.
Visibilité partagée. Une tâche réunit au même endroit les exigences, l'état de la tâche, les échanges, les enregistrements d'exécution et la relecture, au lieu de les disperser entre des prompts et des sessions privés. Un collègue peut ouvrir SH-214 et voir ce qui a été demandé, ce qui tourne et ce qui est revenu.
Responsabilité. Une tâche sépare la responsabilité humaine de l'exécution par l'agent. Une personne répond du résultat ; un agent ou un Crew est l'exécutant assigné. Les deux sont enregistrés, si bien que « qui est responsable de ceci » a toujours une réponse.
Des preuves pour la relecture. Chaque exécution produit une trace : quand elle a démarré, quels outils elle a appelés, pourquoi elle a été mise en file d'attente et comment elle s'est terminée. Le rapport de l'agent est conservé sous forme de commentaire lié à cette trace. La relecture cesse d'être « faites confiance à celui qui a regardé le terminal » pour devenir « lisez le compte rendu ».
Des exécutions parallèles sans collision. Chaque tâche dispose d'un répertoire isolé, et un travail adossé à un dépôt peut utiliser un worktree git distinct par exécution : plusieurs tâches peuvent donc modifier la même base de code en même temps. Ces mécanismes de parallélisme font l'objet d'un guide dédié : comment exécuter plusieurs agents Claude Code en parallèle.
Une limite à poser honnêtement avant de commencer. Toutes les sessions Claude Code n'ont pas besoin de cela. Utilisez un Agent Chat autonome, ou une simple session en terminal, pour explorer une question, élaborer un plan ou faire une modification locale rapide. Utilisez une tâche quand le travail exige une responsabilité identifiée, un statut, un historique d'exécution ou une relecture.
Étape 1 : transformer le ticket en une tâche qu'un agent peut exécuter
Le parcours commence avant même qu'un agent se lance. Claude Code élabore son approche à partir de ce que vous lui donnez : une tâche vague produit donc une exécution assurée dans la mauvaise direction.
Un bon titre de tâche nomme le résultat attendu plutôt que le sujet. La description doit contenir tout ce dont une nouvelle personne, ou un agent, aurait besoin pour avancer : pourquoi le travail compte ; ce qui entre ou non dans le périmètre ; les fichiers, liens ou comportements observés pertinents ; les contraintes et les décisions déjà prises ; et la manière dont l'achèvement sera évalué.
C'est ce dernier point que les workflows en solo oublient. Écrire dans la description « terminé signifie que la logique de retry dispose d'un test qui échoue avec l'ancien comportement » donne une liste de contrôle au relecteur et une cible à l'agent. Gardez dans la description l'objectif, le périmètre et les critères d'acceptation, qui ne bougent pas ; réservez les commentaires aux échanges.
La catégorie de statut compte aussi : une tâche en Backlog est en attente, et lui assigner un agent ne déclenche pas l'exécution. C'est voulu. Vous pouvez préparer un lot de tâches, les assigner toutes, puis libérer chacune délibérément en la sortant du Backlog quand elle est prête.
Si vos tickets vivent déjà ailleurs, vous n'avez pas à reconstruire votre processus. Les intégrations de Sharkly incluent Jira, Slack et GitHub : vos outils de suivi actuels restent en place, tandis que l'exécution devient assignable et traçable. La discipline qui consiste à rédiger un travail exécutable par des agents s'inscrit dans une mutation plus large, que nous abordons dans qu'est-ce que le codage agentique.
Étape 2 : l'assigner à un agent dont le Runtime est Claude Code
Dans Sharkly, vous n'assignez pas le travail directement à Claude Code. Vous l'assignez à un agent, et le Runtime de cet agent est Claude Code. La distinction a son importance.
Un agent est une configuration de travail enregistrée, et non un prompt ponctuel : ses instructions, son Runtime, ses Skills, ses dépôts, ses variables d'environnement et ses paramètres d'exécution déterminent sa façon de traiter le travail. Une personne configure une fois un agent « Backend Fixer », le partage dans le Space, et toute l'équipe assigne du travail à cette même configuration éprouvée au lieu que chaque développeur improvise ses prompts. Nous détaillons le concept dans Les agents de Sharkly, expliqués.
Le Runtime est l'outil d'agent concret disponible sur un Computer. Quand vous connectez une machine, un petit service local détecte les outils d'agent pris en charge qui y sont installés et les déclare chacun comme un Runtime ; une installation de Claude Code apparaît comme Runtime disponible dès que le service la repère.
Trois faits sur ce fonctionnement permettent de garder les bonnes attentes :
- L'agent suit le modèle par défaut du Runtime. Sharkly n'affiche ni ne promet de nom de modèle, et il n'existe aucun sélecteur de modèle ni réglage de profondeur de réflexion sur l'agent. Pour changer de modèle, modifiez la configuration dans Claude Code lui-même.
- L'usage du modèle repose sur vos propres abonnements. Les exécutions consomment l'abonnement Claude ou la clé API déjà configurés dans Claude Code sur ce Computer. Le quota de modèle dépend des outils de codage IA, des forfaits et des comptes API que votre équipe connecte.
- L'assignation est explicite. Vous ouvrez le sélecteur Assignee de la tâche et choisissez l'agent, comme vous assigneriez un ticket à un collègue. La personne responsable reste enregistrée séparément.
Pour un travail petit et bien défini, assignez directement la tâche à un seul agent. N'utilisez un Crew, un groupe réutilisable de personnes et d'agents coordonné par un agent leader, que lorsque ce leader a réellement besoin d'interpréter l'objectif et de ramener les résultats des autres membres dans une seule tâche. La version pas à pas d'une première assignation se trouve dans comment assigner votre première tâche à un agent IA.
Étape 3 : l'exécution sur un Computer, dans un worktree isolé
Quand la tâche quitte le Backlog et que l'agent est prêt, Sharkly met l'exécution en file d'attente et la transmet au Computer sélectionné : votre portable, un serveur distant ou un conteneur. Le service local de cette machine reçoit l'exécution, prépare le répertoire de la tâche, démarre Claude Code et renvoie la progression en continu. Votre code, vos identifiants et votre installation de Claude Code ne quittent jamais du matériel que vous contrôlez.
Cette séparation des responsabilités mérite d'être énoncée clairement : l'agent définit comment le travail doit être traité ; le Computer fournit l'hôte et les ressources locales ; le Runtime exécute la session d'agent proprement dite ; la tâche reste le compte rendu partagé.
Pour le travail sur dépôt, le mode de répertoire de travail recommandé est Temporary : chaque tâche dispose d'un répertoire isolé, et le service local peut préparer un nouveau worktree git par exécution à partir des données de dépôt mises en cache. Deux tâches portant sur le même dépôt écrivent dans deux répertoires différents sur le disque : c'est pourquoi les exécutions parallèles ne se marchent pas dessus. Cette primitive est traitée dans comment utiliser les worktrees git avec les agents de codage IA. Le mode Specified, un répertoire local configuré que les exécutions réutilisent, existe pour les exceptions légitimes : un dépôt très volumineux, des caches locaux coûteux ou des outils liés à un chemin unique.
Pendant que Claude Code travaille, l'exécution traverse des états visibles : en file d'attente, transmise, en cours, puis terminée, échouée ou annulée. L'état de l'exécution est distinct du statut de la tâche, et cette séparation est utile : une tâche peut rester In Progress pendant que son agent travaille, attend une réponse humaine ou signale une erreur, sans que personne ait à surveiller un terminal pour savoir dans quel cas on se trouve.
Étape 4 : la progression et les blocages remontent dans la tâche
Tout ce que l'équipe doit voir revient au même endroit. Le rapport de l'agent est stocké sous forme de commentaire lié à sa trace d'exécution. Activity affiche les commentaires et les modifications de la tâche sur une même chronologie. Executions conserve l'historique des exécutions : source de déclenchement, heures de début et de fin, appels d'outils et détails des échecs.
Les blocages remontent au lieu de stagner en silence. Un agent peut laisser une tâche en attente d'une réponse ou d'une relecture humaine, et les tâches bloquées alimentent l'Inbox, la file personnelle qui distingue les tâches réclamant votre attention des mises à jour de moindre priorité. La différence est structurelle : une session à l'arrêt attend que vous pensiez à consulter l'onglet, tandis qu'une tâche bloquée prévient la personne responsable qu'elle est bloquée.
Poursuivre le travail se fait par un commentaire, pas par une nouvelle session. Un commentaire éligible sur une tâche toujours assignée à l'agent déclenche une exécution de suivi avec tout le contexte accumulé de la tâche, et les commentaires rapprochés sont regroupés pour éviter de créer des exécutions en attente en double.
Étape 5 : relecture humaine et acceptation
Le parcours se termine là où il doit se terminer : sur une personne. Les agents cherchent, exécutent, testent et rendent compte. Les humains donnent la direction, accordent l'autorité et acceptent le résultat.
Relire une tâche gérée, c'est lire des preuves, pas revoir une session. Le relecteur confronte le rapport de l'agent aux critères d'acceptation rédigés à l'étape 1 : le travail est-il resté dans le périmètre, les vérifications pertinentes ont-elles été lancées, les conclusions sont-elles étayées, les incertitudes ont-elles été consignées plutôt que devinées. La trace d'exécution est là quand le résumé ne suffit pas.
L'acceptation prend alors l'un de trois chemins, tous assumés. Accepter le travail et faire passer la tâche à un statut terminé. Demander des modifications via un commentaire ciblé, ce qui lance une exécution de suivi portant tout le contexte. Ou considérer que l'exécution a mal tourné : l'annuler, lire le journal d'exécution, puis réessayer ou confier le travail à un autre agent.
Rien de tout cela ne remplace votre relecture git. Claude Code crée des branches, écrit des commits et ouvre des pull requests via votre hébergement git habituel, et votre relecture de fusion reste là où elle est. La tâche ajoute ce que la page de PR ne peut pas montrer : la demande d'origine, les preuves d'exécution et l'acceptation enregistrée.
Session en solo vs tâche gérée
| Question | Session Claude Code en solo | Tâche Sharkly gérée |
|---|---|---|
| Qui a demandé cela ? | Votre mémoire | La description de la tâche, avec périmètre et critères d'acceptation |
| Qui travaille dessus ? | Celui qui occupe le terminal | Une personne responsable, plus un agent comme exécutant assigné |
| Que se passe-t-il en ce moment ? | Il faut surveiller le terminal | L'état de l'exécution sur la tâche, les tableaux et l'Inbox |
| Qu'a fait l'exécution ? | L'historique du terminal, jusqu'à la fermeture de l'onglet | La trace d'exécution et les commentaires conservés |
| Deux exécutions peuvent-elles partager un dépôt ? | Seulement si vous créez les worktrees à la main | Un worktree isolé par tâche par défaut |
| Qui a approuvé le résultat ? | Personne ne l'enregistre | La relecture et l'acceptation sur la tâche |
| L'équipe peut-elle réutiliser la configuration ? | Les prompts restent chez une seule personne | Des agents et des Skills partagés dans le Space |
La colonne de gauche n'est pas la mauvaise colonne. C'est le bon outil pour l'exploration et les corrections rapides. La colonne de droite s'impose quand le travail doit être visible, relisible et parallèle.
D'une tâche à un projet géré
Tout ce qui précède passe d'une seule tâche à un plan sans changer de forme. Les tâches se regroupent en Projects lorsque plusieurs servent un même résultat, et en Sprints quand la question est de savoir ce qui sera livré dans ce laps de temps. Les Views enregistrent les questions qu'une équipe se pose en boucle, comme les tâches en attente de relecture.
Voilà toute la thèse de ce workflow. Le levier d'une équipe ne vient pas de l'ouverture de plus de chats IA ; il vient du partage des rôles, des règles, du contexte et des workflows. La place de cette discipline dans le paysage plus large fait l'objet de notre guide pilier, qu'est-ce que la gestion de projet par agents IA.
Commencez plus petit que nécessaire. Connectez un seul Computer, vérifiez que Claude Code apparaît comme Runtime disponible, créez un agent au rôle étroit et assignez-lui une tâche à faible risque avec de vrais critères d'acceptation. Relisez le résultat comme vous reliriez la première pull request d'un nouveau collègue. La documentation Sharkly approfondit chaque concept.
FAQ
Sharkly remplace-t-il Claude Code ?
Non. Sharkly ne remplace ni Claude Code, ni Codex, ni les autres outils d'exécution. C'est Claude Code qui exécute : il lit la base de code, modifie les fichiers, lance les commandes et travaille avec git. Sharkly ajoute la couche propre à l'équipe autour de lui : assignation, contexte des tâches, progression, blocages, résultats et relecture humaine.
Faut-il un abonnement de modèle distinct pour exécuter Claude Code via Sharkly ?
Non. L'usage du modèle passe par les abonnements ou les clés API déjà configurés dans Claude Code sur vos Computers connectés. Le quota de modèle dépend des outils de codage IA, des forfaits et des comptes API que votre équipe connecte.
Puis-je continuer à utiliser Claude Code directement dans le terminal ?
Oui, et c'est même recommandé. Une session directe ou un Agent Chat autonome est l'outil idéal pour explorer une question, élaborer un plan ou faire une modification locale rapide. Passez à une tâche quand le travail exige une responsabilité identifiée, un statut, un historique d'exécution ou une relecture.
Que se passe-t-il lorsqu'une exécution échoue ?
L'exécution est marquée comme échouée sur la tâche, et le journal d'exécution consigne le titre ainsi que les détails techniques d'origine fournis par le service de modèle. Les conseils de dépannage de Sharkly associent les cas courants, comme les limites de débit, le quota épuisé ou les erreurs d'authentification, aux étapes suivantes, et renvoient à la référence d'erreurs de Claude Code. Réessayez après avoir corrigé la cause, ou assignez la tâche à un autre agent.
Plusieurs tâches Claude Code peuvent-elles tourner sur le même dépôt en même temps ?
Oui. En mode de répertoire de travail Temporary, chaque tâche s'exécute dans son propre répertoire isolé, et chaque exécution adossée à un dépôt peut disposer d'un nouveau worktree git : les tâches simultanées n'écrivent donc pas dans une copie de travail partagée. Les limites de concurrence de l'agent et du Computer plafonnent le nombre d'exécutions simultanées.
