Vous décrivez une fonctionnalité, vous la confiez à un agent de codage, et vous partez vaquer à vos occupations pendant qu'il ouvre une pull request. Puis vous recommencez avec un deuxième agent, et un troisième. Très vite, le vrai problème n'est plus de lancer des agents, mais de garder la trace de chacun d'eux. GitHub Agent HQ est la réponse de GitHub à ce chaos : un centre de commandement qui rassemble des agents de codage de plusieurs fournisseurs dans un seul poste de pilotage au sein de GitHub. L'idée est vraiment solide, et ce guide couvre ce qu'il est, à qui il s'adresse, et la limite qu'il trace et que la plupart des articles oublient : Agent HQ coordonne le travail qui vit à l'intérieur de l'écosystème GitHub, pas les outils qui vivent en dehors.
Cette frontière compte dès l'instant où votre équipe n'est pas entièrement sur GitHub. Si votre outil de suivi est Jira, que vos dépôts sont sur GitLab, ou que la moitié de vos agents tournent sur des ordinateurs portables et des terminaux qui ne touchent jamais au cloud de GitHub, il vous faut une couche qui se situe au-dessus de tous les outils, et non à l'intérieur de l'un d'eux. Cette couche, c'est Sharkly, une plateforme tout-en-un de commandement et de gestion d'agents. Cet article passe en revue les points forts d'Agent HQ, l'endroit exact où se situent ses limites, et comment une couche neutre garde une flotte mixte visible, de la demande à la mise en production.
Nous supposerons tout au long de cet article la meilleure version d'Agent HQ, car elle le mérite. Ensuite, nous tracerons la frontière clairement, afin que vous puissiez déterminer en deux minutes environ si Agent HQ suffit à lui seul ou si vous avez déjà dépassé les capacités d'un hub mono-écosystème.
TL;DR
GitHub Agent HQ est un plan de contrôle au sein de GitHub, baptisé Mission Control, qui permet d'assigner, de piloter et de suivre des agents de codage de plusieurs fournisseurs (Claude, Codex, Google, Cognition, xAI) dans le cadre d'un abonnement GitHub Copilot payant. Il est agnostique vis-à-vis des modèles et excellent lorsque votre travail vit déjà dans les dépôts, les pull requests et les Actions de GitHub. Sa frontière, c'est l'écosystème, pas le fournisseur d'agents : il coordonne les agents qui travaillent à l'intérieur de GitHub, et ne gère donc pas les exécutions sur GitLab, un tableau Jira, Bitbucket, ni les agents qui tournent localement sur des Computers en dehors du cloud de GitHub. Utilisez Agent HQ lorsque vous êtes une équipe 100 % GitHub. Utilisez une couche neutre comme Sharkly lorsque votre équipe mélange outils de suivi, hébergeurs et runtimes et a besoin d'un enregistrement partagé avec revue humaine pour l'ensemble.
Ce qu'est réellement GitHub Agent HQ
GitHub Agent HQ est un centre de commandement au sein de GitHub qui permet d'assigner, de piloter et de suivre des agents de codage de plusieurs fournisseurs, le tout via un abonnement GitHub Copilot payant. Cette seule phrase contient toute l'idée. Au lieu que chaque agent vive dans son propre outil avec sa propre interface de lancement, Agent HQ les rassemble dans un espace unique que GitHub appelle Mission Control, accessible depuis GitHub lui-même, VS Code, l'application mobile et la ligne de commande.
Le changement qu'il vaut la peine de souligner, c'est qu'Agent HQ n'est pas l'agent d'un seul fournisseur. GitHub l'a ouvert aux agents de codage d'Anthropic, OpenAI, Google, Cognition et xAI, ce qui vous permet de choisir Claude pour une étape et Codex pour une autre sans quitter le hub. Vous assignez une tâche à un agent, il travaille sur une branche dans l'environnement GitHub, exécute vos vérifications et renvoie une pull request que vous révisez comme vous révisez déjà du code. Mission Control est l'endroit où vous suivez plusieurs de ces exécutions en même temps, et des fonctionnalités comme Plan Mode vous aident à structurer le travail avant qu'un agent ne démarre.
L'intérêt du hub, c'est la coordination. Vous ne passez plus d'un outil d'agent à l'autre en essayant de vous rappeler lequel fait quoi. Si vous avez lu notre article explicatif sur ce que signifie l'orchestration d'agents IA, Agent HQ est l'orchestration dans sa forme mono-écosystème : plusieurs fournisseurs d'agents, une seule plateforme, et cette plateforme, c'est GitHub.
Ce qu'Agent HQ fait bien
Prenez la fonctionnalité sous son meilleur jour, car sa meilleure version est solide. Voici ce qui fait la valeur d'Agent HQ.
Un choix d'agents neutre vis-à-vis des fournisseurs. La plupart des hubs d'agents vous enferment chez un seul fabricant de modèles. Agent HQ, non. Vous pouvez faire tourner Claude, Codex et d'autres côte à côte et passer de l'idée à la mise en œuvre en utilisant différents agents à différentes étapes, sans changer d'outil ni perdre le contexte. C'est une vraie réponse à l'enfermement à un modèle, et c'est la fonctionnalité mise en avant au lancement, à juste titre.
Un centre de commandement unique sur toutes les surfaces. Mission Control vous offre une vue unique de l'activité des agents depuis GitHub, VS Code, le mobile et le CLI. Vous assignez, pilotez et suivez depuis là où vous vous trouvez déjà. Pour une équipe qui jonglait auparavant manuellement avec des exécutions parallèles, notre guide sur l'exécution de plusieurs agents Claude Code en parallèle montre à quel point la version bricolée devient délicate. Agent HQ supprime cette gymnastique à l'intérieur de GitHub.
Un travail qui atterrit là où la revue a déjà lieu. Les agents travaillent sur des branches et renvoient des pull requests. Le résultat s'intègre directement dans le flux de revue GitHub auquel votre équipe fait confiance, avec la même revue de code, les mêmes vérifications et les mêmes règles de fusion que vous appliquez déjà. Aucun nouvel endroit où chercher un diff.
Natif de la plateforme dans laquelle les équipes vivent déjà. Si GitHub est votre maison, Agent HQ n'est pas un ajout rapporté. Il partage votre identité, vos permissions, vos Actions et vos dépôts. Les instructions et contrôles personnalisés des agents se trouvent à côté du code sur lequel ils agissent, de sorte que la configuration reste proche du travail au lieu d'être reléguée dans une console séparée.
Pour une équipe standardisée sur GitHub de bout en bout, c'est une boucle nette et puissante. Décrivez le travail, choisissez un agent, révisez la pull request, fusionnez. Si c'est votre cas, Agent HQ est peut-être toute l'orchestration dont vous avez besoin, et vous pouvez arrêter votre lecture ici en toute conscience.
À qui s'adresse Agent HQ
Agent HQ est conçu pour l'équipe 100 % GitHub, et il la sert bien. Le cas d'usage le plus évident ressemble à ceci : votre code source vit dans des dépôts GitHub, votre CI tourne sur GitHub Actions, votre équipe révise et fusionne via des pull requests GitHub, et vous disposez d'un abonnement Copilot payant. Tout ce dont un agent a besoin pour lire, modifier, tester et livrer se trouve déjà dans une seule plateforme, si bien qu'un hub au sein de cette plateforme dispose d'une portée complète sur le travail.
La valeur s'accumule pour cette équipe à mesure que le déploiement se poursuit tout au long de 2026. Chaque nouveau fournisseur d'agents et chaque nouvelle fonctionnalité de Mission Control arrive à l'endroit où votre travail se trouve déjà. Vous n'intégrez rien. Vous activez davantage une plateforme que vous utilisez déjà. Pour une organisation d'ingénierie centrée sur GitHub, c'est le chemin le plus court entre une tâche décrite et une modification révisée et fusionnée.
La question n'est pas de savoir si Agent HQ est bon pour cela. C'est de savoir si la réalité de votre équipe tient entièrement dans GitHub. C'est là que la frontière entre en jeu.
La frontière honnête : il orchestre l'écosystème GitHub, pas vos autres outils
Voici la limite que les annonces vous tracent rarement, et ce n'est pas celle que les gens attendent. La limite n'est pas le fournisseur d'agents. Agent HQ est rafraîchissant d'ouverture sur ce point. La limite, c'est l'écosystème. Agent HQ coordonne les agents qui travaillent à l'intérieur de GitHub : dépôts GitHub, pull requests GitHub, GitHub Actions, identité GitHub, dans le cadre d'un abonnement GitHub Copilot. Chacun de ces éléments est un élément GitHub. Ce n'est pas un défaut. C'est la conception. Mais cela fixe une limite dure le jour où le travail de votre équipe cesse de vivre entièrement dans GitHub.
Agent HQ ne gère pas le travail sur GitLab ou Bitbucket. Si certains de vos dépôts ou pipelines vivent en dehors de GitHub, les agents qu'Agent HQ coordonne ne les atteignent pas. Ces exécutions vivent dans un monde séparé, sans chronologie partagée.
Agent HQ n'est pas votre outil de suivi de projet. Il coordonne des agents sur du code et des pull requests. Si votre équipe planifie et assigne le travail dans Jira ou Linear, la question de savoir qui est responsable d'une tâche, de quoi elle dépend et ce qui la bloque vit dans un système qu'Agent HQ n'exécute pas. Une pull request est une surface de revue, pas une couche d'assignation et de contexte.
Agent HQ ne coordonne pas les agents qui tournent en dehors de son cloud. Si un collègue exécute Claude Code dans un terminal local, ou Codex sur son propre Computer, ou un agent sur un runtime que vous hébergez vous-même, ce travail n'apparaît pas dans Mission Control. Le hub voit les agents qu'il lance à l'intérieur de GitHub, pas ceux que votre équipe exécute ailleurs.
Rien de tout cela n'est une critique de GitHub. Disons clairement ce qu'un outil n'est pas, à l'endroit précis où un lecteur pourrait supposer le contraire à tort : Agent HQ est un plan de contrôle mono-écosystème, pas une couche de coordination neutre couvrant tous les outils de suivi, hébergeurs et runtimes que votre équipe utilise. Si toute votre stack est GitHub, la frontière ne mord jamais. Dès qu'une partie ne l'est plus, elle mord.
Le duo de décisions : équipe 100 % GitHub ou équipe multi-outils
Le choix n'est pas « bon hub contre mauvais hub ». C'est « quelle forme de coordination correspond à votre équipe ». Voici le duo de décisions honnête.
Utilisez GitHub Agent HQ si vous êtes une équipe 100 % GitHub. Dépôts, Actions, pull requests et abonnements Copilot, sans travail significatif en dehors de cet écosystème. Dans ce monde, Agent HQ est le chemin le plus court entre une tâche et une branche révisée, et ajouter une autre couche serait une surcharge dont vous n'avez pas besoin. Le hub a une portée complète parce que le travail n'a qu'un seul foyer.
Utilisez une couche neutre lorsque votre équipe mélange outils de suivi, hébergeurs et runtimes. Dès que votre réalité inclut un tableau Jira, un dépôt GitLab ou des agents tournant sur des Computers que vous contrôlez en dehors du cloud de GitHub, ce qui vous manque n'est pas davantage d'agents. C'est un enregistrement partagé. Vous avez besoin d'une seule Task qui contient l'objectif, le diff, la discussion et la revue humaine, quel que soit l'hébergeur, l'outil de suivi ou le runtime qui a réalisé le travail. C'est le rôle d'une couche qui se situe au-dessus de chaque outil, et non à l'intérieur de l'un d'eux.
C'est le même embranchement que rencontrent les développeurs avec n'importe quel hub mono-fournisseur, que nous abordons pour le cas des éditeurs dans les agents en arrière-plan de Cursor, expliqués, et pour les tableaux locaux dans le guide des alternatives à Vibe Kanban. L'orchestration mono-écosystème est confortable, jusqu'au moment où l'écosystème ne raconte plus toute l'histoire.
Où se situe Sharkly : la couche neutre autour de chaque runtime et de chaque outil de suivi
Sharkly ne remplace ni GitHub, ni Copilot, ni Claude Code, ni Codex, ni les autres outils d'exécution. Il ajoute la Task partagée, le Computer, le contexte, le contrôle et la couche de revue autour des outils que votre équipe utilise déjà. Cette phrase résume toute la relation, alors lisez-la deux fois. Vous gardez GitHub. Vous gardez Agent HQ là où il convient. Sharkly est ce qui coordonne la flotte lorsque la flotte est plus grande qu'un seul écosystème.
La répartition des rôles est claire. GitHub, Copilot, Claude Code, Codex et les outils similaires assurent l'exécution. Sharkly gère l'assignation au niveau de l'équipe, les Computers connectés, le contexte des Tasks, la progression, les blocages, les résultats et la revue humaine à travers ces outils. Les agents recherchent, exécutent, testent et font leur rapport. Les personnes donnent la direction, accordent l'autorité et acceptent le résultat. L'automatisation s'arrête là où le jugement de l'équipe est requis.
Concrètement, une Task dans Sharkly est l'unité de travail principale, et elle regroupe en un seul endroit tout ce qui concerne un travail. Vous l'assignez à un Agent qui tourne sur un Computer que vous contrôlez, avec le Runtime de votre choix. L'exécution, les blocages, les résultats et les discussions de suivi reviennent dans la chronologie de la Task, au lieu de se disperser entre le cloud d'une plateforme, un outil de suivi séparé et une poignée de terminaux privés. L'objectif, le diff, la discussion et la revue de chaque exécution restent ensemble, que cette exécution ait eu lieu via Agent HQ dans GitHub, via Claude Code sur le Computer d'un collègue, ou via un outil que vous adopterez l'année prochaine.
Et il ne vous demande de reconstruire quoi que ce soit. Conservez les projets, les tâches, les statuts et les workflows que votre équipe comprend déjà, connectez Sharkly aux outils de suivi et aux hébergeurs que vous utilisez déjà, et commencez à router le travail sans reconstruire le processus que votre équipe emploie déjà. L'utilisation des modèles continue via les abonnements ou les clés API configurés dans ces outils, de sorte que vous apportez votre propre abonnement et Sharkly ajoute la coordination par-dessus. Si vous découvrez la plateforme, découvrez Sharkly présente les idées clés, et le tutoriel de la première tâche montre la plus petite version utile de bout en bout. Vous pouvez télécharger Sharkly et connecter un Computer pour l'essayer sur du travail réel.
Erreurs courantes à éviter
- Supposer que « neutre vis-à-vis des fournisseurs » signifie « neutre vis-à-vis des outils ». Agent HQ est ouvert quant à l'agent qui réalise le travail, et c'est une vraie force. Il n'est pas ouvert quant à l'endroit où vit le travail. Les agents opèrent toujours à l'intérieur de GitHub. Lisez la frontière comme une frontière d'écosystème, pas de fabricant de modèles.
- Adopter le hub d'un écosystème comme s'il constituait toute votre stratégie. Si vous standardisez sur Agent HQ aujourd'hui et que vous conservez un dépôt GitLab ou un tableau Jira au trimestre prochain, vous avez discrètement scindé votre surface de coordination. Décidez tôt si vous êtes réellement 100 % GitHub ou une équipe multi-outils.
- Traiter les pull requests comme la couche de coordination. Les pull requests sont une surface de revue, pas une couche d'assignation et de contexte. Qui est responsable de la Task, de quoi elle dépend et pourquoi elle est bloquée : rien de tout cela ne tient dans un diff.
- Oublier les agents qui ne touchent jamais au hub. Toute exécution lancée en dehors de GitHub, dans un terminal local ou sur un Computer que vous hébergez, n'apparaîtra pas dans Mission Control. Comptez ces exécutions avant de déclarer qu'un seul hub est votre source de vérité unique.
GitHub Agent HQ face à une couche d'orchestration neutre
À lire comme une répartition des rôles, pas comme un tableau de scores.
| Dimension | GitHub Agent HQ | Couche neutre (Sharkly) |
|---|---|---|
| Quels agents il exécute | Claude, Codex, Google, Cognition, xAI | Claude Code, Codex, Gemini, OpenCode, et d'autres |
| Où vit le travail | Dépôts, Actions et pull requests GitHub | Tout hébergeur et outil de suivi que votre équipe connecte |
| Où tournent les agents | L'environnement cloud de GitHub | Les Computers que votre équipe connecte et contrôle |
| Surface de commande | Mission Control sur GitHub, VS Code, mobile, CLI | Assignation de Tasks, CLI, API REST |
| Outil de suivi | Natif GitHub | Se connecte à Jira, Linear et à l'outil de suivi que vous utilisez déjà |
| Enregistrement partagé entre les outils | À l'intérieur de l'écosystème GitHub | Une Task unique contenant contexte, progression, blocages, résultats |
| Idéal pour | Les équipes entièrement standardisées sur GitHub | Les équipes mélangeant hébergeurs, outils de suivi et runtimes |
| Relation | Un plan de contrôle au sein d'un écosystème | Une couche autour des outils que vous utilisez déjà |
Aucune colonne n'est « fausse ». Si vos réponses ligne par ligne tombent majoritairement dans la colonne de gauche, Agent HQ convient. Si elles dérivent vers la droite, en particulier sur les lignes « où vit le travail », « outil de suivi » et « enregistrement partagé », vous avez dépassé les capacités de l'orchestration mono-écosystème.
Points clés à retenir
- GitHub Agent HQ est un plan de contrôle au sein de GitHub, baptisé Mission Control, qui permet d'assigner, de piloter et de suivre des agents de codage de plusieurs fournisseurs dans le cadre d'un abonnement Copilot payant.
- Il le fait bien : choix d'agents neutre vis-à-vis des fournisseurs, un centre de commandement unique sur GitHub, VS Code, mobile et CLI, et un travail qui atterrit dans le flux de revue des pull requests auquel vous faites déjà confiance.
- Sa frontière, c'est l'écosystème, pas le fournisseur d'agents : il coordonne les agents qui travaillent à l'intérieur de GitHub, de sorte que les dépôts GitLab, les tableaux Jira et les agents tournant en dehors du cloud de GitHub restent en dehors.
- Utilisez Agent HQ lorsque vous êtes une équipe 100 % GitHub. Utilisez une couche neutre lorsque votre équipe mélange hébergeurs, outils de suivi et runtimes et a besoin d'un enregistrement partagé avec revue pour l'ensemble.
- Sharkly fonctionne aux côtés de GitHub, et non à sa place : gardez vos outils, apportez votre propre abonnement, et laissez chaque exécution revenir à une seule Task, de la demande à la livraison.
La prochaine étape est volontairement modeste. Connectez un Computer, créez un Agent et assignez-lui quelque chose d'ennuyeux. La documentation approfondit chaque concept sur docs.sharkly.ai.
FAQ
Qu'est-ce que GitHub Agent HQ en une phrase ? C'est un centre de commandement au sein de GitHub, baptisé Mission Control, qui assigne, pilote et suit des agents de codage de plusieurs fournisseurs dans le cadre d'un abonnement GitHub Copilot payant, les agents travaillant sur des branches et renvoyant des pull requests.
Quels agents peuvent tourner dans Agent HQ ? GitHub l'a ouvert aux agents de codage d'Anthropic, OpenAI, Google, Cognition et xAI, ce qui vous permet de choisir Claude pour une étape et Codex pour une autre sans quitter le hub. La liste exacte s'étoffe au fil du déploiement tout au long de 2026.
GitHub Agent HQ est-il gratuit ? Non. Il est fourni via un abonnement GitHub Copilot payant, avec une disponibilité liée à des offres comme Copilot Pro+ et Copilot Enterprise. Consultez les pages de GitHub pour les détails actuels des offres, car ils évoluent au fur et à mesure du déploiement.
Agent HQ fonctionne-t-il avec GitLab ou Jira ? Agent HQ coordonne les agents qui travaillent à l'intérieur de l'écosystème GitHub : dépôts, Actions et pull requests GitHub. Le travail sur GitLab ou Bitbucket, ainsi que la planification dans Jira ou Linear, restent en dehors. C'est une couche neutre au-dessus de chaque outil qui les relie. Consultez notre article explicatif sur les agents en arrière-plan de Cursor pour la version de cette même frontière liée à l'éditeur.
Dois-je remplacer GitHub pour utiliser Sharkly ? Non. Sharkly ne remplace ni GitHub ni aucun outil d'exécution. Il ajoute la Task partagée, le contexte et la couche de revue autour des outils que vous utilisez déjà, de sorte que GitHub, Copilot et Agent HQ continuent de fonctionner exactement comme avant.
Quand ne dois-je pas ajouter une couche d'orchestration par-dessus Agent HQ ? Si toute votre stack est GitHub — dépôts, Actions, pull requests et Copilot — sans travail significatif ailleurs, Agent HQ est peut-être toute l'orchestration dont vous avez besoin. Ajoutez une couche neutre uniquement lorsque vous exécutez plusieurs hébergeurs, outils de suivi ou runtimes et avez besoin d'un enregistrement partagé entre eux.
Sharkly change-t-il ma façon de payer les modèles ? Non. Vous apportez votre propre abonnement. L'utilisation des modèles continue via les abonnements ou les clés API configurés dans vos outils connectés, et le quota de modèles dépend des offres et des comptes API que votre équipe connecte.
Comment essayer l'approche par couche neutre sans grosse migration ? Commencez par le plus petit workflow utile : connectez un Computer, créez un Agent et assignez une Task à faible risque. Le tutoriel de la première tâche le détaille étape par étape, et l'exécution de plusieurs agents Claude Code en parallèle montre le côté flotte.
