Utiliser la révision assistée par IA

Ce guide vous montre comment faire relire une demande de tirage par des agents relecteurs, puis comment publier le résultat sur GitHub.

Lancer une révision par IA

Ouvrez la PR et allez à son onglet Aperçu
Ouvrez le menu de débordement ⋯ de la rangée d’actions et choisissez Ask AI

L’élément n’apparaît que tant que la PR est ouverte — c’est une action qui précède la fusion. Le même bouton est offert sous le libellé Ask AI dans l’état vide de l’onglet Revue, avant qu’une révision n’existe.

Control Center démarre le pipeline préconfiguré pr_review et ouvre l’onglet Revue de la PR pour que vous puissiez le suivre. Le pipeline :

Ouvre l’espace de révision propre à la PR, dont l’arbre de travail isolé a la PR extraite à sa tête
Déploie les relecteurs selon le niveau de revue de l’espace de travail — trois par défaut (les agents préconfigurés qa, architect et engineer, en parallèle). Il n’y a aucune détection de langue ni de domaine
Demande à l’agent principal (CEO) de consolider leurs constats en un parcours guidé
Finalise : classe les constats dans des catégories de consensus et calcule le verdict. Quand l’association atteint awaiting approval, Publier sur GitHub apparaît dans l’onglet Revue

La profondeur de la révision dépend du niveau de revue de l’espace de travail — light (un relecteur), balanced (trois, par défaut) ou thorough (les cinq, en ajoutant les spécialistes de la sécurité et de la performance) — réglé dans Paramètres → Espace de travail → Général, sur la carte Règles de l’espace de travail. Un niveau plus léger consigne tout autant de constats ; il en signale simplement moins au premier plan.

Tous les relecteurs publient dans l’espace de révision unique de la PR, et c’est ce qui rend leurs constats comparables. Voir Révision par IA pour comprendre comment les pièces s’assemblent.

pr_review n’est livré qu’avec un déclencheur manuel. Pour qu’il se lance à chaque PR publiée, ajoutez vous-même un déclencheur — voir Lancer des agents relecteurs. Vous pouvez aussi lancer une révision depuis GitHub même, sans déclencheur de pipeline : mentionnez le bot du serveur sur la PR ou ajoutez l’étiquette ai-review — voir Parler à Control Center depuis une PR GitHub.

Si une notification indique qu’une révision est déjà en cours pour cette demande de tirage, c’est qu’une révision est déjà lancée ; restez dans l’onglet Revue ou ouvrez Pipelines pour la trouver.

Lire les constats

Les relecteurs consignent leurs constats sous forme de nœuds de révision dans l’espace de révision. Chacun comporte :

Champ	Description
Type	`bug`, `suggestion`, `recommendation`, `question` ou `ticket`
Priorité	P0 (critique) → P3 (détail mineur)
Catégorie	`security`, `stability`, `data_integrity`, `correctness`, `performance` ou `maintainability`
Fichier et ligne	Où le constat est ancré
Code d’origine	Le code que vise le constat
Code suggéré	La correction proposée
Confiance	Le degré de confiance du relecteur
Statut	`open` → `consensus-ready` → `resolved` ou `dismissed`

Un constat n’atteint consensus-ready qu’une fois qu’un relecteur pair l’a confirmé. Un agent ne peut pas confirmer son propre constat : l’avis d’un seul relecteur ne progresse donc jamais tout seul.

L’onglet Revue affiche la liste des constats, filtrable par type et par statut, avec un commutateur pour les constats rejetés, à côté de l’artéfact publié par l’agent qui a consolidé. La vue déterministe — cohortes, tableau de bord multi-axes, diffs de contrat et visuels — est calculée côté serveur, mais n’a aucune interface dans l’appli ; voir Calcul de révision pour ce que produit cette passe.

Consulter le panneau des désaccords

Quand deux relecteurs ancrent des constats au même fichier et à la même ligne, mais les évaluent très différemment — des priorités séparées par deux niveaux ou plus, ou l’un qui parle d’un bug alors que l’autre parle d’une suggestion —, un panneau de désaccords apparaît au-dessus de la liste des constats. Lisez-les en premier : c’est là que les avis des relecteurs divergent et que votre jugement vaut le plus.

Lire le verdict

Quand l’agent principal finalise, il calcule un verdict :

Verdict	Signification
Ship	Rien de bloquant n’a été trouvé
Hold	Des problèmes à régler avant la fusion
Block	Des problèmes critiques qui doivent être corrigés

Le verdict s’accompagne d’un score de confiance global et du nombre de constats par priorité.

Les axes de révision s’y intègrent ensuite, et ils ne peuvent que le rendre plus sévère. Un axe verrouillé qui échoue force Block ; un axe verrouillé qui n’a pas pu se terminer (partial) ou qui n’a pas pu s’exécuter du tout (unavailable) force au moins Hold. L’absence de preuve ne lève jamais un verrou.

Publier la révision sur GitHub

La publication est une étape distincte, délibérément contrôlée par l’utilisateur. Le pipeline pr_review garde la révision dans Control Center ; il ne publie rien sur GitHub.

Dans l’onglet Revue, attendez que Publier sur GitHub apparaisse
Appuyez sur Publier sur GitHub

Control Center envoie une seule révision GitHub. Les constats déjà résolus ou rejetés sont ignorés. Le bouton inclut tous les constats ouverts restants et, sur Ship, soumet APPROVE. (L’outil MCP publish_review_to_github se limite toujours par défaut aux constats confirmés par un pair et n’approuve pas, à moins que vous ne passiez approve_on_ship.) Les constats qui portent un ancrage de fichier et de ligne deviennent des commentaires en ligne ; tout le reste est regroupé dans le corps du résumé, chacun accompagné d’une mention « — Control Center AI review » pour que la source soit sans ambiguïté. Un verdict Block est soumis comme REQUEST_CHANGES ; Hold comme COMMENT ; Ship comme APPROVE à partir de ce bouton. Une notification affiche alors Publié. La révision est publiée sous l’identité d’application du serveur.

Si GitHub rejette un ancrage en ligne parce que la ligne ne fait pas partie du diff, la révision entière est renvoyée avec chaque constat regroupé dans le corps, de sorte que rien ne disparaît en silence.

D’autres pipelines intégrés publient, eux, directement sur GitHub : cross_review, pr_triage, ticket_to_pr et pre_merge_gate se terminent chacun par une étape de commentaire. Seul pr_review retient sa sortie pour vous.

Lancer vous-même les relecteurs

Pour choisir quels rôles révisent la PR et quels fichiers chacun examine, utilisez l’outil MCP dispatch_reviewers dans un espace de révision existant, ou ajoutez des nœuds de relecteur à un pipeline. Les deux méthodes, avec la signature exacte de l’outil, sont décrites dans Lancer des agents relecteurs.