Vous commencez avec un terminal et Claude Code. Puis une deuxième tâche arrive : vous ouvrez un second terminal et lancez Codex dessus. Un correctif frontend part dans un troisième. Vous voilà à faire des alt-tab entre trois fenêtres, à essayer de vous rappeler laquelle vous attend, laquelle a posé une question il y a dix minutes, et laquelle a discrètement terminé et tourne à vide pendant que vous brûlez votre attention sur les deux autres. Rien n'est en feu. Mais c'est vous qui êtes devenu le routeur du travail entre les agents, et ce rôle passe à l'échelle moins bien que n'importe lequel d'entre eux.
Le coût, ce ne sont pas les terminaux. C'est vous. Quand les agents tournent à la main, chaque décision sur la suite vit à un seul endroit : votre tête. Quel agent reçoit la tâche suivante, si le dernier diff est sûr, ce qui a échoué pendant que vous lisiez une autre fenêtre. Cette coordination est un vrai travail, elle n'est pas payée, et elle croît plus vite que le nombre d'agents que vous ajoutez.
Cet article détaille ce que coûte réellement l'exécution manuelle d'agents de codage, où la facture se cache jusqu'à ce qu'elle s'accumule, et le workflow qui en élimine l'essentiel. Sharkly est la couche de gestion qui se place au-dessus de vos agents : vous gardez Claude Code, Codex ou le runtime que vous utilisez déjà, et Sharkly regroupe les tâches, l'isolation et la revue dans un espace partagé plutôt que sur un mur de terminaux.
TL;DR
Faire tourner des agents de codage à la main semble gratuit, car aucun outil ne le facture. Le vrai coût, c'est votre attention : vous devenez le routeur entre les agents, la mémoire de ce que fait chacun, et l'unique relecteur qui doit rattraper chaque fenêtre. Ce coût reste faible avec deux ou trois agents et s'accumule au-delà de cinq. Vous pouvez continuer à le faire manuellement, ou faire passer vos agents existants par une couche de tâches comme Sharkly qui attribue le travail, isole chaque exécution et renvoie chaque résultat dans une Task pour revue.
Le problème, ce ne sont pas les terminaux, c'est vous
Voici la définition qui vaut la peine d'être retenue : un terminal est l'endroit où tourne un agent ; une tâche est le travail sur lequel il tourne. Quand vous gérez vos agents à la main, rien ne relie les deux à part vous. Le terminal affiche la sortie. Il ne sait pas quelle était la tâche, si elle est terminée, ni qui décide de la suite. C'est vous qui fournissez tout cela de mémoire, une fenêtre à la fois.
C'est pourquoi « trop de terminaux » est un symptôme, pas la maladie. Répartir un agent sur cinq panneaux avec tmux ne réduit pas la coordination ; cela ne fait que la réorganiser. Vous gardez toujours en tête la carte de quel panneau possède quelle tâche, laquelle est en cours d'exécution, et laquelle est terminée et attend qu'un humain y jette un œil. Cette carte n'existe nulle part en partagé : dès que vous vous absentez, elle devient obsolète, et dès qu'un collègue en a besoin, elle n'existe pas.
Ce que coûte réellement l'exécution manuelle des agents
La facture se paie en attention, et l'attention a un prix mesuré. Quand vous passez d'une tâche sans rapport à une autre, vous ne reprenez pas instantanément. Des recherches de Gloria Mark et de ses collègues sur le travail intellectuel interrompu, publiées à CHI 2008, ont montré qu'il faut en moyenne plus de vingt minutes à une personne pour revenir à une tâche interrompue après avoir été détournée. La synthèse de l'American Psychological Association sur les recherches consacrées à l'alternance de tâches estime la perte de productivité liée au passage d'une tâche à l'autre à jusqu'à 40 %. Chaque fois qu'un agent termine et que vous pivotez vers une autre fenêtre, vous payez une variante de cette taxe.
Exécuter des agents à la main fait de ce changement de contexte votre boucle principale. Voici où le coût s'accumule :
| Coût caché | À quoi cela ressemble à la main | Pourquoi cela s'accumule |
|---|---|---|
| Routage | Vous décidez de mémoire quel agent reçoit chaque nouvelle tâche | Plus d'agents signifie plus d'associations à garder en tête |
| Rechargement du contexte | Vous relisez chaque terminal pour vous rappeler ce qu'il faisait | Chaque bascule relance le chrono pour se replonger dans cette tâche |
| Dérive d'état | Chaque terminal porte sa propre branche, son environnement et ses modifications à moitié faites | Deux tâches dans un même dossier se corrompent discrètement l'une l'autre |
| Arriéré de revues | Vous êtes le seul à avoir vu chaque exécution se produire | Le travail terminé attend l'unique personne capable de le relire |
| Aucun enregistrement partagé | Le statut vit dans votre session, nulle part où un collègue puisse le voir | Éloignez-vous et la progression devient invisible ; personne ne peut reprendre le flambeau |
Aucun de ces coûts ne se manifeste par un plantage. Ils se manifestent par une journée qui semblait bien remplie et qui a produit trois PR fusionnées au lieu de huit, sans qu'on puisse pointer un moment précis comme étant le problème.
Les modes de défaillance se cachent jusqu'à ce qu'ils s'accumulent
Avec deux agents, vous pouvez garder toute la carte en mémoire de travail et le coût est proche de zéro. Cela mérite d'être dit sans détour, car c'est là que la plupart des conseils exagèrent le problème : si vous faites tourner un ou deux agents sur une seule machine et que vous relisez chacun avant de lancer le suivant, vous n'avez pas encore besoin d'une couche de gestion. Gardez le nombre de pièces mobiles à zéro.
L'équation change dès que le travail se chevauche dans le temps ou dans l'état. Lancez trois agents dans le même checkout et vous tombez sur le problème d'isolation traité dans plusieurs agents de codage dans le même dépôt : deux agents touchent les mêmes fichiers, et l'un écrase silencieusement l'autre. Réglez cela avec un worktree par tâche, la discipline décrite dans les worktrees d'agents de codage, et vous échangez un problème de fusion contre un problème de tenue de registre : quel dossier correspond à quelle tâche, lequel peut être supprimé sans risque, lequel est en cours de revue par un humain. Résolvez cela avec plus de terminaux et vous revenez au point de départ, avec seulement plus de fenêtres.
Le dernier coût est le plus discret. Quand chaque exécution se déroule dans un terminal privé, le travail terminé n'a nulle part où aller sinon vers votre attention. La revue devient le goulot d'étranglement, car vous êtes la seule personne à avoir regardé l'agent travailler et le seul à pouvoir dire si le diff est bon. Les agents en parallèle n'aident en rien si la relecture de leur production se sérialise sur un seul humain. C'est le piège décrit dans pourquoi le meilleur agent de codage compte moins que la façon dont vous les gérez : le modèle est devenu plus rapide, mais pas votre file de revues.
Ce que la couche de gestion élimine
Un tableau de tâches élimine la partie que vous faisiez à la main : servir de tissu conjonctif entre les agents et le travail. Dans Sharkly, la Task est l'unité qui porte l'exécution. Vous assignez une Task à un Agent, et Sharkly prépare un worktree isolé sur un Computer connecté, y exécute la session de l'agent, puis renvoie le diff, les logs et les éventuels blocages dans cette Task. Le routage, l'isolation et le registre que vous gardiez en tête deviennent des propriétés de la Task.
Cela préserve une répartition du travail limpide. Les agents explorent, exécutent, testent et rendent compte ; les humains fixent la direction, accordent l'autorité et acceptent le résultat. Sharkly ne remplace ni Claude Code, ni Codex, ni le runtime que vous utilisez déjà ; ce sont eux qui exécutent. Il ajoute autour d'eux la tâche partagée, le Computer connecté et la couche de revue, afin que le contexte, la progression, les blocages, les résultats et la revue humaine restent visibles de la demande à la livraison, au lieu d'être éparpillés dans cinq sessions que vous seul pouvez voir. Quand vous devez surveiller plusieurs exécutions en même temps, c'est précisément à cela que sert un tableau de bord d'agents, et c'est pourquoi les équipes finissent par vouloir la couche au-dessus de Claude Code et Codex plutôt qu'un terminal de plus.
Si vous faites déjà tourner plusieurs agents, c'est le workflow autour duquel Sharkly est conçu. Vous pouvez continuer à router à la main entre les terminaux, ou faire passer vos agents de codage existants par Sharkly et laisser le tableau porter la carte.
Quand le manuel suffit, et quand il ne suffit plus
La règle de décision honnête est courte :
- Faites tourner vos agents à la main quand vous en avez un ou deux, sur une seule machine, et que vous relisez chacun avant de lancer le suivant. La surcharge d'un outil ne se justifie pas encore.
- Passez à une couche de tâches quand un troisième agent entre en jeu, que le travail s'étend sur plus d'un dépôt, ou que quelqu'un d'autre que vous a besoin de voir ce qui tourne. C'est le moment où le coût de coordination cesse de tenir dans la tête d'une seule personne.
Le signal n'est pas le nombre de terminaux. C'est le moment où vous vous surprenez à demander « attends, c'était dans quelle fenêtre, déjà ? ». Cette question est la taxe de coordination qui se manifeste sous forme de phrase, et c'est exactement le chaos des agents qu'un tableau de tâches existe pour faire cesser.
FAQ
tmux ou un multiplexeur de terminaux ne suffit-il pas ? Il organise les fenêtres ; il n'élimine pas la coordination. Vous gardez toujours en tête quel panneau possède quelle tâche, ce qui est terminé et qui le relit. Un multiplexeur résout la question de l'espace à l'écran. Le coût de l'exécution manuelle des agents, c'est l'attention, pas les pixels.
Combien d'agents puis-je faire tourner à la main avant que ça fasse mal ? La plupart des gens s'en sortent avec un ou deux et commencent à le sentir vers trois à cinq, surtout sur plus d'un dépôt. Le nombre exact dépend de la durée de chaque tâche et du temps de revue que chacune exige. Le signe révélateur, c'est quand le routage et la relecture des fenêtres prennent plus de votre journée que la revue elle-même.
Un tableau de tâches rend-il mes agents plus rapides ? Non, et Sharkly ne prétend pas le contraire. Les agents tournent à la même vitesse. Ce qui change, c'est votre surcharge : le routage, l'isolation et la revue cessent d'habiter dans votre tête et commencent à revenir dans une Task où le travail est visible et relisible.
Et conserver le contexte d'une session à l'autre ? Les terminaux privés le perdent dès que vous les fermez. Lier une exécution à une Task garde ensemble l'objectif, le diff et la discussion : c'est le problème de la conservation du contexte entre les sessions résolu au niveau de l'enregistrement plutôt que de la mémoire.
Puis-je quand même utiliser Claude Code et Codex ensemble de cette façon ? Oui. Sharkly gère le travail autour des outils ; il ne les remplace pas. Voir comment faire tourner Claude Code et Codex ensemble pour le schéma.
