Toute conversation sur les agents de codage IA finit par buter sur la même question pratique, généralement plus tard qu’il ne faudrait : où le code s’exécute-t-il réellement ? Pas quel modèle, mais quelle machine héberge votre dépôt, vos identifiants, vos caches et le shell dans lequel l’agent tape ses commandes.
Sharkly fait de cette réponse un concept à part entière, baptisé Computer. Un Computer fournit l’hôte d’exécution du travail des Agents. Il peut s’agir d’un ordinateur local, d’un serveur distant, d’un conteneur ou d’un hôte cloud pris en charge. Votre portable en fait partie. Tout comme la machine Linux dans votre rack. Vous choisissez l’hôte, vous le contrôlez, et Sharkly y coordonne le travail au lieu d’exécuter votre code dans un endroit que vous ne pouvez pas voir.
Sharkly ne remplace pas Claude Code, Codex ou d’autres outils d’exécution. Il ajoute une couche partagée de tâches, de Computers, de contexte, de contrôle et de revue autour des outils que votre équipe utilise déjà. Ces outils restent installés sur vos machines, et l’usage des modèles continue de passer par les abonnements ou les clés API configurés dans ces outils.
TL;DR
Un Computer est l’hôte d’exécution du travail des Agents dans Sharkly : un ordinateur local, un serveur distant, un conteneur ou un hôte cloud pris en charge que vous contrôlez. Un petit service local relie le Computer à Sharkly, détecte les Runtimes disponibles (les outils d’agent concrets qui y sont installés, comme Claude Code ou Codex), reçoit les exécutions mises en file d’attente, prépare le répertoire de la tâche, démarre le Runtime sélectionné et renvoie la progression en flux continu vers la Task. Connectez une machine personnelle avec Sharkly Desktop, ou un hôte distant avec la CLI Sharkly et un token d’installation à usage unique. L’usage des modèles passe par les abonnements et les clés API déjà configurés dans vos outils ; les limites de concurrence déterminent la quantité de travail parallèle qu’un hôte peut absorber.
Ce qu’est un Computer, et ce qu’il n’est pas
Sharkly répartit l’exécution en quatre rôles, chacun ayant une seule mission :
- L’Agent définit la manière dont le travail doit être traité : instructions, Skills, dépôts, paramètres d’exécution.
- Le Computer fournit l’hôte et les ressources locales : système d’exploitation, fichiers, identifiants, réseau, outils.
- Le Runtime assure la session d’agent proprement dite : l’outil de codage détecté sur ce Computer.
- La Task reste l’enregistrement partagé : objectif, discussion, état d’exécution, trace, résultat.
Cette séparation explique la majeure partie de ce qui suit. Un Agent n’est pas l’hôte d’exécution ; une même configuration d’Agent peut pointer vers différents Computers au fil du temps. Un Computer n’est pas un agent ; il héberge un ou plusieurs Runtimes et ne fait rien tant qu’aucun travail ne lui est envoyé. Et un seul Computer peut servir plusieurs Agents à la fois, dans la limite de sa concurrence.
Cela explique aussi le positionnement. Les plateformes hébergées regroupent le modèle, l’exécuteur et l’infrastructure en un seul produit : votre code s’exécute donc sur une infrastructure que vous n’exploitez pas. Sharkly défend la position inverse : l’hôte d’exécution vous appartient, et ce qu’il apporte par-dessus, c’est l’attribution, la mise en file d’attente et la revue. Si ce modèle ne vous est pas familier, ce qu’est Sharkly en donne une vue complète.
Le service local : la pièce qui fait le vrai travail
Un petit service local relie chaque Computer à Sharkly. Il enregistre le Computer, détecte les Runtimes installés, envoie des heartbeats, reçoit les exécutions en file d’attente, prépare les répertoires de tâche, démarre l’outil d’agent sélectionné et renvoie la progression ainsi que les résultats.
Un détail de conception pèse lourd sur le plan opérationnel : c’est le service local qui initie la connexion au serveur, si bien qu’une configuration classique ne nécessite aucun port entrant. C’est ce qui permet à un portable derrière une box domestique, à un poste de travail derrière un pare-feu d’entreprise et à un serveur dans un sous-réseau privé d’être des Computers tout aussi viables.
Les heartbeats indiquent à Sharkly qu’un Computer est en vie : Online lorsque le serveur les reçoit, Offline lorsqu’ils s’arrêtent. La distinction qui fait gagner du temps en dépannage : online signifie seulement que les heartbeats arrivent. Cela ne veut pas dire que le Runtime sélectionné peut exécuter une Task.
Les Runtimes : ce que votre Computer peut réellement exécuter
Un Runtime est une capacité d’exécution d’agent prise en charge, détectée sur un Computer. Le service local recherche les outils d’agent pris en charge et signale chacun de ceux qui sont utilisables : un Computer où Claude Code et Codex sont installés expose donc les deux comme Runtimes sélectionnables par un Agent.
La page de détail du Computer indique un état de capacité pour chaque Runtime :
- Available : le Runtime est connecté et peut exécuter le travail des Agents.
- Needs configuration : l’outil est détecté mais la configuration requise est manquante.
- Not installed : l’outil n’est pas accessible au service local ; installez-le ou choisissez un autre Runtime.
- Unsupported : le Runtime ou l’environnement sort du périmètre des capacités prises en charge.
L’installation reste à votre charge, et c’est voulu. Vous installez et authentifiez chaque outil comme vous le feriez pour l’utiliser directement ; la page de détail du Computer renvoie au guide d’installation officiel, et une nouvelle analyse confirme que le service local le voit bien. Si une capacité dont vous dépendez n’est pas détectée, vous pouvez ajouter un Runtime ACP personnalisé avec un nom et une commande de démarrage, puis tester la connexion.
Deux conséquences en découlent. L’approche « apportez votre propre abonnement » est à prendre au sens littéral : le quota de modèle dépend des outils de codage IA, des forfaits et des comptes API que votre équipe connecte ; une erreur de quota renvoie donc au compte configuré dans l’outil, et non à un réglage Sharkly. Et la sélection du modèle reste du ressort de l’outil : un Agent suit le modèle par défaut de son Runtime. La configuration des Agents est détaillée dans Les Agents dans Sharkly.
Connecter votre premier Computer
Le premier Computer est généralement la machine sur laquelle vous êtes assis. Ouvrez Settings, allez dans Computers, choisissez Connect Computer et sélectionnez la procédure adaptée à votre système d’exploitation. Pour un ordinateur personnel pris en charge, la voie recommandée consiste à installer Sharkly Desktop, qui embarque le service local et vous guide tout au long de l’enregistrement. Le guide de démarrage couvre l’ensemble de bout en bout en une dizaine de minutes.
Une fois la connexion établie, vérifiez qu’au moins un Runtime est indiqué comme Available. C’est le point de contrôle que l’on oublie : un Computer connecté sans Runtime utilisable ne peut pas exécuter de travail d’Agent.
Deux réglages propres à l’application de bureau comptent pour les portables. Prevent sleep maintient la machine éveillée pour qu’une longue exécution ne soit pas interrompue, et Keep running with lid closed est une option macOS distincte. Les deux n’apparaissent que sur la machine locale, jamais sur un Computer distant.
Ajouter un serveur distant
Un portable fait un excellent premier Computer et un piètre Computer permanent. Il se met en veille, se déplace et vous dispute la mémoire avec votre IDE. La deuxième étape naturelle est un hôte distant qui reste allumé. Installez-y directement la CLI Sharkly et le service local :
curl -fsSL https://file-assets.sharkly.ai/download/install.sh | bash
sharkly version
Ensuite, depuis la page Computers, générez un token d’installation à usage unique et exécutez sur l’hôte cible la commande d’enregistrement qu’elle vous fournit :
sharkly computer register --install-token sit_...
L’enregistrement déclare le Computer dans votre organisation, démarre le service local et lance la détection des Runtimes. Le token d’installation expire au bout de 30 minutes et ne peut servir qu’une seule fois, d’où une règle d’hygiène que la documentation énonce sans détour : ne le placez jamais dans une image réutilisable, un script, une Task ou un commentaire.
Les identifiants sont volontairement séparés ici. Un personal access token n’enregistre pas de Computer, et un install token ne crée pas de connexion CLI humaine. Le personal access token shk_ vous authentifie pour les commandes portant sur les ressources, comme sharkly task list ; l’install token sit_ crée la session utilisée par le service local. Le reste de la surface de commandes fait l’objet du guide de la CLI et de l’API Sharkly.
Après l’enregistrement, la même CLI fait aussi office de trousse de diagnostic : sharkly computer status et sharkly computer logs lisent l’état local sur l’hôte, tandis que sharkly computer list, show, usage et ping inspectent les Computers enregistrés depuis n’importe où. L’hôte distant a besoin des mêmes éléments que votre portable : les outils d’agent installés et authentifiés, ainsi que l’accès Git pour les dépôts privés.
Local, distant ou conteneur : une comparaison honnête
Il n’existe pas d’hôte idéal unique. La documentation les traite tous comme des Computers, et les compromis sont ceux, classiques, de l’infrastructure.
| Hôte | Idéal pour | Atouts | Points de vigilance |
|---|---|---|---|
| Ordinateur local (Sharkly Desktop) | Première installation, travail en solo, exécutions en répertoire Specified qui réutilisent votre copie de travail et vos caches existants | Aucune infrastructure supplémentaire ; votre environnement et vos identifiants exacts ; les répertoires de travail Specified ne sont disponibles que sur les Computers locaux | La veille et l’arrêt interrompent la disponibilité ; les exécutions concurrencent votre propre travail pour le CPU et la mémoire |
| Serveur distant (CLI + service local) | Charges de travail d’équipe, capacité toujours disponible, concurrence plus élevée | Reste en ligne ; isole la charge des agents du portable de chacun ; un hôte peut servir plusieurs Agents | Vous installez et authentifiez vous-même les Runtimes et l’accès Git ; le dimensionnement de la capacité vous revient |
| Conteneur ou hôte cloud pris en charge | Environnements d’exécution reproductibles et jetables | Environnement propre et reconstructible ; même flux d’enregistrement via install token | Le token à usage unique doit être généré à chaque enregistrement, jamais intégré à une image réutilisable |
Le choix qui compte le plus : utilisez votre Computer local quand vous voulez que les Agents travaillent dans l’environnement auquel vous faites déjà confiance ; utilisez-en un distant quand les Tasks doivent continuer d’avancer portable fermé. Beaucoup d’équipes finissent par avoir les deux, car router le travail vers un autre hôte est un changement de configuration, pas de méthode de travail.
Ce qui se passe pendant une exécution
Lorsqu’une Task assignée à un Agent devient prête, Sharkly met une exécution en file d’attente et l’envoie au Computer sélectionné. Avant que le Runtime ne démarre, le service local peut attendre qu’une place de concurrence se libère, préparer un répertoire, récupérer les dépôts et projeter les variables d’environnement autorisées.
La préparation des répertoires suit l’un de deux modes. En mode Temporary, chaque Task dispose d’un répertoire isolé, et les exécutions adossées à un dépôt peuvent préparer un Git worktree neuf à partir des données de dépôt mises en cache ; utilisez-le pour la plupart des travaux sur dépôt et dès que plusieurs Tasks risquent de modifier la même base de code en parallèle, comme expliqué dans comment Sharkly exécute les Agents en parallèle sans conflits de fusion. En mode Specified, l’exécution réutilise un répertoire absolu configuré sur un Computer local, avec les dépendances et les caches qui s’y trouvent déjà, et un répertoire spécifié ne sert qu’à une exécution à la fois.
Pendant que le Runtime travaille, la progression est renvoyée en continu. L’état de l’exécution passe par Queued, Dispatched, Waiting for local directory, Running, puis Completed, Failed ou Canceled. Les événements de trace, les appels d’outils et la réponse finale reviennent tous à la Task. Le Computer est le lieu physique de l’exécution ; la Task, celui de la validation.
Concurrence : quelle charge un Computer doit-il porter ?
Chaque Computer a une limite de concurrence de tâches, et chaque Agent a son propre maximum de Tasks exécutées en parallèle. Les valeurs par défaut sont volontairement prudentes : un Agent qui utilise des répertoires temporaires se voit attribuer 50 % de la limite du Computer, et un Agent qui utilise des répertoires spécifiés, le nombre de répertoires configurés. Si vous forcez manuellement une valeur supérieure à ce nombre, le produit vous avertit que les écritures risquent d’entrer en collision. Croyez cet avertissement.
La recommandation de la documentation est la bonne : une concurrence plus élevée consomme plus de CPU, de mémoire, de disque, de capacité du fournisseur et de bande passante de dépôt ; ne l’augmentez qu’une fois que la configuration actuelle absorbe la charge existante de manière fiable. La capacité du fournisseur est le plafond que l’on oublie : dix exécutions parallèles sur un même compte de modèle atteignent ses limites de débit dix fois plus vite. Pour les schémas de montée en charge, voir exécuter plusieurs agents Claude Code en parallèle.
Un Agent en ligne peut avoir du travail en file d’attente simplement parce que la concurrence ou la capacité de répertoires est saturée. L’état Queued est un état normal, pas un blocage.
Partage, propriété et entretien de l’hôte
Dès qu’un Computer rend service à l’équipe, trois contrôles entrent en jeu. La visibilité détermine qui peut le voir et l’utiliser : Personal, Organization ou Space. La propriété est distincte : le propriétaire peut transférer le Computer et est la seule personne à pouvoir le supprimer. Et pour un Computer personnel local, le propriétaire contrôle les Organizations autorisées à l’utiliser, de sorte qu’adhérer à une nouvelle organisation ne met jamais votre portable à disposition à votre insu.
Les exécutions d’agents laissent derrière elles des répertoires de travail, des caches et des artefacts : le nettoyage est donc intégré. Il rend les exécutions terminées ou annulées éligibles au bout d’environ 7 jours par défaut, peut imposer un seuil minimal d’espace libre et ne touche jamais au travail en cours ou en file d’attente, aux exécutions épinglées, ni aux exécutions échouées encore en cours d’analyse. Pour un contrôle immédiat, sharkly daemon disk-usage indique l’utilisation et sharkly daemon cleanup montre ce qui serait récupéré.
Commencez avec la machine que vous avez
Le concept de Computer répond à une question que les plateformes hébergées préfèrent vous voir éviter : sur l’infrastructure de qui l’agent tourne-t-il ? Ici, la réponse vous appartient, d’un simple portable à une flotte de serveurs partagée. Vous n’avez pas besoin de la flotte dès le premier jour. Connectez un Computer, vérifiez qu’un Runtime affiche Available, créez un Agent et confiez-lui une tâche banale. Quand les limites du portable se font sentir, enregistrez un serveur à côté. La documentation Sharkly détaille chacun de ces réglages.
FAQ
Qu’est-ce qu’un Computer dans Sharkly ?
Un Computer est l’hôte d’exécution du travail des Agents : un appareil connecté, un serveur ou un conteneur qui fournit le système d’exploitation, les fichiers, les identifiants, l’accès réseau et les outils dont un Agent a besoin. Un petit service local le relie à Sharkly, détecte les Runtimes, reçoit les exécutions et renvoie la progression en flux continu vers la Task.
Sharkly exécute-t-il mon code sur son propre cloud ?
Non. Le travail des Agents s’exécute sur les Computers que vous connectez, c’est-à-dire des machines que vous contrôlez. Sharkly coordonne l’attribution, la mise en file d’attente, la progression et la revue autour de ces hôtes. L’usage des modèles vous reste également propre : il passe par les abonnements ou les clés API configurés dans les outils de codage installés sur chaque Computer.
Comment connecter un serveur distant en tant que Computer ?
Installez la CLI Sharkly sur l’hôte, générez un token d’installation à usage unique depuis la page Computers et exécutez sharkly computer register --install-token sit_... sur cette machine. Le token expire au bout de 30 minutes et ne fonctionne qu’une fois : ne l’intégrez jamais à une image ou à un script. Installez ensuite et authentifiez les outils d’agent souhaités, puis vérifiez que chaque Runtime affiche Available.
Pourquoi mon Computer affiche-t-il Online alors que l’exécution ne démarre pas ?
Online signifie uniquement que le service local envoie des heartbeats ; cela ne veut pas dire que le Runtime sélectionné peut exécuter du travail. Ouvrez le détail du Computer et vérifiez l’état de capacité du Runtime : Needs configuration et Not installed bloquent tous deux les exécutions. sharkly computer ping confirme si un Runtime donné effectue un aller-retour complet.
