Un agent de codage n’est disponible que dans la mesure où la machine qui l’exécute l’est. Lancez un long refactoring avec Claude Code ou Codex, refermez le capot pour attraper un train, et l’exécution meurt avec votre session SSH. Démarrez deux agents sur le même ordinateur portable et les ventilateurs s’emballent pendant que votre éditeur saccade. À un moment, la question cesse d’être « quel agent » pour devenir « où l’agent s’exécute-t-il réellement ».
La réponse est généralement l’une de ces trois options : le garder sur votre ordinateur portable, le déplacer vers un serveur distant, ou répartir le travail entre les deux. Chaque choix échange de la commodité contre de la fiabilité. Un ordinateur portable est juste là, mais il se met en veille, bride ses performances et se déconnecte. Un serveur reste éveillé et dispose de plus de cœurs, mais il ajoute de la configuration et une couche de « qu’est-ce qu’il fabrique là, au juste ». Répartir la différence vous donne le meilleur des deux et la charge de suivi des deux.
Cet article détaille de bout en bout la configuration d’un agent distant : la voie à faire soi-même avec de vraies commandes, le mode de défaillance qui attend à chaque étape, et l’endroit où un Computer connecté dans Sharkly supprime la partie qui n’arrête pas de casser. Vous avez déjà des agents de codage. Le problème, c’est de les exécuter quelque part de durable et de savoir ce qui s’est passé quand vous détournez le regard.
Pourquoi déplacer un agent hors de votre ordinateur portable
L’ordinateur portable est l’hôte par défaut parce que c’est là que vous tapez. C’est aussi le pire hôte pour tout ce qui dure plus longtemps que votre capacité d’attention. macOS se met en veille à la fermeture du capot. Le mode batterie bride le CPU. Les VPN d’entreprise tombent. Chacun de ces événements tue un agent en pleine tâche, et l’agent n’a aucune idée qu’il a été interrompu ; vous le découvrez en rouvrant le terminal sur une invite morte et sans résumé.
Un hôte distant corrige la physique. Une VM cloud ou une machine Linux de rechange reste allumée, conserve son réseau et a des cœurs en réserve pour le travail parallèle. Le coût, c’est que l’agent s’exécute désormais quelque part que vous ne voyez pas. Vous vous connectez en SSH pour vérifier, vous faites défiler un journal pour deviner où il en est, et les résultats restent sur cette machine jusqu’à ce que vous les copiiez ailleurs.
Exécuter les deux est l’état final honnête pour la plupart des gens. Vous gardez les modifications rapides et interactives sur l’ordinateur portable, où le retour est instantané, et vous poussez les tâches longues ou parallèles vers le serveur, où elles peuvent tourner une heure sans surveillance. L’astuce consiste à faire en sorte qu’un hôte ou cinq donnent l’impression d’un seul endroit, plutôt que d’un tableur d’adresses IP.
La configuration distante à faire soi-même, et où chaque étape échoue
La méthode manuelle est bien connue. En voici la version courte, avec le mode de défaillance qui apparaît à chaque étape.
Provisionnez l’hôte et installez votre agent dessus :
ssh you@build-server
# install the agent's CLI, e.g. Claude Code or Codex
# authenticate it with your own subscription or API key
git clone [email protected]:your-org/your-repo.git
cd your-repo
claude
Mode de défaillance : l’agent s’authentifie avec votre compte sur une machine que d’autres personnes peuvent toucher, et les identifiants restent dans l’historique et la configuration de ce shell. Aucun registre n’indique quel hôte détient quelles clés.
Maintenez l’exécution en vie au-delà de votre session SSH :
tmux new -s agent
claude # start the long task
# Ctrl-b d to detach, close the laptop, reconnect later
tmux attach -t agent
Mode de défaillance : tmux survit à une connexion SSH interrompue, mais pas à un redémarrage du serveur, à un kill OOM, ni au fait que vous oubliez laquelle de six sessions, sur lequel de trois serveurs, contient l’exécution qui vous intéresse. Se détacher n’équivaut pas à être durable.
Récupérez les résultats et voyez ce qui s’est passé :
scp you@build-server:~/your-repo/CHANGES.md .
ssh you@build-server 'cd your-repo && git diff'
Mode de défaillance : le diff est sur la machine ; le raisonnement est dans un tampon de défilement déjà tronqué ; le « pourquoi » a disparu. Multipliez cela par deux agents sur deux hôtes et vous reconstruisez l’état à la main chaque fois que vous vérifiez.
Aucune de ces étapes n’est difficile. Le problème, c’est qu’elles ne se composent pas. Chaque nouvel hôte et chaque nouvel agent est une cible SSH de plus, une session tmux de plus, un endroit de plus où vit un secret, et un journal de plus à lire pour répondre à « est-ce terminé ».
Ce qu’un Computer connecté change
Sharkly nomme la chose que vous improvisiez. Un Computer est un appareil, un serveur ou un conteneur connecté où un Agent peut exécuter du travail ; il fournit le système d’exploitation, les fichiers, les identifiants, l’accès réseau et les outils dont l’Agent a besoin. Cette définition couvre vos trois options : « Il peut s’agir d’un ordinateur local, d’un serveur distant, d’un conteneur ou d’un hôte cloud pris en charge. »
Vous enregistrez un hôte une fois au lieu de vous y connecter en SSH à chaque fois. Générez un jeton d’installation à usage unique depuis Réglages > Computers sur la machine cible, puis exécutez :
sharkly computer register --install-token <install-token>
Le jeton est de courte durée et à usage unique, il n’a donc rien à faire dans une image ou un script. Ensuite, un service local en arrière-plan s’exécute sur le Computer. Il enregistre l’hôte, détecte quels outils d’agent sont installés et les déclare chacun comme un Runtime, envoie des heartbeats, reçoit les exécutions en file d’attente, prépare les répertoires et renvoie la progression et les résultats.
Deux limites méritent d’être énoncées clairement, car c’est là que les gens supposent à tort. Premièrement, le service local initie la connexion au serveur, donc une configuration typique ne nécessite pas de port entrant ; vous n’ouvrez pas votre machine de build à Internet. Deuxièmement, un Computer affiché comme Online signifie seulement que son service local envoie des heartbeats. Cela ne signifie pas que le Runtime peut exécuter une Task. Si une exécution ne démarre pas sur un hôte en ligne, vérifiez l’état de capacité du Runtime avant de toucher au réseau.
À partir de là, les modes de défaillance précédents ont des adresses. Les identifiants sont ceux de l’hôte, limités à lui. Une exécution survit à votre terminal parce que c’est le service local qui la possède, pas une session tmux. Et le diff, le résumé et le raisonnement reviennent dans la Task au lieu de vivre dans un tampon de défilement sur une machine où vous devez vous connecter en SSH.
Ordinateur portable, serveur ou les deux : comment choisir vraiment
Plus d’hôtes n’est pas automatiquement mieux, alors choisissez en fonction du travail.
Utilisez votre ordinateur portable lorsque la tâche est courte, interactive et que vous voulez la suivre. Enregistrez-le comme Computer personnel et, dans Sharkly Desktop, activez Prevent sleep pour qu’un travail rapide ne soit pas interrompu par la veille du système. À noter que Prevent sleep n’apparaît que sur la machine locale dans l’application de bureau ; il n’est pas disponible sur un Computer partagé ou distant. Si tout ce que vous exécutez se termine en moins d’une pause café et n’a jamais besoin de survivre à un capot fermé, vous n’avez pas encore besoin d’un serveur, et en ajouter un ne représente que de la maintenance que vous finirez par détester.
Utilisez un serveur distant lorsque les tâches durent longtemps, nécessitent plus de cœurs ou ne doivent pas se battre avec votre éditeur pour les ressources. Un hôte Linux ou une VM cloud enregistré reste éveillé par défaut et donne aux agents parallèles la place de travailler. C’est aussi là que la limite de concurrence des tâches par hôte d’un Computer et la visibilité Organization ou Space gagnent leur place : la machine et ses identifiants sont faits pour être partagés, et Sharkly les traite comme tels.
Utilisez les deux lorsque vous voulez les modifications interactives en local et les exécutions lourdes à distance sans conserver deux modèles mentaux. Enregistrez l’ordinateur portable et le serveur, puis affectez chaque Task au Computer et au Runtime qui convient. L’isolation par worktree qui évite aux agents parallèles d’entrer en collision fonctionne de la même manière, que les agents partagent un seul hôte ou s’étendent sur plusieurs, donc « les deux » vous coûte une sélection, pas un second workflow.
Là où le DIY cesse de passer à l’échelle, et ce qu’apporte un tableau de tâches
La configuration SSH et tmux tient pour un agent sur un hôte. Elle s’arrête dès que vous avez plusieurs agents sur plusieurs machines, car il n’existe aucune réponse partagée à « quel agent est sur quoi, qu’est-ce qui a terminé, qu’est-ce qui a échoué, et qu’est-ce qui nécessite ma relecture ». Cette question est toute la raison de faire tourner plus d’un agent à la fois, et c’est exactement ce qu’un tas de terminaux ne peut pas répondre.
Un tableau de tâches fait passer l’unité de « une session sur un hôte » à « une Task avec un enregistrement ». Les agents recherchent, exécutent, testent et rendent compte ; les humains donnent la direction, accordent l’autorité et acceptent le résultat. L’exécution, les blocages, les résultats et les discussions de suivi reviennent dans la chronologie de la Task, donc vérifier une exécution distante consiste à ouvrir une Task, pas à se connecter en SSH à une supposition. L’automatisation s’arrête là où le jugement de l’équipe est requis : l’agent vous remet une modification avec son résumé et ses preuves, et la décision de fusion et de publication reste la vôtre.
C’est la ligne de démarcation entre les deux approches. Le DIY exécute l’agent à distance. Un tableau de tâches garde le contexte, la progression, les blocages, les résultats et la relecture humaine visibles, de la demande à la publication, quel que soit l’hôte qui a fait le travail.
La liste de contrôle à appliquer dès aujourd’hui
Parcourez cette liste sur les hôtes que vous comptez utiliser :
- [ ] Choisissez vos hôtes honnêtement : ordinateur portable pour l’interactif, serveur pour le long ou le parallèle, les deux si vous en avez vraiment besoin.
- [ ] Installez un Runtime d’agent pris en charge sur chaque hôte et authentifiez-le avec votre propre abonnement ou clé API.
- [ ] Enregistrez chaque hôte une fois avec
sharkly computer register --install-token <token>au lieu de vous connecter en SSH à chaque exécution. - [ ] Vérifiez que chaque Computer affiche Online et possède au moins un Runtime signalé comme Available ; être en ligne ne suffit pas à exécuter une Task.
- [ ] Définissez la visibilité du Computer sur Personal pour votre ordinateur portable, Organization ou Space pour un serveur partagé.
- [ ] Sur l’ordinateur portable, activez Prevent sleep pour les exécutions qui doivent survivre à un capot fermé.
- [ ] Affectez une Task petite et ennuyeuse à un hôte distant et vérifiez que le résultat revient dans la Task, pas dans un tampon de défilement.
- [ ] Utilisez
sharkly computer listetsharkly daemon disk-usagepour suivre vos hôtes et récupérer de l’espace.
Vous pouvez construire la configuration distante à la main avec SSH, tmux et des worktrees, ou enregistrer vos hôtes existants en tant que Computers et laisser le service local prendre en charge les exécutions. Si vous faites déjà tourner plusieurs agents de codage sur plus d’une machine, Sharkly vous offre un seul endroit pour gérer leurs tâches et leurs résultats. Connectez un Computer, créez un Agent, et confiez-lui d’abord quelque chose d’ennuyeux.
