Premiers pas avec Sharkly en 10 minutes

Démarrer avec Sharkly prend une dizaine de minutes : connecter un Ordinateur, créer un Agent et assigner une petite Tâche. Sharkly est un système de gestion du travail pour les humains et les agents. Il transforme les outils de codage IA comme Claude Code et Codex en coéquipiers assignables au sein d'un système de tâches partagé, pour que l'exécution cesse de disparaître dans des terminaux privés. Voici comment se déroule la première prise en main :

1. Connectez-vous et créez (ou rejoignez) une Organisation avec un Espace actif.
2. Connectez un Ordinateur via Sharkly Desktop ou la CLI Sharkly.
3. Vérifiez qu'au moins un Runtime, comme Claude Code, apparaît comme disponible.
4. Créez un Agent avec un rôle étroit et des instructions claires.
5. Rédigez une Tâche courte et bien délimitée, puis assignez-la à l'Agent.
6. Examinez le résultat sur la Tâche et répondez par un commentaire de suivi.

Le reste de ce guide détaille chaque étape dans l'ordre, explique les quatre concepts qui les sous-tendent et indique quoi vérifier à la fin de la première exécution. À l'arrivée, vous disposerez d'une boucle fonctionnelle que vous pourrez faire évoluer vers des exécutions parallèles, des Skills partagés et des Sprints.

Pourquoi les dix premières minutes avec Sharkly sont décisives

La plupart des équipes utilisent déjà des agents de codage IA. Le problème, c'est l'endroit où ce travail se déroule : dans le terminal d'une seule personne, invisible pour tous les autres. Quelqu'un colle un ticket Jira dans une fenêtre de chat, lance un agent, recopie le diff, et le raisonnement derrière la modification ne vit nulle part. Multipliez cela par cinq développeurs et trois outils d'agent différents, et vous obtenez des résultats sans trace.

Sharkly aborde le problème du côté de l'équipe. Ce n'est pas un agent de codage de plus. Le positionnement officiel est sans ambiguïté sur la frontière : Sharkly ne remplace ni Claude Code, ni Codex, ni les autres outils d'exécution. Il ajoute la couche partagée de tâches, de contexte, de contrôle et de revue autour des outils que votre équipe utilise déjà. Ces outils exécutent ; Sharkly gère l'assignation, les Ordinateurs connectés, le contexte des tâches, la progression, les blocages, les résultats et la revue humaine à travers eux.

C'est précisément pourquoi ces dix premières minutes sont structurées ainsi. Vous n'installez pas une nouvelle IA : vous reliez celle que vous utilisez déjà à un registre partagé, afin que chaque exécution garde visibles le contexte, la progression, les blocages, les résultats et la revue humaine, de la demande à la mise en production. Si vous voulez d'abord le positionnement global, lisez Qu'est-ce que Sharkly ? puis revenez ; ce guide-ci reste concret.

Les quatre concepts derrière toute configuration Sharkly

Quatre termes portent tout le modèle. Une fois qu'ils sont clairs, plus rien ne vous troublera par la suite.

Une Tâche est l'unité de travail principale dans Sharkly. Elle consigne l'objectif et la description, le statut, la priorité, les étiquettes, la personne responsable, l'Agent ou le Crew chargé de l'exécution, les commentaires, les pièces jointes, ainsi que l'état d'exécution complet et sa trace.

Un Agent est une configuration de travail enregistrée plutôt qu'un prompt ponctuel. La configuration soignée d'une personne (instructions, dépôts liés, environnement, délais d'expiration) devient réutilisable dans tout l'Espace dès lors que l'Agent est partagé.

Un Ordinateur fournit l'hôte d'exécution. Un petit service local le relie à Sharkly : il détecte les outils d'agent installés, reçoit le travail, prépare le répertoire de la tâche, démarre le Runtime sélectionné et renvoie la progression en temps réel. C'est le service local qui initie la connexion vers l'extérieur ; une configuration classique ne nécessite donc aucun port entrant.

Cette séparation des responsabilités est voulue : l'Agent définit comment le travail doit être traité, l'Ordinateur fournit l'hôte et les ressources locales, le Runtime exécute la session, et la Tâche reste le registre partagé de l'équipe. Votre code et vos identifiants restent sur des machines que vous contrôlez.

Ce qu'il vous faut avant de commencer

La liste des prérequis est courte :

• un compte Sharkly et une Organisation ;
• au moins un Espace actif ;
• une machine capable d'exécuter Sharkly Desktop ou le service local ;
• un Runtime pris en charge, installé et authentifié sur cette machine, comme Claude Code, Codex ou Gemini CLI ;
• un accès Git sur cette machine si votre première Tâche touche à un dépôt privé.

Deux précisions concernant les modèles. D'abord, apportez votre propre abonnement : l'usage des modèles passe toujours par les abonnements ou les clés API configurés dans ces outils, et votre quota dépend des forfaits et des comptes que votre équipe connecte. Ensuite, l'Agent suit le modèle par défaut du Runtime. Aucun sélecteur de modèle n'est exposé ; vous changez de modèle dans la configuration propre au Runtime, pas sur l'Agent.

Vous pouvez organiser des Tâches sans Ordinateur connecté. Un Agent, en revanche, ne peut rien exécuter tant qu'un Runtime éligible n'est pas en ligne : si la connexion d'un Ordinateur constitue la première étape, ce n'est pas un hasard.

Si votre Organisation n'a pas encore d'Espace actif, Sharkly vous guide pour en créer un. Choisissez une catégorie de travail afin de préremplir des types de tâches pertinents : le développement logiciel démarre avec Requirement, Bug, Task et User Story. Le premier Espace est public pour l'Organisation par défaut, et vous pourrez resserrer les accès plus tard.

Étape 1 : connecter un Ordinateur

Ouvrez Settings, puis Computers, et choisissez Connect Computer. Deux parcours couvrent la quasi-totalité des cas :

• Sharkly Desktop pour une machine personnelle prise en charge. Installez-le, connectez-vous : il enregistre la machine et démarre le service local pour vous.
• La CLI Sharkly, avec le service local, pour un hôte distant ou une machine Linux. Générez un jeton d'installation à usage unique dans la boîte de dialogue de connexion, puis exécutez la commande générée sur la machine cible :

sharkly computer register --install-token sit_9f2ka7x1mrq8

Le jeton d'installation est éphémère et à usage unique. Ne le placez pas dans une image réutilisable, un script, une Tâche ou un commentaire. Il a aussi un rôle très précis : un jeton d'installation enregistre un Ordinateur, il ne crée pas de session CLI humaine. Les jetons d'accès personnels (ils commencent par shk_) s'en chargent séparément.

Attendez que l'Ordinateur apparaisse comme connecté, puis ouvrez sa page de détail. Chaque Runtime détecté affiche un statut de capacité : Available, Needs configuration, Not installed ou Unsupported. Cette distinction vous évite la confusion la plus fréquente au démarrage. Un Ordinateur en ligne signifie simplement que son service local envoie des battements de cœur. Cela ne veut pas dire que le Runtime que vous avez sélectionné peut exécuter une Tâche. Si une exécution refuse de démarrer plus tard, vérifiez le statut de capacité du Runtime avant de chercher un problème de connexion.

Vous pouvez aussi vérifier depuis le terminal :

sharkly computer list
sharkly computer show cmp_4c81d2
sharkly computer ping cmp_4c81d2 rt_claude_code

La documentation sur les Ordinateurs traite en profondeur des diagnostics, des Runtimes personnalisés, de la visibilité et des paramètres de nettoyage.

Étape 2 : créer votre premier Agent

Ouvrez Agents et sélectionnez New Agent. Résistez à l'envie de construire un assistant qui fait tout. Commencez par un rôle étroit, car une description ciblée indique aux humains quoi assigner, tandis que les instructions indiquent à l'Agent comment travailler.

Une bonne première configuration ressemble à ceci :

• Name : Code Reader
• Description : Reads a repository, explains the current implementation, and reports risks without changing files.
• Visibility : Personal, ou l'Espace dans lequel l'Agent sera utilisé
• Computer and Runtime : la connexion que vous avez vérifiée à l'étape 1

Pour les instructions, l'exemple du Quickstart mérite d'être repris presque mot pour mot :

Lisez la Tâche dans son intégralité et les commentaires pertinents avant d'agir. Limitez-vous au périmètre de la demande. Pour la première Tâche, ne modifiez aucun fichier. Indiquez ce que vous avez examiné, les preuves de chaque conclusion et tout ce qui reste incertain.

Remarquez ce que couvrent ces instructions : le périmètre, la manière d'examiner avant d'agir et le format de restitution. C'est le bon niveau de détail. Placez les comportements stables dans les instructions de l'Agent, les exigences propres à une Tâche dans la description de la Tâche, et les procédures réutilisables que plusieurs Agents partagent dans un Skill. C'est en gardant ces trois couches distinctes qu'un Agent devient réutilisable plutôt que fragile.

Étape 3 : ajouter un dépôt ou un répertoire de travail

Si votre Agent doit lire du code, il lui faut du code à lire. Deux options :

• Lier un dépôt Git à l'Agent (ou s'appuyer sur les dépôts configurés pour l'Espace de la Tâche). Les exécutions adossées à un dépôt peuvent préparer un git worktree neuf pour chaque Tâche, ce qui rend possible par la suite une exécution parallèle sans risque.
• Configurer un répertoire local spécifié sur un Ordinateur local. Les exécutions réutilisent le code, les dépendances, les caches et les outils déjà présents, au lieu de préparer une copie neuve.

La règle de décision : utilisez des répertoires temporaires adossés à un worktree pour la plupart des travaux sur dépôt, et dès que plusieurs Tâches risquent de modifier la même base de code en parallèle. Utilisez un répertoire spécifié lorsqu'une exécution a besoin d'un environnement coûteux à reconstruire, en gardant en tête qu'un répertoire spécifié ne sert qu'à une exécution à la fois. Nous avons consacré un article complet à la façon dont les worktrees évitent aux agents parallèles de se marcher sur les pieds si vous voulez les détails techniques.

Étape 4 : rédiger une Tâche qu'un Agent peut exécuter

Créez une Tâche dans le même Espace. L'exemple du Quickstart est volontairement banal, et c'est justement l'idée :

Title : Vérifier le chemin d'erreur d'authentification

Description : Lisez l'implémentation actuelle de l'authentification et identifiez trois cas de défaillance visibles par l'utilisateur. Ne modifiez aucun fichier. Pour chaque cas, citez le fichier ou le composant concerné et expliquez le comportement attendu. Terminez par toute question à trancher avant l'implémentation.

Cette Tâche réunit les trois propriétés de toute bonne première Tâche. Elle a une frontière claire (lire, ne pas modifier). Elle produit un résultat vérifiable (trois cas avec preuves). Et elle est à faible risque, ce qui vous permet d'évaluer le jugement de l'Agent sans mettre votre base de code en danger. Si votre dépôt ne contient pas de code d'authentification, remplacez le sujet par n'importe quelle petite zone existante, comme le chargement de configuration ou un composant d'état vide.

Confier du travail à un logiciel de cette manière ne ressemble pas à un prompt, et c'est normal. Un prompt est une conversation ; une Tâche est un contrat avec un résultat vérifiable. Une fois cette boucle en place, la même approche passe à l'échelle sur de vrais tickets : notre guide sur l'assignation d'un ticket Jira à un agent IA en montre la version en production.

Étape 5 : assigner la Tâche et suivre l'exécution

Ouvrez le champ Assignee de la Tâche et choisissez votre Agent. Les humains, les Agents et les Crews peuvent tous être assignés ; sélectionner un Agent en fait l'assigné chargé de l'exécution.

Une seule règle de statut détermine le démarrage de l'exécution. Une Tâche assignée à un Agent ne lance pas d'exécution tant qu'elle reste en Backlog. Le Backlog est une zone d'attente où le travail se prépare. Déplacez la Tâche vers un statut prêt pour le travail (unstarted ou started), et Sharkly met l'exécution en file d'attente dès que l'Ordinateur et le Runtime sont prêts. Les statuts Completed, canceled et duplicate ne déclenchent jamais d'exécution initiale.

Pendant l'exécution, la Tâche affiche son état : queued, dispatched, running, puis completed, failed ou canceled. Une exécution adossée à un dépôt peut prendre un moment pour récupérer le code et préparer son répertoire isolé. Trois vues s'offrent à vous :

• Chat pour l'échange façon commentaires avec l'Agent ;
• Activity pour les commentaires et les modifications de la Tâche sur une même chronologie ;
• Executions pour l'historique des exécutions et la trace complète : appels d'outils, événements du Runtime, source du déclenchement et détails des échecs.

L'état d'une exécution et le statut d'une Tâche sont liés mais distincts. Une exécution peut être Running alors que le statut de la Tâche indique encore In Progress, car l'un décrit l'avancement de l'exécution et l'autre la position dans le flux de travail.

Étape 6 : examiner le résultat en relecteur, pas en spectateur

La réponse finale de l'Agent revient dans la Tâche sous forme de commentaire lié à sa trace d'exécution. C'est ici que commence le volet humain du contrat : les agents explorent, exécutent, testent et rendent compte. Les humains donnent la direction, accordent l'autorité et acceptent le résultat.

Vérifiez que l'Agent :

• a bien examiné le code ou la source visés ;
• est resté dans la limite « aucune modification » ;
• a fourni des preuves pour chaque conclusion ;
• a consigné ses incertitudes au lieu de deviner ;
• a laissé sur la Tâche un résultat exploitable par un coéquipier.

S'il faut un second passage, répondez par un commentaire ciblé. Un commentaire éligible sur une Tâche toujours assignée à cet Agent déclenche une exécution de suivi, et les commentaires rapprochés sont regroupés pour éviter de créer des exécutions en attente en double. Si l'Agent a besoin de votre contribution ou d'une validation, sa demande peut apparaître dans votre Inbox, qui sépare les éléments nécessitant votre réponse des mises à jour de moindre priorité.

Quand le résultat tient la route, marquez la Tâche comme terminée. Vous bouclez ainsi le premier cycle suivi par la checklist de configuration : Ordinateur connecté, Agent créé, dépôt prêt, Tâche créée, assignée et terminée.

Après la première boucle : cinq façons de faire grandir votre configuration

La première exécution prouve que la plomberie fonctionne. Chacune des étapes suivantes ajoute une dimension.

Comment exécuter plusieurs Tâches en même temps ?

Augmentez la concurrence de façon réfléchie. Avec des répertoires temporaires, la concurrence par défaut correspond à la moitié de la limite de l'Ordinateur ; chaque Tâche obtient un worktree isolé, de sorte que les exécutions parallèles ne se heurtent pas. Surveillez le CPU, la mémoire et la capacité de votre fournisseur de modèles avant de relever les limites, et lisez comment les équipes lancent plusieurs sessions Claude Code en parallèle pour la comparaison avec les bricolages maison.

Quand utiliser Agent Chat plutôt qu'une Tâche ?

Sharkly conserve volontairement deux surfaces. Utilisez le Chat pour explorer, planifier ou enquêter avec un Agent avant que le travail n'ait besoin d'être suivi. Utilisez une Tâche quand le travail exige un responsable, un statut, un historique d'exécution ou une revue. Si un Chat produit quelque chose sur quoi l'équipe doit agir, transformez-le en Tâche pour que le résultat soit consigné.

Quand avez-vous besoin d'un Crew ?

Un Crew est un groupe réutilisable d'humains et d'Agents coordonné par un Agent chef de file. Pour un travail petit et bien défini, assignez la Tâche directement à un seul Agent et ne multipliez pas les pièces mobiles. Utilisez un Crew quand le chef de file doit interpréter un objectif, faire intervenir des membres spécialisés et ramener leurs résultats dans une seule Tâche.

Quand un Skill vaut-il mieux que modifier les instructions ?

Quand plusieurs Agents ont besoin de la même procédure (une checklist de revue, un schéma de migration, un format de restitution), déplacez-la dans un Skill et liez-le là où c'est nécessaire. Le savoir-faire d'un développeur devient une infrastructure d'organisation plutôt qu'un prompt privé.

Et le reste de l'équipe ?

Tout ce qui précède fonctionne en solo. Le bénéfice s'accumule quand les Tâches vivent dans des Espaces partagés, que les Sprints regroupent le travail en cycles et que les coéquipiers relisent la production des Agents dans les vues qu'ils utilisent déjà pour le travail humain. La couche projet de Sharkly (Espaces, Projets, Sprints, vues kanban et liste) reste suffisamment standard pour que personne n'ait besoin d'une nouvelle formation.

Quand Sharkly n'est pas l'outil adapté à votre situation actuelle

Une frontière honnête vous fait gagner du temps. Si vous êtes un développeur seul à lancer un agent sur un seul dépôt, un terminal et une branche suffisent peut-être aujourd'hui. La couche de coordination devient rentable quand les exécutions se multiplient : plus d'un agent, plus d'une personne ayant besoin de voir les résultats, ou du travail qui exige une revue avant fusion.

La même logique vaut pour l'outillage que vous avez développé vous-même. Les sessions tmux et les scripts de worktree maison fonctionnent réellement ; les équipes s'en détachent quand les parties invisibles (qui a lancé quoi, où est passé le diff, qui l'a approuvé) finissent par coûter plus que ce que les scripts font économiser. Et si votre équipe vit de bout en bout dans l'écosystème d'un seul fournisseur, évaluez d'abord l'orchestration proposée par ce fournisseur. Sharkly est le plus pertinent quand vous mélangez outils, machines et personnes, car il reste neutre vis-à-vis des trois. Pour replacer le sujet dans son contexte, voir Qu'est-ce que le codage agentique ?.

Ce qui ne change dans aucun de ces cas : gardez les outils que votre équipe utilise déjà. La voie d'adoption de Sharkly consiste à ajouter une couche visible et vérifiable autour d'eux, pas à remplacer le flux de travail qui les sous-tend.

Trois premières exécutions qui fonctionnent en pratique

L'équipe plateforme prudente. Un ingénieur DevEx connecte un Ordinateur Linux partagé, crée un Agent Code Reader en lecture seule et laisse ses coéquipiers assigner des Tâches d'investigation pendant une semaine. Personne n'accorde d'accès en écriture avant que les rapports aient fait leurs preuves. L'adoption se diffuse parce que les traces d'exécution rendent le jugement de l'Agent inspectable.

Le développeur solo qui monte en puissance. Un développeur connecte un ordinateur portable, crée deux Agents (un pour l'implémentation, un pour la revue) et commence à faire passer les petits bugs par des Tâches plutôt que par des prompts improvisés. Le gain immédiat n'est pas la vitesse : c'est que chaque correctif dispose désormais d'une description, d'un diff, d'une trace et d'un relevé de ce qui a été vérifié.

L'équipe centrée sur Jira. Un engineering manager garde Jira comme source de vérité pour la planification et connecte Sharkly pour que les tickets deviennent des Tâches exécutables. Les développeurs cessent de copier-coller le contexte des tickets dans leurs terminaux. Résultats, blocages et demandes de revue reviennent dans la Tâche, là où le manager peut les voir.

Vos dix prochaines minutes

Le plus petit flux de travail utile dans Sharkly est volontairement minimal : connecter un Ordinateur, créer un Agent et assigner une Tâche à faible risque. Toutes les capacités avancées (worktrees parallèles, Crews, Skills, Automations, Sprints) s'appuient sur cette boucle sans la modifier.

Alors lancez la boucle. Connectez un Ordinateur, créez un Agent et confiez-lui quelque chose de banal. Examinez le résultat comme vous reliriez la première PR d'un nouveau coéquipier : avec attention, une limite claire et une question de suivi. Décidez ensuite, preuves à l'appui, ce que vous accorderez en plus. Le Quickstart de la documentation reprend ces étapes avec des captures d'écran à jour quand vous serez prêt à démarrer.

Questions fréquentes

Quels agents de codage fonctionnent avec Sharkly ?

Sharkly détecte les outils d'agent pris en charge installés sur un Ordinateur connecté et les présente chacun comme un Runtime. Claude Code, Codex, Gemini CLI et OpenCode font partie des outils cités dans la documentation officielle. La page de détail de l'Ordinateur indique l'ensemble actuellement pris en charge pour votre machine, avec un lien vers le guide d'installation pour chaque Runtime, et vous pouvez ajouter un Runtime ACP personnalisé si un outil n'est pas détecté automatiquement.

Sharkly remplace-t-il Claude Code ou Codex ?

Non. Sharkly ne remplace ni Claude Code, ni Codex, ni les autres outils d'exécution. Ces outils prennent en charge la session d'agent proprement dite sur votre Ordinateur. Sharkly ajoute la couche partagée autour d'eux : assignation à l'échelle de l'équipe, contexte des tâches, progression, résultats et revue humaine. Vous continuez d'utiliser les outils d'agent et les comptes que vous avez déjà.

Combien coûte Sharkly ?

Le modèle de Sharkly repose sur votre propre abonnement : l'usage des modèles passe par les abonnements ou les clés API configurés dans vos outils d'agent, et votre quota dépend des forfaits que votre équipe connecte. Pour connaître les offres actuelles, consultez directement sharkly.ai, car cet article ne suit pas les tarifs.

Mon code et mes identifiants passent-ils par les serveurs de Sharkly ?

L'exécution a lieu sur les Ordinateurs que vous connectez : votre portable, vos serveurs ou vos conteneurs. L'Ordinateur fournit le système d'exploitation, les fichiers, les identifiants et les outils, et le service local renvoie la progression et les résultats dans la Tâche. Les dépôts sont récupérés avec l'accès Git configuré sur cet Ordinateur.

Pourquoi mon Agent ne lance-t-il aucune exécution ?

Vérifiez trois causes courantes, dans cet ordre. D'abord, la Tâche est peut-être en Backlog ; une Tâche assignée y attend jusqu'à être déplacée vers un statut prêt pour le travail. Ensuite, le Runtime n'est peut-être pas utilisable ; un Ordinateur en ligne ne confirme que les battements de cœur, alors ouvrez le détail de l'Ordinateur et vérifiez le statut de capacité du Runtime. Enfin, la capacité est peut-être saturée ; un Agent en ligne peut malgré tout mettre du travail en file d'attente lorsque les limites de concurrence ou de répertoire sont atteintes.

Deux Agents peuvent-ils travailler en même temps sur le même dépôt ?

Oui, avec des répertoires de travail temporaires. Chaque Tâche dispose d'un répertoire isolé, et les exécutions adossées à un dépôt préparent un git worktree distinct par exécution, ce qui réduit les interférences entre Tâches simultanées. Les répertoires spécifiés fonctionnent à l'inverse : un chemin configuré ne sert qu'à une exécution à la fois.

Puis-je exécuter des Agents Sharkly sur un serveur distant ?

Oui. Installez la CLI Sharkly et le service local sur l'hôte distant, puis enregistrez-le avec un jeton d'installation à usage unique récupéré sur la page Computers. Le service local se connecte vers Sharkly depuis l'intérieur, donc une configuration classique ne nécessite aucun port entrant. Les Ordinateurs distants conviennent à la capacité partagée d'une équipe ; les portables, à l'expérimentation personnelle.

Quelle doit être ma première Tâche ?

Quelque chose en lecture seule, avec une limite claire et un résultat vérifiable. La documentation suggère d'examiner un chemin d'erreur d'authentification et de signaler trois cas de défaillance visibles par l'utilisateur, preuves à l'appui, sans modifier de fichier. N'importe quelle petite zone réelle de votre base de code fait l'affaire. Évitez les premières Tâches vagues du type « améliore le code » : on ne peut pas relire ce qu'on n'a pas délimité.