TL;DR : Le routage consiste à décider quel agent de codage prend en charge une tâche donnée. Routez en fonction des propriétés de la tâche, pas du classement de la semaine dernière : ce qu'elle modifie, sa réversibilité, si elle touche des fichiers qu'un autre agent est en train de modifier, combien de temps elle tourne sans surveillance, et quel abonnement la couvre. Faites correspondre ces éléments à l'agent dont le comportement sur votre base de code convient. Cela fonctionne de tête avec un ou deux agents. Au-delà de trois, la décision de routage a besoin d'un endroit partagé où exister. Ce guide vous donne les règles et une checklist.
Vous avez Claude Code dans un terminal, Codex dans un autre, peut-être Gemini CLI dans un troisième. Une tâche arrive : corriger un test instable, ajouter un endpoint, refactoriser un module importé par trois autres fichiers. Quel agent s'en charge ? La plupart d'entre nous répondent par habitude, ou selon la fenêtre déjà au premier plan. Ça marche jusqu'au moment où vous ne vous souvenez plus à quel agent vous avez confié la migration, ou que deux d'entre eux modifient le même fichier.
Choisir le « meilleur » agent est une décision ponctuelle qui vieillit dès qu'un nouveau modèle sort. Décider quel agent prend cette tâche est une décision que vous prenez des dizaines de fois par semaine, et elle dépend bien plus de la tâche que du classement. Dès que vous avez plus d'un agent, le routage est là où passe votre temps.
Sharkly est construit autour de cette décision. Sharkly est une plateforme tout-en-un de commande et de gestion d'agents : vous connectez votre propre Computer, vous définissez un Agent une fois comme un rôle lié à un runtime, et vous lui assignez une Task. Elle se situe au-dessus des agents de codage que vous utilisez déjà, pas à côté. Cet article explique comment bien router une tâche, d'abord sous forme de règles que vous appliquez à la main, puis jusqu'au point où la décision de routage a besoin d'un endroit partagé où exister.
Le routage est une décision, pas une préférence
Commençons par une définition claire. Le routage consiste à faire correspondre une tâche à l'agent qui doit l'exécuter. Ce n'est pas la même chose que choisir votre agent préféré, ni que choisir un modèle. Quel modèle pour quelle tâche de codage est une question distincte et plus étroite qui se situe un niveau en dessous ; ici, nous décidons quel agent (Claude Code, Codex, Gemini CLI, OpenCode, et les autres) reçoit le travail.
Une tâche porte des propriétés qui déterminent sa route avant même que la capacité n'entre en jeu :
- Ce qu'elle modifie. Une correction dans un seul fichier, une refactorisation transversale, une fonctionnalité greenfield, des tests, de la documentation. Chacune a un rayon d'impact différent.
- Sa réversibilité. Une faute de frappe corrigée et une migration de base de données produisent toutes deux un diff. Une seule vous gâche l'après-midi si l'agent se trompe.
- Le chevauchement de fichiers. Touche-t-elle des fichiers qu'un autre agent est en train de modifier en ce moment ?
- L'horizon d'autonomie. Une modification interactive rapide, ou une longue exécution sans surveillance qui doit planifier, exécuter et s'auto-vérifier.
- Le plafond de coût. Quel abonnement ou budget d'API doit l'absorber.
Lisez une tâche à travers ces cinq propriétés et la route se choisit généralement d'elle-même. L'erreur consiste à sauter directement à « quel agent est le meilleur », une question sans réponse fixe qui change à chaque sortie de modèle.
Routez selon la forme de la tâche, avant de router selon la capacité
Les agents de codage diffèrent réellement. L'un planifie peut-être bien les tâches longues à plusieurs étapes ; un autre est peut-être plus précis sur les modifications chirurgicales ou plus rapide sur les boucles courtes. Mais la version honnête est celle-ci : ils diffèrent sur votre base de code, et le seul moyen de le savoir est de les regarder travailler dessus. Les benchmarks mesurent un ensemble de problèmes fixe à un moment fixe, ce qui n'est ni votre dépôt ni le mois prochain. Comparez les agents sur votre propre base de code avant de faire confiance à un classement.
Routez donc d'abord selon la forme. Une paire de décisions pour vous ancrer : utilisez un agent rapide et interactif quand la tâche est petite, bien délimitée, et que vous allez la surveiller ; tournez-vous vers l'agent le plus autonome quand la tâche est assez vaste pour que vous préfériez la décrire une fois et relire le résultat plutôt que de surveiller chaque étape.
| Forme de la tâche | Router vers | Pourquoi |
|---|---|---|
| Petite, bien délimitée, vous surveillez | Votre agent interactif le plus rapide | Peu de surcharge, boucle serrée |
| Vaste, à plusieurs étapes, décrire une fois | Votre agent autonome le plus fiable | Il planifie et s'auto-vérifie sans surveillance |
| Touche des fichiers qu'un autre agent a ouverts | N'importe quel agent, dans un worktree isolé | Évite la collision de merge |
| À risque élevé ou irréversible | L'agent dont vous relisez le résultat de près, permissions strictes | C'est le rayon d'impact qui domine, pas la vitesse |
| Bon marché et répétitive | Celui que votre budget préfère | Le plafond de coût décide |
Rien de tout cela ne désigne un gagnant, parce qu'il n'y en a pas. Il y a une adéquation entre une tâche et le comportement observé d'un agent, et c'est cette adéquation qui guide votre routage.
Les contraintes qui décident du routage avant la capacité
Deux contraintes priment sur la capacité à chaque fois, et toutes deux relèvent de la coordination, pas de la compétence.
La première est le chevauchement de fichiers. Cinq agents modifiant un même dépôt, ça semble efficace jusqu'à ce que deux d'entre eux touchent les mêmes fichiers et que vous deviez résoudre un conflit de merge que vous avez créé exprès. La solution est l'isolation : donnez à chaque tâche son propre checkout pour que les agents ne puissent pas se percuter. Les worktrees d'agents de codage, un checkout par tâche détaille le mécanisme, et faire tourner plusieurs agents dans un même dépôt décrit ce qui casse sans cela. Quand deux tâches toucheraient les mêmes fichiers, la route n'est pas « le meilleur agent », c'est « n'importe quel agent, dans un worktree séparé ».
La seconde est le risque. Une tâche qui migre des données, modifie l'authentification ou réécrit un chemin critique devrait être routée là où votre relecture est la plus stricte et les permissions de l'agent les plus restreintes, quel que soit l'agent techniquement le plus fort. Les agents font des recherches, exécutent, testent et rendent compte. Les humains donnent la direction, accordent l'autorité et acceptent le résultat. Router une tâche risquée vers l'agent le plus rapide revient à optimiser la mauvaise variable.
Là où le routage mental cesse de passer à l'échelle
Avec un agent, il n'y a pas de problème de routage. Avec deux, vous gardez le tableau en tête et tout va bien. Les ennuis commencent autour de trois agents et de plusieurs tâches ouvertes : la décision de routage n'a nulle part où exister en dehors de votre mémoire à court terme.
Vous ne vous souvenez plus quel agent a reçu la migration. Une exécution terminée défile hors du haut du terminal avant que vous ne l'ayez lue. Vous reprenez la même décision de routage trois fois parce qu'aucun enregistrement ne prouve que vous l'avez prise une fois. Deux agents modifient le même fichier parce que rien n'a prévenu l'un que l'autre était là. Rien de tout cela n'est un échec d'agent. C'est le coût de garder une table de routage dans votre tête alors que les terminaux se multiplient. Trop de terminaux, c'est un coût bien réel, et le routage est le premier endroit où cela se voit.
C'est là qu'un tableau de tâches mérite sa place, parce qu'il sort la décision de routage de votre tête pour la déposer dans un enregistrement partagé. Sharkly s'appuie sur trois notions. Une Task est l'unité de travail partagée. Un Agent est un rôle lié à un runtime, défini une fois pour que la décision de routage devienne réutilisable au lieu d'être refaite dans chaque terminal. Vous assignez une Task à un Agent, et l'exécution, les blocages et les résultats reviennent à cette Task au lieu de défiler hors de vue. Vous voyez quel agent fait quoi sans changer de fenêtre, et le diff et la sortie des tests vous attendent au même endroit pour relecture. Assigner, suivre et relire le travail des agents, voilà ce qui remplace le jeu de mémoire.
Vous n'avez besoin de rien de tout cela pour bien faire tourner un seul agent. Vous pouvez aussi faire tourner Claude Code et Codex ensemble sur une même base de code à la main, et pour deux agents c'est raisonnable. L'équation change quand les décisions de routage dépassent ce que vous pouvez garder en tête : plusieurs agents, plusieurs tâches, plusieurs dépôts, une équipe qui a besoin de voir le même tableau.
Une checklist de routage à appliquer dès aujourd'hui
Avant de confier une tâche à un agent, passez-la au crible de ces points :
- Nommez la forme de la tâche. Correction dans un fichier, refactorisation, greenfield, tests ou documentation ? Cela fixe le rayon d'impact.
- Vérifiez la réversibilité. Difficile à annuler ? Routez vers votre relecture la plus stricte et vos permissions les plus restreintes, pas vers votre agent le plus rapide.
- Vérifiez le chevauchement de fichiers. Un autre agent est-il déjà dans ces fichiers ? Si oui, isolez d'abord cette tâche dans son propre worktree.
- Faites correspondre l'horizon d'autonomie. Courte et surveillée, ou longue et sans surveillance ? Routez vers l'agent dont le comportement convient sur votre dépôt.
- Fixez le plafond de coût. Décidez quel abonnement ou budget absorbe l'exécution.
- Enregistrez la route quelque part de partagé. Au-delà de deux agents, notez-la là où vous et votre équipe pouvez la voir : une Task, pas un terminal que vous allez fermer.
- Renvoyez les résultats au même endroit. Le diff, la sortie des tests et la relecture doivent revenir à l'enregistrement de la tâche, pas se disperser entre les fenêtres.
Routez selon la tâche, pas selon le classement. Le meilleur agent pour une tâche est celui dont la forme correspond au travail qui vous attend, et la décision de routage ne reste peu coûteuse que si elle vit quelque part où vous pouvez la voir.
Si vous faites déjà tourner plusieurs agents de codage, Sharkly vous offre un seul endroit pour router leurs tâches et lire leurs résultats. Vous pouvez télécharger Sharkly et connecter les agents que vous utilisez.
FAQ
Le routage, est-ce la même chose que choisir le meilleur agent de codage ? Non. Choisir le meilleur agent est un jugement ponctuel qui vieillit vite. Le routage consiste à décider quel agent prend en charge chaque tâche, en fonction de sa forme, de son risque, du chevauchement de fichiers et de l'horizon d'autonomie. Vous routez des dizaines de fois pour chaque fois que vous choisissez.
En quoi est-ce différent du choix d'un modèle ? Le choix d'un modèle se fait un niveau en dessous, à l'intérieur de l'agent. Le routage décide quel agent reçoit la tâche ; la question du modèle décide de ce qui tourne dans la session de cet agent. Voir quel modèle pour quelle tâche de codage pour la décision plus étroite.
Quand ai-je vraiment besoin d'un outil pour ça ? Quand les décisions de routage dépassent ce que vous pouvez suivre de tête, généralement autour de trois agents et de plusieurs tâches ouvertes, ou quand une équipe a besoin de voir les mêmes décisions. Pour un ou deux agents, un tableau mental et des terminaux séparés suffisent.
Sharkly remplace-t-il Claude Code ou Codex ? Non. Sharkly n'est pas un remplacement de Claude Code, Codex ou d'autres outils d'exécution. Il ajoute la couche partagée de tâches, de Computer, de contexte et de relecture autour des agents de codage que votre équipe utilise déjà.
