Parler à Control Center depuis une PR GitHub

Ce guide explique comment travailler avec Control Center sans quitter GitHub : demandez une revue par IA depuis la page de la PR, posez une question au bot dans un commentaire, et poursuivez la conversation dans ses fils de revue.

Le bot est la GitHub App propre à votre serveur — celle qui permet déjà aux utilisateurs de se connecter et exécute le travail en arrière-plan. Rien de nouveau n’est enregistré, et rien n’a besoin d’être joignable depuis Internet : le serveur découvre ce qui a été dit sur GitHub par sondage, si bien qu’un ordinateur portable derrière un NAT se comporte exactement comme un déploiement public.

Prérequis

Le serveur a sa GitHub App enregistrée et installée, avec Pull requests: read and write (pour les commentaires, les fils et les réactions) et Issues: read (pour la recherche de commentaires). Les deux figurent déjà dans la liste des autorisations de ce guide
Le dépôt est lié à un espace de travail dans Control Center
Ni URL de webhook, ni tunnel, ni callback — il n’y a rien à configurer côté réseau

Trouver le nom de votre bot

L’identifiant de connexion du bot est <appslug>[bot], où appslug est le nom que vous avez donné à l’application au moment de l’enregistrer.

Ouvrez Paramètres → Serveur → Authentification unique et faites défiler jusqu’à la carte Applications fournisseur
Ouvrez le bloc GitHub et cliquez sur Tester
Copiez Login du bot lorsqu’il se remplit. S’il affiche encore l’indice du champ vide, l’identifiant est toujours <appslug>[bot] — saisissez-le, ou bien la forme courte @appslug

GitHub ne propose pas les comptes d’application dans son autocomplétion @, l’identifiant doit donc être saisi à la main — c’est pourquoi la carte de paramètres le rend copiable en un clic. Le suffixe [bot] est facultatif : @myapp et @myapp[bot] s’adressent tous deux au bot.

Demander une revue depuis GitHub

Deux moyens, qui lancent tous deux le même pipeline pr_review amorcé que le bouton Ask AI :

Ajoutez l’étiquette ai-review à la PR. C’est ce que GitHub propose de plus proche d’une affectation du bot comme relecteur — les comptes d’application ne peuvent pas occuper le créneau natif de relecteur demandé. Il n’y a aucun commentaire auquel réagir, donc rien n’est publié sur GitHub ; la revue démarre dans Control Center
Commentez @myapp review (ou simplement @myapp) dans la conversation de la PR. Le bot réagit avec 👀, puis répond lorsque la revue a démarré (ou qu’une revue est déjà en cours)

Les relecteurs travaillent dans l’espace de revue de la PR ; lisez et publiez les constats comme dans Utiliser la revue assistée par IA. La publication vers GitHub reste une décision que vous prenez dans Control Center — lancer une revue depuis GitHub ne publie rien sur GitHub de lui-même.

L’étiquette ne se déclenche qu’une fois par PR : l’ajouter constitue la demande, et elle n’est pas réarmée lorsqu’on la retire puis la rajoute. Pour relancer une revue — après un push, par exemple — mentionnez le bot.

Poser une question

Commentez dans la conversation de la PR :

@myapp why does the flaky test in runner_test.dart fail on CI but not locally?

Ce qui se passe, dans l’ordre :

Le bot réagit avec 👀 pour vous montrer que le commentaire a été vu
La question est publiée dans l’espace de revue de la PR en votre nom — même attribution que si vous l’aviez saisie dans Control Center
Un agent répond dans l’espace, et la réponse est renvoyée sur la PR sous forme de commentaire qui vous @-mentionne

Une question sur une PR qui n’a pas encore de revue réveille l’agent CEO de l’espace de travail ; une fois qu’une revue a tourné, c’est l’agent qui a parlé en dernier qui répond, donc les relances aboutissent chez qui détient le contexte.

Poursuivre dans un fil de revue

Répondez à l’intérieur d’un fil de revue en ligne auquel le bot participe — un commentaire sur le diff qu’il a laissé, ou une réponse qu’il a publiée dans ce fil. Aucune mention n’est nécessaire ; le fil est l’adressage :

> @myapp the retry loop looks O(n²) to me

what would the complexity be with the bounded queue instead?

Les échanges à plusieurs tours fonctionnent de la même façon : chaque réponse est une nouvelle question dans la même conversation, avec l’espace de revue pour contexte, et la réponse revient dans le fil.

Une relance dans la chronologie de la conversation de la PR constitue un nouveau commentaire de premier niveau, elle nécessite donc toujours une @mention.

À qui le bot s’adresse

Un commentaire GitHub n’arrive guère avec autre chose qu’un identifiant de connexion, le bot résout donc l’auteur avant de faire quoi que ce soit :

Votre compte GitHub doit être lié à votre identité dans Control Center — connectez-vous avec GitHub, ou collez un jeton, depuis Paramètres → Espace de travail → Profil et identité → Hébergement de code
Vous devez être membre avec un rôle d’écriture (member, admin ou owner) dans l’espace de travail qui lie le dépôt

Toute autre personne reçoit une seule réponse courtoise expliquant ce qui manque — un identifiant inconnu (non lié, ou lié mais pas membre ici) et un rôle en lecture seule constituent les deux cas — et ses propos n’entrent jamais dans l’espace de travail. L’étiquette ai-review n’est pas soumise à cette condition : elle n’a pas d’auteur, elle lance donc la revue dans l’espace de travail qui lie déjà le dépôt.

Ce à quoi vous attendre

Élément	Comportement
Accusé de réception	👀 sur un commentaire en une minute environ — l’intervalle de balayage. L’étiquette `ai-review` n’a aucun commentaire auquel réagir
Réponses	Publiées en tant que bot (l’application), dans le fil où la question a été posée
Attribution dans l’espace	La question est la vôtre ; l’agent s’exécute en votre nom, selon les réglages d’autonomie de l’espace
Revues	Les constats arrivent dans l’espace de revue ; la publication vers GitHub est manuelle

Cette latence d’environ une minute est le prix à payer pour n’avoir besoin d’aucun accès réseau entrant. Rien dans le balayage n’est urgent, et rien n’est perdu pendant que le serveur est hors ligne — un commentaire qui arrive pendant une interruption est rattrapé au balayage suivant.

Dépannage

Rien ne se passe pour un commentaire qui mentionne le bot.

L’application est-elle installée sur le compte qui possède le dépôt, et le dépôt lié à un espace de travail ? Un dépôt non lié est ignoré avant que quoi que ce soit ne soit enregistré, donc le lier plus tard livre quand même le commentaire
Votre compte GitHub est-il lié, et êtes-vous membre avec un rôle d’écriture ? Cherchez sur la PR la réponse de refus du bot — elle indique lequel
Toujours rien ? Le journal du serveur nomme le balayage et la PR en cas d’échec ; cherchez pr_conversation: (l’interrogateur) et github_pr_conversation: (la passerelle)

L’étiquette ne lance pas de revue.

Elle ne se déclenche qu’une fois par PR. Si une revue a déjà tourné, ou si l’étiquette a été ajoutée avant que le serveur n’ait jamais vu la PR (le premier balayage enregistre l’arriéré en silence au lieu de le traiter en rafale), mentionnez plutôt le bot — @myapp review en lance toujours une, sauf si une revue est déjà en cours.

La réponse du bot n’est jamais arrivée sur GitHub.

La réponse elle-même n’est jamais perdue — elle se trouve dans l’espace de revue de la PR, dans Control Center. Un échec de publication (GitHub indisponible, autorisations modifiées) est journalisé et la réponse n’est pas réessayée ; reposez la question dans le fil si cela compte.

Guides connexes

Créer la GitHub App : l’enregistrement dont naît le bot
Utiliser la revue assistée par IA : lire les constats que produit une revue lancée par une mention
Configurer l’intégration GitHub : lier votre propre compte GitHub, sur lequel le bot s’appuie pour vous identifier
Utiliser les espaces : le lieu où tout cela aboutit