Vous ouvrez un terminal pour Claude Code, un autre pour Codex, et peut-être un troisième pour Gemini CLI. Chacun d'eux produit du bon code. Pourtant, aucun n'est capable de vous dire quel agent travaille sur quelle tâche, ce qui s'est terminé pendant votre réunion, ce qui a échoué en silence, ou ce qui attend désormais une relecture humaine sur une branche. C'est précisément dans cet intervalle que s'inscrit la gestion des agents de code, et c'est tout l'enjeu abordé dans cet article.
Ce décalage se fait très vite sentir. Lancer un premier agent dans un second terminal ressemble à un gain net. Mais au cinquième, on passe son temps à basculer d'une fenêtre à l'autre pour se rappeler qui fait quoi, à nettoyer des worktrees à la main et à relire des diffs déjà vérifiés. Les outils d'exécution excellent dans l'exécution. En revanche, ils n'ont jamais été conçus pour se coordonner entre eux.
Sharkly a été conçu pour assurer cette couche de coordination, et constitue le cas pratique détaillé dans cet article. Sharkly n'écrit pas de code et ne remplace pas les agents que vous utilisez déjà. Il se positionne au-dessus d'eux : vous conservez Claude Code et Codex, et Sharkly prend en charge les tâches, le contexte, l'avancement, les blocages, les résultats et la revue humaine qui les encadrent. La suite de cet article explique ce que recouvre la notion de « gestion » à ce niveau d'abstraction et comment savoir si vous en avez déjà l'utilité.
Ce que signifie la gestion des agents de code
La gestion des agents de code consiste à attribuer, suivre, isoler et passer en revue le travail de plusieurs agents IA depuis un espace centralisé, plutôt que d'ouvrir un terminal par agent. Il s'agit d'une couche d'orchestration, et non d'un outil venant concurrencer les agents situés en dessous.
Il est plus simple d'analyser cette pile de haut en bas :
Models Claude / GPT / Gemini (reason and generate)
Coding agents Claude Code / Codex / Gemini CLI (execute tasks)
Management layer Sharkly (assign, track, isolate, review)
Team you and other developers (set direction, accept results)
Chaque niveau remplit un rôle précis. Le modèle raisonne. L'agent de code traduit une requête en fichiers modifiés, commandes exécutées et diffs. La couche de gestion détermine quel agent prend en charge quelle tâche, évite les conflits entre leurs modifications et conserve l'historique sur lequel se base la revue. Vous donnez la direction et validez le résultat. Quand on qualifie les agents de véritables coéquipiers plutôt que de simple autocomplétion, c'est précisément cet organigramme que l'on vise — et la couche de gestion est la pièce qui manquait jusqu'ici à la plupart des environnements.
Cette séparation des couches est fondamentale. Un agent de code n'a aucune conscience de l'existence des autres agents. Claude Code ne sait absolument pas que Codex est en train de modifier le même fichier deux dossiers plus loin. Gérer ces interactions n'est pas le rôle de l'agent, et demander à un agent de superviser les autres ne fait que déplacer le chaos.
Le problème que les outils sous-jacents ne résolvent pas
Faites l'inventaire en toute franchise d'un après-midi chargé avec trois ou quatre agents en activité : quel agent s'occupe de quoi, lequel doit recevoir la prochaine tâche, qu'est-ce qui est terminé, qu'est-ce qui a échoué, et qu'est-ce qui nécessite une validation humaine avant fusion ? Ajoutez-y la logistique sous-jacente : terminaux multiples, worktrees multiples, branches multiples, dépôts multiples et abonnements multiples facturés en arrière-plan.
Rien de tout cela n'est un défaut de Claude Code ou de Codex. C'est simplement le prix à payer lorsqu'on fait tourner simultanément plusieurs exécutants performants sans aucune supervision. Le travail est bien réel, il s'exécute en parallèle, mais reste invisible. On ne s'aperçoit qu'un agent a fait fausse route que lorsqu'on bascule enfin sur sa fenêtre, bien après que l'erreur s'est produite.
Voici l'ennemi qu'il faut nommer : non pas un outil concurrent, mais le chaos des agents. Dès l'instant où votre espace de travail commence à ressembler à un mur de terminaux que vous n'osez plus fermer, c'est que l'utilisation isolée d'agents ne suffit plus. La plupart des développeurs s'y heurtent en voulant faire tourner plusieurs agents Claude Code ou utiliser Claude Code et Codex ensemble sur une même base de code — et le casse-tête de la gestion apparaît bien avant le gain de productivité.
Le rôle de la couche de gestion
Si l'on résume cette couche à l'essentiel, elle remplit quatre missions : attribution, isolation, visibilité et revue. C'est la maîtrise de ces quatre piliers qui définit concrètement l'orchestration d'agents IA.
Attribution. Le travail prend la forme d'une Task, et c'est cette Task que l'on confie à un agent, plutôt qu'un prompt collé dans le terminal actif. Une Task porte son propre objectif, son contexte et ses critères d'acceptation, permettant à l'agent de démarrer à partir de l'état réel du projet plutôt que d'un fil de discussion vierge.
Isolation. Deux agents travaillant sur le même dépôt ne posent pas de problème, jusqu'à ce qu'ils touchent aux mêmes fichiers. La solution consiste à dédier un worktree par Task, afin que chaque agent dispose de son propre checkout et que leurs modifications n'entrent jamais en collision en cours d'exécution. Vous pouvez mettre cela en place vous-même avec Git ; le rôle de la couche de gestion est de créer, suivre et nettoyer ces worktrees isolés pour vous éviter de le faire manuellement.
Visibilité. L'exécution, les points de blocage, les résultats et les échanges qui en découlent remontent dans la timeline de la Task, au lieu de défiler dans un terminal fermé depuis longtemps. Un point central répond à la question « que fait chaque agent en ce moment même », ce qui correspond exactement à ce qu'un tableau de bord pour agents devrait vous montrer.
Revue. Les agents explorent, exécutent, testent et rendent compte. Les humains fixent le cap, accordent les autorisations et valident le résultat. La limite la plus importante imposée par la couche de gestion est que l'automatisation s'arrête là où le jugement de l'équipe est requis : un agent peut préparer une modification, exécuter les tests et joindre les éléments de preuve, mais c'est un humain qui tranche sur la fusion. Ce point de contrôle human-in-the-loop est un atout, pas un frein.
Voici le dilemme en toute franchise. Si vous n'utilisez qu'un seul agent de code, travaillez dans un seul terminal et terminez une tâche avant de passer à la suivante, vous n'avez pas besoin de couche de gestion, et en ajouter une ne ferait que vous imposer une charge mentale superflue. L'équation change dès l'instant où vous lancez deux agents ou plus sur plusieurs tâches, worktrees ou dépôts, ou dès qu'une seconde personne a besoin de voir ce que les agents ont produit. C'est là que cette couche commence à être rentable.
Gérer ses agents de code avec Sharkly
Sharkly sert ici d'exemple de couche de gestion ; voici concrètement comment cela fonctionne.
Vous connectez un Computer, c'est-à-dire n'importe quelle machine (votre ordinateur portable, un serveur, ou les deux) sur laquelle une session d'agent peut s'exécuter. Vous configurez un Agent, qui correspond à un profil réutilisable définissant la manière dont le travail doit être traité, et non à un nouveau modèle. Vous conservez vos propres abonnements : la consommation de modèles passe toujours par les comptes Claude Code, Codex ou Gemini que vous payez déjà. Sharkly coordonne, sans revendre de temps de calcul ou d'inférence.
Vous assignez ensuite une Task. Prenons l'exemple de la tâche SH-312 : « corriger le test instable du tunnel d'achat et ajouter de la couverture ». Vous la confiez à un Agent adossé à Claude Code, ou vous répartissez un objectif plus vaste au sein d'une Crew, où un Agent coordinateur analyse le périmètre et regroupe les résultats des autres Agents dans une seule Task. La Task s'exécute dans son propre worktree sur un Computer connecté. Pendant son exécution, sa progression, les points de blocage et le diff remontent dans la timeline de la Task. Une fois le travail terminé, l'Agent y associe le résumé des modifications, les résultats des tests ainsi que les limites connues, et la Task passe en attente de revue. Vous la parcourez, demandez des ajustements ou validez la fusion.
Rien dans ce fonctionnement ne vous oblige à abandonner Claude Code ou Codex. Vous centralisez simplement les agents que vous utilisez déjà dans un espace partagé, afin que le travail devienne attribuable et traçable au lieu d'être dispersé dans des terminaux isolés. Si vous souhaitez avoir un panorama complet des options existantes, nous avons comparé les outils de gestion d'agents de code en parallèle plutôt que de prétendre qu'un seul flux de travail convient à tout le monde.
Pourquoi la couche de gestion compte plus que l'agent qui l'emporte
Voici une prédiction, assumée comme telle : le « meilleur agent de code » ne cessera de changer, et fonder toute son organisation sur le gagnant du moment est un pari risqué. Claude Code, Codex, Gemini et les futurs arrivants se disputeront la première place tâche après tâche et trimestre après trimestre. Construire l'intégralité de son flux de travail autour de l'un d'eux implique de tout reconstruire à chaque bascule du classement.
La couche de gestion est précisément l'élément qui résiste à ce roulement continuel. Si vos tâches, votre contexte, votre isolation et vos revues se situent au-dessus des agents, vous pouvez remplacer l'agent qui exécute une Task donnée sans toucher à la façon dont votre équipe attribue et évalue le travail. La neutralité vis-à-vis des fournisseurs n'est pas une simple case à cocher : c'est une assurance face à un marché redistribué tous les trimestres.
Rien de tout cela ne prétend que Sharkly écrit du meilleur code que les agents qu'il pilote. Ce n'est pas le cas. Les agents exécutent ; la couche coordonne. Le pari à faire aujourd'hui ne porte pas sur un agent en particulier, mais sur le flux de travail qui les englobe tous : identifiez les tâches que vous lanceriez de toute façon en parallèle, et installez une véritable couche de gestion au-dessus avant d'être submergé par le nombre de terminaux ouverts.
Si vous utilisez déjà plusieurs agents de code, Sharkly met à votre disposition un point d'accès unique pour leur assigner des tâches, isoler leur travail et examiner leurs résultats. Vous pouvez reproduire une grande partie de ce système par vous-même à grands renforts de worktrees et de rigueur, ou bien orchestrer vos agents de code actuels via Sharkly et laisser cette couche se charger de la coordination.
