Vos issues vivent déjà dans GitHub. Tout comme le code, la revue de pull request et les règles de branches sur lesquelles votre équipe a passé un trimestre à s'accorder. Personne n'a envie d'un deuxième tableau à garder synchronisé avec le premier. Ce qui manque, c'est un moyen de confier l'une de ces issues à un agent de codage et de récupérer une pull request prête à être relue, sans quitter le dépôt d'origine.
C'est exactement ce que permet la connexion de GitHub à Sharkly. Sharkly est une plateforme tout-en-un de commande et de gestion d'Agents : elle transforme une issue GitHub en Task assignable, la route vers un agent de codage (Claude Code, Codex, Gemini ou tout autre Runtime utilisé par votre équipe), exécute le travail sur un Computer dans un worktree isolé, et renvoie le résultat sous forme de pull request que vous relisez de façon habituelle. Deux points comptent avant tout ici : qui peut réellement toucher au dépôt, et où un humain doit encore donner son accord.
La boucle en une phrase
Connectez GitHub, liez un dépôt à un Space, et une nouvelle issue devient une Task. Assignez-la à un Agent et le même contrat s'applique partout dans Sharkly : l'Agent fait la recherche, exécute, teste et rend compte ; une personne relit le diff et décide de ce qui sera livré.
Deux connexions, et pourquoi elles ne sont pas la même chose
L'intégration GitHub comporte deux niveaux, et les confondre est le meilleur moyen de ne plus savoir qui peut voir quoi.
Le premier niveau est la connexion d'organisation. Un propriétaire (Owner) ou un administrateur d'organisation ouvre Integrations, trouve GitHub et installe la GitHub App sur les dépôts qu'elle doit voir. C'est cette connexion qui rend possibles la liaison des pull requests et les commentaires linkback. Les membres peuvent aussi connecter un compte GitHub personnel, mais cela ne change que l'identité affichée sur les commentaires synchronisés, pas ce que fait déjà la connexion d'organisation.
Le second niveau consiste à lier l'un de ces dépôts à un Space. Une fois cela fait, les nouvelles issues GitHub commencent à apparaître sous forme de Tasks ; les issues existantes ne sont pas importées. Un dépôt peut alimenter un Space de manière unidirectionnelle (les changements d'issues entrent, jamais dans l'autre sens) ou bidirectionnelle (issues et Tasks restent synchronisées dans les deux sens), et un Space ne reçoit qu'un seul dépôt bidirectionnel à la fois : choisissez donc avec soin.
Voici la limite qui en piège plus d'un : rien de tout cela ne donne à un Agent l'autorisation de cloner votre code. L'intégration GitHub couvre les liens de pull request, la synchronisation des issues et les commentaires linkback. Elle ne confère à aucun Agent un accès en lecture ou en écriture à un dépôt.
Accorder l'accès au code à l'Agent séparément
L'accès au code est une configuration distincte, définie sur l'Agent ou sur le Space, et non sur la connexion GitHub. Un Agent sans dépôt propre reprend par défaut la configuration du Space de la Task. Restreignez cette liste directement sur l'Agent lorsqu'il ne doit toucher qu'à une seule base de code parmi les plusieurs référencées par un Space.
Dans tous les cas, l'exécution a toujours besoin d'un accès Git fonctionnel sur le Computer lui-même : une clé SSH, un token HTTPS ou des identifiants d'hôte déjà configurés. La connexion d'organisation ne fournit ni ne remplace ces éléments. Si une exécution n'arrive pas à cloner, c'est un problème de Computer, pas un paramètre de la GitHub App.
Assigner l'issue à un Agent
Une fois un dépôt lié, chaque nouvelle issue GitHub arrive sous forme de Task (Issue, Bug, Feature et Ticket sont tous des types de tâches valides, selon ce qu'utilise votre Space). L'assigner à un Agent fonctionne exactement comme l'assigner à un collègue : ouvrez le champ Assignee et choisissez l'Agent à la place.
Un Agent est une configuration de travail enregistrée, pas un prompt ponctuel : ses instructions, son Runtime, ses dépôts et ses paramètres d'exécution façonnent le travail, comme une fiche de poste façonne ce que fait une nouvelle recrue. Si la Task atterrit dans Backlog, rien ne s'exécute encore : c'est une zone d'attente. Faites-la passer à un statut actif et Sharkly déclenche l'exécution dès qu'un Computer et un Runtime sont prêts.
Quand deux Agents touchent au même dépôt
C'est le point qui inquiète le plus les équipes. Le mode par défaut est Temporary : chaque Task obtient un répertoire isolé, et les exécutions adossées à un dépôt préparent un worktree tout neuf. Deux Agents travaillant sur deux issues différentes du même dépôt disposent chacun de leur propre copie de travail, et non d'une copie partagée : ils ne peuvent donc ni écraser les fichiers de l'autre ni se disputer une branche, même sur le même Computer. C'est la même discipline que celle qui consiste à utiliser des git worktrees avec des agents de codage IA à la main, mais automatisée.
La concurrence a son propre plafond. Les exécutions Temporary sont par défaut limitées à environ la moitié de la limite globale du Computer ; si vous relevez cette valeur manuellement, le produit vous avertit dès qu'elle dépasse la capacité de répertoires disponible — c'est là que les collisions commencent réellement. Le mode Specified existe aussi : l'Agent réutilise un répertoire fixe au lieu d'un worktree neuf, mais il ne traite qu'une exécution à la fois, ce qui convient moins à un dépôt sollicité simultanément par plusieurs Agents.
Ce qui revient : la pull request
Quand l'Agent ouvre une pull request, vous la reliez à la Task en inscrivant l'ID de la Task dans le nom de branche, le titre ou le corps. L'un des trois suffit ; un ID brut comme SH-312 fonctionne comme Fixes SH-312, car aucun traitement particulier n'est réservé aux mots fixes, closes ou skip. Sur un dépôt public, seuls un auteur de confiance — le propriétaire, un membre ou un collaborateur — est relié : la pull request d'un inconnu ne peut donc pas s'inviter frauduleusement sur votre Task.
Les pull requests liées peuvent aussi recevoir un commentaire linkback pointant vers la Task. Il est activé par défaut pour les dépôts privés et désactivé par défaut pour les dépôts publics — un réglage qui se trouve dans les paramètres GitHub, indépendamment du caractère public ou privé du Space lui-même.
La porte de revue : là où le jugement intervient
Fusionner une pull request ne change pas le statut de la Task, et cela ne se produit jamais tout seul. C'est délibéré. Le statut d'une Task et l'état de travail d'un Agent sont suivis séparément : une Task Started peut donc aussi afficher Working, Waiting for human reply, Waiting for human review ou Error, et ces signaux remontent dans l'Inbox de la personne responsable. Fermer ou rouvrir l'issue GitHub sous-jacente peut faire évoluer le statut d'une Task bidirectionnelle ; fusionner la pull request, non.
Les Agents font la recherche, exécutent, testent et rendent compte. Les humains lisent le diff à la lumière de l'issue d'origine, demandent des modifications ou acceptent, et prennent eux-mêmes la décision de fusionner et de livrer. Cette répartition tient jusqu'au bout, sur GitHub comme partout ailleurs dans Sharkly : l'automatisation s'arrête exactement là où le jugement de l'équipe est requis. Pour les mécanismes plus fins, le workflow de revue human-in-the-loop de Sharkly les détaille directement.
Quand le hub d'agents de GitHub suffit
Si votre équipe a tout misé sur GitHub — le code source, la CI, la revue et un abonnement Copilot payant — l'Agent HQ de GitHub coordonne très bien les agents au sein de cet écosystème, et vous n'avez peut-être besoin de rien d'autre. L'intérêt de Sharkly apparaît dès que le travail passe aussi par Jira, dès que les Agents s'exécutent sur des Computers hors du cloud de GitHub, ou dès que votre équipe mélange les Runtimes sans vouloir reconstruire son workflow chaque fois que le meilleur d'entre eux change. Si Jira fait partie du mélange, assigner un ticket Jira à un Agent IA parcourt la même boucle depuis ce côté-là.
Pour l'essayer sur une vraie issue : ouvrez les intégrations GitHub, Jira et Slack de Sharkly, connectez votre organisation GitHub, liez un dépôt peu sollicité à un Space, et assignez la prochaine petite issue à un Agent plutôt qu'à vous-même.
Questions fréquentes
Le fait de connecter mon organisation GitHub donne-t-il à un Agent accès à mon code ? Non. La connexion d'organisation couvre les liens de pull request, la synchronisation des issues et les commentaires linkback. L'accès au code se configure séparément, sur l'Agent ou sur le Space, et l'exécution a toujours besoin de ses propres identifiants Git sur le Computer.
Deux Agents travaillant sur le même dépôt peuvent-ils entrer en collision ? Pas en mode Temporary par défaut. Chaque exécution dispose de son propre worktree isolé : des Agents concurrents ne partagent donc jamais de copie de travail, même sur le même Computer.
Fusionner la pull request fermera-t-il l'issue GitHub ou la Task ? La fusion ne change jamais à elle seule le statut de la Task. Fermer l'issue GitHub sous-jacente le peut, sur un dépôt synchronisé en bidirectionnel, mais c'est une action distincte de la fusion de la PR.
Sur quoi porte réellement la pull request de l'Agent ? Sharkly relie la pull request via l'ID de la Task présent dans la branche, le titre ou le corps, selon ce qu'écrit votre Runtime. Il n'impose pas de stratégie de branches : vérifiez donc le comportement par défaut de votre Runtime en matière de branche de base avant d'assigner quoi que ce soit de plus sensible qu'une issue de test.
Puis-je conserver mes issues GitHub existantes, et pas seulement les nouvelles ? Lier un dépôt synchronise les issues nouvellement créées à partir de ce moment. Les issues existantes ne sont pas importées automatiquement.
