Parler à Control Center depuis une PR GitHub

Ce guide vous montre comment travailler avec Control Center sans quitter GitHub : demandez une révision par IA depuis la page de la PR, posez une question au robot dans un commentaire et poursuivez la conversation dans ses fils de révision.

Le robot est la GitHub App de votre propre serveur — celle qui permet déjà aux gens de se connecter et qui exécute le travail en arrière-plan. Rien de nouveau n’est enregistré, et rien n’a besoin d’être accessible depuis Internet : le serveur découvre ce qui a été dit sur GitHub par interrogation périodique, de sorte qu’un ordinateur portatif 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 de permissions de ce guide
Le dépôt est lié à un espace de travail dans Control Center
Aucune URL de webhook, aucun tunnel, aucun rappel — il n’y a rien à configurer du côté du réseau

Trouver le nom de votre robot

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

Allez dans 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 une fois le champ rempli. S’il affiche encore l’indice vide, l’identifiant de connexion est toujours <appslug>[bot] — saisissez-le, ou la forme courte @appslug

GitHub n’offre pas les comptes d’application dans sa saisie semi-automatique @, l’identifiant de connexion doit donc être tapé à la main — c’est pourquoi la carte de paramètres le copie en un clic. Le suffixe [bot] est facultatif : @myapp et @myapp[bot] joignent tous deux le robot.

Demander une révision depuis GitHub

Deux façons, qui démarrent toutes deux le même pipeline pr_review préamorcé que lance le bouton Ask AI :

Ajoutez l’étiquette ai-review à la PR. C’est ce que GitHub offre de plus proche d’une affectation du robot comme relecteur — les comptes d’application ne peuvent pas occuper l’emplacement natif de relecteur demandé. Aucun commentaire ne permet de réagir, donc rien n’est publié sur GitHub ; la révision démarre dans Control Center
Commentez @myapp review (ou simplement @myapp) dans la conversation de la PR. Le robot réagit avec 👀, puis répond quand la révision a démarré (ou qu’une révision est déjà en cours)

Les relecteurs travaillent dans l’espace de révision de la PR ; lisez et publiez les constats comme dans Utiliser la révision assistée par IA. La publication vers GitHub demeure une décision que vous prenez dans Control Center — lancer une révision depuis GitHub ne publie rien sur GitHub en soi.

L’étiquette se déclenche une seule fois par PR : l’ajouter constitue la demande, et elle n’est pas réarmée si on la retire puis la remet. Pour relancer une révision — après un push, par exemple —, mentionnez le robot.

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 robot réagit avec 👀, ce qui vous confirme que le commentaire a été vu
La question est publiée dans l’espace de révision de la PR en votre nom — la même attribution que si vous l’aviez saisie dans Control Center
Un agent répond dans l’espace, et la réponse est publiée dans la PR sous forme de commentaire qui vous @-mentionne

Une question sur une PR encore sans révision réveille l’agent principal (CEO) de l’espace de travail ; une fois qu’une révision a eu lieu, c’est l’agent qui a parlé en dernier qui répond, de sorte que les relances aboutissent chez la personne qui a le contexte.

Donner suite dans un fil de révision

Répondez dans un fil de révision en ligne auquel le robot participe — un commentaire de 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 révision comme 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 a donc toujours besoin d’une @mention.

À qui le robot parle

Un commentaire GitHub n’arrive guère avec plus qu’un identifiant de connexion ; le robot 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, à partir de 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 de connexion inconnu (non lié, ou lié mais sans appartenance ici) et un rôle en lecture seule sont les deux cas —, et ses propos n’entrent jamais dans l’espace de travail. L’étiquette ai-review n’est pas assujettie à cette vérification : elle n’a pas d’auteur, elle démarre donc la révision dans l’espace de travail qui lie déjà le dépôt.

À quoi s’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 sur lequel réagir
Réponses	Publiées en tant que le robot (l’application), dans la voie 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
Révisions	Les constats arrivent dans l’espace de révision ; la publication vers GitHub est manuelle

Le délai 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 l’arrêt est rattrapé au balayage suivant.

Dépannage

Rien ne se produit pour un commentaire qui mentionne le robot.

L’application est-elle installée sur le compte qui possède le dépôt, et le dépôt est-il lié à un espace de travail ? Un dépôt non lié est ignoré avant que quoi que ce soit soit consigné, 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 dans la PR la réponse de refus du robot — elle indique lequel des deux cas s’applique
Toujours rien ? Le journal du serveur nomme le balayage et la PR quand quelque chose échoue ; cherchez pr_conversation: (l’interrogateur périodique) et github_pr_conversation: (la passerelle)

L’étiquette ne démarre pas de révision.

Elle se déclenche une seule fois par PR. Si une révision a déjà eu lieu, ou si l’étiquette a été ajoutée avant que le serveur ait vu la PR (le premier balayage consigne l’arriéré en silence plutôt que de le déclencher d’un coup), mentionnez plutôt le robot — @myapp review en démarre toujours une, à moins qu’une révision soit déjà en cours.

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

La réponse elle-même n’est jamais perdue — elle se trouve dans l’espace de révision de la PR, dans Control Center. Un échec de publication (GitHub indisponible, permissions modifiées) est consigné 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 le robot est issu
Utiliser la révision assistée par IA : lire les constats que produit une révision lancée par mention
Configurer l’intégration GitHub : lier votre propre compte GitHub, ce par quoi le robot vous résout
Utiliser les espaces : l’espace où tout cela aboutit